From owner-freebsd-stable@FreeBSD.ORG Sun Jan 17 00:24: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 D270A1065679 for ; Sun, 17 Jan 2010 00:24:24 +0000 (UTC) (envelope-from thomas.e.zander@googlemail.com) Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by mx1.freebsd.org (Postfix) with ESMTP id AECF58FC0A for ; Sun, 17 Jan 2010 00:24:24 +0000 (UTC) Received: by pwi15 with SMTP id 15so1114952pwi.3 for ; Sat, 16 Jan 2010 16:24:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type; bh=c70x4CG3aOtY9NIGD2j7xBW2SZXNt0xmYAXt8be6IWU=; b=cCgye5xEp/CZxvcOGTHO0l9L7lhPdXQ2gMD7uvmhItZz9eC8C5uFbZkFicHOvWyibs /80WJhOL3+KRyjoauIR+1reafRui812o4rNRxCkdCgtPpktlCEwgdgYGK35KlZDCtS08 7ys0p7asyFw91z9duNSNOBIraGhSZC5msIpyg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=J4DlbEVj0CsCJ3BmYNCcP5R4CMrup+M6kcf12H661SzdCyu6f0EwxFgqUEuyM2lr1g u5EmEeqeRkVzVeegLePVKFytxBcuABPMnEOXsQtkl6XuJCn9JyOY4Tp2Ca44rWWhjUB1 CDkALLZ5wPa1iaziTftDW0TZodrSv3mq/ZVOQ= MIME-Version: 1.0 Received: by 10.141.187.14 with SMTP id o14mr3051974rvp.189.1263686081046; Sat, 16 Jan 2010 15:54:41 -0800 (PST) Date: Sun, 17 Jan 2010 00:54:41 +0100 Message-ID: <786602c61001161554s79a33401n9700048d4a4c74fb@mail.gmail.com> From: Thomas Zander To: freebsd-stable Content-Type: text/plain; charset=ISO-8859-1 Subject: buildworld WITH_CTF=1 breaks cc1plus on STABLE? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Jan 2010 00:24:24 -0000 Good evening, I am observing that doing a buildworld on stable (r202448) with WITH_CTF=1 breaks /usr/libexec/cc1plus on my amd64. Doing so causes cc1plus to crash with internal errors and ports like devel/popt don't even make it through the configure stage ("fails sanity check"). Is this behaviour expected? Is it discouraged to build world WITH_CTF? Regards. Riggs From owner-freebsd-stable@FreeBSD.ORG Sun Jan 17 00:52: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 355EA1065670 for ; Sun, 17 Jan 2010 00:52:27 +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 1B9A48FC12 for ; Sun, 17 Jan 2010 00:52:27 +0000 (UTC) Received: from localhost ([127.0.0.1] helo=rmac.psg.com) by ran.psg.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NWJNS-000CcZ-5v; Sun, 17 Jan 2010 00:52:26 +0000 Received: from rmac.psg.com.psg.com (localhost [127.0.0.1]) by rmac.psg.com (Postfix) with ESMTP id 5DB732D3AE79; Sun, 17 Jan 2010 09:52:25 +0900 (JST) Date: Sun, 17 Jan 2010 09:52:24 +0900 Message-ID: From: Randy Bush To: Russell Yount In-Reply-To: References: <4B50E33A.7090001@menhennitt.com.au> 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: freebsd-stable@freebsd.org Subject: Re: recommended miniPCI 802.11a/b/g card for Soekris net5501 running FreeBSD 8-STABLE? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Jan 2010 00:52:27 -0000 for about two years, i have been using the Metrix CM9 miniPCI () on freebsd 8 on a 5501 and have been happy with it randy From owner-freebsd-stable@FreeBSD.ORG Sun Jan 17 01:48:30 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from alona.my.domain (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with ESMTP id 6B571106566B; Sun, 17 Jan 2010 01:48:28 +0000 (UTC) (envelope-from davidxu@freebsd.org) Message-ID: <4B526C69.6050300@freebsd.org> Date: Sun, 17 Jan 2010 09:48:25 +0800 From: David Xu User-Agent: Thunderbird 2.0.0.21 (X11/20090522) MIME-Version: 1.0 To: Tijl Coosemans References: <4B4D0293.3040704@rogers.com> <201001140941.46748.tijl@coosemans.org> <4B4FC56A.4020007@freebsd.org> <201001161451.39399.tijl@coosemans.org> In-Reply-To: <201001161451.39399.tijl@coosemans.org> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit Cc: Kostik Belousov , Gardner Bell , freebsd-stable@freebsd.org Subject: Re: process in STOP state X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 17 Jan 2010 01:48:30 -0000 Tijl Coosemans wrote: > On Friday 15 January 2010 02:31:22 David Xu wrote: > >> Tijl Coosemans wrote: >> >>>> Besides weird formatting of procstat -k output, I do not see >>>> anything wrong in the state of the process. It got SIGSTOP, I am >>>> sure. Attaching gdb helps because debugger gets signal reports >>>> instead of target process getting the signal actions on signal >>>> delivery. >>>> >>>> The only question is why the process gets SIGSTOP at all. >>>> >>> Wine uses ptrace(2) sometimes. The SIGSTOP could have come from >>> that. I recently submitted >>> http://www.freebsd.org/cgi/query-pr.cgi?pr=142757 describing a >>> problem with ptrace and signals, so you might want to give the >>> kernel patch a try. >>> >> The problem in your patch is that ksi pointer can not be hold across >> thread sleeping, because once the process is resumed, there is no >> guarantee that the thread will run first, once the signal came from >> process's signal queue, other threads can remove the signal, and here >> your sigqueue_take(ksi) is dangerous code. >> > > If other threads can run before the current thread then there's a > second problem next to the one in the PR (current thread deletes > signal that shouldn't be deleted). Then those other threads can see > that the SIGSTOP bit (or another signal) is still set and stop the > process a second time. This might be what happens in the OP's case. > > So, the signal has to be cleared before suspending the process, but > then other threads can still deliver other signals which might change > delivery order and I don't see any way around that besides introducing > a per process signal lock that is also kept while the process is > stopped. Comments? > > I don't have an idea now, we ever delivered signal to thread's queue, though it may lose signal if thread exits, but it does not have the problem you have described here, we may need to rethink how to fix the signal-lost problem but still deliver signal to thread's queue, just an idea. From owner-freebsd-stable@FreeBSD.ORG Sun Jan 17 06: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 7CFB8106566B for ; Sun, 17 Jan 2010 06:47:38 +0000 (UTC) (envelope-from jonc@chen.org.nz) Received: from chen.org.nz (ip-58-28-152-174.static-xdsl.xnet.co.nz [58.28.152.174]) by mx1.freebsd.org (Postfix) with ESMTP id 366678FC0C for ; Sun, 17 Jan 2010 06:47:38 +0000 (UTC) Received: by chen.org.nz (Postfix, from userid 1000) id B8A83E044E; Sun, 17 Jan 2010 19:47:33 +1300 (NZDT) Date: Sun, 17 Jan 2010 19:47:33 +1300 From: Jonathan Chen To: freebsd-stable@freebsd.org Message-ID: <20100117064733.GA3119@osiris.chen.org.nz> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.3i Subject: Drive light on all the time on 8-STABLE. X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Jan 2010 06:47:38 -0000 Hi, On the weekend, I moved my 8-STABLE installation (csup'd late Dec 2009) onto a new drive, a Seagate ST31000528AS CC3; and while the transfer was successful, I've noticed that the drive light is solidly on all the time, even if it boots into single-user. # uname -a FreeBSD osiris.chen.org.nz 8.0-STABLE FreeBSD 8.0-STABLE #1: Sat Jan 16 08:32:54 NZDT 2010 root@:/usr/obj/usr/src/sys/OSIRIS amd64 Is this something I should be worried about? There doesn't appear to be any disk I/O (I can't hear the disk grinding), but I may be wrong. The drive from which I transferred from did not exhibit this strange behaviour. Any advice would be welcome. Cheers. -- Jonathan Chen ---------------------------------------------------------------------- "The things we know best are the things we haven't been taught." - Marquis de Vauvenargues From owner-freebsd-stable@FreeBSD.ORG Sun Jan 17 10:28: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 810071065672 for ; Sun, 17 Jan 2010 10:28:07 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-fx0-f227.google.com (mail-fx0-f227.google.com [209.85.220.227]) by mx1.freebsd.org (Postfix) with ESMTP id 12CE78FC13 for ; Sun, 17 Jan 2010 10:28:06 +0000 (UTC) Received: by fxm27 with SMTP id 27so1407803fxm.3 for ; Sun, 17 Jan 2010 02:28:06 -0800 (PST) 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 :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=dPFWA50Jdkq4GoBaDC1/mDKM4ASalByB+A4Unh1FHxk=; b=UOLyuWx9C9rp76sb6weqjrJNZ/t6bpHvSeHG3+w9rsm4qTJyS/Xw0LisLo19Vx70mU D7ZCb7agHH5EAdepUmIUFroipswRz08V5Cu6jrw/GUhKW+HSmRjIniocbDBYqc+jzUnU frin7slXi/Ar8rY/5Vij3vXpT45LTUcmQ5030= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=O9RQX9RQmz31/+vApVJz9IDWkcPPwpK8+KZ0KVcXW6+GNo9wv3M8X2D1G82Z+OudDz HZouck5pwJkY3kGZKouxEnGO/VI/veuRQG8l0VCihuzwiaeHUeDaqboMI15oYWssiS6B WFHEPjvcD/cpWIoaF39l8d5K0NA83aW/wcfRw= Received: by 10.223.3.27 with SMTP id 27mr657626fal.8.1263724085896; Sun, 17 Jan 2010 02:28:05 -0800 (PST) Received: from mavbook.mavhome.dp.ua (pc.mavhome.dp.ua [212.86.226.226]) by mx.google.com with ESMTPS id 14sm1494544fxm.11.2010.01.17.02.28.05 (version=SSLv3 cipher=RC4-MD5); Sun, 17 Jan 2010 02:28:05 -0800 (PST) Sender: Alexander Motin Message-ID: <4B52E634.8010609@FreeBSD.org> Date: Sun, 17 Jan 2010 12:28:04 +0200 From: Alexander Motin User-Agent: Thunderbird 2.0.0.23 (X11/20091212) MIME-Version: 1.0 To: Jonathan Chen References: <1263723781.00208012.1263711003@10.7.7.3> In-Reply-To: <1263723781.00208012.1263711003@10.7.7.3> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org Subject: Re: Drive light on all the time on 8-STABLE. X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Jan 2010 10:28:07 -0000 Jonathan Chen wrote: > On the weekend, I moved my 8-STABLE installation (csup'd late Dec 2009) > onto a new drive, a Seagate ST31000528AS CC3; and while the transfer was > successful, I've noticed that the drive light is solidly on all the time, > even if it boots into single-user. > > # uname -a > FreeBSD osiris.chen.org.nz 8.0-STABLE FreeBSD 8.0-STABLE #1: Sat Jan 16 08:32:54 NZDT 2010 root@:/usr/obj/usr/src/sys/OSIRIS amd64 > > Is this something I should be worried about? There doesn't appear to > be any disk I/O (I can't hear the disk grinding), but I may be wrong. > The drive from which I transferred from did not exhibit this strange > behaviour. > > Any advice would be welcome. What disk controller and driver do you use? -- Alexander Motin From owner-freebsd-stable@FreeBSD.ORG Sun Jan 17 13: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 780EE106566B for ; Sun, 17 Jan 2010 13:04:53 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (skuns.zoral.com.ua [91.193.166.194]) by mx1.freebsd.org (Postfix) with ESMTP id A3FB08FC14 for ; Sun, 17 Jan 2010 13:04:51 +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 o0HD4lUX073754 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 17 Jan 2010 15:04:47 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.3/8.14.3) with ESMTP id o0HD4lwv041253; Sun, 17 Jan 2010 15:04:47 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.3/8.14.3/Submit) id o0HD4lP8041252; Sun, 17 Jan 2010 15:04:47 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Sun, 17 Jan 2010 15:04:47 +0200 From: Kostik Belousov To: Thomas Zander Message-ID: <20100117130447.GC62907@deviant.kiev.zoral.com.ua> References: <786602c61001161554s79a33401n9700048d4a4c74fb@mail.gmail.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="KjcUHqqCp23GY06r" Content-Disposition: inline In-Reply-To: <786602c61001161554s79a33401n9700048d4a4c74fb@mail.gmail.com> 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=-4.4 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: freebsd-stable Subject: Re: buildworld WITH_CTF=1 breaks cc1plus on STABLE? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Jan 2010 13:04:54 -0000 --KjcUHqqCp23GY06r Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Jan 17, 2010 at 12:54:41AM +0100, Thomas Zander wrote: > Good evening, >=20 > I am observing that doing a buildworld on stable (r202448) with > WITH_CTF=3D1 breaks /usr/libexec/cc1plus on my amd64. Doing so causes > cc1plus to crash with internal errors and ports like devel/popt don't > even make it through the configure stage ("fails sanity check"). > Is this behaviour expected? Is it discouraged to build world WITH_CTF? WITH_CTF=3D1 results in the broken static binaries after strip(1). Do not use it (yet) for buildworld. --KjcUHqqCp23GY06r Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (FreeBSD) iEYEARECAAYFAktTCu4ACgkQC3+MBN1Mb4jCrACgnNR5oOXsz+YACSwAX/LETRpN zI4AnAoC9/92eFy8MdIz2jwo0txZHrWg =GrN7 -----END PGP SIGNATURE----- --KjcUHqqCp23GY06r-- From owner-freebsd-stable@FreeBSD.ORG Sun Jan 17 13:32: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 B803F106566B for ; Sun, 17 Jan 2010 13:32:27 +0000 (UTC) (envelope-from ronald-freebsd8@klop.yi.org) Received: from smtp-out0.tiscali.nl (smtp-out0.tiscali.nl [195.241.79.175]) by mx1.freebsd.org (Postfix) with ESMTP id 4B4768FC14 for ; Sun, 17 Jan 2010 13:32:27 +0000 (UTC) Received: from [212.123.145.58] (helo=sjakie.klop.ws) by smtp-out0.tiscali.nl with esmtp (Exim) (envelope-from ) id 1NWVEw-0006Qj-6V; Sun, 17 Jan 2010 14:32:26 +0100 Received: from 212-123-145-58.ip.telfort.nl (localhost [127.0.0.1]) by sjakie.klop.ws (Postfix) with ESMTP id DCE93F49F; Sun, 17 Jan 2010 14:32:21 +0100 (CET) Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes To: "Marin Atanasov" , freebsd-hardware@freebsd.org References: <717f7a3e1001120714m37aada69gfaa35f0f9b17f435@mail.gmail.com> <44678539@bb.ipt.ru> <717f7a3e1001142234y1de7ae15x6853e3ddcab4add9@mail.gmail.com> Date: Sun, 17 Jan 2010 14:32:21 +0100 MIME-Version: 1.0 From: "Ronald Klop" Message-ID: In-Reply-To: <717f7a3e1001142234y1de7ae15x6853e3ddcab4add9@mail.gmail.com> User-Agent: Opera Mail/10.10 (FreeBSD) Content-Transfer-Encoding: quoted-printable Cc: freebsd-stable@freebsd.org Subject: Re: Multiple serial consoles via null modem cable X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 17 Jan 2010 13:32:27 -0000 On Fri, 15 Jan 2010 07:34:17 +0100, Marin Atanasov =20 wrote: > Thank you a lot for your feedback! > > Now to the real question again, because I'm a little confused now - can= I > still get a usb-to-serial port converter having let's say 8 serial port= s =20 > and > then connect each machine to the usb-to-serial hub and manage them =20 > remotely > from a single location (the host having the usb-to-serial hub)? That wa= y =20 > I > just specify a serial port number and I get to a specific machine? > > The model provided by Boris looks nice, and that was my initial idea, b= ut > I'm not sure if I could get it working under FreeBSD. Is conserver or > conserver-com able to handle this? I know that cu uses COM1 only, but =20 > will > conserver able to handle serial consoles on different ports, since the > usb-to-serial port would appear as multiple serial ports. You can provide cu with the port to connect to on the command line. cu -l cuaU0 -s 115200 cu -l cuaU1 -s 115200 etc. You can not connect several servers on 1 serial port, but you can connect= =20 several servers on several serial ports. With serial-over-usb it scales t= o =20 many serial ports. Ronald. > > Thank you and regards, > Marin > > > On Tue, Jan 12, 2010 at 7:04 PM, Boris Samorodov wrote: > >> On Tue, 12 Jan 2010 17:14:44 +0200 Marin Atanasov wrote: >> >> > I'm thinking about the following situation - 1 system acting like a = =20 >> host >> > with a serial port hub, each port of the hub is connected to a =20 >> different >> > machine on sio0, using null modem cables. >> >> Along with milti-io serial cards we use multi-usb serial >> converters, such as SUNIX UTS7009P (7 USB to serial adapter): >> http://www.sunix.com.tw/it/en/LinkCraft/UTS4009P_UTS7009P.htm >> >> -- >> WBR, Boris Samorodov (bsam) >> Research Engineer, http://www.ipt.ru Telephone & Internet SP >> FreeBSD Committer, http://www.FreeBSD.org The Power To Serve >> > > > From owner-freebsd-stable@FreeBSD.ORG Sun Jan 17 15:04: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 62570106566B for ; Sun, 17 Jan 2010 15:04:22 +0000 (UTC) (envelope-from morganw@chemikals.org) Received: from warped.bluecherry.net (unknown [IPv6:2001:440:eeee:fffb::2]) by mx1.freebsd.org (Postfix) with ESMTP id C148A8FC13 for ; Sun, 17 Jan 2010 15:04:21 +0000 (UTC) Received: from volatile.chemikals.org (adsl-67-242-76.shv.bellsouth.net [98.67.242.76]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by warped.bluecherry.net (Postfix) with ESMTPSA id 72132A223D4A; Sun, 17 Jan 2010 09:04:20 -0600 (CST) Received: from localhost (morganw@localhost [127.0.0.1]) by volatile.chemikals.org (8.14.3/8.14.3) with ESMTP id o0HF4GfM070345; Sun, 17 Jan 2010 09:04:16 -0600 (CST) (envelope-from morganw@chemikals.org) Date: Sun, 17 Jan 2010 09:04:16 -0600 (CST) From: Wes Morgan X-X-Sender: morganw@volatile To: Volodymyr Kostyrko In-Reply-To: <20100116014659.46536463@limbo.lan> Message-ID: References: <7ab0356e1001151213y5536d4cdi1d1759ce28ad546a@mail.gmail.com> <20100115232922.GM45688@e-Gitt.NET> <20100116014659.46536463@limbo.lan> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: clamav-milter 0.95.2 at warped X-Virus-Status: Clean Cc: freebsd-stable@freebsd.org Subject: Re: AHCI and ZFS: root mount error X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 17 Jan 2010 15:04:22 -0000 On Sat, 16 Jan 2010, Volodymyr Kostyrko wrote: > On Sat, 16 Jan 2010 00:29:23 +0100 > Oliver Brandmueller wrote: > > > Check with "zpool status" if your zpool refers to diskslices like > > "ad0s1". I use gpt have setup the ZFS mirror to refer to gptids: > > > > pool: silver > > state: ONLINE > > scrub: none requested > > config: > > > > NAME STATE READ WRITE CKSUM > > silver ONLINE 0 0 0 > > mirror ONLINE 0 0 0 > > gptid/9e68d234-f306-11de-a0c4-0002b3b6e838 ONLINE 0 0 0 > > gptid/a025b88c-f306-11de-a0c4-0002b3b6e838 ONLINE 0 0 0 > > > > With that kind of configuration I can switch back and forth between > > using ATA_CAM or using traditional ATA drivers. Since you're not using > > GPT I gues you can use geom labels to do more or less the same thing. > > > > In short: use labels, nut device names. Saves headaches in many cases. > > ZFS actually can find disks without any glabel help. I have one server > which I have moved recently to ahci and nothing changes for me. ZFS > silently accepted new provider names and continue working as usual. > Agreed, I experienced the same thing here when I moved to AHCI. I think pjd committed some changes in the last few months that greatly improved the ability of zfs to find devices by uuid. Using glabel or gptid's with zfs is highly overrated IMO! From owner-freebsd-stable@FreeBSD.ORG Sun Jan 17 17: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 CA6E31065693; Sun, 17 Jan 2010 17:42:11 +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 9D8598FC08; Sun, 17 Jan 2010 17:42:11 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id o0HHgBYB008072; Sun, 17 Jan 2010 17:42:11 GMT (envelope-from danger@freefall.freebsd.org) Received: (from danger@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id o0HHgBf1008071; Sun, 17 Jan 2010 17:42:11 GMT (envelope-from danger) Date: Sun, 17 Jan 2010 17:42:11 +0000 From: Daniel Gerzo To: hackers@freebsd.org Message-ID: <20100117174211.GA99840@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 Quarterly Status Report for October - December 2009 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: Sun, 17 Jan 2010 17:42:11 -0000 Introduction This report covers FreeBSD related projects between October and December 2009. This is the last of the four reports covering 2009, which has shown to be a very important year for the FreeBSD Project. Besides other notable things, a new major version of FreeBSD, 8.0-RELEASE, has been released, while the release process for 7.3-RELEASE is soon to begin. Thanks to all the reporters for the excellent work! We hope you enjoy reading. Let us also take this opportunity to wish you all a happy and successful new year for 2010. Please note that the deadline for submissions covering the period between January and March 2010 is April 15th, 2010. __________________________________________________________________ Google Summer of Code * BSD-licensed iconv Projects * 3G USB support * Clang replacing GCC in the base system * FreeBSD TDM Framework * HAST -- Highly Available Storage * Intel XScale hwpmc(9) support * POSIX utmpx for FreeBSD * SUJ -- Journaled SoftUpdates * The webcamd deamon FreeBSD Team Reports * FreeBSD Bugbusting Team * FreeBSD Release Engineering * The FreeBSD Foundation Status Report Network Infrastructure * bwn(4) -- Broadcom Wireless driver * IP Payload Compression Protocol support * Ralink wireless RT2700U/2800U/3000U run(4) USB driver * Syncing pf(4) with OpenBSD 4.5 * Wireless mesh networking Kernel * CAM-based ATA implementation * Group Limit Increase * NFSv4 ACL support * V4L support in Linux emulator Documentation * The FreeBSD German Documentation Project * The FreeBSD Hungarian Documentation Project * The FreeBSD Spanish Documentation Project Architectures * Flattened Device Tree for embedded FreeBSD * FreeBSD/ia64 * FreeBSD/mips * FreeBSD/sparc64 Ports * Chromium web browser * Ports Collection * VirtualBox on FreeBSD Vendor / 3rd Party Software * DAHDI (Zaptel) support for FreeBSD * NVIDIA amd64 driver Miscellaneous * AsiaBSDCon 2010 -- The BSD Conference * BSDCan 2010 -- The BSD Conference * meetBSD 2010 -- The BSD Conference * The FreeBSD Forums Userland utilities * BSD-licensed text processing tools __________________________________________________________________ 3G USB support Contact: Andrew Thompson Recently, a bunch of new device IDs have been added for the u3g(4) cellular wireless driver; the list should be comparable now with other operating systems around. A lot of these devices have a feature where the unit first attaches as a disk or CD-ROM that contains the Win/Mac drivers. This state should be detected by the u3g driver and the usb device is sent a command to switch to modem mode. This has been working for quite some time but as it is implemented differently for each vendor I am looking for feedback on any units where the auto switchover is not working (or the init is not recognized at all). Please ensure you are running an up to date kernel, like r201681 or later from 9.0-CURRENT, or 8-STABLE after the future merge of this revision. __________________________________________________________________ AsiaBSDCon 2010 -- The BSD Conference URL: http://2010.AsiaBSDCon.org/ Contact: AsiaBSDCon Information AsiaBSDCon is a conference for users and developers on BSD based systems. AsiaBSDCon is a technical conference and aims to collect the best technical papers and presentations available to ensure that the latest developments in our open source community are shared with the widest possible audience. The conference is for anyone developing, deploying and using systems based on FreeBSD, NetBSD, OpenBSD, DragonFlyBSD, Darwin and MacOS X. The next conference will be held at the Tokyo University of Science, Tokyo, Japan, on 11th to 14th March, 2010. For more detailed information, please check the conference web site. __________________________________________________________________ BSD-licensed iconv URL: http://p4db.FreeBSD.org/depotTreeBrowser.cgi?FSPC=//depot/projects/soc2 009/gabor_iconv Contact: Gábor Kövesdán Good compatibility has been ensured and there are only few pending items that have to be reviewed/enhanced. Recently, an enhancement has been completed, which makes it possible to accomplish better transliteration, just like in the GNU version. An initial testing patch is expected at the beginning of February. Open tasks: 1. Enhance conversion tables to make use of enhanced transliteration. 2. A performance optimization might be done later. __________________________________________________________________ BSD-licensed text processing tools URL: http://p4db.FreeBSD.org/depotTreeBrowser.cgi?FSPC=//depot/projects/soc2 008/gabor_textproc Contact: Gábor Kövesdán As 8.0-RELEASE is out, BSD bc/dc can be now committed to 9.0-CURRENT. We are only waiting for an experimental package building to make sure there are no regressions after this change. BSD grep is complete but it cannot be integrated yet because of some regex library issues. We need first a fast and modern regex library so that we can change to BSD grep. BSD sort has few incomplete features and needs some performance review. Open tasks: 1. Commit BSD bc/dc. 2. Implement remaining features for sort and optimize performance. __________________________________________________________________ BSDCan 2010 -- The BSD Conference URL: http://www.BSDCan.org/2010/ Contact: BSDCan Information BSDCan, a BSD conference held in Ottawa, Canada, has quickly established itself as the technical conference for people working on and with 4.4BSD based operating systems and related projects. The organizers have found a fantastic formula that appeals to a wide range of people from extreme novices to advanced developers. BSDCan 2010 will be held on 13-14 May 2010 at the University of Ottawa, and will be preceded by two days of Tutorials on 11-12 May 2010. There will be related events (of a social nature, for the most part) on the day before and after the conference. Please check the conference web site for more information. __________________________________________________________________ bwn(4) -- Broadcom Wireless driver URL: http://p4db.FreeBSD.org/depotTreeBrowser.cgi?FSPC=//depot/user/weongyo/ wireless/src/sys/dev/bwn&HIDEDEL=NO Contact: Weongyo Jeong bwn(4) is replacing bwi(4) driver for to the following reasons: * Uses latest v4 firmware image instead of using the much older v3 firmware. In this way, we have some great benefits, such as support for N-PHYs and the fixes of various earlier firmware bugs. * Supports PIO mode. This is important because -- as you might know -- the Broadcom Wireless Driver is created by reverse-engineering so some pieces of hardware might not work with DMA operations. * Supports 64 bit DMA operations. * Separates bwi(4) driver into two parts; siba(4) driver and bwn(4) driver. Many Broadcom wireless and NIC devices are based on Silicon Sonics Backplane, such as bwi(4), which implemented the SIBA operations internally. This resulted in code duplication as other drivers had to implement their own routines to deal with SIBA. In the case of bwn(4), these two parts have been separated and implemented in their own kernel modules to avoid this problem and help further development by providing a standalone siba(4) driver. Currently, it is tested on big/little endian machines and 32/64-bit DMA operation with STA mode. A major patch for siba(4) is being reviewed before committing into 9.0-CURRENT. Open tasks: 1. MESH/IBSS/HOSTAP mode is not supported. 2. LP/N PHYs are not supported. __________________________________________________________________ CAM-based ATA implementation Contact: Alexander Motin Contact: Scott Long Existing ata(4) infrastructure, which has been around many years, has various problems and limitations when compared to modern controllers/device support. Although the CAM subsystem (used for SCSI) is almost as old as ata(4), it is more eligible to solve the current problems. To reduce code duplication and better support border cases such as ATAPI and SAS, we have started to develop a new CAM based ATA implementation. As such, CAM infrastructure has been extended to support different transports. New transport has been implemented to support PATA/SATA buses. To support ATA disks, a new CAM driver (ada) has been written. ATAPI devices are supported by existing SCSI drivers cd, da, sa, etc. To support SATA port-multipliers another new CAM driver (pmp) has been written. To support most featured and widespread SATA controllers, new drivers ahci(4) and siis(4) have been developed. To support legacy ATA controllers, a kernel option ATA_CAM has been added. When used, it makes all ata(4) controllers directly available to CAM, deprecating ata(4) peripheral drivers and external APIs. To make this possible, ata(4) code has been heavily refactored, making controller driver API stricter. Command queuing support gives new ATA implementation up to double performance benefit on some workloads, with 20-30% improvement quite usual. SATA Port Multiplier support makes it easy to build fast and cheap storage with huge capacities, by using dozens of SATA drives in one system or external enclosures, Some of that code has been presented in the recently released FreeBSD 8.0-RELEASE but 8-STABLE now includes a much improved version. Open tasks: 1. Improve timeout and transport error recovery. 2. Improve hot-plug support. 3. Find and fix any show stoppers for legacy ata(4) deprecation. 4. Write a new, more featured driver for Marvell SATA controllers (specifications desired). 5. Write SAS-specific transport and drivers for SAS HBAs (specifications desired). SAS controllers can support SATA devices and multipliers, so it should fit nicely into the new infrastructure. __________________________________________________________________ Chromium web browser URL: http://chromium.jaggeri.com URL: http://www.links.org/?p=724 Contact: Ben Laurie Chromium is a Webkit-based web browser that is largely BSD licensed. It has been ported from Linux to FreeBSD in October and we have been posting patches and test builds periodically since then. Chromium works well on FreeBSD -- it is very fast and stable but there are a handful of rough edges that need to be polished up. Two remaining bugs should probably be fixed before releasing a chromium-devel port. We are looking for volunteers to test and maintain this port to make this BSD browser a viable option on FreeBSD desktop systems. Open tasks: 1. Fix sporadic rendering freezes. 2. Fix JavaScript interpreter, v8, on i386 architecture. __________________________________________________________________ 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 We are again able to build bootable i386/amd64 kernel. Nathan Whitehorn committed a fix to FreeBSD, which enabled LLVM/clang to work mostly fine on PowerPC. There is some preliminary testing of LLVM/clang on ARM and MIPS being done. We have some ideas about sparc64 support which are currently being investigated. You are welcome to contact us if you want to help. Since the last report, a lot has happened mostly in the area of C++; clang is currently able to build working groff, gperf and devd, i.e. all of the C++ apps we have in base. Unfortunately, it still cannot build any of the C++ libraries -- two of them are missing builtins and libstdc++ is broken for other reasons. Not much happened in the clangbsd branch as we cannot upgrade the clang/llvm there because we are blocked by a bug that requires using newer assembler than we can ship. This might be solved by either fixing this (short term) or using llvm-mc instead of GNU as for assembling (longer term). Open tasks: 1. Help with ARM/MIPS/sparc64. 2. More testing of clang on 3rd party apps (ports). 3. Discussion on integrating LLVM/clang into FreeBSD. __________________________________________________________________ DAHDI (Zaptel) support for FreeBSD URL: http://www.mail-archive.com/asterisk-dev@lists.digium.com/msg39598.html URL: http://svn.digium.com/svn/dahdi/freebsd/trunk/ Contact: Max Khon A DAHDI support module for FreeBSD has been created in the official Asterisk SVN repository. The following drivers are currently ported: * main DAHDI driver * all software echo cancellation drivers * dahdi_dynamic * dahdi_dynamic_loc The following HW drivers are currently ported and tested: * wct4xxp, including HW echo cancellation support (Octasic) + Digium TE205P/TE207P/TE210P/TE212P: PCI dual-port T1/E1/J1 + Digium TE405P/TE407P/TE410P/TE412P: PCI quad-port T1/E1/J1 + Digium TE220: PCI-Express dual-port T1/E1/J1 + Digium TE420: PCI-Express quad-port T1/E1/J1 * wcb4xxp + Digium B410: PCI quad-port BRI + Junghanns.NET HFC-2S/4S/8S duo/quad/octoBRI + OpenVox B200P/B400P/B800P + BeroNet BN2S0/BN4S0/BN8S0 Open tasks: 1. The port for dahdi_dynamic_eth and dahdi_dynamic_ethmf is underway. 2. More HW drivers need to be ported. 3. Please let me know if you can provide remote access with serial console to any box with ISDN/T1/E1 HW not currently supported by DAHDI for FreeBSD but supported by DAHDI for Linux. I am also interested in porting drivers for FXO/FXS cards. Please let me know if you can provide a remote access or donate a card. __________________________________________________________________ Flattened Device Tree for embedded FreeBSD URL: http://wiki.FreeBSD.org/FlattenedDeviceTree URL: http://p4db.FreeBSD.org/changeList.cgi?FSPC=//depot/projects/fdt/... Contact: Rafal Jaworowski The purpose of this project is to provide FreeBSD with support for the Flattened Device Tree (FDT) technology, the mechanism for describing computer hardware resources, which cannot be probed or self enumerated, in a uniform and portable way. The primary consumers of this technology are embedded FreeBSD platforms (ARM, AVR32, MIPS, PowerPC), where a lot of designs are based on similar chips but have different assignment of pins, memory layout, addresses bindings, interrupts routing and other resources. Current state highlights: * Environment, supported tools + Integrated device tree compiler (dtc) and libfdt into FreeBSD userspace, kernel and loader build * loader(8) + Full support for device tree blob handling + Load, traverse, modify (including add/remove) device tree nodes and properties + Pass the device tree blob to the kernel + Both ARM and PowerPC loader(8) supported * Kernel side FDT support (common) + Developed OF interface for FDT-backed platforms + ofw_bus I/F (and /dev/openfirm) available with FDT + Integrated FDT resources representation with newbus (fdtbus and simplebus drivers) * PowerPC kernel (Freescale MPC85XX SOC) + MPC8555CDS and MPC8572DS successfully converted to FDT conventions * ARM kernel (Marvell Orion, Kirkwood and Discovery SOC) + Work in progress on integrating FDT infrastructure with ARM platform code Work on this project has been sponsored by the FreeBSD Foundation. Open tasks: 1. Complete missing pieces for PowerPC (PCI bridge driver conversion to FDT). 2. Complete ARM support. 3. Merge to SVN. __________________________________________________________________ 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/ URL: http://people.FreeBSD.org/~linimon/studies/prs/recommended_prs.html URL: http://people.FreeBSD.org/~linimon/recommended_subscribers.txt Contact: Gavin Atkinson Contact: Mark Linimon Contact: Remko Lodder Contact: Volker Werth Bugmeister Gavin Atkinson has now been granted a src commit bit, and is now starting to work through some of our backlog. The list of PRs recommended for committer evaluation by the Bugbusting Team continues to receive new additions; however, it has not yet achieved high visibility. (This list contains PRs, mostly with patches, that the Bugbusting Team consider potentially ready to be committed as-is, or are probably trivially resolved in the hands of a committer with knowledge of the particular subsystem.) One of the suggestions at the Cambridge devsummit was to create a way for people to be emailed the weekly summary that is posted to freebsd-bugs@, and this has now been implemented. Please email linimon@FreeBSD.org to ask to be added to the recommended_subscribers.txt file (see above). We continue to classify PRs as they arrive, adding 'tags' to the subject lines corresponding to the kernel subsystem involved, or man page references for userland PRs. These tags, in turn, produce lists of PRs sorted both by tag and by manpage. At this point most of the PRs that refer to supported versions of FreeBSD have been converted, and we are keeping up as new ones come in. We hope that this is making it easier to browse the PR database. The overall PR count jumped to over 6,200 during the 8.0-RELEASE release cycle but seems to have stabilized at around 6,100. As in the past, we have a fairly good clearance rate for ports PRs but much less so for other PRs. (Partly this is due to the concept of individual ports having 'maintainers'.) Open tasks: 1. Try to find ways to get more committers helping us with closing PRs that the team has already analyzed. __________________________________________________________________ FreeBSD Release Engineering URL: http://www.FreeBSD.org/releng/ Contact: Release Engineering Team The Release Engineering Team announced FreeBSD 8.0-RELEASE on November 26th, 2009. With 8.0-RELEASE completed planning has begun for 7.3-RELEASE. The schedule has been set with the release date planned for early March 2010. The Release Engineering Team would like to thank George Neville-Neil (gnn@) for his service on the team. George continues to work with the FreeBSD Project but has stepped down from the Release Engineering Team to focus on other activities. __________________________________________________________________ FreeBSD TDM Framework Contact: Rafal Czubak Contact: Michal Hajduk Important changes regarding FreeBSD TDM Framework since the last status report: * Fully functional TDM controller driver for Marvell Kirkwood and Discovery SoCs. * Working voiceband channel character device driver. * Working Si3215, Si3050 codec drivers on corresponding FXS, FXO ports. * Demo application, which is capable of manipulating voiceband channel and codec state, starting/stopping channel transfers and echoing on single channel. * Preliminary version of driver bridging the voiceband infrastructure with Zaptel/DAHDI. Open tasks: 1. Improve various issues regarding working drivers and demo application. 2. Test Si3050 codec driver operation with PSTN. 3. Fully integrate voiceband infrastructure with Zaptel/DAHDI telephony hardware drivers. __________________________________________________________________ FreeBSD/ia64 Contact: Marcel Moolenaar Work continues on our ia64 port. Many recent commits to help improve stability have been made to 9.0-CURRENT and MFCed to 8-STABLE. Due to interest from a very motivated user, package builds have been restarted for ia64-8. This is primarily intended as a QA step to discover and fix bugs on ia64, rather than to create packages for upload. Based on the above, Mark Linimon documented how to add more architectures to the package cluster scheduler. (This work will also be of use in an upcoming effort to start powerpc package builds.) There are currently 3 ia64 machines online and building packages. The machines seem stable as long as multiple simultaneous package builds are not attempted, in which case they get machine checks. This is puzzling, since other heavy workloads seem stable on the same machines. Open tasks: 1. Continue to try to understand why multiple simultaneous package builds bring the machines down. 2. Upgrade the firmware on the two machines at Yahoo! to see if that helps the problem. 3. Configure a fourth machine that has been made available to us. 4. Figure out the problems with the latest GCC port on ia64. 5. We can use some help with reviewing the ia64 platform pages and bringing them up-to-date. __________________________________________________________________ FreeBSD/mips URL: http://www.FreeBSD.org/projects/mips/index.html URL: http://wiki.FreeBSD.org/FreeBSD/mips Contact: The FreeBSD/mips mailing list Contact: Warner Losh The base/projects/mips branch has been merged into 9.0-CURRENT. The merge is complete and the sanity tests have passed. The code has booted on both a Ubiquiti RouterStation (big endian) as well as in gxemul (little endian). The branch lived for one year, minus a day, and accumulated much work: * A new port to the Atheros AR71xx series of processors. This port supports the RouterStation and RouterStation PRO boards from Ubiquiti. Other boards should work with minimal tweaking. This port should be considered as nearing production quality, and has been used extensively by the developers. The primary author of this port is Oleksandr Tymoshenko (gonzo@FreeBSD.org). * A new port to the SiByte BCM1250 SoC on the BCM91250 evaluation board (aka SWARM). This port is reported to be stable, but this hardware is a little old and not widely available. The primary author of this port is Neel Natu (neel@FreeBSD.org). Only one core is presently supported. * A port, donated by Cavium, to their Octeon and Octeon plus series of SoC (CN3xxx and CN5xxx). This code is preliminary, supporting only a single core right now. It has been lightly tested on the CN3860 evaluation board only in 32-bit mode. Warner Losh (imp@FreeBSD.org) has been driving the efforts to get this code into the tree. * A port, donated by RMI, to their XLR series of SoCs. This port is single core only, as well. The code reaches multi-user but should be considered beta quality for the moment. Randal Stewart (rrs@FreeBSD.org) has been driving the efforts to integrate this into the tree. * Preliminary support for building a mips64 kernel from this source base. More work is needed here, but at least two kernels successfully build in 64-bit mode (OCTEON1 and MALTA64). * Very early support for N32 and N64 ABIs * Support for booting compressed kernels has been added (gonzo@). * Improved support for debugging * Improved busdma and bus_space support * Many bug fixes * More types of MIPS cores are recognized * Expanded cache handling for newer processors * Beginning of a port to the alchemy au1XXX cpus is present, but experimental. * Work on SMP is underway to support multicore processors like the SiByte, Octeon and XLR processors. The development branch had been updated incorrectly several times over the past year, and the damage was too much to repair. We have retired the branch and will do further mips development in 9.0-CURRENT for the time being. If you have a checked out tree, the suggested way to update the projects/mips tree you have is to do a "svn switch svn://svn.FreeBSD.org/base/head" in that tree. I would like to thank everybody that has contributed time, code or hardware to make FreeBSD/mips better. As development proceeds, I will keep posting updates. In addition, I hope to have some mini "how-to" wiki pages done for people that want to try it out. Open tasks: 1. We are still investigating how feasible merging all this work into 8-STABLE will be, as it represents a huge leap forward in code stability and quality. __________________________________________________________________ FreeBSD/sparc64 Contact: Marius Strobl The main thing that has taken place since the last Status Report is that I have gotten to the bottom of the remaining PCI problems with Sun Fire V215/V245 and support for these has been completed and since r202023 now is part of 9.0-CURRENT. With some luck it will also be part of the upcoming 7.3-RELEASE. Some other news: * Two bugs in the NFS server causing unaligned access and thus panics on sparc64 and all other architectures with strict alignment requirements (basically all Tier-2 ones) have been fixed. There likely will be a 8.0-RELEASE Erratum Notice released for these. * FreeBSD has been adopted to the changed firmware of newer Sun Fire V480 (those equipped with version 7 Schizo bridges) and has been reported to now run fine on these. The necessary change will be part of 7.3-RELEASE. Unfortunately, using the on-board NICs in older models of Sun Fire V480 (at least those equipped with version 4 Schizo bridges) under FreeBSD still leads to the firmware issuing a FATAL RESET due to what appears to be a CPU bug, which needs to be worked around. * Work on supporting Sun Fire V1280 has been started but still is in very early stages. Unfortunately, these are rather quirky machines. After solving two firmware specialties the loader now is able to boot the kernel but the latter currently still fails in early cycles as trying to take the trap table over from the firmware results in a solid hang. __________________________________________________________________ Group Limit Increase Contact: Brooks Davis Historically, FreeBSD has limited the number of supplemental groups per process to 15 (NGROUPS_MAX was incorrectly declared to be 16). In FreeBSD 8.0-RELEASE we raised the limit to 1023, which should be sufficient for most users and will be acceptably efficient for incorrectly written applications that statically allocate NGROUPS_MAX + 1 entries. Because some systems such as Linux 2.6 support a larger group limit, we have further relaxed this restriction in 9.0-CURRENT and made kern.ngroups a tunable value, which supports values between 1023 and INT_MAX - 1. We plan to merge this to 8-STABLE before 8.1-RELEASE. __________________________________________________________________ HAST -- Highly Available Storage URL: http://lists.FreeBSD.org/pipermail/freebsd-announce/2009-October/001279 .html Contact: Pawel Jakub Dawidek HAST software will provide synchronous replication of any GEOM provider (eg. disk, partition, mirror, etc.) or file from one FreeBSD machine (primary node) to another one (secondary node). Because data is replicated at the block level neither applications, nor file systems have to be modified to take advantage of this functionality. The functionality that HAST software will provide is very similar to the functionality provided by the DRBD project for Linux. The HAST project is sponsored by the FreeBSD Foundation. Work is progressing well; first milestone was reached in December 2009 and the expected project completion date is January 31, 2010. Check out FreeBSD mailing lists for patches to test in February and wish me good luck! And by the way, do not forget to donate to the FreeBSD Foundation, as your donations make projects like this possible. Thank you! __________________________________________________________________ Intel XScale hwpmc(9) support Contact: Rui Paulo Preliminary Hardware Performance Counter support for Intel XScale ARM processors was committed to FreeBSD 9.0-CURRENT in December. This adds another supported architecture to hwpmc(9). The system works for basic performance counter usage but more advanced usage scenarios, namely callchain support, are not yet implemented. __________________________________________________________________ IP Payload Compression Protocol support Contact: Bjoern A. Zeeb One of the longer outstanding feature problems with the FreeBSD IP security stack, broken IP Payload Compression Protocol (IPcomp) support, has been fixed. While working on the fix, various problems had been identified: * Problems with the IPcomp packet handling in IPsec. * opencrypto compression handling and deflate implementation limitations. These were debugged using DTrace SDT probes. * Problems due to an outdated version of zlib used in some parts of the network stack and by the opencrypto framework. Patches for all but the zlib support have been committed to 9.0-RELEASE and merged to all supported stable branches including 6-STABLE. Special thanks to Eugene Grosbein for helping with testing. Open tasks: 1. Fix ng_deflate so that we can make use of Kip Macy's work on an up-to-date unified zlib version in the kernel, which would also fix the last occasional IPcomp hiccups. __________________________________________________________________ meetBSD 2010 -- The BSD Conference URL: http://www.meetBSD.org Contact: meetBSD Information The meetBSD conference is an annual event gathering users and developers of the BSD operating system family, mostly FreeBSD, NetBSD and OpenBSD. Afer the special California edition, meetBSD Wintercamp in Livigno, this year we are back to Krakow, Poland. In 2010, meetBSD will be held on 2-3 July at the Jagiellonian University. See the conference main web site for more details. __________________________________________________________________ NFSv4 ACL support URL: http://wiki.FreeBSD.org/NFSv4_ACLs Contact: Edward Tomasz Napierala Native NFSv4 ACL support in ZFS and UFS has been committed into 9.0-CURRENT. It is expected to be MFCed in order to make it into FreeBSD 8.1-RELEASE. Open tasks: 1. Support for NFSv4 ACLs in tar(1). 2. MFC. __________________________________________________________________ NVIDIA amd64 driver URL: http://www.nvnews.net/vbulletin/showthread.php?t=142120 Contact: John Baldwin NVIDIA has released the first BETA version of its graphics drivers for FreeBSD/amd64. Note that this driver will work on FreeBSD versions 7.3-RELEASE or 8.0-RELEASE and later. It also works on very recent versions of 7.2-STABLE. More details are provided in the official release announcement. __________________________________________________________________ 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://tinderbox.marcuscom.com Contact: Mark Linimon Most of the recent activity has been dealing with the 8.0-RELEASE process. As an experiment, we have tried to decouple the ports QA timeline as much as possible from the src QA timeline. Although this meant that the impact on people actively maintaining and using ports has been much less than in previous releases, it still has not solved the problem of the release going out with a stale set of packages. We are still trying to come up with a better solution for the problem. The ports count is over 21,000. The PR count jumped to over 1,000 but is now back to around 950. We are currently building packages for amd64-6, amd64-7, amd64-8, i386-6, i386-7, i386-8, i386-9, ia64-8, sparc64-7, and sparc64-8. This represents the addition of i386-9 and ia64-8 since the last report. There has been some discussion of when to drop regular package builds for 6.X but no decision has been made yet. The cluster and the port managers are struggling to keep up with so many branches being active all at the same time. Mark Linimon continues to make progress on the cluster nodes. Almost every node that does not have a hard disk failure is now online. In addition, he continues to make progress debugging problems that occasionally take nodes offline. The next task is to characterize the overall performance of the build cluster. The question has been asked of us, "what would it take to speed up package builds?" There is no one simple answer. It is not merely a matter of having a larger number of package building machines, so before asking for funding we first need to identify the current bottlenecks. While we are starting to understand the problems on the nodes, the problems on the dispatch machine itself are much harder. Complicating the matter is that there are several periodic processes (ZFS backup, ZFS expiration, and errorlog compression, among others) that can combine to slow that machine significantly. The simultaneous interaction of all these is proving difficult to quantify. Between Pav Lucistnik and Martin Wilke, many more experimental ports runs have been completed and committed. We have added 3 new committers since the last report, and 1 older one has rejoined us. Open tasks: 1. We are still trying to set up ports tinderboxes that can be made available to committers for pre-testing. 2. Most of the remaining ports PRs are "existing port/PR assigned to committer". Although the maintainer-timeout policy is helping to keep the backlog down, we are going to need to do more to get the ports in the shape they really need to be in. 3. Although we have added many maintainers, we still have more than 4,700 unmaintained ports. (See, for instance, the list on portsmon. The percentage remains steady at just over 22%.) We are always looking for dedicated volunteers to adopt at least a few unmaintained ports. As well, the packages on amd64 and especially sparc64 lag behind i386, and we need more testers for those. __________________________________________________________________ POSIX utmpx for FreeBSD URL: http://lists.FreeBSD.org/pipermail/freebsd-current/2010-January/014893. html URL: http://www.opengroup.org/onlinepubs/9699919799/functions/endutxent.html URL: http://cvsweb.netbsd.org/bsdweb.cgi/~checkout~/src/lib/libc/gen/utmpx.c URL: http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/lib/libc/ port/gen/getutx.c Contact: Ed Schouten On January 13, I removed the utmp user accounting database and replaced it with a new POSIX utmpx implementation. Unfortunately, the upgrade path is a bit complex, because the utmp interface provided almost no library interface to interact with the database files. This change may have caused some regressions. Some ports may fail to build, while there could also be bugs in the library functions. Open tasks: 1. Get a list of broken ports. 2. Fix them to comply to standards. 3. Send patches upstream. __________________________________________________________________ Ralink wireless RT2700U/2800U/3000U run(4) USB driver URL: http://forums.FreeBSD.org/showthread.php?t=7562 Contact: Akinori Furukoshi The run(4) driver brings support for Ralink RT2700U/2800U/3000U USB wireless devices. For detailed information and list of all the supported devices, please see the above mentioned URL. The source code has been imported to the USB P4 repository on January 10, 2010 (172906). Open tasks: 1. Solve USB_TIMEOUT problem when sending beacons, and/or confirm which chipsets supports AP mode if all of them do not support it. 2. Read TX stats for AMRR on AP mode, and/or confirm which chipsets supports AP mode if all of them do not support it. 3. Maintain the code. __________________________________________________________________ SUJ -- Journaled SoftUpdates URL: http://jeffr_tech.livejournal.com/ Contact: Jeff Roberson I have been adding a small intent log to SoftUpdates to eliminate the requirement for fsck after an unclean shutdown. This work has been funded by Yahoo!, iXsystems, and Juniper. Kirk McKusick has been aiding me with design critiques and helping me better understand SoftUpdates. Extensive testing by myself and Peter Holm has yielded a stable patch. Current users are encouraged to follow the instructions posted to the current@FreeBSD.org mailing list to verify stability in your own workloads. Updates are forthcoming and it is expected to be merged to 9.0-CURRENT before the end of January. Ports to older versions of FreeBSD will be available in SVN under alternate branches. Official backports will be decided by re@ when 9.0-CURRENT is stable. The changes are fully backwards and forwards compatible as there are very few metadata changes to the filesystem. The journal may be enabled or disabled on existing FFS filesystems using tunefs(8). The log consumes 64 MB of space at maximum and fsck time is bounded by the size of the log rather than the size of the filesystem. Other details are available in my technical journal. __________________________________________________________________ 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/ Contact: Ermal Luçi This import 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. Currently, the pf(4) import is considered stable with normal kernel, as well as VIMAGE enabled kernels. Open tasks: 1. pflow(4)/pflog(4)/pfsync(4) need to be made VIMAGE aware. 2. More regression testing is needed. __________________________________________________________________ The FreeBSD Forums URL: http://forums.FreeBSD.org/ Contact: FreeBSD Forums Admins Contact: FreeBSD Forums Moderators Since the last report we have seen a growth of 2,000 users on our forums resulting in approximately 10,000 registered users at this time. The posts count is about to reach 60,000 soon, which are contained in almost 9,000 threads. The sign-up rate still hovers between 50-100 each week. The total number of visitors (including 'guests') is currently hard to gauge, but is likely to be a substantial multiple of the registered userbase. New topics and posts are actively 'pushed out' to search engines. This in turn makes the forums show up in search results more and more often, making it a valuable and very accessible source of information for the FreeBSD community. One of the contributing factors to the forums' success is their 'BSD-style' approach when it comes to administration and moderation. The forums have a strong and unified identity and are very actively moderated, spam-free, and with a core group of very active and helpful members, dispensing many combined decades' worth of knowledge to starting, intermediate and professional users of FreeBSD. __________________________________________________________________ The FreeBSD Foundation Status Report URL: http://www.FreeBSDFoundation.org/ URL: https://twitter.com/freebsdfndation Contact: Deb Goodkin Despite a difficult economy, we more than doubled our number of donors, we raised $269K towards our goal of $300K, and with an improved economy hope to surpass that this year. We have funded two new projects. One is the Flattened Device Tree by Rafal Jaworowski. And, the second one is Highly Available Storage by Pawel Jakub Dawidek. We continued supporting the New Console Driver by Ed Schouten and Improvements to the FreeBSD TCP Stack by Lawrence Stewart. We also purchased equipment for several projects. We have big plans for the new year! We are going to significantly increase our project development and equipment spending. Stay tuned for a project proposal submission announcement soon. We just announced that we are accepting travel grant applications for AsiaBSDCon and will be accepting them soon for BSDCan. And, we are working on infrastructure projects to beef up hardware for package-building, network-testing, etc. Read more about how we supported the project and community by reading our end-of-year newsletter available at http://www.FreeBSDFoundation.org/press/2009Dec-newsletter.shtml. We are fund-raising for 2010 now! Find out more at http://www.FreeBSDFoundation.org/donate/. __________________________________________________________________ The FreeBSD German Documentation Project URL: http://doc.bsdgroup.de Contact: Johann Kois Contact: Benedict Reuschling Contact: Martin Wilke We are happy to announce that Benedict Reuschling is now free from mentorship and can commit to the documentation tree on his own. Since the last status report, the German Documentation Team has chased updates to various sections of the FreeBSD Handbook, FAQ and the German website. Many handbook pages have been updated to the latest version, including chapters about configuration, disks, kernel configuration, printing, multimedia and virtualization. We require help from volunteers that are willing to contribute bug fixes or translations. The following documents need active maintainership and are a good training ground for those willing to join the translation team: * arch-handbook/jail/ * developers-handbook/I10n/ * developers-handbook/policies/ * developers-handbook/sockets/ (translation from scratch) * handbook/firewalls/ (translation from scratch) * handbook/security/ * porters-handbook/ Open tasks: 1. Read the translations and report bugs to de-bsd-translators@de.FreeBSD.org. 2. Translate articles or missing sections listed above. __________________________________________________________________ The FreeBSD Hungarian Documentation Project URL: http://www.FreeBSD.org/hu/ URL: http://www.FreeBSD.org/doc/hu/ URL: http://wiki.FreeBSD.org/HungarianDocumentationProject URL: http://p4web.FreeBSD.org/@md=d&cd=//depot/projects/docproj_hu/&c=aXw@// depot/projects/docproj_hu/?ac=83 Contact: Gábor Kövesdán Contact: Gábor Páli In the last months, no new translation has been added. Lacking human resources, we can only manage to keep the existing documentation and web page translations up to date. If you are interested in helping us, please contact us via the the email addresses noted above. Open tasks: 1. Translate release notes. 2. Add more article translations. __________________________________________________________________ The FreeBSD Spanish Documentation Project URL: http://www.FreeBSD.org/doc/es/articles/fdp-es/ URL: https://listas.es.FreeBSD.org/mailman/listinfo/doc Contact: Gábor Kövesdán There is one article translation pending review. Apart from this, neither translations nor maintainance work have been done. We need more volunteers, mostly translators but we are glad to have more reviewers, as well. One can join by simply subscribing to the translators' mailing list where all the work is done. Open tasks: 1. Update Handbook translation. 2. Update webpage translation. 3. Add more article translations. __________________________________________________________________ The webcamd deamon URL: http://www.selasky.org/hans_petter/video4bsd/ Contact: Hans Petter Selasky The webcamd daemon enables hundreds of different USB based webcam devices to be used under the FreeBSD-8/9 operating system. The webcam daemon is basically an application, which is a port of Video4Linux USB webcam drivers into userspace on FreeBSD. The daemon currently depends on libc, pthreads, libusb and the VIDEO4BSD kernel module. Open tasks: 1. Add support for the remaining Video4Linux USB devices. 2. Make patches for increased buffer sizes, due to higher latency in userspace. Especially for High Speed USB. __________________________________________________________________ V4L support in Linux emulator URL: http://opal.com/freebsd/sys/compat/linux/ Contact: J.R. Oldroyd V4L video support in the Linux emulator is now available. This work allows Linux applications using V4L video calls to work with existing FreeBSD video drivers that provide V4L interfaces. It is tested and working with the net/skype port and also with browser-based Flash applications that access webcams. An early version has been committed to 9.0-CURRENT and work is in progress to commit the latest version and then MFC. It is also tested on FreeBSD-8.0/amd64 and FreeBSD-7.2/i386. Note: to be clear, this does not add V4L support to all webcams. The FreeBSD camera driver must already offer V4L support itself in order for a Linux application to be able to use that camera. The multimedia/pwcbsd port provides the pwc(4) driver that already has V4L support. If your camera is supported by a different driver, you will need to enhance that driver to add V4L support. __________________________________________________________________ VirtualBox on FreeBSD URL: http://wiki.FreeBSD.org/VirtualBox Contact: Beat Gaetzi Contact: Bernhard Froehlich Contact: Juergen Lock Contact: Martin Wilke VirtualBox 3.1.2 has been committed to the ports tree. Several changes to the port have been performed with this update including: * Port has been renamed to virtualbox-ose to reflect that we are now using the OSE version. * A seperate port for the kernel modules has been created -- virtualbox-ose-kmod. * A seperate port for guest additions for FreeBSD guests has been created -- virtualbox-ose-additions. * Proper FreeBSD support for PulseAudio has been added. * Procfs is not required anymore because vbox uses sysctl(3) now. * Juergen Lock's FreeBSD host networking patches have been added. They are now also in the upstream vbox SVN (modulo vbox variable naming style adjustments). * Allow direct tap networking again (for users that need the best network performance and/or need more complex network setups, like when they want to use routing instead of bridging to e.g. protect guests from messing with the lan's ARP tables; a tap + routing + proxy arp example is in the above freebsd-emulation@ posting.) * Enable vbox's shared MAC feature when using bridged mode on a Wifi interface, together with the virtualbox-ose-kmod change this should fix bridged mode for Wifi users. * We would like to say thanks to all the people that helped us by reporting bugs and submitting fixes. We also thank the VirtualBox developers for their help with the ongoing effort to port VirtualBox to FreeBSD __________________________________________________________________ Wireless mesh networking URL: http://wiki.FreeBSD.org/WifiMesh Contact: Rui Paulo Development of the FreeBSD 802.11s stack continues. The code in FreeBSD HEAD has been updated to comply with draft 4.0. Merge to FreeBSD 8-STABLE will be done soon. The developer is looking for funding to be able to implement mesh link security algorithms and/or coordinated channel access (performance improvement). From owner-freebsd-stable@FreeBSD.ORG Sun Jan 17 17:57: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 47D3A106568B for ; Sun, 17 Jan 2010 17:57:03 +0000 (UTC) (envelope-from thomas.e.zander@googlemail.com) Received: from mail-px0-f183.google.com (mail-px0-f183.google.com [209.85.216.183]) by mx1.freebsd.org (Postfix) with ESMTP id 1F5D28FC16 for ; Sun, 17 Jan 2010 17:57:02 +0000 (UTC) Received: by pxi13 with SMTP id 13so1570219pxi.3 for ; Sun, 17 Jan 2010 09:57:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=GJnfzUfVLsFz9rHh/4odDS62hIrIqS8SkwkIgKta2Do=; b=CEedPeRKP2J+Zx1aOulkZKOFZLrsOMxxKAFFJbGB0JsdOH30YJoXO7K3mCj9ma/tjO GlLhK8emiyWM2uvAtSIbKIovgyYvsUhcJz4ly6BMrC9U2wrfVKHzm7JMSNzU06MoNc9n 50ldxvX/ONlVUvHWGE1K6CUJTCWyFZi1lzZ48= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=gI5GYH6UXVBqTKlsYFPzTtbe9OxkOnqHc9rYDH/73K1aEbbHMp/Ms5wD0PT+EyryZs RIZfeFHamcXgKbuixRz+FdrxDu7wKv4u1MLXh8GIX4XXcH9lutLUlQw9vdQ2LPOunPC5 SBOrjuLikuQ4skvctwHPHQ/3/9kwEu8BxBEO4= MIME-Version: 1.0 Received: by 10.141.124.9 with SMTP id b9mr3675662rvn.9.1263751022566; Sun, 17 Jan 2010 09:57:02 -0800 (PST) In-Reply-To: <20100117130447.GC62907@deviant.kiev.zoral.com.ua> References: <786602c61001161554s79a33401n9700048d4a4c74fb@mail.gmail.com> <20100117130447.GC62907@deviant.kiev.zoral.com.ua> Date: Sun, 17 Jan 2010 18:57:02 +0100 Message-ID: <786602c61001170957i69bd76c9w857bea35a4953855@mail.gmail.com> From: Thomas Zander To: Kostik Belousov Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-stable Subject: Re: buildworld WITH_CTF=1 breaks cc1plus on STABLE? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Jan 2010 17:57:03 -0000 On Sun, Jan 17, 2010 at 14:04, Kostik Belousov wrote: > WITH_CTF=1 results in the broken static binaries after strip(1). > Do not use it (yet) for buildworld. Thank you, I must have missed this somehow. Is it maybe worth a footnote in the handbook? http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/dtrace-enable.html Regards, Riggs From owner-freebsd-stable@FreeBSD.ORG Sun Jan 17 18:06: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 6A6E01065672 for ; Sun, 17 Jan 2010 18:06:23 +0000 (UTC) (envelope-from jonc@chen.org.nz) Received: from chen.org.nz (ip-58-28-152-174.static-xdsl.xnet.co.nz [58.28.152.174]) by mx1.freebsd.org (Postfix) with ESMTP id 12A518FC0C for ; Sun, 17 Jan 2010 18:06:22 +0000 (UTC) Received: by chen.org.nz (Postfix, from userid 1000) id 3D1C5E040A; Mon, 18 Jan 2010 07:06:20 +1300 (NZDT) Date: Mon, 18 Jan 2010 07:06:20 +1300 From: Jonathan Chen To: Ian Smith Message-ID: <20100117180620.GB10081@osiris.chen.org.nz> References: <20100117064733.GA3119@osiris.chen.org.nz> <20100117194712.C41296@sola.nimnet.asn.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100117194712.C41296@sola.nimnet.asn.au> User-Agent: Mutt/1.4.2.3i Cc: freebsd-stable@freebsd.org Subject: Re: Drive light on all the time on 8-STABLE. X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Jan 2010 18:06:23 -0000 On Sun, Jan 17, 2010 at 08:03:02PM +1100, Ian Smith wrote: > Jonathan, > > On Sun, 17 Jan 2010, Jonathan Chen wrote: > > On the weekend, I moved my 8-STABLE installation (csup'd late Dec 2009) > > onto a new drive, a Seagate ST31000528AS CC3; and while the transfer was > > successful, I've noticed that the drive light is solidly on all the time, > > even if it boots into single-user. > > I guess this is the red/amber case LED, rather than on the drive itself? Yes. > > # uname -a > > FreeBSD osiris.chen.org.nz 8.0-STABLE FreeBSD 8.0-STABLE #1: Sat Jan 16 08:32:54 NZDT 2010 root@:/usr/obj/usr/src/sys/OSIRIS amd64 > > > > Is this something I should be worried about? There doesn't appear to > > be any disk I/O (I can't hear the disk grinding), but I may be wrong. > > gstat should be definitive about activity. Even constant low level > activity should usually show some flickering. gstat doesn't show much activity on the drive at all. Most of the time the drive and it's associated slices read green on 0.0. > > The drive from which I transferred from did not exhibit this strange > > behaviour. > > > > Any advice would be welcome. > > If it were IDE I'd suspect its cable - and the drive if it wasn't that > - but I guess the SATA controller would be driving the LED. Yup. I've booted it into Windows, and the behaviour is what I'd expect - ie LED is off when no disk activity is happening. Thanks anyway. -- Jonathan Chen ---------------------------------------------------------------------- The human mind ordinarily operates at only ten percent of its capacity -- the rest is overhead for the operating system. From owner-freebsd-stable@FreeBSD.ORG Sun Jan 17 18:10: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 65CE3106566B for ; Sun, 17 Jan 2010 18:10:48 +0000 (UTC) (envelope-from russell.yount@gmail.com) Received: from qw-out-2122.google.com (qw-out-2122.google.com [74.125.92.27]) by mx1.freebsd.org (Postfix) with ESMTP id 1E7AA8FC18 for ; Sun, 17 Jan 2010 18:10:47 +0000 (UTC) Received: by qw-out-2122.google.com with SMTP id 5so478720qwd.7 for ; Sun, 17 Jan 2010 10:10:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=a++Ia4NG++O02v2OZDx7FNNt1o54kDsNSrZl3sa74Bg=; b=m+KSn0QTRwiDEHdLXPoX/isbE1OoMje2Rzn8Lq4rj2His1Dm8VO7zhKd5/qn5TURvO JA2IvYzs8F0bHDqAJ56Xa9pkOcLHqgXnBp+sbU2SMTBJl2ahqo89i+nd5T5Lbq2BQ22j UHZutL0mC3wEVAWH4CClqSvLixNN2IIBkPOeM= 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=FFZ5k/C4YnzNzajLAktHYjTTx0oFjf6cj+58HjmVc3LNbfplNYNs4J2DTNNQiwE1aI vnH1mPyLGirJUsLcLSmjrW96lOxX5jVt+87ygzJ7sT67EvG1pS7VFqlU4wEzZfdwydTM HFEWhmcepOQ6xvWo0j1wXNTRMxwx5Bwwi0ucQ= MIME-Version: 1.0 Received: by 10.220.122.229 with SMTP id m37mr71627vcr.75.1263751847142; Sun, 17 Jan 2010 10:10:47 -0800 (PST) In-Reply-To: <4B521FC2.4050402@errno.com> References: <4B521FC2.4050402@errno.com> Date: Sun, 17 Jan 2010 13:10:47 -0500 Message-ID: From: Russell Yount To: Sam Leffler Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-stable@freebsd.org Subject: Re: atheros broadcast/multicast corruption with multiple hostap's X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 17 Jan 2010 18:10:48 -0000 On Sat, Jan 16, 2010 at 3:21 PM, Sam Leffler wrote: > Russell Yount wrote: > >> It seems AP to client broadcasts/multicasts traffic is >> broken when using WPA2/802.11i with multiple hostapds in 8.0. >> >> Only the SSID associated with the last hostapd to be started has >> AP to client broadcasts/multicasts being delivered correctly. >> >> The AP and client are 8.0 freebsd systems althought I see same >> problems with windows XP as a client. >> >> The AP has 4 hostapds configured to use TLS with client certificates for >> authentication. (hostapd recompiled with HOSTAPD_CFLAGS=-DEAP_SERVER) >> The AP and client radio are shown as ath0: AR5212 mac 5.9 RF5112 phy 4.3 >> in dmesg. >> >> Client authenticate using client certificates associate correctly >> to all 4 SSIDs. Unicast traffic flows correctly between clients and AP >> for all for 4 SSIDs. Client to AP broadcast/multicast traffic works >> on of 4 SSIDs. AP to client broadcast/multicast traffic only works >> on 1 of the SSIDs. I have documented this using ARP broadcasts, >> but normal IP broadcasts also observed to corrupted. >> >> When an ARP request is send through the AP to an associated client >> it seems to be trashed on any of the SSID except the one associated >> with the last hostapd to be started. Here is the output of client side >> tcpdump showing the problems. >> >> In the first client side tcpdump with the hostapd associated with the SSID >> being associaed with the last hostapd started and the traffic flowing >> normally. >> >> In the second client side tcpdump with the hostapd associated with the >> SSID >> being not the last hostapd started the ARP request is resent multiple >> times >> and appears corrupted. >> >> I would really like to find a fix for this. >> Any help would be greatly appreciated. >> > > This sounds like the crypto encap of the frame is clobbering the mbuf > contents. You can verify this by setting up multiple vaps w/o WPA. If this > is the problem look for the mbuf copy logic for mcast frames and make sure a > deep copy is done. > > Sam > The four VAPs broadcast traffic works find without WPA if I do not start hostapds on them I have been trying to discovery why broadcast traffic only works correctly on the VAP associated with the last hostapd to be started. I have move with VAP has the working broadcast traffic by restarting the hostapd associated with it. It would seem something in the WPA/802.1x layer initialization remembers which hostapd was started last and that affected the crypto encap. I keep looking but do not see any place in the code that could account for this. It seems the corrupt crypto encap also happens on broadcast between stations. Please correct me if I am wrong: but when using hostapd normally traffic is bridged withing the card. So if a station sends to the VAP a broadcast it is actaully sending a non- broadcast frame to the AP and the AP sends the frame to all the other stations. -Russ From owner-freebsd-stable@FreeBSD.ORG Sun Jan 17 18:20: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 71FDF1065676; Sun, 17 Jan 2010 18:20:11 +0000 (UTC) (envelope-from jonc@chen.org.nz) Received: from chen.org.nz (ip-58-28-152-174.static-xdsl.xnet.co.nz [58.28.152.174]) by mx1.freebsd.org (Postfix) with ESMTP id 5FC628FC12; Sun, 17 Jan 2010 18:20:10 +0000 (UTC) Received: by chen.org.nz (Postfix, from userid 1000) id 9FF3CE044E; Mon, 18 Jan 2010 07:20:08 +1300 (NZDT) Date: Mon, 18 Jan 2010 07:20:08 +1300 From: Jonathan Chen To: Alexander Motin Message-ID: <20100117182008.GA3224@osiris.chen.org.nz> References: <1263723781.00208012.1263711003@10.7.7.3> <4B52E634.8010609@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4B52E634.8010609@FreeBSD.org> User-Agent: Mutt/1.4.2.3i Cc: freebsd-stable@freebsd.org Subject: Re: Drive light on all the time on 8-STABLE. X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Jan 2010 18:20:11 -0000 On Sun, Jan 17, 2010 at 12:28:04PM +0200, Alexander Motin wrote: > Jonathan Chen wrote: > > On the weekend, I moved my 8-STABLE installation (csup'd late Dec 2009) > > onto a new drive, a Seagate ST31000528AS CC3; and while the transfer was > > successful, I've noticed that the drive light is solidly on all the time, > > even if it boots into single-user. > > > > # uname -a > > FreeBSD osiris.chen.org.nz 8.0-STABLE FreeBSD 8.0-STABLE #1: Sat Jan 16 08:32:54 NZDT 2010 root@:/usr/obj/usr/src/sys/OSIRIS amd64 > > > > Is this something I should be worried about? There doesn't appear to > > be any disk I/O (I can't hear the disk grinding), but I may be wrong. > > The drive from which I transferred from did not exhibit this strange > > behaviour. > > > > Any advice would be welcome. > > What disk controller and driver do you use? It's just the out of the box ATA drivers. All the filesystems are UFS. I'm not sure how to find out what the disk controller is, so I've included the dmesg output. The motherboard is a Gigabyte GA-MA69G-S3H. Thanks. -- Jonathan Chen ---------------------------------------------------------------------- "Nyuck, nyuck, nyuck" - Curly --------------dmesg output----------------------------------- 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.0-STABLE #1: Sat Jan 16 08:32:54 NZDT 2010 root@:/usr/obj/usr/src/sys/OSIRIS amd64 Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: AMD Athlon(tm) 64 X2 Dual Core Processor 5600+ (2806.38-MHz K8-class CPU) Origin = "AuthenticAMD" Id = 0x40f33 Stepping = 3 Features=0x178bfbff Features2=0x2001 AMD Features=0xea500800 AMD Features2=0x1f real memory = 4294967296 (4096 MB) avail memory = 4105285632 (3915 MB) ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs FreeBSD/SMP: 1 package(s) x 2 core(s) cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 ioapic0: Changing APIC ID to 2 ioapic0 irqs 0-23 on motherboard kbd1 at kbdmux0 acpi0: on motherboard acpi0: [ITHREAD] acpi0: Power Button (fixed) acpi0: reservation of 0, a0000 (3) failed acpi0: reservation of 100000, cfde0000 (3) failed Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <32-bit timer at 3.579545MHz> port 0x4008-0x400b on acpi0 acpi_hpet0: iomem 0xfed00000-0xfed003ff on acpi0 Timecounter "HPET" frequency 14318180 Hz quality 900 acpi_button0: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pcib1: at device 2.0 on pci0 pci1: on pcib1 vgapci0: port 0xef00-0xef7f mem 0xfa000000-0xfaffffff,0xd0000000-0xdfffffff,0xf8000000-0xf9ffffff irq 18 at device 0.0 on pci1 atapci0: port 0xff00-0xff07,0xfe00-0xfe03,0xfd00-0xfd07,0xfc00-0xfc03,0xfb00-0xfb0f mem 0xfe02f000-0xfe02f3ff irq 22 at device 18.0 on pci0 atapci0: [ITHREAD] atapci0: AHCI v1.10 controller with 4 3Gbps ports, PM supported ata2: on atapci0 ata2: port is not ready (timeout 0ms) tfd = 000001d0 ata2: software reset clear timeout ata2: [ITHREAD] ata3: on atapci0 ata3: [ITHREAD] ata4: on atapci0 ata4: port is not ready (timeout 0ms) tfd = 000001d0 ata4: software reset clear timeout ata4: [ITHREAD] ata5: on atapci0 ata5: [ITHREAD] ohci0: mem 0xfe02e000-0xfe02efff irq 16 at device 19.0 on pci0 ohci0: [ITHREAD] usbus0: on ohci0 ohci1: mem 0xfe02d000-0xfe02dfff irq 17 at device 19.1 on pci0 ohci1: [ITHREAD] usbus1: on ohci1 ohci2: mem 0xfe02c000-0xfe02cfff irq 18 at device 19.2 on pci0 ohci2: [ITHREAD] usbus2: on ohci2 ohci3: mem 0xfe02b000-0xfe02bfff irq 17 at device 19.3 on pci0 ohci3: [ITHREAD] usbus3: on ohci3 ohci4: mem 0xfe02a000-0xfe02afff irq 18 at device 19.4 on pci0 ohci4: [ITHREAD] usbus4: on ohci4 ehci0: mem 0xfe029000-0xfe0290ff irq 19 at device 19.5 on pci0 ehci0: [ITHREAD] ehci0: AMD SB600/700 quirk applied usbus5: EHCI version 1.0 usbus5: on ehci0 pci0: at device 20.0 (no driver attached) atapci1: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xf900-0xf90f at device 20.1 on pci0 ata0: on atapci1 ata0: [ITHREAD] hdac0: mem 0xfe024000-0xfe027fff irq 16 at device 20.2 on pci0 hdac0: HDA Driver Revision: 20091113_0138 hdac0: [ITHREAD] isab0: at device 20.3 on pci0 isa0: on isab0 pcib2: at device 20.4 on pci0 pci2: on pcib2 xl0: <3Com 3c905-TX Fast Etherlink XL> port 0xdf00-0xdf3f irq 21 at device 7.0 on pci2 miibus0: on xl0 nsphy0: PHY 24 on miibus0 nsphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto xl0: Ethernet address: 00:60:97:a4:7f:82 xl0: [ITHREAD] fwohci0: mem 0xfdfff000-0xfdfff7ff,0xfdff8000-0xfdffbfff irq 22 at device 14.0 on pci2 fwohci0: [ITHREAD] fwohci0: OHCI version 1.10 (ROM=1) fwohci0: No. of Isochronous channels is 4. fwohci0: EUI64 00:1d:7d:00:00:f0:67:8b fwohci0: Phy 1394a available S400, 3 ports. fwohci0: Link S400, max_rec 2048 bytes. firewire0: on fwohci0 dcons_crom0: on firewire0 dcons_crom0: bus_addr 0x1574000 fwe0: on firewire0 if_fwe0: Fake Ethernet address: 02:1d:7d:f0:67:8b fwe0: Ethernet address: 02:1d:7d:f0:67:8b fwip0: on firewire0 fwip0: Firewire address: 00:1d:7d:00:00:f0:67:8b @ 0xfffe00000000, S400, maxrec 2048 fwohci0: Initiate bus reset fwohci0: fwohci_intr_core: BUS reset fwohci0: fwohci_intr_core: node_id=0x00000000, SelfID Count=1, CYCLEMASTER mode re0: port 0xdc00-0xdcff mem 0xfdffe000-0xfdffe0ff irq 23 at device 15.0 on pci2 re0: Chip rev. 0x18000000 re0: MAC rev. 0x00000000 miibus1: on re0 rgephy0: PHY 1 on miibus1 rgephy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-FDX, auto re0: Ethernet address: 00:1d:7d:9d:3f:1f re0: [FILTER] uart1: <16550 or compatible> port 0x2f8-0x2ff irq 3 on acpi0 uart1: [FILTER] ppc0: port 0x378-0x37f,0x778-0x77b irq 7 drq 3 on acpi0 ppc0: Generic chipset (ECP/PS2/NIBBLE) in COMPATIBLE mode ppc0: FIFO with 16/16/16 bytes threshold ppc0: [ITHREAD] ppbus0: on ppc0 ppbus0: IEEE1284 device found /NIBBLE/ECP ppbus0: Probing for PnP devices: ppbus0: PJL,MLC,PCLXL,PCL,POSTSCRIPT plip0: on ppbus0 plip0: [ITHREAD] lpt0: on ppbus0 lpt0: [ITHREAD] lpt0: Interrupt-driven port ppi0: on ppbus0 atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] atkbd0: [ITHREAD] atrtc0: port 0x70-0x73 on acpi0 cpu0: on acpi0 powernow0: on cpu0 cpu1: on acpi0 powernow1: on cpu1 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 Timecounters tick every 1.000 msec vboxdrv: fAsync=0 offMin=0xa4 offMax=0x29b supdrvGipCreate: omni timer not supported, falling back to synchronous mode ipfw2 (+ipv6) initialized, divert enabled, nat loadable, rule-based forwarding disabled, default to deny, logging disabled firewire0: 1 nodes, maxhop <= 0 cable IRM irm(0) (me) firewire0: bus manager 0 usbus0: 12Mbps Full Speed USB v1.0 usbus1: 12Mbps Full Speed USB v1.0 usbus2: 12Mbps Full Speed USB v1.0 usbus3: 12Mbps Full Speed USB v1.0 usbus4: 12Mbps Full Speed USB v1.0 usbus5: 480Mbps High Speed USB v2.0 ugen0.1: at usbus0 uhub0: on usbus0 ugen1.1: at usbus1 uhub1: on usbus1 ugen2.1: at usbus2 uhub2: on usbus2 ugen3.1: at usbus3 uhub3: on usbus3 ugen4.1: at usbus4 uhub4: on usbus4 ugen5.1: at usbus5 uhub5: on usbus5 acd0: DVDR at ata0-master UDMA33 ad4: 953868MB at ata2-master UDMA100 SATA 3Gb/s ad8: 305244MB at ata4-master UDMA100 SATA 3Gb/s hdac0: HDA Codec #3: Realtek ALC885 pcm0: at cad 3 nid 1 on hdac0 pcm1: at cad 3 nid 1 on hdac0 pcm2: at cad 3 nid 1 on hdac0 SMP: AP CPU #1 Launched! uhub0: 2 ports with 2 removable, self powered uhub1: 2 ports with 2 removable, self powered uhub2: 2 ports with 2 removable, self powered uhub3: 2 ports with 2 removable, self powered uhub4: 2 ports with 2 removable, self powered Root mount waiting for: usbus5 Root mount waiting for: usbus5 Root mount waiting for: usbus5 acd0: FAILURE - INQUIRY ILLEGAL REQUEST asc=0x24 ascq=0x00 sks=0x40 0x00 0x01 uhub5: 10 ports with 10 removable, self powered Root mount waiting for: usbus5 (probe0:ata0:0:0:0): TEST UNIT READY. CDB: 0 0 0 0 0 0 (probe0:ata0:0:0:0): CAM Status: SCSI Status Error (probe0:ata0:0:0:0): SCSI Status: Check Condition (probe0:ata0:0:0:0): NOT READY csi:0,0,bb,0 asc:3a,0 (probe0:ata0:0:0:0): Medium not present (probe0:ata0:0:0:0): Unretryable error cd0 at ata0 bus 0 scbus0 target 0 lun 0 cd0: Removable CD-ROM SCSI-0 device cd0: 33.000MB/s transfers cd0: Attempt to query device size failed: NOT READY, Medium not present Trying to mount root from ufs:/dev/ad4s2a From owner-freebsd-stable@FreeBSD.ORG Sun Jan 17 18:25: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 3E0C61065676 for ; Sun, 17 Jan 2010 18:25:38 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta10.westchester.pa.mail.comcast.net (qmta10.westchester.pa.mail.comcast.net [76.96.62.17]) by mx1.freebsd.org (Postfix) with ESMTP id DDDFD8FC14 for ; Sun, 17 Jan 2010 18:25:37 +0000 (UTC) Received: from omta22.westchester.pa.mail.comcast.net ([76.96.62.73]) by qmta10.westchester.pa.mail.comcast.net with comcast id WiJ01d00Q1ap0As5AiRdro; Sun, 17 Jan 2010 18:25:37 +0000 Received: from koitsu.dyndns.org ([98.248.46.159]) by omta22.westchester.pa.mail.comcast.net with comcast id WiRk1d00A3S48mS3iiRlXU; Sun, 17 Jan 2010 18:25:45 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 5F73C1E3033; Sun, 17 Jan 2010 10:25:35 -0800 (PST) Date: Sun, 17 Jan 2010 10:25:35 -0800 From: Jeremy Chadwick To: freebsd-stable@freebsd.org Message-ID: <20100117182535.GA21009@icarus.home.lan> References: <20100117064733.GA3119@osiris.chen.org.nz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100117064733.GA3119@osiris.chen.org.nz> User-Agent: Mutt/1.5.20 (2009-06-14) Subject: Re: Drive light on all the time on 8-STABLE. X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Jan 2010 18:25:38 -0000 On Sun, Jan 17, 2010 at 07:47:33PM +1300, Jonathan Chen wrote: > Hi, > > On the weekend, I moved my 8-STABLE installation (csup'd late Dec 2009) > onto a new drive, a Seagate ST31000528AS CC3; and while the transfer was > successful, I've noticed that the drive light is solidly on all the time, > even if it boots into single-user. > > # uname -a > FreeBSD osiris.chen.org.nz 8.0-STABLE FreeBSD 8.0-STABLE #1: Sat Jan 16 08:32:54 NZDT 2010 root@:/usr/obj/usr/src/sys/OSIRIS amd64 > > Is this something I should be worried about? There doesn't appear to > be any disk I/O (I can't hear the disk grinding), but I may be wrong. > The drive from which I transferred from did not exhibit this strange > behaviour. Is it possible for you to swap the drive out with another brand (e.g. Western Digital), or possibly a different model of Seagate? The reason I ask: I've seen what you describe, though it was many years ago -- but the similarity is that the disk was Seagate. I replaced the drive with one from WD and the behaviour disappeared. Footnote: I'm not slamming/insulting Seagate here, I'm just saying that in the past I've seen something similar. -- | 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 Sun Jan 17 18:45: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 33C821065670 for ; Sun, 17 Jan 2010 18:45:04 +0000 (UTC) (envelope-from sam@errno.com) Received: from ebb.errno.com (ebb.errno.com [69.12.149.25]) by mx1.freebsd.org (Postfix) with ESMTP id E95788FC14 for ; Sun, 17 Jan 2010 18:45:03 +0000 (UTC) Received: from ice.local ([10.0.0.115]) (authenticated bits=0) by ebb.errno.com (8.13.6/8.12.6) with ESMTP id o0HIj2QB081670 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 17 Jan 2010 10:45:03 -0800 (PST) (envelope-from sam@errno.com) Message-ID: <4B535AAE.3060308@errno.com> Date: Sun, 17 Jan 2010 10:45:02 -0800 From: Sam Leffler User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Russell Yount References: <4B521FC2.4050402@errno.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-DCC-sonic.net-Metrics: ebb.errno.com; whitelist Cc: freebsd-stable@freebsd.org Subject: Re: atheros broadcast/multicast corruption with multiple hostap's X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 17 Jan 2010 18:45:04 -0000 Russell Yount wrote: > > > On Sat, Jan 16, 2010 at 3:21 PM, Sam Leffler > wrote: > > Russell Yount wrote: > > It seems AP to client broadcasts/multicasts traffic is > broken when using WPA2/802.11i with multiple hostapds in 8.0. > > Only the SSID associated with the last hostapd to be started has > AP to client broadcasts/multicasts being delivered correctly. > > The AP and client are 8.0 freebsd systems althought I see same > problems with windows XP as a client. > > The AP has 4 hostapds configured to use TLS with client > certificates for > authentication. (hostapd recompiled with > HOSTAPD_CFLAGS=-DEAP_SERVER) > The AP and client radio are shown as ath0: AR5212 mac 5.9 RF5112 > phy 4.3 > in dmesg. > > Client authenticate using client certificates associate correctly > to all 4 SSIDs. Unicast traffic flows correctly between clients > and AP > for all for 4 SSIDs. Client to AP broadcast/multicast traffic works > on of 4 SSIDs. AP to client broadcast/multicast traffic only works > on 1 of the SSIDs. I have documented this using ARP broadcasts, > but normal IP broadcasts also observed to corrupted. > > When an ARP request is send through the AP to an associated client > it seems to be trashed on any of the SSID except the one associated > with the last hostapd to be started. Here is the output of > client side > tcpdump showing the problems. > > In the first client side tcpdump with the hostapd associated > with the SSID > being associaed with the last hostapd started and the traffic > flowing > normally. > > In the second client side tcpdump with the hostapd associated > with the SSID > being not the last hostapd started the ARP request is resent > multiple times > and appears corrupted. > > I would really like to find a fix for this. > Any help would be greatly appreciated. > > > This sounds like the crypto encap of the frame is clobbering the > mbuf contents. You can verify this by setting up multiple vaps w/o > WPA. If this is the problem look for the mbuf copy logic for mcast > frames and make sure a deep copy is done. > > Sam > > > > > The four VAPs broadcast traffic works find without WPA if I do not start > hostapds on them > > I have been trying to discovery why broadcast traffic only works > correctly on the VAP associated with the last hostapd to be started. I > have move with VAP has the working broadcast traffic by restarting the > hostapd > associated with it. > > It would seem something in the WPA/802.1x layer initialization remembers > which hostapd was started last and that affected the crypto encap. > > I keep looking but do not see any place in the code that could account > for this. > > It seems the corrupt crypto encap also happens on broadcast between > stations. > Please correct me if I am wrong: > but when using hostapd normally traffic is bridged withing the card. > So if a station sends to the VAP a broadcast it is actaully sending a > non- broadcast frame to the AP > and the AP sends the frame to all the other stations. I told you waht the likely problem is. Look in the net80211 layer in the kernel for the problem. Sam From owner-freebsd-stable@FreeBSD.ORG Sun Jan 17 19:53: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 631411065696; Sun, 17 Jan 2010 19:53:20 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (skuns.zoral.com.ua [91.193.166.194]) by mx1.freebsd.org (Postfix) with ESMTP id A4F8B8FC14; Sun, 17 Jan 2010 19:53:19 +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 o0HJr8hM008452 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 17 Jan 2010 21:53:08 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.3/8.14.3) with ESMTP id o0HJr8Bx043510; Sun, 17 Jan 2010 21:53:08 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.3/8.14.3/Submit) id o0HJr7Af043509; Sun, 17 Jan 2010 21:53:07 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Sun, 17 Jan 2010 21:53:07 +0200 From: Kostik Belousov To: David Xu Message-ID: <20100117195307.GJ62907@deviant.kiev.zoral.com.ua> References: <4B4D0293.3040704@rogers.com> <201001140941.46748.tijl@coosemans.org> <4B4FC56A.4020007@freebsd.org> <201001161451.39399.tijl@coosemans.org> <4B526C69.6050300@freebsd.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="SR0DFWOzPg+ymaCV" Content-Disposition: inline In-Reply-To: <4B526C69.6050300@freebsd.org> 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=-4.4 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: Gardner Bell , Tijl Coosemans , freebsd-stable@freebsd.org Subject: Re: process in STOP state X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 17 Jan 2010 19:53:20 -0000 --SR0DFWOzPg+ymaCV Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Jan 17, 2010 at 09:48:25AM +0800, David Xu wrote: > Tijl Coosemans wrote: > >On Friday 15 January 2010 02:31:22 David Xu wrote: > > =20 > >>Tijl Coosemans wrote: > >> =20 > >>>>Besides weird formatting of procstat -k output, I do not see > >>>>anything wrong in the state of the process. It got SIGSTOP, I am > >>>>sure. Attaching gdb helps because debugger gets signal reports > >>>>instead of target process getting the signal actions on signal > >>>>delivery. > >>>> > >>>>The only question is why the process gets SIGSTOP at all. > >>>> =20 > >>>Wine uses ptrace(2) sometimes. The SIGSTOP could have come from > >>>that. I recently submitted > >>>http://www.freebsd.org/cgi/query-pr.cgi?pr=3D142757 describing a > >>>problem with ptrace and signals, so you might want to give the > >>>kernel patch a try. > >>> =20 > >>The problem in your patch is that ksi pointer can not be hold across > >>thread sleeping, because once the process is resumed, there is no > >>guarantee that the thread will run first, once the signal came from > >>process's signal queue, other threads can remove the signal, and here > >>your sigqueue_take(ksi) is dangerous code. > >> =20 > > > >If other threads can run before the current thread then there's a > >second problem next to the one in the PR (current thread deletes > >signal that shouldn't be deleted). Then those other threads can see > >that the SIGSTOP bit (or another signal) is still set and stop the > >process a second time. This might be what happens in the OP's case. > > > >So, the signal has to be cleared before suspending the process, but > >then other threads can still deliver other signals which might change > >delivery order and I don't see any way around that besides introducing > >a per process signal lock that is also kept while the process is > >stopped. Comments? > > > > =20 > I don't have an idea now, we ever delivered signal to thread's queue, > though it may lose signal if thread exits, but it does not have the probl= em > you have described here, we may need to rethink how to fix the signal-lost > problem but still deliver signal to thread's queue, just an idea. >=20 I do think that signal shall be removed from the queue before ptracestop(), and I do not see a problem with other threads taking other signals. ptracestop() stops the whole process, and delivery order when signals go to different threads is somewhat vague due to scheduling events etc. So even if we guarantee that thread goes to userland for signal delivery before another thread, that another thread may still run handler observable earlier due to scheduler, swapping etc. I think your fix might be slightly reworked, making three points: 1. do remove signal from queue, and reinsert it into the _head_ of the _thread_ queue after. We already got it from the head, and current thread did not masked the signal. Since thread cannot change the mask in between, this signal is the first to be delivered to this thread, and current thread is still eligible for delivery. I added KSI_HEAD flag to adjust behaviour of sigqueue_add(). 2. Instead of adding signal to sq_kill, I just call sigqueue_add with NULL ksi. 3. To remove ksi from the queue, but not freeing it, I had to copy/paste the sigqueue_get() into sigqueue_steal(). It returns pointer to the removed ksi. I did not found good way to merge _get and steal. diff --git a/sys/kern/kern_sig.c b/sys/kern/kern_sig.c index 1c21bc5..80e5a07 100644 --- a/sys/kern/kern_sig.c +++ b/sys/kern/kern_sig.c @@ -316,6 +316,42 @@ sigqueue_get(sigqueue_t *sq, int signo, ksiginfo_t *si) return (signo); } =20 +static int +sigqueue_steal(sigqueue_t *sq, int signo, ksiginfo_t **si) +{ + struct proc *p; + struct ksiginfo *ksi, *next; + int count; + + KASSERT(sq->sq_flags & SQ_INIT, ("sigqueue not inited")); + p =3D sq->sq_proc; + count =3D 0; + + if (!SIGISMEMBER(sq->sq_signals, signo)) + return (0); + + if (SIGISMEMBER(sq->sq_kill, signo)) { + count++; + SIGDELSET(sq->sq_kill, signo); + } + + TAILQ_FOREACH_SAFE(ksi, &sq->sq_list, ksi_link, next) { + if (ksi->ksi_signo =3D=3D signo) { + if (count =3D=3D 0) { + TAILQ_REMOVE(&sq->sq_list, ksi, ksi_link); + ksi->ksi_sigq =3D NULL; + *si =3D ksi; + } + if (++count > 1) + break; + } + } + + if (count <=3D 1) + SIGDELSET(sq->sq_signals, signo); + return (signo); +} + void sigqueue_take(ksiginfo_t *ksi) { @@ -357,7 +393,10 @@ sigqueue_add(sigqueue_t *sq, int signo, ksiginfo_t *si) =20 /* directly insert the ksi, don't copy it */ if (si->ksi_flags & KSI_INS) { - TAILQ_INSERT_TAIL(&sq->sq_list, si, ksi_link); + if (si->ksi_flags & KSI_HEAD) + TAILQ_INSERT_HEAD(&sq->sq_list, si, ksi_link); + else + TAILQ_INSERT_TAIL(&sq->sq_list, si, ksi_link); si->ksi_sigq =3D sq; goto out_set_bit; } @@ -2492,6 +2531,7 @@ issignal(struct thread *td, int stop_allowed) struct sigacts *ps; struct sigqueue *queue; sigset_t sigpending; + ksiginfo_t *psi; int sig, prop, newsig; =20 p =3D td->td_proc; @@ -2529,24 +2569,24 @@ issignal(struct thread *td, int stop_allowed) if (p->p_flag & P_TRACED && (p->p_flag & P_PPWAIT) =3D=3D 0) { /* * If traced, always stop. + * Remove old signal from queue before the stop. + * XXX shrug off debugger, it causes siginfo to + * be thrown away. */ + queue =3D &td->td_sigqueue; + psi =3D NULL; + if (sigqueue_steal(queue, sig, &psi) =3D=3D 0) { + queue =3D &p->p_sigqueue; + sigqueue_steal(queue, sig, &psi); + } + =09 mtx_unlock(&ps->ps_mtx); newsig =3D ptracestop(td, sig); mtx_lock(&ps->ps_mtx); =20 if (sig !=3D newsig) { - ksiginfo_t ksi; - - queue =3D &td->td_sigqueue; - /* - * clear old signal. - * XXX shrug off debugger, it causes siginfo to - * be thrown away. - */ - if (sigqueue_get(queue, sig, &ksi) =3D=3D 0) { - queue =3D &p->p_sigqueue; - sigqueue_get(queue, sig, &ksi); - } + if (psi !=3D NULL && ksiginfo_tryfree(psi)) + p->p_pendingcnt--; =20 /* * If parent wants us to take the signal, @@ -2561,10 +2601,14 @@ issignal(struct thread *td, int stop_allowed) * Put the new signal into td_sigqueue. If the * signal is being masked, look for other signals. */ - SIGADDSET(queue->sq_signals, sig); + sigqueue_add(queue, sig, NULL); if (SIGISMEMBER(td->td_sigmask, sig)) continue; signotify(td); + } else { + if (psi !=3D NULL) + psi->ksi_flags |=3D KSI_INS | KSI_HEAD; + sigqueue_add(&td->td_sigqueue, sig, psi); } =20 /* diff --git a/sys/sys/signalvar.h b/sys/sys/signalvar.h index c9455c2..c35fe69 100644 --- a/sys/sys/signalvar.h +++ b/sys/sys/signalvar.h @@ -234,6 +234,7 @@ typedef struct ksiginfo { #define KSI_EXT 0x02 /* Externally managed ksi. */ #define KSI_INS 0x04 /* Directly insert ksi, not the copy */ #define KSI_SIGQ 0x08 /* Generated by sigqueue, might ret EGAIN. */ +#define KSI_HEAD 0x10 /* Insert into head, not tail. */ #define KSI_COPYMASK (KSI_TRAP|KSI_SIGQ) =20 #define KSI_ONQ(ksi) ((ksi)->ksi_sigq !=3D NULL) --SR0DFWOzPg+ymaCV Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (FreeBSD) iEYEARECAAYFAktTaqIACgkQC3+MBN1Mb4g7pACgxtQ036HFhit7SrcTRTZ1mzef SiMAni95XltrO6uwEPVuxqaYmT7gilQr =DXYA -----END PGP SIGNATURE----- --SR0DFWOzPg+ymaCV-- From owner-freebsd-stable@FreeBSD.ORG Sun Jan 17 19:18:58 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 06EA8106566C; Sun, 17 Jan 2010 19:18:58 +0000 (UTC) (envelope-from wahjava.ml@gmail.com) Received: from mail-yw0-f197.google.com (mail-yw0-f197.google.com [209.85.211.197]) by mx1.freebsd.org (Postfix) with ESMTP id 85CFE8FC13; Sun, 17 Jan 2010 19:18:57 +0000 (UTC) Received: by ywh35 with SMTP id 35so1767137ywh.7 for ; Sun, 17 Jan 2010 11:18:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:received:from:to :subject:organization:x-face:x-uptime:x-url:x-openpgp-id :x-openpgp-fingerprint:x-os:x-mailer:x-mail-morse:x-attribution :organisation:date:message-id:user-agent:face:mime-version :content-type; bh=3PKfXHfa5olR7bQQ9pofKNzEJfd44n0qp+KXNtByis0=; b=C9IXs06MFlxZ86UKM23MfMi+B7pb2ekBo6q9sodqsxNcNjwtzcckI69eUL1IDR+Oyi ZskD6jDfEh7XWEpZmdYRgWdnjUB6uHs0Fb5C22II43XB/eU1sTyIXPNS+ta60UVBTP0l KdWRwdpE6gxWGeh47TnV/FbEn4kKgbCv86syk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:from:to:subject:organization:x-face:x-uptime:x-url :x-openpgp-id:x-openpgp-fingerprint:x-os:x-mailer:x-mail-morse :x-attribution:organisation:date:message-id:user-agent:face :mime-version:content-type; b=CnHOg3/f/rF4M7L7JnhorbkxXyhNDRU1Jk1O1qsIFoR0MuCQlx7zxZpLY+xS6H8RA0 0geh6oyjN/FH57gW7vF49P/vu6+/sQRZU95FePbAr281kHXlP9a+SJ+z0hPiH4o5QYep CVtVJqaxMS2TT2D1sU+FwowjT8pb3I8MbhWt0= Received: by 10.151.3.21 with SMTP id f21mr2999570ybi.171.1263754108745; Sun, 17 Jan 2010 10:48:28 -0800 (PST) Received: from chateau.d.if ([122.161.225.161]) by mx.google.com with ESMTPS id 4sm1675626ywg.43.2010.01.17.10.48.27 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sun, 17 Jan 2010 10:48:28 -0800 (PST) Sender: Ashish SHUKLA Received: from chateau.d.if (chateau.d.if [IPv6:::1]) by chateau.d.if (Postfix) with ESMTP id 29D995084F; Mon, 18 Jan 2010 00:18:16 +0530 (IST) From: wahjava.ml@gmail.com (Ashish SHUKLA) To: wahjava@gmail.com Organization: alt.religion.emacs X-Face: )vGQ9yK7Y$Flebu1C>(B\gYBm)[$zfKM+p&TT[[JWl6:]S>cc$%-z7-`46Zf0B*syL.C]oCq[upTG~zuS0.$"_%)|Q@$hA=9{3l{%u^h3jJ^Zl; t7 X-Uptime: 12:12AM up 3:45, 5 users, load averages: 1.11, 1.08, 1.06 X-URL: http://762e5e74.wordpress.com/ X-OpenPGP-ID: 762E5E74 X-OpenPGP-Fingerprint: 1E00 4679 77E4 F8EE 2E4B 56F2 1F2F 8410 762E 5E74 X-OS: FreeBSD on FreeBSD 8.0-RELEASE kernel on amd64 architecture X-Mailer: Gnus v5.13 X-Mail-Morse: .-- .- .... .--- .- ...- .- .--.-. --. -- .- .. .-.. .-.-.- -.-. --- -- X-Attribution: =?utf-8?B?4KSG4KS24KWA4KS3?= Organisation: alt.religion.emacs Date: Mon, 18 Jan 2010 00:18:15 +0530 Message-ID: <86my0c1sb4.fsf@chateau.d.if> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (amd64-portbld-freebsd8.0) Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwBAMAAAClLOS0AAAAJ1BMVEWpqal/f39tbW1jY2Md HR2goKCenp6UlJROTk7////9/f35+fnT09ORJdieAAACVklEQVQ4jXXUP2vbQBQA8AvUTkgz5OzY Z0iGWhpS6BSrkECn0mvx0MEJ6AjtYrfoBCVDlD8naJYmNlRfwZq8+mkKlIZaGpJSYmP7Q/XkJDrJ Td8i/H68u3vHPaPufwLdf32AMA4A6GcAgvAamY1pOJiDIFqicTwLswDhfr3uxfFtkAY/GFHPMwzD 8zpnACmIOnE6js7rQb+v4NJrG9od0C+QgpHMy5jBewV+UDSMWiw1Y4fWfyV7+NGFzDsYa3pth9LJ Q4XvXxFHcJRvHOmygn5NAEabnDcQQguarnfoiwSCJ99jmKKcphsZONmWsDK9Ro7cvZOCtQdg8nje egLhc2LNlkLmsezzTFUUy5w18ocox/f0LaLgJy0zO75zk+9pp85GAj36xjqhdI0y3tq2m4dqqcWX zQWBTz8L1irvolXV4J+3q7eCDgVnttjNq6X8H+9KOZsuNk1uCzx8pSp+E9HImfJOTLdcGqo+YKnG EIovizkEn48V7BO+ch2DXcD4ENSpWiU+q8hjjbgTBZCXnZtyj0Ws4Q1Q0B2WXFtYZo65Bbyeeldw RS6qFueM80LlLA29YlVwGRYvFD+kwI/0O+A2PlpOP9GwslUVciHuYGechuBTp922YiDZCrghTknm XSyOM+D3aoRZlo0Jb42zY7DN4p2x4AeZ+QAYutx1sHwTHzMT5cMNduQ9yW3GczN4KZ86kb0c9O8T yXDeFqpl2fryPEAYGXIlezAPXYh2NgVr/gvdoHIuDwuPwOhcWE8f8mmICq41eATkn8x0kuRTIKcB wE9+/QUtiiAnYcaN7wAAAABJRU5ErkJggg== MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailman-Approved-At: Sun, 17 Jan 2010 20:29:13 +0000 Cc: Subject: Apologies for the bounced 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: Sun, 17 Jan 2010 19:18:58 -0000 Hi everyone Due to some issues with my mailserver configuration. Some of the messages bounced back on the list. Please accept my apologies for that inconvenience. And I make sure not to repeat this again. Sorry again, Ashish SHUKLA -- They who can give up essential liberty to obtain a little temporary safety, deserve neither liberty nor safety. -- Benjamin Franklin, Memoirs of the life and writings of Benjamin Franklin From owner-freebsd-stable@FreeBSD.ORG Sun Jan 17 23:21: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 2C999106566B for ; Sun, 17 Jan 2010 23:21:21 +0000 (UTC) (envelope-from garrettmoore@gmail.com) Received: from mail-iw0-f177.google.com (mail-iw0-f177.google.com [209.85.223.177]) by mx1.freebsd.org (Postfix) with ESMTP id E1E188FC13 for ; Sun, 17 Jan 2010 23:21:20 +0000 (UTC) Received: by iwn7 with SMTP id 7so1721861iwn.7 for ; Sun, 17 Jan 2010 15:21:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type; bh=yewUqBfp/mAhdJIIQFiVWzhD84OAYIsNJBWFPJPmcrQ=; b=USjssp0CF3Y39THQqpqFhvuxkzXaz1DBr0+uikOL0ql2JaQKs1fjZ8NmOobB32VgRJ i7d9pmnrFzVaZKiM4pyu2pST+Rf6ET8X3M3Te8qxvOhSy/8BeLWuh89cf9AaOT5e7XV0 dvelhv3Ip6y8hYqmzXedKKSfWdsLCOWXM7BFw= 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=KMzFzUVwJszibTOoDmvnDX2AbBOQgIWuwloeMa3u/2bofuwbIfw845AXsazp7J+tBD v22MtV7xR4GZM9rNgv5ry5NmmCDjB10fyukHv3POH7y5ldWiqvIQ9p4/zGfn9+QTZHB7 wnHDpX0pkq+Aq1IzCHyQadVVLwB7X+FtJKD90= MIME-Version: 1.0 Received: by 10.231.59.7 with SMTP id j7mr3661296ibh.12.1263770480097; Sun, 17 Jan 2010 15:21:20 -0800 (PST) In-Reply-To: <7346c5c61001091706m45a3a2a5k3ca8bb0c4bec5ea8@mail.gmail.com> References: <7346c5c61001030842r7dc76199y51e4c1c90a3eea6e@mail.gmail.com> <7346c5c61001080831w375d158fu5b1996ee58cb0f8d@mail.gmail.com> <2ae8edf31001091051l156cb57alf549cfe06f1c7197@mail.gmail.com> <7346c5c61001091640w1a0ffb5y3ffe97cb88c76436@mail.gmail.com> <20100110005621.GA45015@icarus.home.lan> <7346c5c61001091706m45a3a2a5k3ca8bb0c4bec5ea8@mail.gmail.com> Date: Sun, 17 Jan 2010 18:21:20 -0500 Message-ID: <7346c5c61001171521w1ca4738w98e8fcca24643cda@mail.gmail.com> From: Garrett Moore To: freebsd-stable@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Re: ZFS performance degradation over time X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 17 Jan 2010 23:21:21 -0000 I upgraded my system to 8GB of ram to see if that would help. It hasn't made much of a difference. After having rTorrent running for a while, my performance again tanked. Around 6.5GB of memory was showing as 'Active' according to top. Copying a file from the zpool to another location on the zpool had the following performance (from zpool iostat 1): tank 2.57T 8.31T 11 215 273K 745K tank 2.57T 8.31T 22 97 816K 540K tank 2.57T 8.31T 6 67 13.5K 887K tank 2.57T 8.31T 5 101 639K 190K tank 2.57T 8.31T 14 81 1.14M 154K tank 2.57T 8.31T 6 152 12.5K 897K tank 2.57T 8.31T 11 153 143K 790K tank 2.57T 8.31T 3 172 134K 566K tank 2.57T 8.31T 3 105 7.48K 699K tank 2.57T 8.31T 5 136 138K 383K Combined read/write of <2MB/s -- pretty pathetic. I then tried Artem's trick, running ` perl -e '$x="x"x3000000000'` to force a swapout. This command completed in about 10 seconds, and I then had >5GB of memory showing as 'Free' according to top. Checking zpool iostat 1 again showed: tank 2.57T 8.31T 375 477 46.1M 57.9M tank 2.57T 8.31T 18 472 1.75M 44.8M tank 2.57T 8.31T 129 0 16.1M 0 tank 2.57T 8.31T 428 0 53.2M 0 tank 2.57T 8.31T 262 947 31.8M 103M tank 2.57T 8.30T 80 105 9.61M 196K tank 2.57T 8.30T 612 0 75.8M 0 tank 2.57T 8.30T 155 951 18.4M 103M tank 2.57T 8.30T 662 0 82.1M 0 tank 2.57T 8.30T 176 945 21.1M 103M Which is obviously much better, and a respectable rate of performance. This was all done during the same single `copy` command - I did not stop/restart the copy when running the perl oneliner. So it seems based on this that ZFS is keeping too much data cached and not being smart about when to release 'old' cache entries in favour of new ones. Any suggestions at this point? The only tuning I have done so far is to disable prefetch, since my primary usage is streaming HD media, and prefetch has been known to cause problems in that situation. From owner-freebsd-stable@FreeBSD.ORG Mon Jan 18 01:48: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 2146F1065679 for ; Mon, 18 Jan 2010 01:48:28 +0000 (UTC) (envelope-from davidxu@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id E663B8FC08; Mon, 18 Jan 2010 01:48:27 +0000 (UTC) Received: from apple.my.domain (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id o0I1mOfL022561; Mon, 18 Jan 2010 01:48:25 GMT (envelope-from davidxu@freebsd.org) Message-ID: <4B53BDE8.9000509@freebsd.org> Date: Mon, 18 Jan 2010 09:48:24 +0800 From: David Xu User-Agent: Thunderbird 2.0.0.9 (X11/20080612) MIME-Version: 1.0 To: Kostik Belousov References: <4B4D0293.3040704@rogers.com> <201001140941.46748.tijl@coosemans.org> <4B4FC56A.4020007@freebsd.org> <201001161451.39399.tijl@coosemans.org> <4B526C69.6050300@freebsd.org> <20100117195307.GJ62907@deviant.kiev.zoral.com.ua> In-Reply-To: <20100117195307.GJ62907@deviant.kiev.zoral.com.ua> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Gardner Bell , Tijl Coosemans , freebsd-stable@freebsd.org Subject: Re: process in STOP state X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 18 Jan 2010 01:48:28 -0000 Kostik Belousov wrote: > On Sun, Jan 17, 2010 at 09:48:25AM +0800, David Xu wrote: >> Tijl Coosemans wrote: >>> On Friday 15 January 2010 02:31:22 David Xu wrote: >>> >>>> Tijl Coosemans wrote: >>>> >>>>>> Besides weird formatting of procstat -k output, I do not see >>>>>> anything wrong in the state of the process. It got SIGSTOP, I am >>>>>> sure. Attaching gdb helps because debugger gets signal reports >>>>>> instead of target process getting the signal actions on signal >>>>>> delivery. >>>>>> >>>>>> The only question is why the process gets SIGSTOP at all. >>>>>> >>>>> Wine uses ptrace(2) sometimes. The SIGSTOP could have come from >>>>> that. I recently submitted >>>>> http://www.freebsd.org/cgi/query-pr.cgi?pr=142757 describing a >>>>> problem with ptrace and signals, so you might want to give the >>>>> kernel patch a try. >>>>> >>>> The problem in your patch is that ksi pointer can not be hold across >>>> thread sleeping, because once the process is resumed, there is no >>>> guarantee that the thread will run first, once the signal came from >>>> process's signal queue, other threads can remove the signal, and here >>>> your sigqueue_take(ksi) is dangerous code. >>>> >>> If other threads can run before the current thread then there's a >>> second problem next to the one in the PR (current thread deletes >>> signal that shouldn't be deleted). Then those other threads can see >>> that the SIGSTOP bit (or another signal) is still set and stop the >>> process a second time. This might be what happens in the OP's case. >>> >>> So, the signal has to be cleared before suspending the process, but >>> then other threads can still deliver other signals which might change >>> delivery order and I don't see any way around that besides introducing >>> a per process signal lock that is also kept while the process is >>> stopped. Comments? >>> >>> >> I don't have an idea now, we ever delivered signal to thread's queue, >> though it may lose signal if thread exits, but it does not have the problem >> you have described here, we may need to rethink how to fix the signal-lost >> problem but still deliver signal to thread's queue, just an idea. >> > > I do think that signal shall be removed from the queue before > ptracestop(), and I do not see a problem with other threads taking other > signals. ptracestop() stops the whole process, and delivery order when > signals go to different threads is somewhat vague due to scheduling > events etc. So even if we guarantee that thread goes to userland for > signal delivery before another thread, that another thread may still run > handler observable earlier due to scheduler, swapping etc. > > I think your fix might be slightly reworked, making three points: > 1. do remove signal from queue, and reinsert it into the _head_ of the > _thread_ queue after. We already got it from the head, and current > thread did not masked the signal. Since thread cannot change the mask in > between, this signal is the first to be delivered to this thread, and > current thread is still eligible for delivery. I added KSI_HEAD flag to > adjust behaviour of sigqueue_add(). > > 2. Instead of adding signal to sq_kill, I just call sigqueue_add > with NULL ksi. > > 3. To remove ksi from the queue, but not freeing it, I had to copy/paste > the sigqueue_get() into sigqueue_steal(). It returns pointer to the > removed ksi. I did not found good way to merge _get and steal. > > diff --git a/sys/kern/kern_sig.c b/sys/kern/kern_sig.c > index 1c21bc5..80e5a07 100644 > --- a/sys/kern/kern_sig.c > +++ b/sys/kern/kern_sig.c > @@ -316,6 +316,42 @@ sigqueue_get(sigqueue_t *sq, int signo, ksiginfo_t *si) > return (signo); > } > > +static int > +sigqueue_steal(sigqueue_t *sq, int signo, ksiginfo_t **si) > +{ > + struct proc *p; > + struct ksiginfo *ksi, *next; > + int count; > + > + KASSERT(sq->sq_flags & SQ_INIT, ("sigqueue not inited")); > + p = sq->sq_proc; > + count = 0; > + > + if (!SIGISMEMBER(sq->sq_signals, signo)) > + return (0); > + > + if (SIGISMEMBER(sq->sq_kill, signo)) { > + count++; > + SIGDELSET(sq->sq_kill, signo); > + } > + > + TAILQ_FOREACH_SAFE(ksi, &sq->sq_list, ksi_link, next) { > + if (ksi->ksi_signo == signo) { > + if (count == 0) { > + TAILQ_REMOVE(&sq->sq_list, ksi, ksi_link); > + ksi->ksi_sigq = NULL; > + *si = ksi; > + } > + if (++count > 1) > + break; > + } > + } > + > + if (count <= 1) > + SIGDELSET(sq->sq_signals, signo); > + return (signo); > +} > + > void > sigqueue_take(ksiginfo_t *ksi) > { > @@ -357,7 +393,10 @@ sigqueue_add(sigqueue_t *sq, int signo, ksiginfo_t *si) > > /* directly insert the ksi, don't copy it */ > if (si->ksi_flags & KSI_INS) { > - TAILQ_INSERT_TAIL(&sq->sq_list, si, ksi_link); > + if (si->ksi_flags & KSI_HEAD) > + TAILQ_INSERT_HEAD(&sq->sq_list, si, ksi_link); > + else > + TAILQ_INSERT_TAIL(&sq->sq_list, si, ksi_link); > si->ksi_sigq = sq; > goto out_set_bit; > } > @@ -2492,6 +2531,7 @@ issignal(struct thread *td, int stop_allowed) > struct sigacts *ps; > struct sigqueue *queue; > sigset_t sigpending; > + ksiginfo_t *psi; > int sig, prop, newsig; > > p = td->td_proc; > @@ -2529,24 +2569,24 @@ issignal(struct thread *td, int stop_allowed) > if (p->p_flag & P_TRACED && (p->p_flag & P_PPWAIT) == 0) { > /* > * If traced, always stop. > + * Remove old signal from queue before the stop. > + * XXX shrug off debugger, it causes siginfo to > + * be thrown away. > */ > + queue = &td->td_sigqueue; > + psi = NULL; > + if (sigqueue_steal(queue, sig, &psi) == 0) { > + queue = &p->p_sigqueue; > + sigqueue_steal(queue, sig, &psi); > + } > + > mtx_unlock(&ps->ps_mtx); > newsig = ptracestop(td, sig); > mtx_lock(&ps->ps_mtx); > > if (sig != newsig) { > - ksiginfo_t ksi; > - > - queue = &td->td_sigqueue; > - /* > - * clear old signal. > - * XXX shrug off debugger, it causes siginfo to > - * be thrown away. > - */ > - if (sigqueue_get(queue, sig, &ksi) == 0) { > - queue = &p->p_sigqueue; > - sigqueue_get(queue, sig, &ksi); > - } > + if (psi != NULL && ksiginfo_tryfree(psi)) > + p->p_pendingcnt--; > > /* > * If parent wants us to take the signal, > @@ -2561,10 +2601,14 @@ issignal(struct thread *td, int stop_allowed) > * Put the new signal into td_sigqueue. If the > * signal is being masked, look for other signals. > */ > - SIGADDSET(queue->sq_signals, sig); > + sigqueue_add(queue, sig, NULL); > if (SIGISMEMBER(td->td_sigmask, sig)) > continue; > signotify(td); > + } else { > + if (psi != NULL) > + psi->ksi_flags |= KSI_INS | KSI_HEAD; > + sigqueue_add(&td->td_sigqueue, sig, psi); > } > > /* > diff --git a/sys/sys/signalvar.h b/sys/sys/signalvar.h > index c9455c2..c35fe69 100644 > --- a/sys/sys/signalvar.h > +++ b/sys/sys/signalvar.h > @@ -234,6 +234,7 @@ typedef struct ksiginfo { > #define KSI_EXT 0x02 /* Externally managed ksi. */ > #define KSI_INS 0x04 /* Directly insert ksi, not the copy */ > #define KSI_SIGQ 0x08 /* Generated by sigqueue, might ret EGAIN. */ > +#define KSI_HEAD 0x10 /* Insert into head, not tail. */ > #define KSI_COPYMASK (KSI_TRAP|KSI_SIGQ) > > #define KSI_ONQ(ksi) ((ksi)->ksi_sigq != NULL) In the patch, even if you removed the KSI from queue, current thread still holds the pointer and sleeps, this might be not a good idea since other code try to implement reliable signal like SIGCHLD and AIO signal and mqueue, those code may remove the signal from queue and free it, if they run before the current thread, they will do. otherwise, we have to use unreliable signals, that means, when a realtime signal is delivered, sig_info is lost and only a bit set in sq_kill like sigqueue() syscall does, this is not perfect. From owner-freebsd-stable@FreeBSD.ORG Mon Jan 18 04:11: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 D52491065670 for ; Mon, 18 Jan 2010 04:11:50 +0000 (UTC) (envelope-from jonc@chen.org.nz) Received: from chen.org.nz (ip-58-28-152-174.static-xdsl.xnet.co.nz [58.28.152.174]) by mx1.freebsd.org (Postfix) with ESMTP id 797A78FC1A for ; Mon, 18 Jan 2010 04:11:50 +0000 (UTC) Received: by chen.org.nz (Postfix, from userid 1000) id 4FA71E040A; Mon, 18 Jan 2010 17:11:48 +1300 (NZDT) Date: Mon, 18 Jan 2010 17:11:48 +1300 From: Jonathan Chen To: freebsd-stable@freebsd.org Message-ID: <20100118041148.GA3764@osiris.chen.org.nz> References: <1263723781.00208012.1263711003@10.7.7.3> <4B52E634.8010609@FreeBSD.org> <20100117182008.GA3224@osiris.chen.org.nz> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100117182008.GA3224@osiris.chen.org.nz> User-Agent: Mutt/1.4.2.3i Subject: Re: Drive light on all the time on 8-STABLE. X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jan 2010 04:11:50 -0000 On Mon, Jan 18, 2010 at 07:20:08AM +1300, Jonathan Chen wrote: > On Sun, Jan 17, 2010 at 12:28:04PM +0200, Alexander Motin wrote: > > Jonathan Chen wrote: > > > On the weekend, I moved my 8-STABLE installation (csup'd late Dec 2009) > > > onto a new drive, a Seagate ST31000528AS CC3; and while the transfer was > > > successful, I've noticed that the drive light is solidly on all the time, > > > even if it boots into single-user. > > > > > > # uname -a > > > FreeBSD osiris.chen.org.nz 8.0-STABLE FreeBSD 8.0-STABLE #1: Sat Jan 16 08:32:54 NZDT 2010 root@:/usr/obj/usr/src/sys/OSIRIS amd64 > > > > > > Is this something I should be worried about? There doesn't appear to > > > be any disk I/O (I can't hear the disk grinding), but I may be wrong. > > > The drive from which I transferred from did not exhibit this strange > > > behaviour. > > > > > > Any advice would be welcome. > > > > What disk controller and driver do you use? > > It's just the out of the box ATA drivers. All the filesystems are UFS. > I'm not sure how to find out what the disk controller is, so I've > included the dmesg output. The motherboard is a Gigabyte GA-MA69G-S3H. I've rebooted the box a few times, and have observed that the drive LED flickers normally up until: > atapci0: port 0xff00-0xff07,0xfe00-0xfe03,0xfd00-0xfd07,0xfc00-0xfc03,0xfb00-0xfb0f mem 0xfe02f000-0xfe02f3ff irq 22 at device 18.0 on pci0 > atapci0: [ITHREAD] > atapci0: AHCI v1.10 controller with 4 3Gbps ports, PM supported > ata2: on atapci0 > ata2: port is not ready (timeout 0ms) tfd = 000001d0 > ata2: software reset clear timeout > ata2: [ITHREAD] At which point after the software reset, the drive LED stays solidly on from then onwards. Cheers. -- Jonathan Chen ---------------------------------------------------------------------- When you don't know what you are doing, do it neatly. From owner-freebsd-stable@FreeBSD.ORG Mon Jan 18 06:35: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 0A6AD1065672 for ; Mon, 18 Jan 2010 06:35:27 +0000 (UTC) (envelope-from peterjeremy@acm.org) Received: from mail17.syd.optusnet.com.au (mail17.syd.optusnet.com.au [211.29.132.198]) by mx1.freebsd.org (Postfix) with ESMTP id 8DBFB8FC15 for ; Mon, 18 Jan 2010 06:35:26 +0000 (UTC) Received: from server.vk2pj.dyndns.org (c122-106-232-148.belrs3.nsw.optusnet.com.au [122.106.232.148]) by mail17.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id o0I6ZKlE027606 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 18 Jan 2010 17:35:21 +1100 X-Bogosity: Ham, spamicity=0.000000 Received: from server.vk2pj.dyndns.org (localhost.vk2pj.dyndns.org [127.0.0.1]) by server.vk2pj.dyndns.org (8.14.3/8.14.3) with ESMTP id o0I6ZFih068046; Mon, 18 Jan 2010 17:35:15 +1100 (EST) (envelope-from peter@server.vk2pj.dyndns.org) Received: (from peter@localhost) by server.vk2pj.dyndns.org (8.14.3/8.14.3/Submit) id o0I6ZFww068045; Mon, 18 Jan 2010 17:35:15 +1100 (EST) (envelope-from peter) Date: Mon, 18 Jan 2010 17:35:15 +1100 From: Peter Jeremy To: Jonathan Chen Message-ID: <20100118063515.GA64544@server.vk2pj.dyndns.org> References: <1263723781.00208012.1263711003@10.7.7.3> <4B52E634.8010609@FreeBSD.org> <20100117182008.GA3224@osiris.chen.org.nz> <20100118041148.GA3764@osiris.chen.org.nz> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="BXVAT5kNtrzKuDFl" Content-Disposition: inline In-Reply-To: <20100118041148.GA3764@osiris.chen.org.nz> X-PGP-Key: http://members.optusnet.com.au/peterjeremy/pubkey.asc User-Agent: Mutt/1.5.20 (2009-06-14) Cc: freebsd-stable@freebsd.org Subject: Re: Drive light on all the time on 8-STABLE. X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jan 2010 06:35:27 -0000 --BXVAT5kNtrzKuDFl Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2010-Jan-18 17:11:48 +1300, Jonathan Chen wrote: >On Mon, Jan 18, 2010 at 07:20:08AM +1300, Jonathan Chen wrote: >> On Sun, Jan 17, 2010 at 12:28:04PM +0200, Alexander Motin wrote: >> > Jonathan Chen wrote: >> > > On the weekend, I moved my 8-STABLE installation (csup'd late Dec 20= 09) >> > > onto a new drive, a Seagate ST31000528AS CC3; and while the transfer= was >> > > successful, I've noticed that the drive light is solidly on all the = time, >> > > even if it boots into single-user. =2E.. >I've rebooted the box a few times, and have observed that the drive >LED flickers normally up until: > >> atapci0: port 0xff00-0xff07,0xfe00-0xfe0= 3,0xfd00-0xfd07,0xfc00-0xfc03,0xfb00-0xfb0f mem 0xfe02f000-0xfe02f3ff irq 2= 2 at device 18.0 on pci0 I have exactly the same behaviour on my Gigabyte GA-MA770-DS3 with 3 Samsung HD103UJ HDDs and a Pioneer DVR-215 DVD-RW. I'm running 8.0-STABLE/amd64 from the end of November. It looks like it might be a bug in the IXP600 SATA driver. --=20 Peter Jeremy --BXVAT5kNtrzKuDFl Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (FreeBSD) iEYEARECAAYFAktUASMACgkQ/opHv/APuIcWDQCgrhm3MADwUvHBPAxOvugQ33FL +vMAnjKmnEjKys4/tNSmz5bSgATuGg/v =8JoP -----END PGP SIGNATURE----- --BXVAT5kNtrzKuDFl-- From owner-freebsd-stable@FreeBSD.ORG Mon Jan 18 07: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 CE2C6106568B for ; Mon, 18 Jan 2010 07:33:27 +0000 (UTC) (envelope-from graham@menhennitt.com.au) Received: from mail01.syd.optusnet.com.au (mail01.syd.optusnet.com.au [211.29.132.182]) by mx1.freebsd.org (Postfix) with ESMTP id 4C3578FC20 for ; Mon, 18 Jan 2010 07:33:26 +0000 (UTC) Received: from maxwell.mencon.com.au (c122-107-224-152.eburwd5.vic.optusnet.com.au [122.107.224.152]) by mail01.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id o0I7XIH3001723; Mon, 18 Jan 2010 18:33:20 +1100 Received: from [203.2.73.73] (chief.mencon.com.au [203.2.73.73]) by maxwell.mencon.com.au (Postfix) with ESMTP id AE20E5D4E; Mon, 18 Jan 2010 18:33:09 +1100 (EST) Message-ID: <4B540EC3.7040506@menhennitt.com.au> Date: Mon, 18 Jan 2010 18:33:23 +1100 From: Graham Menhennitt User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Sam Leffler , FreeBSD stable References: <0122e9480533dc61e94ec7d00678aeaf.squirrel@lamneth> <0c682ad7769fbd678a6835f041d0c791.squirrel@lamneth> <4B522102.1050805@errno.com> In-Reply-To: <4B522102.1050805@errno.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Subject: Re: ath hostap 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: Mon, 18 Jan 2010 07:33:27 -0000 Sam Leffler wrote: > Are both machines SMP? Stuck beacons typically arise for two reasons: > the channel is busy and the ap can't get on the air to send the frame, > or the host/bus is overloaded and cannot meet the realtime > requirements of posting the beacon frame in time to hit the beacon > transmit schedule. I can't tell from the above info whether either > might be possible. Sam, I'm having a similar problem with the "stuck beacon" message (see my request at http://www.mail-archive.com/freebsd-stable@freebsd.org/msg107619.html). What info do you need to be able to diagnose it? Thanks for any help, Graham Menhennitt From owner-freebsd-stable@FreeBSD.ORG Mon Jan 18 11:40: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 11ABE106568F for ; Mon, 18 Jan 2010 11:40:46 +0000 (UTC) (envelope-from alexander@leidinger.net) Received: from mail.ebusiness-leidinger.de (mail.ebusiness-leidinger.de [217.11.53.44]) by mx1.freebsd.org (Postfix) with ESMTP id 909398FC0C for ; Mon, 18 Jan 2010 11:40:45 +0000 (UTC) Received: from outgoing.leidinger.net (pD9E2D341.dip.t-dialin.net [217.226.211.65]) by mail.ebusiness-leidinger.de (Postfix) with ESMTPSA id 3357A844043; Mon, 18 Jan 2010 12:40:38 +0100 (CET) Received: from webmail.leidinger.net (webmail.leidinger.net [192.168.1.102]) by outgoing.leidinger.net (Postfix) with ESMTP id C54BA114E99; Mon, 18 Jan 2010 12:40:34 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=Leidinger.net; s=outgoing-alex; t=1263814835; bh=LtIGb3kfb+a1s8G6wtc4b+1mQMQRlOWDwbWCCbXegFE=; h=Message-ID:Date:From:To:Cc:Subject:References:In-Reply-To: MIME-Version:Content-Type:Content-Transfer-Encoding; b=FXzb0Ufs8EHwKWficPxV2acjygFSqe8vOsJfb6vADWnuBlFiQiIdE2NMCiI3qP38y 5nJ6lz+dgHokDpNeg7tGXqfRPG4gTLqvF1rAV6UPLQU0u47QaP/md1lgViC0nPBXIp EaEFwvpuQ8otooxyfVRAKqV3MDnY+vQ6MEzSOhBn0GrOh9WSgNeIdtOR8r22tGgh64 rXahra87uR90jXe8L9i2jHfnJFHTYjRUszjPCUitI/8wzq0FrRvuVcE1SjtsCqW7dK Xkdnnjso6z5VvK3mR22lvcP5ockYKm21TJ6uSVDxgn+7LbINN2yVmHLO+Obo1BKW++ GZyrORmFQPBUg== Received: (from www@localhost) by webmail.leidinger.net (8.14.3/8.13.8/Submit) id o0IBeXtb058300; Mon, 18 Jan 2010 12:40:34 +0100 (CET) (envelope-from Alexander@Leidinger.net) Received: from pslux.cec.eu.int (pslux.cec.eu.int [158.169.9.14]) by webmail.leidinger.net (Horde Framework) with HTTP; Mon, 18 Jan 2010 12:40:33 +0100 Message-ID: <20100118124033.17544y7zrba4g1og@webmail.leidinger.net> Date: Mon, 18 Jan 2010 12:40:33 +0100 From: Alexander Leidinger To: Wes Morgan References: <7ab0356e1001151213y5536d4cdi1d1759ce28ad546a@mail.gmail.com> <20100115232922.GM45688@e-Gitt.NET> <20100116014659.46536463@limbo.lan> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: Dynamic Internet Messaging Program (DIMP) H3 (1.1.4) X-EBL-MailScanner-Information: Please contact the ISP for more information X-EBL-MailScanner-ID: 3357A844043.D01E4 X-EBL-MailScanner: Found to be clean X-EBL-MailScanner-SpamCheck: not spam, spamhaus-ZEN, SpamAssassin (not cached, score=-1.286, required 6, autolearn=disabled, ALL_TRUSTED -1.44, DKIM_SIGNED 0.00, DKIM_VERIFIED -0.00, TW_GP 0.08, TW_ZF 0.08) X-EBL-MailScanner-From: alexander@leidinger.net X-EBL-MailScanner-Watermark: 1264419640.12978@+1ERnXzRCo8GWTc4hbl8FA X-EBL-Spam-Status: No Cc: Volodymyr Kostyrko , freebsd-stable@freebsd.org Subject: Re: AHCI and ZFS: root mount error X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 18 Jan 2010 11:40:46 -0000 Quoting Wes Morgan (from Sun, 17 Jan 2010 09:04:16 -0600 (CST)): > On Sat, 16 Jan 2010, Volodymyr Kostyrko wrote: > >> On Sat, 16 Jan 2010 00:29:23 +0100 >> Oliver Brandmueller wrote: >> >> > Check with "zpool status" if your zpool refers to diskslices like >> > "ad0s1". I use gpt have setup the ZFS mirror to refer to gptids: >> > >> > pool: silver >> > state: ONLINE >> > scrub: none requested >> > config: >> > >> > NAME STATE >> READ WRITE CKSUM >> > silver ONLINE >> 0 0 0 >> > mirror ONLINE >> 0 0 0 >> > gptid/9e68d234-f306-11de-a0c4-0002b3b6e838 ONLINE >> 0 0 0 >> > gptid/a025b88c-f306-11de-a0c4-0002b3b6e838 ONLINE >> 0 0 0 >> > >> > With that kind of configuration I can switch back and forth between >> > using ATA_CAM or using traditional ATA drivers. Since you're not using >> > GPT I gues you can use geom labels to do more or less the same thing. >> > >> > In short: use labels, nut device names. Saves headaches in many cases. >> >> ZFS actually can find disks without any glabel help. I have one server >> which I have moved recently to ahci and nothing changes for me. ZFS >> silently accepted new provider names and continue working as usual. >> > > Agreed, I experienced the same thing here when I moved to AHCI. I think > pjd committed some changes in the last few months that greatly improved > the ability of zfs to find devices by uuid. Using glabel or gptid's > with zfs is highly overrated IMO! Jumping into the discussion without much knowledge about the initial start... If this is with 8-stable: the stuff is merged and should work. If this is with 7-stable: the stuff is merged (by me) since 1-2 weeks. If this is something else, have a look if the code as displayed at http://svn.freebsd.org/viewvc/base?view=revision&revision=200158 is there (after this commit there is nothing else which affects the ability to find devices). What may work too is to export the zpool before switching and importing it again after switching the storage subsystem. Bye, Alexander. -- Do you mean that you not only want a wrong answer, but a certain wrong answer? -- Tobaben http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 From owner-freebsd-stable@FreeBSD.ORG Mon Jan 18 16:29: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 97B01106566B for ; Mon, 18 Jan 2010 16:29:49 +0000 (UTC) (envelope-from npapke@acm.org) Received: from idcmail-mo1so.shaw.ca (idcmail-mo1so.shaw.ca [24.71.223.10]) by mx1.freebsd.org (Postfix) with ESMTP id 606EF8FC08 for ; Mon, 18 Jan 2010 16:29:49 +0000 (UTC) Received: from pd2ml3so-ssvc.prod.shaw.ca ([10.0.141.148]) by pd3mo1so-svcs.prod.shaw.ca with ESMTP; 18 Jan 2010 09:29:48 -0700 X-Cloudmark-SP-Filtered: true X-Cloudmark-SP-Result: v=1.0 c=1 a=UTAa5JNdb5oA:10 a=VF9RaR9bft6c8SsOr3WyFg==:17 a=N54-gffFAAAA:8 a=lvbMJxvVAAAA:8 a=1U_RM8WOjPZmsj63ZXsA:9 a=Ka3TPYiD9yAtmhqh6i6MieQX5DUA:4 a=nAPXUAfsBmEA:10 Received: from unknown (HELO proven.lan.provenpath.ca) ([24.85.241.34]) by pd2ml3so-dmz.prod.shaw.ca with ESMTP; 18 Jan 2010 09:29:48 -0700 Received: from proven.lan.provenpath.ca (localhost [127.0.0.1]) by proven.lan.provenpath.ca (8.14.3/8.14.3) with ESMTP id o0IGTmZM005594 for ; Mon, 18 Jan 2010 08:29:48 -0800 (PST) (envelope-from npapke@acm.org) Received: (from npapke@localhost) by proven.lan.provenpath.ca (8.14.3/8.14.3/Submit) id o0IGTmK1005593 for freebsd-stable@freebsd.org; Mon, 18 Jan 2010 08:29:48 -0800 (PST) (envelope-from npapke@acm.org) X-Authentication-Warning: proven.lan.provenpath.ca: npapke set sender to npapke@acm.org using -f From: Norbert Papke To: freebsd-stable@freebsd.org Date: Mon, 18 Jan 2010 08:29:48 -0800 User-Agent: KMail/1.12.4 (FreeBSD/8.0-STABLE; KDE/4.3.4; amd64; ; ) References: <7346c5c61001030842r7dc76199y51e4c1c90a3eea6e@mail.gmail.com> <7346c5c61001091706m45a3a2a5k3ca8bb0c4bec5ea8@mail.gmail.com> <7346c5c61001171521w1ca4738w98e8fcca24643cda@mail.gmail.com> In-Reply-To: <7346c5c61001171521w1ca4738w98e8fcca24643cda@mail.gmail.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-Id: <201001180829.48126.npapke@acm.org> Subject: Re: ZFS performance degradation over time X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 18 Jan 2010 16:29:49 -0000 On January 17, 2010, Garrett Moore wrote: > I upgraded my system to 8GB of ram to see if that would help. It hasn't > made much of a difference. After having rTorrent running for a while, my > performance again tanked. Around 6.5GB of memory was showing as 'Active' > according to top. 6.5GB of "active" memory seems to imply that a user process is growing or a large number of user processes are being created. I would expect ZFS's cache to increase the size of "wired" memory. Sorry, I have not followed this thread closely. Are you sure that the degradation is ZFS related? Could it be caused by, for instance, a userland memory leak? What happens to active memory when you restart rtorrent? Cheers, -- Norbert Papke. npapke@acm.org http://saveournet.ca Protecting your Internet's level playing field From owner-freebsd-stable@FreeBSD.ORG Mon Jan 18 19:43: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 1EF61106568D; Mon, 18 Jan 2010 19:43:00 +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 DB7AE8FC18; Mon, 18 Jan 2010 19:42:59 +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 1NWxUo-000Jkj-QB; Mon, 18 Jan 2010 19:42:42 +0000 Received: from petefrench by dilbert.ticketswitch.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NWxUo-000NGn-PI; Mon, 18 Jan 2010 19:42:42 +0000 Date: Mon, 18 Jan 2010 19:42:42 +0000 Message-Id: To: attilio@freebsd.org In-Reply-To: <3bbf2fe11001150419uac3caealddfcd261a8b4cacc@mail.gmail.com> From: Pete French Cc: freebsd-stable@freebsd.org Subject: Re: [PATCH] Lockmgr deadlock on STABLE_8 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 18 Jan 2010 19:43:00 -0000 > One may never know, try without WITNESS but still the same setup. Well, I have been running like this for three days with no lockups dissapointingly. I just saw that you commited the lock patches, so am going to update to the latest STABLE and go back to GENERIC to see if that still locks up (as I can see a couple of other fixes in there). Will let you know what happens - at the moment it's frustrating as it wont lockup if I have anything diagnostic in the kernel it seem! cheers, -pete. From owner-freebsd-stable@FreeBSD.ORG Mon Jan 18 20:13: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 A97FC106566B; Mon, 18 Jan 2010 20:13:54 +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 6134E8FC12; Mon, 18 Jan 2010 20:13:54 +0000 (UTC) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost1.zedat.fu-berlin.de (Exim 4.69) with esmtp (envelope-from ) id <1NWxyz-0002pJ-8z>; Mon, 18 Jan 2010 21:13:53 +0100 Received: from e178000095.adsl.alicedsl.de ([85.178.0.95] helo=thor.walstatt.dyndns.org) by inpost2.zedat.fu-berlin.de (Exim 4.69) with esmtpsa (envelope-from ) id <1NWxyz-0005nO-62>; Mon, 18 Jan 2010 21:13:53 +0100 Message-ID: <4B54C100.9080906@mail.zedat.fu-berlin.de> Date: Mon, 18 Jan 2010 21:13:52 +0100 From: "O. Hartmann" User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.1.5) Gecko/20091219 Thunderbird/3.0 MIME-Version: 1.0 To: FreeBSD Stable , freebsd-questions@freebsd.org Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: 85.178.0.95 Cc: Subject: immense delayed write to file system (ZFS and UFS2), performance issues X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 18 Jan 2010 20:13:54 -0000 I realise a strange behaviour of several FreeBSD 8.0-STABLE/amd64 boxes. All boxes have the most recent STABLE. One box is a UP system, two others SMP boxes, one with a Q6600 4-core, another XEON with 2x 4-cores (Dell Poweredge III). Symptome: All boxes have ZFS and UFS2 filesystems. Since two weeks or so, sometimes the I/O performance drops massively when doing 'svn update', 'make world' or even 'make kernel'. It doesn't matter what memory and how many cpu the box has, it get stuck for several seconds and freezing. On the UP box, this is sometimes for 10 - 20 seconds. A very interesting phenomenon is the massively delayed file writing on ZFS filesystems I realise. Editing a file in 'vi' running on one XTerm and having in another Xterminal my shell for compiling this file, it takes sometimes up to 20 seconds to get the file updated after it has been written. It's like having an old, slow NFS connection with long cache delays. These massively delayed file transactions are not necessarely under heavy load, sometimes they occur in a relaxed situation. They seem to occur much more often on the UP box than on the SMP boxes, but this strange phenomenon also occur on the Dell Poweredge II, which has 16GB RAM and summa summarum 16 cores. This phenomenon does occur on ZFS- and UFS2 filesystems as well. It is hardly reproducable. Is there any known issue? Ragrds, Oliver From owner-freebsd-stable@FreeBSD.ORG Mon Jan 18 20:20: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 30ECC1065679 for ; Mon, 18 Jan 2010 20:20:11 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta03.westchester.pa.mail.comcast.net (qmta03.westchester.pa.mail.comcast.net [76.96.62.32]) by mx1.freebsd.org (Postfix) with ESMTP id CFFD48FC13 for ; Mon, 18 Jan 2010 20:20:10 +0000 (UTC) Received: from omta19.westchester.pa.mail.comcast.net ([76.96.62.98]) by qmta03.westchester.pa.mail.comcast.net with comcast id X3vo1d00Q27AodY538KnDi; Mon, 18 Jan 2010 20:19:47 +0000 Received: from koitsu.dyndns.org ([98.248.46.159]) by omta19.westchester.pa.mail.comcast.net with comcast id X8LN1d00A3S48mS3f8LPyE; Mon, 18 Jan 2010 20:20:23 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 6A7D01E3033; Mon, 18 Jan 2010 12:20:07 -0800 (PST) Date: Mon, 18 Jan 2010 12:20:07 -0800 From: Jeremy Chadwick To: freebsd-stable@freebsd.org Message-ID: <20100118202007.GA54223@icarus.home.lan> References: <4B54C100.9080906@mail.zedat.fu-berlin.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4B54C100.9080906@mail.zedat.fu-berlin.de> User-Agent: Mutt/1.5.20 (2009-06-14) Subject: Re: immense delayed write to file system (ZFS and UFS2), performance issues X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 18 Jan 2010 20:20:11 -0000 On Mon, Jan 18, 2010 at 09:13:52PM +0100, O. Hartmann wrote: > I realise a strange behaviour of several FreeBSD 8.0-STABLE/amd64 > boxes. All boxes have the most recent STABLE. One box is a UP > system, two others SMP boxes, one with a Q6600 4-core, another XEON > with 2x 4-cores (Dell Poweredge III). > > Symptome: All boxes have ZFS and UFS2 filesystems. Since two weeks > or so, sometimes the I/O performance drops massively when doing 'svn > update', 'make world' or even 'make kernel'. It doesn't matter what > memory and how many cpu the box has, it get stuck for several > seconds and freezing. On the UP box, this is sometimes for 10 - 20 > seconds. > A very interesting phenomenon is the massively delayed file writing > on ZFS filesystems I realise. Editing a file in 'vi' running on one > XTerm and having in another Xterminal my shell for compiling this > file, it takes sometimes up to 20 seconds to get the file updated > after it has been written. It's like having an old, slow NFS > connection with long cache delays. > These massively delayed file transactions are not necessarely under > heavy load, sometimes they occur in a relaxed situation. They seem > to occur much more often on the UP box than on the SMP boxes, but > this strange phenomenon also occur on the Dell Poweredge II, which > has 16GB RAM and summa summarum 16 cores. This phenomenon does occur > on ZFS- and UFS2 filesystems as well. It is hardly reproducable. Possibly this is an extreme example of what Garrett Moore et al have been discussing recently? http://lists.freebsd.org/pipermail/freebsd-stable/2010-January/053845.html You might try the force-swap-out approach here to find out if what you're seeing is identical: http://lists.freebsd.org/pipermail/freebsd-stable/2010-January/053949.html -- | 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 Mon Jan 18 20:55: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 0F01F106566C for ; Mon, 18 Jan 2010 20:55:12 +0000 (UTC) (envelope-from freebsd-questions@pp.dyndns.biz) Received: from proxy1.bredband.net (proxy1.bredband.net [195.54.101.71]) by mx1.freebsd.org (Postfix) with ESMTP id BB48D8FC17 for ; Mon, 18 Jan 2010 20:55:11 +0000 (UTC) Received: from ipb1.telenor.se (195.54.127.164) by proxy1.bredband.net (7.3.140.3) id 4AD3E1C00274076B; Mon, 18 Jan 2010 21:34:56 +0100 X-SMTPAUTH-B2: X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AtA4AP5UVEtV4js3PGdsb2JhbACBRoZwk0ABAQEBN7hThDME X-IronPort-AV: E=Sophos;i="4.49,298,1262559600"; d="scan'208";a="27530636" Received: from c-373be255.107-1-64736c10.cust.bredbandsbolaget.se (HELO gatekeeper.pp.dyndns.biz) ([85.226.59.55]) by ipb1.telenor.se with ESMTP; 18 Jan 2010 21:34:56 +0100 Received: from [192.168.69.67] (phobos [192.168.69.67]) by gatekeeper.pp.dyndns.biz (8.14.3/8.14.3) with ESMTP id o0IKYsjG041717; Mon, 18 Jan 2010 21:34:54 +0100 (CET) (envelope-from freebsd-questions@pp.dyndns.biz) Message-ID: <4B54C5EE.5070305@pp.dyndns.biz> Date: Mon, 18 Jan 2010 21:34:54 +0100 From: =?ISO-8859-15?Q?Morgan_Wesstr=F6m?= User-Agent: Thunderbird 2.0.0.23 (X11/20091010) MIME-Version: 1.0 To: "O. Hartmann" References: <4B54C100.9080906@mail.zedat.fu-berlin.de> In-Reply-To: <4B54C100.9080906@mail.zedat.fu-berlin.de> Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit Cc: FreeBSD Stable , freebsd-questions@freebsd.org Subject: Re: immense delayed write to file system (ZFS and UFS2), performance issues X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 18 Jan 2010 20:55:12 -0000 O. Hartmann wrote: > I realise a strange behaviour of several FreeBSD 8.0-STABLE/amd64 boxes. > All boxes have the most recent STABLE. One box is a UP system, two > others SMP boxes, one with a Q6600 4-core, another XEON with 2x 4-cores > (Dell Poweredge III). > > Symptome: All boxes have ZFS and UFS2 filesystems. Since two weeks or > so, sometimes the I/O performance drops massively when doing 'svn > update', 'make world' or even 'make kernel'. It doesn't matter what > memory and how many cpu the box has, it get stuck for several seconds > and freezing. On the UP box, this is sometimes for 10 - 20 seconds. > A very interesting phenomenon is the massively delayed file writing on > ZFS filesystems I realise. Editing a file in 'vi' running on one XTerm > and having in another Xterminal my shell for compiling this file, it > takes sometimes up to 20 seconds to get the file updated after it has > been written. It's like having an old, slow NFS connection with long > cache delays. > These massively delayed file transactions are not necessarely under > heavy load, sometimes they occur in a relaxed situation. They seem to > occur much more often on the UP box than on the SMP boxes, but this > strange phenomenon also occur on the Dell Poweredge II, which has 16GB > RAM and summa summarum 16 cores. This phenomenon does occur on ZFS- and > UFS2 filesystems as well. It is hardly reproducable. > > Is there any known issue? > > Ragrds, > Oliver The disks involved don't happen to be Western Digital Green Power disks, do they? The Intelli-Park function in these disks are wrecking havoc with I/O in Linux-land at least, causing massive stalls and iowait through the roof during the 25-30 seconds it takes for the heads to unload after parking. I have two of these disks sitting on my desk now collecting dust... /Morgan From owner-freebsd-stable@FreeBSD.ORG Mon Jan 18 21:02: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 2DABD106566C for ; Mon, 18 Jan 2010 21:02:20 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: from mail-fx0-f227.google.com (mail-fx0-f227.google.com [209.85.220.227]) by mx1.freebsd.org (Postfix) with ESMTP id B5EEB8FC19 for ; Mon, 18 Jan 2010 21:02:19 +0000 (UTC) Received: by fxm27 with SMTP id 27so2741861fxm.3 for ; Mon, 18 Jan 2010 13:02:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type; bh=p2ySm0DMeq+LgUbysq4rNiSytN191fISaR1lOuaZhNI=; b=vGqoeX1X7rpVCG/p/RniWrpoxpyj9NMEFHUkQU1XU7MEAnAEYa8tHSxOC0nr290THV XEI6C/W6qKFAf2HEGwsaCp9dZGkw+yk11xSZI35i8T4nvQTPWb9fap5JOBeO8gS+RlGQ ByblnRdNO6jKpgLyivlxKcoTqbuDl6JVRLyt8= 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=Z/D+PS35k04ULPM0UowuQxF4cR9qc+EEOTIwDUFnZA3pAVX1aOj67spnrPdekdqoG9 5IDpBcGvZsMq5fOQuTBTowU1/jrmksg8n58ENrEa9tMOZNbt6v+6biLKhq3GTCH8BjsU ExM7DKfvgyKJGefURPPSL2QxiswmL20FFPwv4= MIME-Version: 1.0 Sender: asmrookie@gmail.com Received: by 10.223.4.22 with SMTP id 22mr2525190fap.97.1263848538684; Mon, 18 Jan 2010 13:02:18 -0800 (PST) In-Reply-To: References: <3bbf2fe11001150419uac3caealddfcd261a8b4cacc@mail.gmail.com> Date: Mon, 18 Jan 2010 22:02:18 +0100 X-Google-Sender-Auth: 86097783e8132bbd Message-ID: <3bbf2fe11001181302g4a7e7669w8d8d321a1c123e17@mail.gmail.com> From: Attilio Rao To: Pete French Content-Type: text/plain; charset=UTF-8 Cc: freebsd-stable@freebsd.org Subject: Re: [PATCH] Lockmgr deadlock on STABLE_8 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 18 Jan 2010 21:02:20 -0000 2010/1/18 Pete French : >> One may never know, try without WITNESS but still the same setup. > > Well, I have been running like this for three days with no lockups > dissapointingly. I just saw that you commited the lock patches, so > am going to update to the latest STABLE and go back to GENERIC to see if > that still locks up (as I can see a couple of other fixes in there). > Will let you know what happens - at the moment it's frustrating > as it wont lockup if I have anything diagnostic in the kernel it > seem! May you post your kernel config? Attilio -- Peace can only be achieved by understanding - A. Einstein From owner-freebsd-stable@FreeBSD.ORG Mon Jan 18 23:10: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 EED861065692 for ; Mon, 18 Jan 2010 23:10:58 +0000 (UTC) (envelope-from matheusber@gmail.com) Received: from mail-yx0-f171.google.com (mail-yx0-f171.google.com [209.85.210.171]) by mx1.freebsd.org (Postfix) with ESMTP id 9E2238FC1D for ; Mon, 18 Jan 2010 23:10:58 +0000 (UTC) Received: by yxe1 with SMTP id 1so2572391yxe.3 for ; Mon, 18 Jan 2010 15:10:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:received:date:from:to :subject:message-id:in-reply-to:references:x-mailer:mime-version :content-type:content-transfer-encoding; bh=OLiQzAkAmU5e8+bUmxuRk/yGc7RZo1mLehYlqHvpGZo=; b=s356GaQFpsLq4fqdKJHmI7fiuAPlntAEBmoeO5iTsdcaTVoq3/a/DmwL6UUWN/mbHV x2yBCtWPIL4t9gvXo90hmYYEKSCnJvlvQl68SC2xGo4tgEsJJSeozrpebLCkfxduai0O BFFbkVs3qyWT3vL2CbBmgvbfcnvrgFAYbKXzg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:date:from:to:subject:message-id:in-reply-to:references :x-mailer:mime-version:content-type:content-transfer-encoding; b=edCv2ZXeSu7lfsUzGf0PiJk9VpWu3IR6xbpLOoAhK+QXIQQj/DacO5nTagwY/OLfX9 +CsvrwN5B80yX6QWwPcoMDKmvgc/vLPmLS3rPuxDzHksfljR/nA4MbDUKjHe/sJARh9l fUWEvlY9U1ZiBlMo3YrwLHTMPVk9lqEmsIAn8= Received: by 10.91.72.12 with SMTP id z12mr6156529agk.73.1263856257665; Mon, 18 Jan 2010 15:10:57 -0800 (PST) Received: from cygnus.homeunix.com ([189.71.15.170]) by mx.google.com with ESMTPS id 4sm1549341yxd.16.2010.01.18.15.10.52 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 18 Jan 2010 15:10:54 -0800 (PST) Sender: Nenhum_de_Nos Received: from arroway.apartnet (arroway.apartnet [10.1.1.80]) by cygnus.homeunix.com (Postfix) with SMTP id D19FEB8057 for ; Mon, 18 Jan 2010 20:10:45 -0300 (BRT) Date: Mon, 18 Jan 2010 20:11:57 -0300 From: Nenhum_de_Nos To: freebsd-stable@freebsd.org Message-Id: <20100118201157.8bbea948.matheus@eternamente.info> In-Reply-To: <4B522102.1050805@errno.com> References: <0122e9480533dc61e94ec7d00678aeaf.squirrel@lamneth> <0c682ad7769fbd678a6835f041d0c791.squirrel@lamneth> <4B522102.1050805@errno.com> X-Mailer: Sylpheed 2.4.8 (GTK+ 2.12.9; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: Re: ath hostap 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: Mon, 18 Jan 2010 23:10:59 -0000 On Sat, 16 Jan 2010 12:26:42 -0800 Sam Leffler wrote: > Nenhum_de_Nos wrote: > > On Tue, January 5, 2010 00:09, Nenhum_de_Nos wrote: > >> hail, > >> > >> I have a Core 2 Duo 2.66 GHz as a wifi ap: > >> > >> Jan 4 22:31:08 xxx kernel: cpu_reset: Stopping other CPUs > >> Jan 4 22:31:08 xxx kernel: Copyright (c) 1992-2010 The FreeBSD Project. > >> Jan 4 22:31:08 xxx kernel: Copyright (c) 1979, 1980, 1983, 1986, 1988, > >> 1989, 1991, 1992, 1993, 1994 > >> Jan 4 22:31:08 xxx kernel: The Regents of the University of California. > >> All rights reserved. > >> Jan 4 22:31:08 xxx kernel: FreeBSD is a registered trademark of The > >> FreeBSD Foundation. > >> Jan 4 22:31:08 xxx kernel: FreeBSD 8.0-STABLE #0: Sun Jan 3 00:25:30 BRT > >> 2010 > >> Jan 4 22:31:08 xxx kernel: root@xxx.xxx:/usr/obj/usr/src/sys/xxx amd64 > >> Jan 4 22:31:08 xxx kernel: Timecounter "i8254" frequency 1193182 Hz > >> quality 0 > >> Jan 4 22:31:08 xxx kernel: CPU: Intel(R) Core(TM)2 Duo CPU E6750 @ > >> 2.66GHz (2669.34-MHz K8-class CPU) > >> Jan 4 22:31:08 xxx kernel: Origin = "GenuineIntel" Id = 0x6fb Stepping > >> = 11 > >> > >> xxx# uname -a > >> FreeBSD xxx.xxx 8.0-STABLE FreeBSD 8.0-STABLE #0: Sun Jan 3 00:25:30 BRT > >> 2010 root@xxx.xxx:/usr/obj/usr/src/sys/xxx amd64 > >> > >> cat /etc/hostapd.conf > >> interface=wlan0 > >> #bridge=bridge0 > >> driver=bsd > >> logger_syslog=-1 > >> logger_syslog_level=2 > >> logger_stdout=-1 > >> logger_stdout_level=2 > >> debug=0 > >> dump_file=/tmp/hostapd.dump > >> ctrl_interface=/var/run/hostapd > >> ctrl_interface_group=0 > >> ssid=apartnet2 > >> #macaddr_acl=1 > >> #accept_mac_file=/etc/hostapd/accept > >> auth_algs=3 > >> eapol_key_index_workaround=0 > >> #eap_server=0 > >> wpa=3 > >> wpa_psk_file=/etc/hostapd/wpa_psk > >> wpa_key_mgmt=WPA-PSK > >> wpa_pairwise=CCMP > >> #stakey=0 > >> ieee8021x=0 > >> hw_mode=g > >> > >> and just get these messages in logs: > >> > >> Jan 4 22:49:46 xxx kernel: ath0: stuck beacon; resetting (bmiss count 4) > >> Jan 4 22:49:48 xxx last message repeated 4 times > >> Jan 4 22:49:48 xxx postfix/local[1293]: fatal: open database > >> /etc/aliases.db: No such file or directory > >> Jan 4 22:49:48 xxx kernel: ath0: stuck beacon; resetting (bmiss count 4) > >> Jan 4 22:50:03 xxx last message repeated 46 times > >> Jan 4 22:50:03 xxx kernel: > >> Jan 4 22:50:03 xxx kernel: ath0: stuck beacon; resetting (bmiss count 4) > >> Jan 4 22:50:19 xxx last message repeated 51 times > >> Jan 4 22:50:20 xxx kernel: > >> Jan 4 22:50:20 xxx kernel: ath0: stuck beacon; resetting (bmiss count 4) > >> Jan 4 22:50:33 xxx last message repeated 41 times > >> Jan 4 22:50:33 xxx kernel: > >> Jan 4 22:50:33 xxx kernel: ath0: stuck beacon; resetting (bmiss count 4) > >> Jan 4 22:50:49 xxx last message repeated 50 times > >> Jan 4 22:50:49 xxx postfix/local[1296]: fatal: open database > >> /etc/aliases.db: No such file or directory > >> Jan 4 22:50:49 xxx kernel: ath0: stuck beacon; resetting (bmiss count 4) > >> Jan 4 22:51:20 xxx last message repeated 98 times > >> Jan 4 22:51:50 xxx last message repeated 100 times > >> Jan 4 22:51:50 xxx postfix/local[1297]: fatal: open database > >> /etc/aliases.db: No such file or directory > >> Jan 4 22:51:50 xxx kernel: ath0: stuck beacon; resetting (bmiss count 4) > >> > >> I can't even see the network in other computers. > >> > >> Some time ago I reported this problem in here, but using slower hardware. > >> and Sam said that was it. That machine was running Linux before and is now > >> being converted to FreeBSD 8. when in linux, I had some performance > >> penalties but it works great for internet access. > >> > >> is there anything I can do to solve this ? > >> > >> the card is this: > >> > >> ath0@pci0:5:0:0: class=0x020000 card=0x3a131186 chip=0x0013168c rev=0x01 > >> hdr=0x00 > >> vendor = 'Atheros Communications Inc.' > >> device = '802.11a/b/g Wireless Adapter (AR5212)' > >> class = network > >> subclass = ethernet > >> > >> the card doesn't support 802.11a though. > >> > >> I'm about to buy a rum based usb wlan, may be Hawking HWUG1 or TP-LINK > >> TL-WN321G, to make another freebsd based ap for light internet access. is > >> this supposed to happen as well ? > >> > >> thanks, > >> > >> matheus > > > > Using similar configuration file for hostapd, I did test another atheros > > based wlan card in same role: > > > > ath0@pci0:1:0:0: class=0x020000 card=0x3065168c chip=0x001c168c > > rev=0x01 hdr=0x00 > > vendor = 'Atheros Communications Inc.' > > device = > > 'HDAUDIOFUNC_01&VEN_1095&DEV_1392&SUBSYS_10280242&REV_1000 > > (USBVID_147E&PID_20165&B71A446&0&1)' > > class = network > > subclass = ethernet > > > > this is a pcie part, AFAIK, running on Asus F3T turion based notebook. > > Runs FreeBSD 8 as well: > > > > [matheus@xxx/usr/home/matheus]$ uname -a > > FreeBSD xxx.xxx 8.0-STABLE FreeBSD 8.0-STABLE #5: Sun Jan 3 16:20:25 BRT > > 2010 root@xxx.xxx:/usr/obj/usr/src/sys/xxx amd64 > > > > but this time I have no message as tha other box, and the AP works fine. > > > > matheus > > Are both machines SMP? yes. both 8-stable amd64 smp machines. if anything else, please ask. thanks, matheus > Stuck beacons typically arise for two reasons: > the channel is busy and the ap can't get on the air to send the frame, > or the host/bus is overloaded and cannot meet the realtime requirements > of posting the beacon frame in time to hit the beacon transmit schedule. > I can't tell from the above info whether either might be possible. > > Sam > > _______________________________________________ > 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" -- We will call you Cygnus, The God of balance you shall be A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? http://en.wikipedia.org/wiki/Posting_style From owner-freebsd-stable@FreeBSD.ORG Mon Jan 18 23:36: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 55F6B106568F; Mon, 18 Jan 2010 23:36:53 +0000 (UTC) (envelope-from dan.naumov@gmail.com) Received: from mail-yx0-f171.google.com (mail-yx0-f171.google.com [209.85.210.171]) by mx1.freebsd.org (Postfix) with ESMTP id E0CBF8FC19; Mon, 18 Jan 2010 23:36:52 +0000 (UTC) Received: by yxe1 with SMTP id 1so2587199yxe.3 for ; Mon, 18 Jan 2010 15:36:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type; bh=VuZoDBcjPg64urqTe62VFZT95JRMk5Ek/y1fPPc44KA=; b=aCJvMEGXsNlQFhjz5pM5hajuhjNIHFit1oBzXiOIMXFBVZA12vlWTu6weNxkcK9hse +/6HCU5uxLsxkSLUAPcEMY+08Mh8YfkTiIpQO0xOt4h44k/l+JNmuiVauHoT3ITzTVNy rvb8Ie5H7iJ4Nz/ZHbkG7+BJKPkkITEVuirU4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=TnesAS6ssvUM/6kthQmEGruI8JVS62aGBXSENODFarUx+pCt2mFADIDRYtkSNoqG54 vxuIRzn3uTWCQm0G4YXWwE9tK2ujJLVVCWD6L/YiTq3KwDcwXNAvcfwLkPQcpSD0DjFy z6Hh7uvCgGnuJGeHozTzr6bO4U0f7Phah0SXI= MIME-Version: 1.0 Received: by 10.101.115.16 with SMTP id s16mr10718114anm.21.1263857812075; Mon, 18 Jan 2010 15:36:52 -0800 (PST) Date: Tue, 19 Jan 2010 01:36:52 +0200 Message-ID: From: Dan Naumov To: FreeBSD-STABLE Mailing List , freebsd-geom@freebsd.org, freebsd-bugs@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Cc: Subject: RE: bin/115406: [patch] gpt(8) GPT MBR hangs award BIOS on boot X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 18 Jan 2010 23:36:53 -0000 > 1) Is this bug now officially fixed as of 8.0-RELEASE? Ie, can I > expect to set up a completely GPT-based system using an Intel > D945GCLF2 board and not have the installation crap out on me later? > > 2) The very last entry into the PR states the following: > "The problem has been addressed in gart(8) and gpt(8) is obsolete, so > no follow-up is to be expected at this time. Close the PR to reflect > this." Hello list. Referring to PR: http://www.freebsd.org/cgi/query-pr.cgi?pr=115406&cat=bin I have now been battling with trying to setup a FreeBSD 8.0 system using GPT on an Intel D945GCLF2 board for over 24 hours and it looks to me that the problem is not resolved. If I do a traditional installation using sysinstall / MBR, everything works. But if I use GPT and do a manual installation and do everything right, the way it's supposed to be done, the BIOS refuses to boot off the disk. I have verified that I am doing everything right by employing the exact same installation method with GPT inside a VMWare Player virtual machine and there, everything works as expected and I have also been testing this with an installation script in both cases to ensure that this is definately no user error :) Reading the original PR, it can be seen that a (supposed) fix to gpart was committed to stable/8 back in Aug 27, is it possible that this somehow didn't make it into 8.0-RELEASE or is this a question of the fix being there but not actually solving the problem? Reading the discussion on the forums at http://forums.freebsd.org/showthread.php?t=4680 I am seeing that a 7.2-RELEASE user had solved his exact same problem by editing the actual PMBR (resulting in "bootable" flag (0x80) being set and the start of the partition has being set to the beginning of the disk (0x010100).) and applying it to his disk with DD. Can anyone point me towards an explanation regarding how to edit and apply my own PMBR to my disk to see if it helps? Thanks. Sincerely, Dan Naumov From owner-freebsd-stable@FreeBSD.ORG Tue Jan 19 02:20: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 26207106566B; Tue, 19 Jan 2010 02:20:37 +0000 (UTC) (envelope-from doconnor@gsoft.com.au) Received: from cain.gsoft.com.au (cain.gsoft.com.au [203.31.81.10]) by mx1.freebsd.org (Postfix) with ESMTP id 987EB8FC0C; Tue, 19 Jan 2010 02:20:36 +0000 (UTC) Received: from inchoate.gsoft.com.au ([203.31.81.30]) (authenticated bits=0) by cain.gsoft.com.au (8.13.8/8.13.8) with ESMTP id o0J2KTwW096164 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Tue, 19 Jan 2010 12:50:29 +1030 (CST) (envelope-from doconnor@gsoft.com.au) From: "Daniel O'Connor" To: freebsd-stable@freebsd.org Date: Tue, 19 Jan 2010 12:50:13 +1030 User-Agent: KMail/1.9.10 References: <4B54C100.9080906@mail.zedat.fu-berlin.de> <4B54C5EE.5070305@pp.dyndns.biz> In-Reply-To: <4B54C5EE.5070305@pp.dyndns.biz> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart2955529.oGW1gFcb1l"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <201001191250.23625.doconnor@gsoft.com.au> X-Spam-Score: -3.635 () ALL_TRUSTED,AWL,BAYES_00 X-Scanned-By: MIMEDefang 2.63 on 203.31.81.10 Cc: "O. Hartmann" , Morgan =?utf-8?q?Wesstr=C3=B6m?= , freebsd-questions@freebsd.org Subject: Re: immense delayed write to file system (ZFS and UFS2), performance issues X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 19 Jan 2010 02:20:37 -0000 --nextPart2955529.oGW1gFcb1l Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Tue, 19 Jan 2010, Morgan Wesstr=F6m wrote: > The disks involved don't happen to be Western Digital Green Power > disks, do they? The Intelli-Park function in these disks are wrecking > havoc with I/O in Linux-land at least, causing massive stalls and > iowait through the roof during the 25-30 seconds it takes for the > heads to unload after parking. I have two of these disks sitting on > my desk now collecting dust... There's this.. http://www.silentpcreview.com/Terabyte_Drive_Fix and you can get the tool at.. http://home.arcor.de/ghostadmin/wdidle3_1_00.zip I am planning to try this out tonight.. =2D-=20 Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C --nextPart2955529.oGW1gFcb1l Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.12 (FreeBSD) iD8DBQBLVRbn5ZPcIHs/zowRAgw5AKCnV25BbksA6CVLuxD96Q5x8WGqogCgoHjw Hx8GOn5vpLDgfI1YbAp4LbI= =8ATs -----END PGP SIGNATURE----- --nextPart2955529.oGW1gFcb1l-- From owner-freebsd-stable@FreeBSD.ORG Tue Jan 19 02:41: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 0B1111065670 for ; Tue, 19 Jan 2010 02:41:55 +0000 (UTC) (envelope-from garrettmoore@gmail.com) Received: from mail-iw0-f177.google.com (mail-iw0-f177.google.com [209.85.223.177]) by mx1.freebsd.org (Postfix) with ESMTP id C063F8FC18 for ; Tue, 19 Jan 2010 02:41:54 +0000 (UTC) Received: by iwn7 with SMTP id 7so2507840iwn.7 for ; Mon, 18 Jan 2010 18:41:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=jMiJnGtS+iAMKfMfEFL3pMMM4sPT3sA6DGD9Voi9hds=; b=scRqjsvOFmGr1Mv3Y8tVAEQ8TIkvwFtwapG6pefUbIZrtfTiKXvTCH+5mnCjlNYxhz 924H5JPSVJXVKAOmVokr0gWamIP/IYPnb6CH1/1FO4letPXLmShmmX6R0Y34D4KHE6Af lyMHOYh22eSOkjHo8lioXFK5TJel+UEX6Bk1c= 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=RqPc5+LzKfMPmTSf8OdEUZuwG+juH7fUftHbePqgXRi2O3NGEv8Ft+UwjIIH07nDiA MkXtX90qZxjt6ntbtkDfjw3kLJfrfOFLfIsJAapgHdNUCbrDthbt0eMSQ1Cs6TDGXndZ CGDLyLhM/JxpNMxwUlIMGyROnQBPM2nN31X3o= MIME-Version: 1.0 Received: by 10.231.154.197 with SMTP id p5mr1013733ibw.28.1263868913874; Mon, 18 Jan 2010 18:41:53 -0800 (PST) In-Reply-To: <201001191250.23625.doconnor@gsoft.com.au> References: <4B54C100.9080906@mail.zedat.fu-berlin.de> <4B54C5EE.5070305@pp.dyndns.biz> <201001191250.23625.doconnor@gsoft.com.au> Date: Mon, 18 Jan 2010 21:41:53 -0500 Message-ID: <7346c5c61001181841j3653a7c3m32bc033c8c146a92@mail.gmail.com> From: Garrett Moore To: freebsd-stable@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: "O. Hartmann" Subject: Re: immense delayed write to file system (ZFS and UFS2), performance issues X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 19 Jan 2010 02:41:55 -0000 The drives being discussed in my related thread (regarding poor performance= ) are all WD Green drives. I have used wdidle3 to set all of my drive timeout= s to 5 minutes. I'll see what sort of difference this makes for performance. Even if it makes no difference to performance, thank you for pointing it ou= t -- my drives have less than 2,000 hours on them and were all over 90,000 load cycles due to this moronic factory setting. Since changing the timeout= , they haven't parked (which is what I would expect). On Mon, Jan 18, 2010 at 9:20 PM, Daniel O'Connor wro= te: > On Tue, 19 Jan 2010, Morgan Wesstr=F6m wrote: > > The disks involved don't happen to be Western Digital Green Power > > disks, do they? The Intelli-Park function in these disks are wrecking > > havoc with I/O in Linux-land at least, causing massive stalls and > > iowait through the roof during the 25-30 seconds it takes for the > > heads to unload after parking. I have two of these disks sitting on > > my desk now collecting dust... > > There's this.. > http://www.silentpcreview.com/Terabyte_Drive_Fix > > and you can get the tool at.. > http://home.arcor.de/ghostadmin/wdidle3_1_00.zip > > I am planning to try this out tonight.. > > -- > Daniel O'Connor software and network engineer > for Genesis Software - http://www.gsoft.com.au > "The nice thing about standards is that there > are so many of them to choose from." > -- Andrew Tanenbaum > GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C > From owner-freebsd-stable@FreeBSD.ORG Tue Jan 19 03:29: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 E9110106566C for ; Tue, 19 Jan 2010 03:29:03 +0000 (UTC) (envelope-from russell.yount@gmail.com) Received: from qw-out-2122.google.com (qw-out-2122.google.com [74.125.92.27]) by mx1.freebsd.org (Postfix) with ESMTP id 9DEFD8FC12 for ; Tue, 19 Jan 2010 03:29:03 +0000 (UTC) Received: by qw-out-2122.google.com with SMTP id 5so795135qwd.7 for ; Mon, 18 Jan 2010 19:29:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=Cus1oYS0qSJ5vKy1D6hzTR+vyZjt6PniOCEKGpJhdHM=; b=W+Xq5QPlyHj30BnbTBpwwRex8quD5Aqe4yxPe2yMijsRHMtUnO+UJ1HyXFGOml62xY dMgGDfZF4OWcKXpN+7Uxo2PQoUt4n+aTCJfSt8tR6wzYI2iEP3dJ5EpwasR4qhE2lGnW sqG2S9P+fJ+qXd0gTOrPpncIbMX1s80Ioroz0= 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=B12YryYgocv4xwYXbEocqbPMYNenUAV1Xm8ehupA1UlpoWhTDcBp/RNXykTwFCyAuc N1DzMdpLqRTZk6C0NXDXhJ8+AnaM0DcGryYZKCTO8MneF9AHzuiQuX7OGZ/Eskl/puo+ y4voih0gRJT4/zdWlrdWcajwMIDFS8KPE9+OI= MIME-Version: 1.0 Received: by 10.220.126.224 with SMTP id d32mr408936vcs.117.1263871742639; Mon, 18 Jan 2010 19:29:02 -0800 (PST) In-Reply-To: <4B535AAE.3060308@errno.com> References: <4B521FC2.4050402@errno.com> <4B535AAE.3060308@errno.com> Date: Mon, 18 Jan 2010 22:29:02 -0500 Message-ID: From: Russell Yount To: Sam Leffler Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: russell.yount@gmail.com, freebsd-stable@freebsd.org Subject: Re: atheros broadcast/multicast corruption with multiple hostap's X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 19 Jan 2010 03:29:04 -0000 On Sun, Jan 17, 2010 at 1:45 PM, Sam Leffler wrote: > Russell Yount wrote: > > >> >> On Sat, Jan 16, 2010 at 3:21 PM, Sam Leffler > sam@errno.com>> wrote: >> >> Russell Yount wrote: >> >> It seems AP to client broadcasts/multicasts traffic is >> broken when using WPA2/802.11i with multiple hostapds in 8.0. >> >> Only the SSID associated with the last hostapd to be started has >> AP to client broadcasts/multicasts being delivered correctly. >> >> The AP and client are 8.0 freebsd systems althought I see same >> problems with windows XP as a client. >> >> The AP has 4 hostapds configured to use TLS with client >> certificates for >> authentication. (hostapd recompiled with >> HOSTAPD_CFLAGS=-DEAP_SERVER) >> The AP and client radio are shown as ath0: AR5212 mac 5.9 RF5112 >> phy 4.3 >> in dmesg. >> >> Client authenticate using client certificates associate correctly >> to all 4 SSIDs. Unicast traffic flows correctly between clients >> and AP >> for all for 4 SSIDs. Client to AP broadcast/multicast traffic works >> on of 4 SSIDs. AP to client broadcast/multicast traffic only works >> on 1 of the SSIDs. I have documented this using ARP broadcasts, >> but normal IP broadcasts also observed to corrupted. >> >> When an ARP request is send through the AP to an associated client >> it seems to be trashed on any of the SSID except the one associated >> with the last hostapd to be started. Here is the output of >> client side >> tcpdump showing the problems. >> >> In the first client side tcpdump with the hostapd associated >> with the SSID >> being associaed with the last hostapd started and the traffic >> flowing >> normally. >> >> In the second client side tcpdump with the hostapd associated >> with the SSID >> being not the last hostapd started the ARP request is resent >> multiple times >> and appears corrupted. >> >> I would really like to find a fix for this. >> Any help would be greatly appreciated. >> >> >> This sounds like the crypto encap of the frame is clobbering the >> mbuf contents. You can verify this by setting up multiple vaps w/o >> WPA. If this is the problem look for the mbuf copy logic for mcast >> frames and make sure a deep copy is done. >> >> Sam >> >> The four VAPs broadcast traffic works find without WPA if I do not >> start hostapds on them >> I have been trying to discovery why broadcast traffic only works >> correctly on the VAP associated with the last hostapd to be started. I have >> move with VAP has the working broadcast traffic by restarting the hostapd >> associated with it. >> It would seem something in the WPA/802.1x layer initialization remembers >> which hostapd was started last and that affected the crypto encap. >> I keep looking but do not see any place in the code that could account >> for this. >> It seems the corrupt crypto encap also happens on broadcast between >> stations. >> Please correct me if I am wrong: >> but when using hostapd normally traffic is bridged withing the card. >> So if a station sends to the VAP a broadcast it is actaully sending a non- >> broadcast frame to the AP >> and the AP sends the frame to all the other stations. >> > > I told you waht the likely problem is. Look in the net80211 layer in the > kernel for the problem. > > Sam > I tried to find problems in mbuf corruption in ieee80211_output.c by placing m = m_unshare(m,M_NOWAIT); if (m == NULL) { IEEE80211_DPRINTF(vap, IEEE80211_MSG_OUTPUT, "%s: cannot get writable mbuf\n", __func__); return NULL; } at begining ieee80211_mbuf_adjust() and at beginning of ieee80211_encap() with no change in the broadcast traffic behaviour. I tried then to in ieee80211_crypto.c substituting flags |= IEEE80211_KEY_SWCRYPT; for the encryption capabilities test code if ((ic->ic_cryptocaps & (1<ic_name); flags |= IEEE80211_KEY_SWCRYPT; } to force all the encryption to be done in software. This fixed the broadcast traffic problem but without hardware support its very slow and really loads machine. Enabling in the debug code to ath and net80211 and enabled ATH_DEBUG_KEYCACHE in if_ath.c and IEEE80211_MSG_CRYPTO in net80211 code. It seems that all the VAPS sets the broadcast key for mac ff:ff:ff:ff:ff:ff in the ath device so I assume they conflict and the last one setting the key is the working one; that would explain why the last hostapd started is the only one with working broadcast code to clients. In if_ath.c the code if ((k->wk_flags & IEEE80211_KEY_GROUP) && sc->sc_mcastkey) { /* * Group keys on hardware that supports multicast frame * key search use a mac that is the sender's address with * the high bit set instead of the app-specified address. */ IEEE80211_ADDR_COPY(gmac, bss->ni_macaddr); gmac[0] |= 0x80; mac = gmac; } else mac = k->wk_macaddr; seems to indicate that for multiple VAPs the ath chips needs to be able to distinguish between broadcast keys by using a permutation of VAPs bssid. But in if_athvar.h the code does not seem complete and sc->sc_mcastkey is also set false. #ifdef notyet #define ath_hal_hasmcastkeysearch(_ah) \ (ath_hal_getcapability(_ah, HAL_CAP_MCAST_KEYSRCH, 0, NULL) == HAL_OK) #define ath_hal_getmcastkeysearch(_ah) \ (ath_hal_getcapability(_ah, HAL_CAP_MCAST_KEYSRCH, 1, NULL) == HAL_OK) #else #define ath_hal_getmcastkeysearch(_ah) 0 #endif I am using cards with an AR5212 which does seem to have multiple bssid support working so I hope they should also support mcastkeysearch capability. Maybe only some firmware revisions have this? Do you know what the status of the HAL code is for supporting this? Why it is commented out in if_athvar.h? -Russ From owner-freebsd-stable@FreeBSD.ORG Tue Jan 19 03:34: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 D58F3106566C for ; Tue, 19 Jan 2010 03:34:05 +0000 (UTC) (envelope-from doconnor@gsoft.com.au) Received: from cain.gsoft.com.au (cain.gsoft.com.au [203.31.81.10]) by mx1.freebsd.org (Postfix) with ESMTP id 5473C8FC15 for ; Tue, 19 Jan 2010 03:34:04 +0000 (UTC) Received: from inchoate.gsoft.com.au ([203.31.81.30]) (authenticated bits=0) by cain.gsoft.com.au (8.13.8/8.13.8) with ESMTP id o0J3Y3nw098594 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Tue, 19 Jan 2010 14:04:03 +1030 (CST) (envelope-from doconnor@gsoft.com.au) From: "Daniel O'Connor" To: freebsd-stable@freebsd.org Date: Tue, 19 Jan 2010 14:03:59 +1030 User-Agent: KMail/1.9.10 References: <4B54C100.9080906@mail.zedat.fu-berlin.de> <201001191250.23625.doconnor@gsoft.com.au> <7346c5c61001181841j3653a7c3m32bc033c8c146a92@mail.gmail.com> In-Reply-To: <7346c5c61001181841j3653a7c3m32bc033c8c146a92@mail.gmail.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart5497663.naMDPYmIWM"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <201001191404.01618.doconnor@gsoft.com.au> X-Spam-Score: -3.635 () ALL_TRUSTED,AWL,BAYES_00 X-Scanned-By: MIMEDefang 2.63 on 203.31.81.10 Cc: "O. Hartmann" , Garrett Moore Subject: Re: immense delayed write to file system (ZFS and UFS2), performance issues X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 19 Jan 2010 03:34:05 -0000 --nextPart5497663.naMDPYmIWM Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Tue, 19 Jan 2010, Garrett Moore wrote: > The drives being discussed in my related thread (regarding poor > performance) are all WD Green drives. I have used wdidle3 to set all > of my drive timeouts to 5 minutes. I'll see what sort of difference > this makes for performance. > > Even if it makes no difference to performance, thank you for pointing > it out -- my drives have less than 2,000 hours on them and were all > over 90,000 load cycles due to this moronic factory setting. Since > changing the timeout, they haven't parked (which is what I would > expect). Mine had 65k or so, except one which only had 66.. Very odd! =2D-=20 Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C --nextPart5497663.naMDPYmIWM Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.12 (FreeBSD) iD8DBQBLVSgp5ZPcIHs/zowRAif1AKCh8Xfac4PnR/0H6EmKKOgoWsEtVwCfXZnC F+RC7onbrbEgilf3H245cqs= =eGZD -----END PGP SIGNATURE----- --nextPart5497663.naMDPYmIWM-- From owner-freebsd-stable@FreeBSD.ORG Tue Jan 19 08:03: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 A9AAF1065693; Tue, 19 Jan 2010 08:03:02 +0000 (UTC) (envelope-from to.my.trociny@gmail.com) Received: from mail-bw0-f209.google.com (mail-bw0-f209.google.com [209.85.218.209]) by mx1.freebsd.org (Postfix) with ESMTP id 077588FC14; Tue, 19 Jan 2010 08:03:01 +0000 (UTC) Received: by bwz1 with SMTP id 1so1292638bwz.13 for ; Tue, 19 Jan 2010 00:03:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:to:cc:subject:references :organization:from:date:in-reply-to:message-id:user-agent :mime-version:content-type:content-transfer-encoding; bh=D7b1832tx6M4Fywxyifrqf+sABYej7JZs9JCYUNZnVk=; b=hFIcAapmcxMF6lGqBTXdoK1jvhptwpw24G+1A8gTCUbJVobbm5VGahKjr5Xolq3cbu 0L/TLgHrQUf9/T11gpYlt66qeIToYqt+D789KfYEG2BTWD2Tikes3KENVdQR0qeOb7to erFcKjd/fHlLTLEpolv7LZuS6T48tN5u8dpgs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=to:cc:subject:references:organization:from:date:in-reply-to :message-id:user-agent:mime-version:content-type :content-transfer-encoding; b=P0kBO18/bYHo8XUVNNXqQoOEMoWoxo7lcqr0ai2N5YmNzp5/NZEYuamJc3ji168cq/ gVo2K5K6Hh1eptRTGi2YiV0xK12LYa8dzeEa/n5RnZytMeTYA0ufBGk6Zq2YDPmIue+d oTIBPwzOeNjJ4FqgVjNcCAk9v+Xt5JpJnF0Js= Received: by 10.204.32.72 with SMTP id b8mr2583084bkd.203.1263888180556; Tue, 19 Jan 2010 00:03:00 -0800 (PST) Received: from localhost (ms.singlescrowd.net [80.85.90.67]) by mx.google.com with ESMTPS id 16sm883583bwz.11.2010.01.19.00.02.59 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 19 Jan 2010 00:02:59 -0800 (PST) To: freebsd-fs@FreeBSD.org References: <86ocl272mb.fsf@kopusha.onet> <86tyuqnz9x.fsf@zhuzha.ua1> <86zl4awmon.fsf@zhuzha.ua1> Organization: TOA Ukraine From: Mikolaj Golub Date: Tue, 19 Jan 2010 10:02:57 +0200 In-Reply-To: <86zl4awmon.fsf@zhuzha.ua1> (Mikolaj Golub's message of "Tue\, 19 Jan 2010 09\:58\:32 +0200") Message-ID: <86vdeywmha.fsf@zhuzha.ua1> User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 8bit Cc: freebsd-stable@FreeBSD.org Subject: Re: FreeBSD NFS client/Linux NFS server issue X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 19 Jan 2010 08:03:02 -0000 Hi, In this thread I have posted to freebsd-fs@ several messages describing our problem with freebsd7.1 nfs clients. As with the time new info has appeared and having this all spread in several messages might be a bit confusing, I want to summarise here what we see and know. Also I cc to freebsd-stable@ hoping to draw more attention to this problem as it looks for me very interesting and challenging :-) I have found in the Internet that other people have been observed the similar problem with FreeBSD6.2 client: http://forums.freebsd.org/showthread.php?t=1697 So, on some of our freebsd7.1 nfs clients (and it looks like we have had similar case with 6.3), which have several nfs mounts to the same CentOS 5.3 NFS server (mount options: rw,-3,-T,-s,-i,-r=32768,-w=32768,-o=noinet6), at some moment the access to one of the NFS mount gets stuck, while the access to the other mounts works ok. In all cases we have been observed so far the first gotten stuck process was php script (or two) that was (were) writing to logs file (appending). In tcpdump we see that every write to the file causes the sequence of the following rpc: ACCESS - READ - WRITE - COMMIT. And at some moment this stops after READ rpc call and successful reply. After this in tcpdump successful readdir/access/lookup/fstat calls are observed from our other utilities, which just check the presence of some files and they work ok (df also works). The php process at this state is in bo_wwait invalidating buffer cache [1]. If at this time we try accessing the share with mc then it hangs acquiring the vn_lock held by php process [2] and after this any operations with this NFS share hang (df hangs too). If instead some other process is started that writes to some other file on this share (append) then the first process "unfreezes" too (starting from WRITE rpc, so there is no any retransmits). With my limited knowledge of this complicated kernel subsystem I have the following hypothesis what is going on. On some of the nfs_write() it does successful ACCESS - READ rpcs but by some reason does not call WRITE to flush dirty buffer to the server (aborts somewere or may be in bdwrite() which calls bd_wakeup() and actually bd_wakeup considers that we don't have enough dirty buffers?). But it looks like on this stage the buffer appears to be unlinked from bufqueues [3] so when bufdaemon runs it does not flush the buffer. The next write() call to this file causes the process to get stuck invalidating the dirty buffer. The buffer is accessible by nfsiod via nmp structure [3] and when the next process is writing to another file, nfsiod is started and flushes this dirty buffer. [1]: Gotten stuck php process: (kgdb) bt #0 sched_switch (td=0xc839e000, newtd=Variable "newtd" is not available. ) at /usr/src/sys/kern/sched_ule.c:1944 #1 0xc07cabe6 in mi_switch (flags=Variable "flags" is not available. ) at /usr/src/sys/kern/kern_synch.c:440 #2 0xc07f42fb in sleepq_switch (wchan=Variable "wchan" is not available. ) at /usr/src/sys/kern/subr_sleepqueue.c:497 #3 0xc07f460c in sleepq_catch_signals (wchan=0xc90c9ee8) at /usr/src/sys/kern/subr_sleepqueue.c:417 #4 0xc07f4ebd in sleepq_wait_sig (wchan=0xc90c9ee8) at /usr/src/sys/kern/subr_sleepqueue.c:594 #5 0xc07cb047 in _sleep (ident=0xc90c9ee8, lock=0xc90c9e8c, priority=333, wmesg=0xc0b731ed "bo_wwait", timo=0) at /usr/src/sys/kern/kern_synch.c:224 #6 0xc0827295 in bufobj_wwait (bo=0xc90c9ec4, slpflag=256, timeo=0) at /usr/src/sys/kern/vfs_bio.c:3870 #7 0xc0966307 in nfs_flush (vp=0xc90c9e04, waitfor=1, td=0xc839e000, commit=1) at /usr/src/sys/nfsclient/nfs_vnops.c:2989 #8 0xc09667ce in nfs_fsync (ap=0xed3c38ec) at /usr/src/sys/nfsclient/nfs_vnops.c:2725 #9 0xc0aee5d2 in VOP_FSYNC_APV (vop=0xc0c2b920, a=0xed3c38ec) at vnode_if.c:1007 #10 0xc0827864 in bufsync (bo=0xc90c9ec4, waitfor=1, td=0xc839e000) at vnode_if.h:538 #11 0xc083f354 in bufobj_invalbuf (bo=0xc90c9ec4, flags=1, td=0xc839e000, slpflag=256, slptimeo=0) at /usr/src/sys/kern/vfs_subr.c:1066 #12 0xc083f6e2 in vinvalbuf (vp=0xc90c9e04, flags=1, td=0xc839e000, slpflag=256, slptimeo=0) at /usr/src/sys/kern/vfs_subr.c:1142 #13 0xc094f216 in nfs_vinvalbuf (vp=0xc90c9e04, flags=Variable "flags" is not available. ) at /usr/src/sys/nfsclient/nfs_bio.c:1326 #14 0xc0951825 in nfs_write (ap=0xed3c3bc4) at /usr/src/sys/nfsclient/nfs_bio.c:918 #15 0xc0aef956 in VOP_WRITE_APV (vop=0xc0c2b920, a=0xed3c3bc4) at vnode_if.c:691 #16 0xc0850097 in vn_write (fp=0xc9969b48, uio=0xed3c3c60, active_cred=0xcb901600, flags=0, td=0xc839e000) at vnode_if.h:373 #17 0xc07f9d17 in dofilewrite (td=0xc839e000, fd=6, fp=0xc9969b48, auio=0xed3c3c60, offset=-1, flags=0) at file.h:256 #18 0xc07f9ff8 in kern_writev (td=0xc839e000, fd=6, auio=0xed3c3c60) at /usr/src/sys/kern/sys_generic.c:401 #19 0xc07fa06f in write (td=0xc839e000, uap=0xed3c3cfc) at /usr/src/sys/kern/sys_generic.c:317 #20 0xc0ad9c75 in syscall (frame=0xed3c3d38) at /usr/src/sys/i386/i386/trap.c:1090 #21 0xc0ac01b0 in Xint0x80_syscall () at /usr/src/sys/i386/i386/exception.s:255 #22 0x00000033 in ?? () Previous frame inner to this frame (corrupt stack?) [2] mc process gotten stuck acquiring _vn_lock held by above php thread: at /usr/src/sys/kern/sched_ule.c:1944 * 178 Thread 100340 (PID=40443: mc) sched_switch (td=0xc9810af0, newtd=Variable "newtd" is not availabl . (kgdb) thr 178 [Switching to thread 178 (Thread 100340)]#0 sched_switch (td=0xc9810af0, newtd=Variable "newtd" is not available. ) at /usr/src/sys/kern/sched_ule.c:1944 1944 cpuid = PCPU_GET(cpuid); (kgdb) bt #0 sched_switch (td=0xc9810af0, newtd=Variable "newtd" is not available. ) at /usr/src/sys/kern/sched_ule.c:1944 #1 0xc07cabe6 in mi_switch (flags=Variable "flags" is not available. ) at /usr/src/sys/kern/kern_synch.c:440 #2 0xc07f42fb in sleepq_switch (wchan=Variable "wchan" is not available. ) at /usr/src/sys/kern/subr_sleepqueue.c:497 #3 0xc07f4946 in sleepq_wait (wchan=0xc90c9e5c) at /usr/src/sys/kern/subr_sleepqueue.c:580 #4 0xc07cb056 in _sleep (ident=0xc90c9e5c, lock=0xc0c77d18, priority=80, wmesg=0xc0b80b92 "nfs", timo=0) at /usr/src/sys/kern/kern_synch.c:226 #5 0xc07adf5a in acquire (lkpp=0xed56b7f0, extflags=Variable "extflags" is not available. ) at /usr/src/sys/kern/kern_lock.c:151 #6 0xc07ae84c in _lockmgr (lkp=0xc90c9e5c, flags=8194, interlkp=0xc90c9e8c, td=0xc9810af0, file=0xc0b74aeb "/usr/src/sys/kern/vfs_subr.c", line=2061) at /usr/src/sys/kern/kern_lock.c:384 #7 0xc0832470 in vop_stdlock (ap=0xed56b840) at /usr/src/sys/kern/vfs_default.c:305 #8 0xc0aef4f6 in VOP_LOCK1_APV (vop=0xc0c1d5c0, a=0xed56b840) at vnode_if.c:1618 #9 0xc084ed86 in _vn_lock (vp=0xc90c9e04, flags=8194, td=0xc9810af0, file=0xc0b74aeb "/usr/src/sys/kern/vfs_subr.c", line=2061) at vnode_if.h:851 #10 0xc0841d84 in vget (vp=0xc90c9e04, flags=8194, td=0xc9810af0) at /usr/src/sys/kern/vfs_subr.c:2061 #11 0xc08355b3 in vfs_hash_get (mp=0xc6b472cc, hash=3326873010, flags=Variable "flags" is not available. ) at /usr/src/sys/kern/vfs_hash.c:81 #12 0xc09534d4 in nfs_nget (mntp=0xc6b472cc, fhp=0xc97be078, fhsize=20, npp=0xed56b9f0, flags=2) at /usr/src/sys/nfsclient/nfs_node.c:120 #13 0xc0964a05 in nfs_lookup (ap=0xed56ba84) at /usr/src/sys/nfsclient/nfs_vnops.c:947 #14 0xc0aefbe6 in VOP_LOOKUP_APV (vop=0xc0c2b920, a=0xed56ba84) at vnode_if.c:99 #15 0xc0836841 in lookup (ndp=0xed56bb48) at vnode_if.h:57 #16 0xc083756f in namei (ndp=0xed56bb48) at /usr/src/sys/kern/vfs_lookup.c:219 #17 0xc0844fef in kern_lstat (td=0xc9810af0, path=0x48611280
, pathseg=UIO_USERSPACE, sbp=0xed56bc18) at /usr/src/sys/kern/vfs_syscalls.c:2169 #18 0xc08451af in lstat (td=0xc9810af0, uap=0xed56bcfc) at /usr/src/sys/kern/vfs_syscalls.c:2152 #19 0xc0ad9c75 in syscall (frame=0xed56bd38) at /usr/src/sys/i386/i386/trap.c:1090 #20 0xc0ac01b0 in Xint0x80_syscall () at /usr/src/sys/i386/i386/exception.s:255 #21 0x00000033 in ?? () Previous frame inner to this frame (corrupt stack?) (kgdb) fr 6 #6 0xc07ae84c in _lockmgr (lkp=0xc90c9e5c, flags=8194, interlkp=0xc90c9e8c, td=0xc9810af0, file=0xc0b74aeb "/usr/src/sys/kern/vfs_subr.c", line=2061) at /usr/src/sys/kern/kern_lock.c:384 384 error = acquire(&lkp, extflags, (LK_HAVE_EXCL | LK_WANT_EXCL), &contested, &waitstart); (kgdb) p *lkp $2 = {lk_object = {lo_name = 0xc0b80b92 "nfs", lo_type = 0xc0b80b92 "nfs", lo_flags = 70844416, lo_witness_data = {lod_list = {stqe_next = 0x0}, lod_witness = 0x0}}, lk_interlock = 0xc0c77d18, lk_flags = 33816640, lk_sharecount = 0, lk_waitcount = 1, lk_exclusivecount = 1, lk_prio = 80, lk_timo = 51, lk_lockholder = 0xc839e000, lk_newlock = 0x0} [3] struct nfsmount of the "problem" share: (kgdb) p *nmp $4 = {nm_mtx = {lock_object = {lo_name = 0xc0b808ee "NFSmount lock", lo_type = 0xc0b808ee "NFSmount lock", lo_flags = 16973824, lo_witness_data = {lod_list = { stqe_next = 0x0}, lod_witness = 0x0}}, mtx_lock = 4, mtx_recurse = 0}, nm_flag = 35399, nm_state = 1310720, nm_mountp = 0xc6b472cc, nm_numgrps = 16, nm_fh = "\001\000\000\000\000\223\000\000\001@\003\n", '\0' , nm_fhsize = 12, nm_rpcclnt = {rc_flag = 0, rc_wsize = 0, rc_rsize = 0, rc_name = 0x0, rc_so = 0x0, rc_sotype = 0, rc_soproto = 0, rc_soflags = 0, rc_timeo = 0, rc_retry = 0, rc_srtt = {0, 0, 0, 0}, rc_sdrtt = {0, 0, 0, 0}, rc_sent = 0, rc_cwnd = 0, rc_timeouts = 0, rc_deadthresh = 0, rc_authtype = 0, rc_auth = 0x0, rc_prog = 0x0, rc_proctlen = 0, rc_proct = 0x0}, nm_so = 0xc6e81d00, nm_sotype = 1, nm_soproto = 0, nm_soflags = 44, nm_nam = 0xc6948640, nm_timeo = 6000, nm_retry = 2, nm_srtt = {15, 15, 31, 52}, nm_sdrtt = {3, 3, 15, 15}, nm_sent = 0, nm_cwnd = 4096, nm_timeouts = 0, nm_deadthresh = 9, nm_rsize = 32768, nm_wsize = 32768, nm_readdirsize = 4096, nm_readahead = 1, nm_wcommitsize = 1177026, nm_acdirmin = 30, nm_acdirmax = 60, nm_acregmin = 3, nm_acregmax = 60, nm_verf = "JW\000\004o", nm_bufq = {tqh_first = 0xda82dc70, tqh_last = 0xda8058e0}, nm_bufqlen = 2, nm_bufqwant = 0, nm_bufqiods = 1, nm_maxfilesize = 1099511627775, nm_rpcops = 0xc0c2b5bc, nm_tprintf_initial_delay = 12, nm_tprintf_delay = 30, nm_nfstcpstate = { rpcresid = 0, flags = 1, sock_send_inprog = 0}, nm_hostname = "172.30.10.92\000/var/www/app31", '\0' , nm_clientid = 0, nm_fsid = { val = {0, 0}}, nm_lease_time = 0, nm_last_renewal = 0} buffers on it: (kgdb) p *nmp->nm_bufq.tqh_first $7 = {b_bufobj = 0xc7324960, b_bcount = 31565, b_caller1 = 0x0, b_data = 0xde581000 " valid_lines:", ' ' , "1341\n invalid_lines:", ' ' , "1556\n total_lines:", ' ' , "2897\n\n Error summary:\n Inactive pr"..., b_error = 0, b_iocmd = 2 '\002', b_ioflags = 0 '\0', b_iooffset = 196608, b_resid = 0, b_iodone = 0, b_blkno = 384, b_offset = 196608, b_bobufs = {tqe_next = 0x0, tqe_prev = 0xc7324964}, b_left = 0x0, b_right = 0x0, b_vflags = 0, b_freelist = { tqe_next = 0xda805894, tqe_prev = 0xc725d3c0}, b_qindex = 0, b_flags = 536870948, b_xflags = 2 '\002', b_lock = {lk_object = {lo_name = 0xc0b73635 "bufwait", lo_type = 0xc0b73635 "bufwait", lo_flags = 70844416, lo_witness_data = {lod_list = { stqe_next = 0x0}, lod_witness = 0x0}}, lk_interlock = 0xc0c77b50, lk_flags = 262144, lk_sharecount = 0, lk_waitcount = 0, lk_exclusivecount = 1, lk_prio = 80, lk_timo = 0, lk_lockholder = 0xfffffffe, lk_newlock = 0x0}, b_bufsize = 31744, b_runningbufspace = 0, b_kvabase = 0xde581000 " valid_lines:", ' ' , "1341\n invalid_lines:", ' ' , "1556\n total_lines:", ' ' , "2897\n\n Error summary:\n Inactive pr"..., b_kvasize = 32768, b_lblkno = 6, b_vp = 0xc73248a0, b_dirtyoff = 31512, b_dirtyend = 31565, b_rcred = 0x0, b_wcred = 0xcebec400, b_saveaddr = 0xde581000, b_pager = { pg_reqpage = 0}, b_cluster = {cluster_head = {tqh_first = 0xda917ec8, tqh_last = 0xda888e94}, cluster_entry = {tqe_next = 0xda917ec8, tqe_prev = 0xda888e94}}, b_pages = {0xc3726e90, 0xc448dca8, 0xc2a55b98, 0xc3bf1a28, 0xc3467ff0, 0xc3299600, 0xc28db130, 0xc2301398, 0x0 }, b_npages = 8, b_dep = {lh_first = 0x0}, b_fsprivate1 = 0x0, b_fsprivate2 = 0x0, b_fsprivate3 = 0x0, b_pin_count = 0} These are entires from our log file. Note that b_qindex is 0. But bufqueues[0] is empty: (kgdb) p bufqueues[0] $8 = {tqh_first = 0x0, tqh_last = 0xc0c83e20} Also does not it look strange that lk_lockholder of b_lock points to innvalid location (0xfffffffe)? -- Mikolaj Golub From owner-freebsd-stable@FreeBSD.ORG Tue Jan 19 08:16: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 BA6BB106566C for ; Tue, 19 Jan 2010 08:16:45 +0000 (UTC) (envelope-from gerrit@pmp.uni-hannover.de) Received: from mrelay1.uni-hannover.de (mrelay1.uni-hannover.de [130.75.2.106]) by mx1.freebsd.org (Postfix) with ESMTP id 2AC758FC0A for ; Tue, 19 Jan 2010 08:16:44 +0000 (UTC) Received: from www.pmp.uni-hannover.de (www.pmp.uni-hannover.de [130.75.117.2]) by mrelay1.uni-hannover.de (8.14.2/8.14.2) with ESMTP id o0J8GfuG001859; Tue, 19 Jan 2010 09:16:43 +0100 Received: from pmp.uni-hannover.de (arc.pmp.uni-hannover.de [130.75.117.1]) by www.pmp.uni-hannover.de (Postfix) with SMTP id DA8C624; Tue, 19 Jan 2010 09:16:41 +0100 (CET) Date: Tue, 19 Jan 2010 09:16:41 +0100 From: Gerrit =?ISO-8859-1?Q?K=FChn?= To: Garrett Moore Message-Id: <20100119091641.cc59f03f.gerrit@pmp.uni-hannover.de> In-Reply-To: <7346c5c61001181841j3653a7c3m32bc033c8c146a92@mail.gmail.com> References: <4B54C100.9080906@mail.zedat.fu-berlin.de> <4B54C5EE.5070305@pp.dyndns.biz> <201001191250.23625.doconnor@gsoft.com.au> <7346c5c61001181841j3653a7c3m32bc033c8c146a92@mail.gmail.com> Organization: Albert-Einstein-Institut (MPI =?ISO-8859-1?Q?f=FCr?= Gravitationsphysik & IGP =?ISO-8859-1?Q?Universit=E4t?= Hannover) X-Mailer: Sylpheed 2.7.1 (GTK+ 2.18.4; i386-portbld-freebsd7.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-PMX-Version: 5.5.9.388399, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2010.1.19.80317 Cc: "O. Hartmann" , freebsd-stable@freebsd.org Subject: Re: immense delayed write to file system (ZFS and UFS2), performance issues X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 19 Jan 2010 08:16:45 -0000 On Mon, 18 Jan 2010 21:41:53 -0500 Garrett Moore wrote about Re: immense delayed write to file system (ZFS and UFS2), performance issues: GM> The drives being discussed in my related thread (regarding poor GM> performance) are all WD Green drives. I have used wdidle3 to set all GM> of my drive timeouts to 5 minutes. I'll see what sort of difference GM> this makes for performance. GM> Even if it makes no difference to performance, thank you for pointing GM> it out GM> -- my drives have less than 2,000 hours on them and were all over GM> 90,000 load cycles due to this moronic factory setting. Since changing GM> the timeout, they haven't parked (which is what I would expect). Thanks for bringing up this topic here. I have drives showing up close to 800000 load cycle counts here. Guess it's time for that fix... :-| cu Gerrit From owner-freebsd-stable@FreeBSD.ORG Tue Jan 19 08:35: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 2241910656A5; Tue, 19 Jan 2010 08:35:22 +0000 (UTC) (envelope-from to.my.trociny@gmail.com) Received: from mail-bw0-f209.google.com (mail-bw0-f209.google.com [209.85.218.209]) by mx1.freebsd.org (Postfix) with ESMTP id 77A218FC19; Tue, 19 Jan 2010 08:35:21 +0000 (UTC) Received: by bwz1 with SMTP id 1so1306363bwz.13 for ; Tue, 19 Jan 2010 00:35:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:to:cc:subject:references :organization:from:date:in-reply-to:message-id:user-agent :mime-version:content-type; bh=KErM9rmOfOmkhqcOLR2SyM37a2Q37/DZeNxXlPiKhsE=; b=d/OLllVB7/2495q1R8WGZazu7bdqOP9VlZAP45Efs/J365zGwNw9XZdrLSCSMEbAQj o/ixWJWtvpAjOd5IjRdUGxc6ywWUUCrsIk07zeqaNMuehf0a8r8WYdSMBIYy9oIp26jc 7/7GheWiUuzon3OYnSh+kYHjdOSb0nn4gZs2U= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=to:cc:subject:references:organization:from:date:in-reply-to :message-id:user-agent:mime-version:content-type; b=MQxAHA6GgFGq1KefSlYUXPPFj+O/z82n19TO1P0LCnKp/xqajJD763ZLqmuyUEU3yD G8Uj0OM1fCffFpz9pgCfDJuJKGlmw4WPSNqGTSPVvkImmbrYo6zLbUVNB6rEAG8izcqQ IoHCXQEmVusPgtafJKvZXw1ZeRsvL4zejRw4g= Received: by 10.204.10.18 with SMTP id n18mr4092509bkn.152.1263890120189; Tue, 19 Jan 2010 00:35:20 -0800 (PST) Received: from localhost (ms.singlescrowd.net [80.85.90.67]) by mx.google.com with ESMTPS id 14sm1055390bwz.1.2010.01.19.00.35.19 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 19 Jan 2010 00:35:19 -0800 (PST) To: freebsd-fs@FreeBSD.org References: <86ocl272mb.fsf@kopusha.onet> <86tyuqnz9x.fsf@zhuzha.ua1> <86zl4awmon.fsf@zhuzha.ua1> <86vdeywmha.fsf@zhuzha.ua1> Organization: TOA Ukraine From: Mikolaj Golub Date: Tue, 19 Jan 2010 10:35:17 +0200 In-Reply-To: <86vdeywmha.fsf@zhuzha.ua1> (Mikolaj Golub's message of "Tue\, 19 Jan 2010 10\:02\:57 +0200") Message-ID: <86r5pmwkze.fsf@zhuzha.ua1> User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: freebsd-stable@FreeBSD.org Subject: Re: FreeBSD NFS client/Linux NFS server issue X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 19 Jan 2010 08:35:22 -0000 On Tue, 19 Jan 2010 10:02:57 +0200 Mikolaj Golub wrote: > I have found in the Internet that other people have been observed the similar > problem with FreeBSD6.2 client: > > http://forums.freebsd.org/showthread.php?t=1697 Reading this through carefully it looks like the guy did not experience the problem (gotten stuck processes). He just described the behaviour of freebsd client when appending the file. -- Mikolaj Golub From owner-freebsd-stable@FreeBSD.ORG Tue Jan 19 09:29: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 2294B106566B for ; Tue, 19 Jan 2010 09:29:02 +0000 (UTC) (envelope-from freebsd-questions@pp.dyndns.biz) Received: from proxy3.bredband.net (proxy3.bredband.net [195.54.101.73]) by mx1.freebsd.org (Postfix) with ESMTP id CB0EE8FC1A for ; Tue, 19 Jan 2010 09:29:01 +0000 (UTC) Received: from ipb1.telenor.se (195.54.127.164) by proxy3.bredband.net (7.3.140.3) id 4AD3E1BA026778CC for freebsd-stable@freebsd.org; Tue, 19 Jan 2010 10:29:00 +0100 X-SMTPAUTH-B2: X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ar86AKIKVUtV4js3PGdsb2JhbACBRoZwkzwBAQEBN7lvhDME X-IronPort-AV: E=Sophos;i="4.49,302,1262559600"; d="scan'208";a="27627115" Received: from c-373be255.107-1-64736c10.cust.bredbandsbolaget.se (HELO gatekeeper.pp.dyndns.biz) ([85.226.59.55]) by ipb1.telenor.se with ESMTP; 19 Jan 2010 10:29:00 +0100 Received: from [192.168.69.67] (phobos [192.168.69.67]) by gatekeeper.pp.dyndns.biz (8.14.3/8.14.3) with ESMTP id o0J9Swlu036158; Tue, 19 Jan 2010 10:28:58 +0100 (CET) (envelope-from freebsd-questions@pp.dyndns.biz) Message-ID: <4B557B5A.8040902@pp.dyndns.biz> Date: Tue, 19 Jan 2010 10:28:58 +0100 From: =?ISO-8859-1?Q?Morgan_Wesstr=F6m?= User-Agent: Thunderbird 2.0.0.23 (X11/20091010) MIME-Version: 1.0 To: Garrett Moore References: <4B54C100.9080906@mail.zedat.fu-berlin.de> <4B54C5EE.5070305@pp.dyndns.biz> <201001191250.23625.doconnor@gsoft.com.au> <7346c5c61001181841j3653a7c3m32bc033c8c146a92@mail.gmail.com> In-Reply-To: <7346c5c61001181841j3653a7c3m32bc033c8c146a92@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "O. Hartmann" , freebsd-stable@freebsd.org Subject: Re: immense delayed write to file system (ZFS and UFS2), performance issues X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 19 Jan 2010 09:29:02 -0000 Garrett Moore wrote: > The drives being discussed in my related thread (regarding poor performance) > are all WD Green drives. I have used wdidle3 to set all of my drive timeouts > to 5 minutes. I'll see what sort of difference this makes for performance. > > Even if it makes no difference to performance, thank you for pointing it out > -- my drives have less than 2,000 hours on them and were all over 90,000 > load cycles due to this moronic factory setting. Since changing the timeout, > they haven't parked (which is what I would expect). > You're welcome. I just feel as bad for you as for everyone else who has bought these obviously Windoze optimized harddrives. Unfortunately neither wdidle3 nor an updated firmware is available or functioning on the latest models in the Green series. At least that's what I've read from other people having this issue. WD only claims they don't support Linux and they probably have never heard of FreeBSD. If anyone successfully has fixed their WD15EADS drives this way I'd be interested in hearing from you. One of my drives has 216,000 load cycles accumulated over 8 months. That's one every 2nd minute... and I was hit by the Seagate 7200.11 fiasco too. Running on Samsungs now :-) From owner-freebsd-stable@FreeBSD.ORG Tue Jan 19 09:34:39 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 AC497106568D for ; Tue, 19 Jan 2010 09:34:39 +0000 (UTC) (envelope-from kraduk@googlemail.com) Received: from mail-fx0-f227.google.com (mail-fx0-f227.google.com [209.85.220.227]) by mx1.freebsd.org (Postfix) with ESMTP id 305C98FC1E for ; Tue, 19 Jan 2010 09:34:38 +0000 (UTC) Received: by fxm27 with SMTP id 27so3144755fxm.3 for ; Tue, 19 Jan 2010 01:34:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=jg3Pgq71gq8jeJCcPGSHnzVKUOse+FZRFpROD/SkFlo=; b=mfYaGtJEB3W98rZx17v1Yx0ScLb5dPvmidyE+gtGiRlhqTpCHOkrF1cDwlE7HpUwzj iORp9VfJzCZbVpQh5x1mEW/bMvlXTbvMxdB27QCkRKO5KssIeAEH/nDFIS1Cb/3YqcoM vPksTGpT+PaDFOSSca+ggUMcyRPAuD8CE6YS0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=czisEekzGTIJ7/4gqrV1mIerdVGtvw1+ygNT3TEEtQxqgT1aChr61JrN0eTOWrMmDZ 457sZ6vg0SCoLpLRmqcFVsBzN0dsyCXcK4UOG8N2AQpDzI84H9Fjwe0/Au89otdxh7lZ du/SAQeXxJnAD1zoWoy8E9xid03VLVsk74ExI= MIME-Version: 1.0 Received: by 10.239.190.137 with SMTP id x9mr138985hbh.18.1263892155986; Tue, 19 Jan 2010 01:09:15 -0800 (PST) In-Reply-To: <4B54C5EE.5070305@pp.dyndns.biz> References: <4B54C100.9080906@mail.zedat.fu-berlin.de> <4B54C5EE.5070305@pp.dyndns.biz> Date: Tue, 19 Jan 2010 09:09:15 +0000 Message-ID: From: krad To: =?ISO-8859-1?Q?Morgan_Wesstr=F6m?= Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: "O. Hartmann" , FreeBSD Stable , freebsd-questions@freebsd.org Subject: Re: immense delayed write to file system (ZFS and UFS2), performance issues X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 19 Jan 2010 09:34:39 -0000 2010/1/18 Morgan Wesstr=F6m > O. Hartmann wrote: > > I realise a strange behaviour of several FreeBSD 8.0-STABLE/amd64 boxes= . > > All boxes have the most recent STABLE. One box is a UP system, two > > others SMP boxes, one with a Q6600 4-core, another XEON with 2x 4-cores > > (Dell Poweredge III). > > > > Symptome: All boxes have ZFS and UFS2 filesystems. Since two weeks or > > so, sometimes the I/O performance drops massively when doing 'svn > > update', 'make world' or even 'make kernel'. It doesn't matter what > > memory and how many cpu the box has, it get stuck for several seconds > > and freezing. On the UP box, this is sometimes for 10 - 20 seconds. > > A very interesting phenomenon is the massively delayed file writing on > > ZFS filesystems I realise. Editing a file in 'vi' running on one XTerm > > and having in another Xterminal my shell for compiling this file, it > > takes sometimes up to 20 seconds to get the file updated after it has > > been written. It's like having an old, slow NFS connection with long > > cache delays. > > These massively delayed file transactions are not necessarely under > > heavy load, sometimes they occur in a relaxed situation. They seem to > > occur much more often on the UP box than on the SMP boxes, but this > > strange phenomenon also occur on the Dell Poweredge II, which has 16GB > > RAM and summa summarum 16 cores. This phenomenon does occur on ZFS- and > > UFS2 filesystems as well. It is hardly reproducable. > > > > Is there any known issue? > > > > Ragrds, > > Oliver > > > The disks involved don't happen to be Western Digital Green Power disks, > do they? The Intelli-Park function in these disks are wrecking havoc > with I/O in Linux-land at least, causing massive stalls and iowait > through the roof during the 25-30 seconds it takes for the heads to > unload after parking. I have two of these disks sitting on my desk now > collecting dust... > /Morgan > _______________________________________________ > freebsd-questions@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-questions > To unsubscribe, send any mail to " > freebsd-questions-unsubscribe@freebsd.org" > ZFS is copy on write, therefore to optimize the write performance it delays writes for a long as possible, upto a set maximum time. It will then flush to the disks. How long this time is depends on how much free ram you have available. Assuming processes are eating up all your ram I would imagine yo= u are hitting the max limit. I'm not sure exactly what its set to on bsd but = I know the default on opensolaris is 30s. I think this explains your delayed writes. Not sure what will cause the lock ups though. From owner-freebsd-stable@FreeBSD.ORG Tue Jan 19 09:37: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 B5E41106566B for ; Tue, 19 Jan 2010 09:37:43 +0000 (UTC) (envelope-from freebsd-questions@pp.dyndns.biz) Received: from proxy1.bredband.net (proxy1.bredband.net [195.54.101.71]) by mx1.freebsd.org (Postfix) with ESMTP id 653058FC08 for ; Tue, 19 Jan 2010 09:37:42 +0000 (UTC) Received: from ipb1.telenor.se (195.54.127.164) by proxy1.bredband.net (7.3.140.3) id 4AD3E1C002766120 for freebsd-stable@freebsd.org; Tue, 19 Jan 2010 10:37:41 +0100 X-SMTPAUTH-B2: X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ar86ANkLVUtV4js3PGdsb2JhbACBRoZwkzwBAQEBN7lthDME X-IronPort-AV: E=Sophos;i="4.49,302,1262559600"; d="scan'208";a="27629933" Received: from c-373be255.107-1-64736c10.cust.bredbandsbolaget.se (HELO gatekeeper.pp.dyndns.biz) ([85.226.59.55]) by ipb1.telenor.se with ESMTP; 19 Jan 2010 10:37:41 +0100 Received: from [192.168.69.67] (phobos [192.168.69.67]) by gatekeeper.pp.dyndns.biz (8.14.3/8.14.3) with ESMTP id o0J9bdXe036349; Tue, 19 Jan 2010 10:37:39 +0100 (CET) (envelope-from freebsd-questions@pp.dyndns.biz) Message-ID: <4B557D63.6090508@pp.dyndns.biz> Date: Tue, 19 Jan 2010 10:37:39 +0100 From: =?ISO-8859-1?Q?Morgan_Wesstr=F6m?= User-Agent: Thunderbird 2.0.0.23 (X11/20091010) MIME-Version: 1.0 To: =?ISO-8859-1?Q?Gerrit_K=FChn?= References: <4B54C100.9080906@mail.zedat.fu-berlin.de> <4B54C5EE.5070305@pp.dyndns.biz> <201001191250.23625.doconnor@gsoft.com.au> <7346c5c61001181841j3653a7c3m32bc033c8c146a92@mail.gmail.com> <20100119091641.cc59f03f.gerrit@pmp.uni-hannover.de> In-Reply-To: <20100119091641.cc59f03f.gerrit@pmp.uni-hannover.de> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Cc: "O. Hartmann" , freebsd-stable@freebsd.org, Garrett Moore Subject: Re: immense delayed write to file system (ZFS and UFS2), performance issues X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 19 Jan 2010 09:37:43 -0000 Gerrit Khn wrote: > Thanks for bringing up this topic here. I have drives showing up close to > 800000 load cycle counts here. Guess it's time for that fix... :-| > Just note that the utility is officially for WD's Raid Edition GP drives and not for the regular consumer models although some users have reported success on using it on those too. /Morgan From owner-freebsd-stable@FreeBSD.ORG Tue Jan 19 09:57: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 A9BFA10656A5 for ; Tue, 19 Jan 2010 09:57:38 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta01.emeryville.ca.mail.comcast.net (qmta01.emeryville.ca.mail.comcast.net [76.96.30.16]) by mx1.freebsd.org (Postfix) with ESMTP id 8E3B18FC0A for ; Tue, 19 Jan 2010 09:57:38 +0000 (UTC) Received: from omta02.emeryville.ca.mail.comcast.net ([76.96.30.19]) by qmta01.emeryville.ca.mail.comcast.net with comcast id XMxT1d0010QkzPwA1MxeFm; Tue, 19 Jan 2010 09:57:38 +0000 Received: from koitsu.dyndns.org ([98.248.46.159]) by omta02.emeryville.ca.mail.comcast.net with comcast id XMxe1d0013S48mS8NMxeMR; Tue, 19 Jan 2010 09:57:38 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id E0CD71E3033; Tue, 19 Jan 2010 01:57:36 -0800 (PST) Date: Tue, 19 Jan 2010 01:57:36 -0800 From: Jeremy Chadwick To: freebsd-stable@freebsd.org Message-ID: <20100119095736.GA71824@icarus.home.lan> References: <4B54C100.9080906@mail.zedat.fu-berlin.de> <4B54C5EE.5070305@pp.dyndns.biz> <201001191250.23625.doconnor@gsoft.com.au> <7346c5c61001181841j3653a7c3m32bc033c8c146a92@mail.gmail.com> <4B557B5A.8040902@pp.dyndns.biz> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <4B557B5A.8040902@pp.dyndns.biz> User-Agent: Mutt/1.5.20 (2009-06-14) Subject: Re: immense delayed write to file system (ZFS and UFS2), performance issues X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 19 Jan 2010 09:57:38 -0000 On Tue, Jan 19, 2010 at 10:28:58AM +0100, Morgan Wesstrm wrote: > Garrett Moore wrote: > > The drives being discussed in my related thread (regarding poor performance) > > are all WD Green drives. I have used wdidle3 to set all of my drive timeouts > > to 5 minutes. I'll see what sort of difference this makes for performance. > > > > Even if it makes no difference to performance, thank you for pointing it out > > -- my drives have less than 2,000 hours on them and were all over 90,000 > > load cycles due to this moronic factory setting. Since changing the timeout, > > they haven't parked (which is what I would expect). > > You're welcome. I just feel as bad for you as for everyone else who has > bought these obviously Windoze optimized harddrives. Unfortunately > neither wdidle3 nor an updated firmware is available or functioning on > the latest models in the Green series. At least that's what I've read > from other people having this issue. WD only claims they don't support > Linux and they probably have never heard of FreeBSD. No offence intended by this statement, but: the Green drives are specifically intended for workstations. I don't believe in the whole "segregation of drive model" thing, but the fact of the matter is, the Green drives are variable-RPM and have numerous firmware-level features which intend for them to be used in workstation environments -- that means not constant I/O or heavy workload. Windows has nothing to do with this. If you want a consumer-edition drive that's better tuned for server work, you should really be looking at the WD Caviar Black series or their RE/RE2 series. I have both the Green and Black drives, and I've done my share of benchmarking. Sustained transfer rates on the Black models exceed that of the Greens by almost 20-25MB/sec. Average seek times are slightly lower, and I/O concurrency is handled much better. The Black drives also have a feature called TLER[1], which can be toggled using a utility from Western Digital. Those using these drives in a RAID or ZFS array will be very interested in disabling this feature to ensure quick timeouts from the drive in the case of I/O errors. Other manufacturers have the same feature, just called something else (ex. Samsung's is called CCTL). Now, admittedly WD doesn't give this utility out any more (which is silly), and some people have reported that recent-day (circa mid-to-late 2009) Black drives refuse to let you toggle TLER. The latter claim is absurd -- I purchased 4 Black drives (2 with manufacturing dates of October 2009, and 2 with September 2009) and all of them let me toggle TLER without any problem. Keep in mind you your SATA controller has to be set to non-AHCI mode (sometimes called "Enhanced mode") or Compatibility mode (e.g. IDE emulation) for the utility work. If you have qualms/concerns/issues with Western Digital drives or their mentality behind their drives, simply don't buy them. Really. People often ask me (and others) "what brand of hard disk is good?" and I always tell them the same thing: "there's no correct answer. Everyone has their own experience with different vendors, models, etc." [1]: http://en.wikipedia.org/wiki/Time-Limited_Error_Recovery > If anyone successfully has fixed their WD15EADS drives this way I'd be > interested in hearing from you. One of my drives has 216,000 load cycles > accumulated over 8 months. That's one every 2nd minute... and I was hit > by the Seagate 7200.11 fiasco too. Running on Samsungs now :-) Aren't Samsung's drives known for firmware bugs/quirks? The documentation associated with smartmontools discusses this quite a bit. This is one reason why I stay away from them. Fujitsu is another vendor I want absolutely nothing to do with (very high failure rates in addition to bad sectors with their SCSI-3 disks at my workplace). -- | 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 Jan 19 10:07: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 BACE0106566B for ; Tue, 19 Jan 2010 10:07:28 +0000 (UTC) (envelope-from gerrit@pmp.uni-hannover.de) Received: from mrelay1.uni-hannover.de (mrelay1.uni-hannover.de [130.75.2.106]) by mx1.freebsd.org (Postfix) with ESMTP id 2D19E8FC1E for ; Tue, 19 Jan 2010 10:07:27 +0000 (UTC) Received: from www.pmp.uni-hannover.de (www.pmp.uni-hannover.de [130.75.117.2]) by mrelay1.uni-hannover.de (8.14.2/8.14.2) with ESMTP id o0JA7O5B007444; Tue, 19 Jan 2010 11:07:26 +0100 Received: from pmp.uni-hannover.de (arc.pmp.uni-hannover.de [130.75.117.1]) by www.pmp.uni-hannover.de (Postfix) with SMTP id C1FF424; Tue, 19 Jan 2010 11:07:24 +0100 (CET) Date: Tue, 19 Jan 2010 11:07:24 +0100 From: Gerrit =?ISO-8859-1?Q?K=FChn?= To: Jeremy Chadwick Message-Id: <20100119110724.ec01a3ed.gerrit@pmp.uni-hannover.de> In-Reply-To: <20100119095736.GA71824@icarus.home.lan> References: <4B54C100.9080906@mail.zedat.fu-berlin.de> <4B54C5EE.5070305@pp.dyndns.biz> <201001191250.23625.doconnor@gsoft.com.au> <7346c5c61001181841j3653a7c3m32bc033c8c146a92@mail.gmail.com> <4B557B5A.8040902@pp.dyndns.biz> <20100119095736.GA71824@icarus.home.lan> Organization: Albert-Einstein-Institut (MPI =?ISO-8859-1?Q?f=FCr?= Gravitationsphysik & IGP =?ISO-8859-1?Q?Universit=E4t?= Hannover) X-Mailer: Sylpheed 2.7.1 (GTK+ 2.18.4; i386-portbld-freebsd7.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-PMX-Version: 5.5.9.388399, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2010.1.19.95419 Cc: freebsd-stable@freebsd.org Subject: Re: immense delayed write to file system (ZFS and UFS2), performance issues X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 19 Jan 2010 10:07:28 -0000 On Tue, 19 Jan 2010 01:57:36 -0800 Jeremy Chadwick wrote about Re: immense delayed write to file system (ZFS and UFS2), performance issues: JC> If you want a consumer-edition drive that's better tuned for server JC> work, you should really be looking at the WD Caviar Black series or JC> their RE/RE2 series. That's exactly what I did. I have WD-RE2 drives here that show exactly this problem (RE2/GP)! The model number is WD1000FYPS-01ZKB0. cu Gerrit From owner-freebsd-stable@FreeBSD.ORG Tue Jan 19 10:33: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 8D877106566B; Tue, 19 Jan 2010 10:33:54 +0000 (UTC) (envelope-from petefrench@ticketswitch.com) Received: from constantine.ticketswitch.com (constantine.ticketswitch.com [IPv6:2002:57e0:1d4e:1::3]) by mx1.freebsd.org (Postfix) with ESMTP id EBC078FC19; Tue, 19 Jan 2010 10:33: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 1NXBOz-000GQC-Py; Tue, 19 Jan 2010 10:33:37 +0000 Received: from petefrench by dilbert.ticketswitch.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NXBOz-000EO8-P4; Tue, 19 Jan 2010 10:33:37 +0000 Date: Tue, 19 Jan 2010 10:33:37 +0000 Message-Id: To: attilio@freebsd.org In-Reply-To: <3bbf2fe11001181302g4a7e7669w8d8d321a1c123e17@mail.gmail.com> From: Pete French Cc: freebsd-stable@freebsd.org Subject: Re: [PATCH] Lockmgr deadlock on STABLE_8 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 19 Jan 2010 10:33:54 -0000 > May you post your kernel config? sure... include GENERIC ident DEBUG options KDB options DDB options WITNESS options INVARIANT_SUPPORT options INVARIANTS That one doesnt lockup, or didnt for the few days I tried it. The other config is the same, except missing the 'WITNESS' line. The one which locked up was just standard GENERIC ever time. It locked up on 8.0 release, and has been locking every tme I have tried it since. The symptoms look very much like it is the disc subsystem which is locking up (but eventually everything else rinds to a halt too). I updated to SVN rev 202576 last night, and have just done a reboot with a new world and GENERIC kernel built from that. Will see how long that lasts - I expect it to have locked in the next 24 hours or so though. For reference, the dmesg from the machine is attached below. Thanks for taking an interest in this one! -pete. --- 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.0-STABLE #0: Mon Jan 18 23:25:15 GMT 2010 webadmin@florentine.rattatosk:/usr/obj/usr/src/sys/GENERIC amd64 Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Intel(R) Xeon(R) CPU E5345 @ 2.33GHz (2333.43-MHz K8-class CPU) Origin = "GenuineIntel" Id = 0x6fb Stepping = 11 Features=0xbfebfbff Features2=0x4e3bd AMD Features=0x20000800 AMD Features2=0x1 TSC: P-state invariant real memory = 4294967296 (4096 MB) avail memory = 4104093696 (3913 MB) ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs FreeBSD/SMP: 1 package(s) x 4 core(s) cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 cpu2 (AP): APIC ID: 2 cpu3 (AP): APIC ID: 3 ACPI Warning: Invalid length for Pm1aControlBlock: 32, using default 16 20090521 tbfadt-707 ioapic0 irqs 0-23 on motherboard ioapic1 irqs 24-47 on motherboard kbd1 at kbdmux0 acpi0: on motherboard acpi0: [ITHREAD] acpi0: Power Button (fixed) Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x908-0x90b on acpi0 acpi_hpet0: iomem 0xfed00000-0xfed003ff on acpi0 Timecounter "HPET" frequency 14318180 Hz quality 900 pcib0: on acpi0 pci0: on pcib0 pcib1: at device 2.0 on pci0 ACPI Warning: \\_SB_.PCI0.PT02._PRT: Return Package has no elements (empty) 20090521 nspredef-545 pci9: on pcib1 pcib2: at device 0.0 on pci9 pci10: on pcib2 pcib3: at device 0.0 on pci10 pci11: on pcib3 pcib4: at device 1.0 on pci10 pci14: on pcib4 pcib5: at device 2.0 on pci10 pci15: on pcib5 pcib6: at device 0.3 on pci9 pci16: on pcib6 pcib7: at device 3.0 on pci0 pci6: on pcib7 pcib8: at device 0.0 on pci6 pci7: on pcib8 pcib9: at device 4.0 on pci7 pci8: on pcib9 ciss0: port 0x4000-0x40ff mem 0xfde80000-0xfdefffff,0xfde70000-0xfde77fff irq 16 at device 8.0 on pci7 ciss0: PERFORMANT Transport ciss0: got 2 MSI messages] ciss0: [ITHREAD] pcib10: at device 4.0 on pci0 pci19: on pcib10 pcib11: at device 5.0 on pci0 pci22: on pcib11 pcib12: at device 6.0 on pci0 pci2: on pcib12 pcib13: at device 0.0 on pci2 pci3: on pcib13 bce0: mem 0xf8000000-0xf9ffffff irq 18 at device 0.0 on pci3 miibus0: on bce0 brgphy0: PHY 1 on miibus0 brgphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-FDX, auto bce0: Ethernet address: 00:1e:0b:5f:1f:76 bce0: [ITHREAD] bce0: ASIC (0x57081020); Rev (B2); Bus (PCI-X, 64-bit, 133MHz); B/C (1.9.6); Flags (MSI|MFW); MFW () pcib14: at device 7.0 on pci0 pci4: on pcib14 pcib15: at device 0.0 on pci4 pci5: on pcib15 bce1: mem 0xfa000000-0xfbffffff irq 19 at device 0.0 on pci5 miibus1: on bce1 brgphy1: PHY 1 on miibus1 brgphy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-FDX, auto bce1: Ethernet address: 00:1e:0b:5f:fd:d8 bce1: [ITHREAD] bce1: ASIC (0x57081020); Rev (B2); Bus (PCI-X, 64-bit, 133MHz); B/C (1.9.6); Flags (MSI|MFW); MFW () uhci0: port 0x1000-0x101f irq 16 at device 29.0 on pci0 uhci0: [ITHREAD] usbus0: on uhci0 uhci1: port 0x1020-0x103f irq 17 at device 29.1 on pci0 uhci1: [ITHREAD] usbus1: on uhci1 uhci2: port 0x1040-0x105f irq 18 at device 29.2 on pci0 uhci2: [ITHREAD] usbus2: on uhci2 uhci3: port 0x1060-0x107f irq 19 at device 29.3 on pci0 uhci3: [ITHREAD] usbus3: on uhci3 ehci0: mem 0xf7df0000-0xf7df03ff irq 16 at device 29.7 on pci0 ehci0: [ITHREAD] usbus4: EHCI version 1.0 usbus4: on ehci0 pcib16: at device 30.0 on pci0 pci1: on pcib16 vgapci0: port 0x3000-0x30ff mem 0xd8000000-0xdfffffff,0xf7ff0000-0xf7ffffff irq 23 at device 3.0 on pci1 pci1: at device 4.0 (no driver attached) pci1: at device 4.2 (no driver attached) uhci4: port 0x3800-0x381f irq 22 at device 4.4 on pci1 uhci4: [ITHREAD] usbus5: on uhci4 pci1: at device 4.6 (no driver attached) isab0: at device 31.0 on pci0 isa0: on isab0 atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0x500-0x50f irq 17 at device 31.1 on pci0 ata0: on atapci0 ata0: [ITHREAD] acpi_tz0: on acpi0 atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] atkbd0: [ITHREAD] uart0: <16550 or compatible> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 uart0: [FILTER] cpu0: on acpi0 est0: on cpu0 est: CPU supports Enhanced Speedstep, but is not recognized. est: cpu_vendor GenuineIntel, msr 725072506000725 device_attach: est0 attach returned 6 p4tcc0: on cpu0 cpu1: on acpi0 est1: on cpu1 est: CPU supports Enhanced Speedstep, but is not recognized. est: cpu_vendor GenuineIntel, msr 725072506000725 device_attach: est1 attach returned 6 p4tcc1: on cpu1 cpu2: on acpi0 est2: on cpu2 est: CPU supports Enhanced Speedstep, but is not recognized. est: cpu_vendor GenuineIntel, msr 725072506000725 device_attach: est2 attach returned 6 p4tcc2: on cpu2 cpu3: on acpi0 est3: on cpu3 est: CPU supports Enhanced Speedstep, but is not recognized. est: cpu_vendor GenuineIntel, msr 725072506000725 device_attach: est3 attach returned 6 p4tcc3: on cpu3 orm0: at iomem 0xc0000-0xcafff,0xe6000-0xe7fff on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 atrtc0: at port 0x70 irq 8 on isa0 ppc0: cannot reserve I/O port range uart1: at port 0x2f8-0x2ff irq 3 on isa0 uart1: [FILTER] ZFS filesystem version 3 ZFS storage pool version 14 Timecounters tick every 1.000 msec usbus0: 12Mbps Full Speed USB v1.0 usbus1: 12Mbps Full Speed USB v1.0 usbus2: 12Mbps Full Speed USB v1.0 usbus3: 12Mbps Full Speed USB v1.0 usbus4: 480Mbps High Speed USB v2.0 usbus5: 12Mbps Full Speed USB v1.0 ugen0.1: at usbus0 uhub0: on usbus0 ugen1.1: at usbus1 uhub1: on usbus1 ugen2.1: at usbus2 uhub2: on usbus2 ugen3.1: at usbus3 uhub3: on usbus3 ugen4.1: at usbus4 uhub4: on usbus4 ugen5.1: <(0x103c)> at usbus5 uhub5: <(0x103c) UHCI root HUB, class 9/0, rev 1.00/1.00, addr 1> on usbus5 uhub0: 2 ports with 2 removable, self powered uhub1: 2 ports with 2 removable, self powered uhub2: 2 ports with 2 removable, self powered uhub3: 2 ports with 2 removable, self powered uhub5: 2 ports with 2 removable, self powered ugen5.2: at usbus5 ukbd0: on usbus5 kbd2 at ukbd0 ums0: on usbus5 ugen5.3: at usbus5 uhub6: on usbus5 uhub4: 8 ports with 8 removable, self powered uhub6: 7 ports with 7 removable, self powered da0 at ciss0 bus 0 scbus0 target 0 lun 0 da0: Fixed Direct Access SCSI-5 device da0: 135.168MB/s transfers da0: Command Queueing enabled da0: 69970MB (143299800 512 byte sectors: 255H 63S/T 8920C) SMP: AP CPU #3 Launched! SMP: AP CPU #1 Launched! SMP: AP CPU #2 Launched! Trying to mount root from ufs:/dev/da0s1a bce0: link state changed to UP lagg0: link state changed to UP bce1: link state changed to UP From owner-freebsd-stable@FreeBSD.ORG Tue Jan 19 10:41: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 386B41065679 for ; Tue, 19 Jan 2010 10:41:57 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: from mail-fx0-f227.google.com (mail-fx0-f227.google.com [209.85.220.227]) by mx1.freebsd.org (Postfix) with ESMTP id 8A8568FC08 for ; Tue, 19 Jan 2010 10:41:56 +0000 (UTC) Received: by fxm27 with SMTP id 27so3201711fxm.3 for ; Tue, 19 Jan 2010 02:41:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type:content-transfer-encoding; bh=nqe4FnGAmH3yy7vMbWAijsgIwfpOddULcaEGcnsuNUs=; b=f89gzLnrO6vDf/sCmPKNxf0qn7gkpurS8Fhz9yO4or+kT0onoSmhWrCKGZgJIWfdCs HCfQ89QTfI6oIgLiqqaMzik/eBHf2ZLZNoL5mBJ9vQJkr1pabhsJ9xdXMLyaOpGzuWEX 1Mh9pOPSuAfNVbGrOr3pPTyZ/NeYdrzRgcQk4= 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=DdiEixuwGcFl9/xWbxBc+JnQAiEm5C92M/kEiIPk32xTGzkCr1IPcLfe1EFZTJZbPG UmK/KftWsGy2rym9cRjSaUN+P1X7kcTcs0eWn+2Y+6/COUHDjT525w2GydslsApZM6IM y67p6iul0UH8/SQsoWGiMy/MLImEj3joX61RQ= MIME-Version: 1.0 Sender: asmrookie@gmail.com Received: by 10.223.13.209 with SMTP id d17mr8817192faa.100.1263897715332; Tue, 19 Jan 2010 02:41:55 -0800 (PST) In-Reply-To: References: <3bbf2fe11001181302g4a7e7669w8d8d321a1c123e17@mail.gmail.com> Date: Tue, 19 Jan 2010 11:41:55 +0100 X-Google-Sender-Auth: c5c7ac6427cb37e3 Message-ID: <3bbf2fe11001190241n107992ffj6b987944a52281bd@mail.gmail.com> From: Attilio Rao To: Pete French Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: base64 Cc: freebsd-stable@freebsd.org Subject: Re: [PATCH] Lockmgr deadlock on STABLE_8 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 19 Jan 2010 10:41:57 -0000 MjAxMC8xLzE5IFBldGUgRnJlbmNoIDxwZXRlZnJlbmNoQHRpY2tldHN3aXRjaC5jb20+Ogo+PiBN YXkgeW91IHBvc3QgeW91ciBrZXJuZWwgY29uZmlnPwo+Cj4gc3VyZS4uLgo+Cj4gwqAgwqAgwqAg wqBpbmNsdWRlIMKgIMKgIMKgIMKgIEdFTkVSSUMKPiDCoCDCoCDCoCDCoGlkZW50IMKgIMKgIMKg IMKgIMKgIERFQlVHCj4gwqAgwqAgwqAgwqBvcHRpb25zIMKgIMKgIMKgIMKgIEtEQgo+IMKgIMKg IMKgIMKgb3B0aW9ucyDCoCDCoCDCoCDCoCBEREIKPiDCoCDCoCDCoCDCoG9wdGlvbnMgwqAgwqAg wqAgwqAgV0lUTkVTUwo+IMKgIMKgIMKgIMKgb3B0aW9ucyDCoCDCoCDCoCDCoCBJTlZBUklBTlRf U1VQUE9SVAo+IMKgIMKgIMKgIMKgb3B0aW9ucyDCoCDCoCDCoCDCoCBJTlZBUklBTlRTCgpPayB0 aGVuLCByZW1vdmUgdGhlIGRlYnVnZ2luZyAoV0lUTkVTUywgSU5WQVJJQU5UKiksIGxlYXZlIGlu IHBsYWNlCktEQiBhbmQgRERCLCBhZGQgR0RCIGFuZCB0cnkgYXQgbGVhc3QgdG8gZ2V0IGEgY29y ZWR1bXAgd2hlbiBpdApkZWFkbG9ja3MuCgpBdHRpbGlvCgoKLS0gClBlYWNlIGNhbiBvbmx5IGJl IGFjaGlldmVkIGJ5IHVuZGVyc3RhbmRpbmcgLSBBLiBFaW5zdGVpbgo= From owner-freebsd-stable@FreeBSD.ORG Tue Jan 19 10:47: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 4FB901065672; Tue, 19 Jan 2010 10:47: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 182E38FC18; Tue, 19 Jan 2010 10:47: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 1NXBcO-000GW2-Eb; Tue, 19 Jan 2010 10:47:28 +0000 Received: from petefrench by dilbert.ticketswitch.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NXBcO-000ER4-DY; Tue, 19 Jan 2010 10:47:28 +0000 Date: Tue, 19 Jan 2010 10:47:28 +0000 Message-Id: To: attilio@freebsd.org In-Reply-To: <3bbf2fe11001190241n107992ffj6b987944a52281bd@mail.gmail.com> From: Pete French Cc: freebsd-stable@freebsd.org Subject: Re: [PATCH] Lockmgr deadlock on STABLE_8 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 19 Jan 2010 10:47:35 -0000 > Ok then, remove the debugging (WITNESS, INVARIANT*), leave in place > KDB and DDB, add GDB and try at least to get a coredump when it > deadlocks. OK, will do. Am building a KDB/GDB/DDB kenel now. -pete. From owner-freebsd-stable@FreeBSD.ORG Tue Jan 19 10:57:58 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 6CD0F106566B for ; Tue, 19 Jan 2010 10:57:58 +0000 (UTC) (envelope-from freebsd-questions@pp.dyndns.biz) Received: from proxy2.bredband.net (proxy2.bredband.net [195.54.101.72]) by mx1.freebsd.org (Postfix) with ESMTP id 212CB8FC1F for ; Tue, 19 Jan 2010 10:57:57 +0000 (UTC) Received: from ipb2.telenor.se (195.54.127.165) by proxy2.bredband.net (7.3.140.3) id 4AD3E1BC027A2899 for freebsd-stable@freebsd.org; Tue, 19 Jan 2010 11:57:56 +0100 X-SMTPAUTH-B2: X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ar86AH4fVUtV4js3PGdsb2JhbACBRoZwkzwBAQEBN7l8hDMEgx8 X-IronPort-AV: E=Sophos;i="4.49,302,1262559600"; d="scan'208";a="27646817" Received: from c-373be255.107-1-64736c10.cust.bredbandsbolaget.se (HELO gatekeeper.pp.dyndns.biz) ([85.226.59.55]) by ipb2.telenor.se with ESMTP; 19 Jan 2010 11:57:50 +0100 Received: from [192.168.69.67] (phobos [192.168.69.67]) by gatekeeper.pp.dyndns.biz (8.14.3/8.14.3) with ESMTP id o0JAvmww037933; Tue, 19 Jan 2010 11:57:48 +0100 (CET) (envelope-from freebsd-questions@pp.dyndns.biz) Message-ID: <4B55902C.1090901@pp.dyndns.biz> Date: Tue, 19 Jan 2010 11:57:48 +0100 From: =?ISO-8859-1?Q?Morgan_Wesstr=F6m?= User-Agent: Thunderbird 2.0.0.23 (X11/20091010) MIME-Version: 1.0 To: Jeremy Chadwick References: <4B54C100.9080906@mail.zedat.fu-berlin.de> <4B54C5EE.5070305@pp.dyndns.biz> <201001191250.23625.doconnor@gsoft.com.au> <7346c5c61001181841j3653a7c3m32bc033c8c146a92@mail.gmail.com> <4B557B5A.8040902@pp.dyndns.biz> <20100119095736.GA71824@icarus.home.lan> In-Reply-To: <20100119095736.GA71824@icarus.home.lan> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org Subject: Re: immense delayed write to file system (ZFS and UFS2), performance issues X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 19 Jan 2010 10:57:58 -0000 Jeremy Chadwick wrote: > No offence intended by this statement, but: the Green drives are > specifically intended for workstations. I don't believe in the whole > "segregation of drive model" thing, but the fact of the matter is, the > Green drives are variable-RPM and have numerous firmware-level features > which intend for them to be used in workstation environments -- that > means not constant I/O or heavy workload. Windows has nothing to do > with this. No offence taken. You are one of the few highly regarded contributors to this list and I always appreciate the information you share. My comment about Windows was based on the fact that Windows-users don't experience this behaviour. The 8 second Intelli-Park timeout is most probably tuned to the Windows kernel flush period but I can't say for sure. But obviously the load/unload cycle isn't triggered nearly as often on that OS. I just feel frustrated that once again a manufacturer simply ignore the users who chose to run something else on their computers than the products from Redmond. In my case I have several decades worth of experience and knowledge and I have no problem grasping the various technical features and their usefullness. The problem is that I as a consumer have no way of knowing that a feature like this would be incompatible in my environment despite my experience. In my search to track this problem down I sidetracked several times in both filesystem and kernel internals until I finally stumbled over the Intelli-Park feature. It hadn't even crossed my mind that the problem could be related to a hardware feature and that bothers me immensely... but I'll deal with it eventually ;) > Aren't Samsung's drives known for firmware bugs/quirks? The > documentation associated with smartmontools discusses this quite a bit. > This is one reason why I stay away from them. Fujitsu is another vendor > I want absolutely nothing to do with (very high failure rates in > addition to bad sectors with their SCSI-3 disks at my workplace). I think both you and I know by now that every harddrive manufacturer have their problems with certain models at some point. What surprises me is the total lack of understanding from the manufacturers, most recently the firmware issue of Seagates 7200.11 series where they simply try to ignore the problem. The only professional response I've seen during my career is IBM's replacement of their "Deathstar" drives many years ago. I accept and understand that a manufacturer now and then makes a bad product but it's how they deal with the situation when it occurs, that decides whether I will ever buy their products again. With Samsung I've completed the full circle and if I run into a problem with them and they don't take their responsibility, well, then I'm not sure what to buy next time. Maybe I should go for Maxtor again... ;-) Regards Morgan From owner-freebsd-stable@FreeBSD.ORG Tue Jan 19 11:24: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 E30661065692 for ; Tue, 19 Jan 2010 11:24:50 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta10.emeryville.ca.mail.comcast.net (qmta10.emeryville.ca.mail.comcast.net [76.96.30.17]) by mx1.freebsd.org (Postfix) with ESMTP id C59A98FC16 for ; Tue, 19 Jan 2010 11:24:50 +0000 (UTC) Received: from omta17.emeryville.ca.mail.comcast.net ([76.96.30.73]) by qmta10.emeryville.ca.mail.comcast.net with comcast id XPQW1d0031afHeLAAPQrjH; Tue, 19 Jan 2010 11:24:51 +0000 Received: from koitsu.dyndns.org ([98.248.46.159]) by omta17.emeryville.ca.mail.comcast.net with comcast id XPQq1d0033S48mS8dPQqoo; Tue, 19 Jan 2010 11:24:50 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 330801E3033; Tue, 19 Jan 2010 03:24:49 -0800 (PST) Date: Tue, 19 Jan 2010 03:24:49 -0800 From: Jeremy Chadwick To: freebsd-stable@freebsd.org Message-ID: <20100119112449.GA73052@icarus.home.lan> References: <4B54C100.9080906@mail.zedat.fu-berlin.de> <4B54C5EE.5070305@pp.dyndns.biz> <201001191250.23625.doconnor@gsoft.com.au> <7346c5c61001181841j3653a7c3m32bc033c8c146a92@mail.gmail.com> <4B557B5A.8040902@pp.dyndns.biz> <20100119095736.GA71824@icarus.home.lan> <20100119110724.ec01a3ed.gerrit@pmp.uni-hannover.de> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20100119110724.ec01a3ed.gerrit@pmp.uni-hannover.de> User-Agent: Mutt/1.5.20 (2009-06-14) Subject: Re: immense delayed write to file system (ZFS and UFS2), performance issues X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 19 Jan 2010 11:24:51 -0000 On Tue, Jan 19, 2010 at 11:07:24AM +0100, Gerrit Khn wrote: > On Tue, 19 Jan 2010 01:57:36 -0800 Jeremy Chadwick > wrote about Re: immense delayed write to file > system (ZFS and UFS2), performance issues: > > JC> If you want a consumer-edition drive that's better tuned for server > JC> work, you should really be looking at the WD Caviar Black series or > JC> their RE/RE2 series. > > That's exactly what I did. I have WD-RE2 drives here that show exactly > this problem (RE2/GP)! The model number is WD1000FYPS-01ZKB0. I should have been more specific. WD makes RE-series drives which don't have GP applied to them; those are what I was referring to. Here's the current list of Western Digital SATA models out there, sans some earlier revisions. All below drives are 3.5", SATA300, and have their SATA power/signal ports placed to permit hot-swapping in drive carriers unless otherwise noted. Enterprise high-performance class =================================== WD3000GLFS - WD VelociRatpor, 300GB, 16MB, 10Krpm, no-hotswap WD1500HLFS - WD VelociRaptor, 150GB, 16MB, 10Krpm WD3000HLFS - WD VelociRaptor, 300GB, 16MB, 10Krpm WD1500BLFS - WD VelociRaptor, 150GB, 16MB, 10Krpm, 2.5" bare WD3000BLFS - WD VelociRaptor, 300GB, 16MB, 10Krpm, 2.5" bare Enterprise business-critical class ==================================== WD2502ABYS - WD RE3, 250GB, 16MB, 7200rpm WD3202ABYS - WD RE3, 320GB, 16MB, 7200rpm WD5002ABYS - WD RE3, 500GB, 16MB, 7200rpm WD1002FBYS - WD RE3, 1TB, 32MB, 7200rpm WD7502ABYS - WD RE3, 750GB, 32MB, 7200rpm WD2003FYYS - WD RE4, 2TB, 64MB, 7200rpm Enterprise energy-saving class ================================ WD5000ABPS - WD RE2-GP, 500GB, 16MB, variable rpm WD7500AYPS - WD RE2-GP, 750GB, 16MB, variable rpm WD1000FYPS - WD RE2-GP, 1TB, 16MB, variable rpm WD2002FYPS - WD RE4-GP, 2TB, 64MB, variable rpm Desktop class =============== WD800AAJS - WD Caviar Blue, 80GB, 8MB, 7200rpm WD1600AAJS - WD Caviar Blue, 160GB, 8MB, 7200rpm WD2500AAJS - WD Caviar Blue, 250GB, 8MB, 7200rpm WD3200AAJS - WD Caviar Blue, 320GB, 8MB, 7200rpm WD2500AAKS - WD Caviar Blue, 250GB, 16MB, 7200rpm WD3200AAKS - WD Caviar Blue, 320GB, 16MB, 7200rpm WD5000AAKS - WD Caviar Blue, 500GB, 16MB, 7200rpm WD6400AAKS - WD Caviar Blue, 640GB, 16MB, 7200rpm WD5000AACS - WD Caviar Green, 500GB, 16MB, variable rpm WD6400AACS - WD Caviar Green, 640GB, 16MB, variable rpm WD7500AACS - WD Caviar Green, 750GB, 16MB, variable rpm WD10EACS - WD Caviar Green, 1TB, 16MB, variable rpm WD5000AADS - WD Caviar Green, 500GB, 32MB, variable rpm WD6400AADS - WD Caviar Green, 640GB, 32MB, variable rpm WD7500AADS - WD Caviar Green, 750GB, 32MB, variable rpm WD10EADS - WD Caviar Green, 1TB, 32MB, variable rpm WD15EADS - WD Caviar Green, 1.5TB, 32MB, variable rpm WD20EADS - WD Caviar Green, 2TB, 32MB, variable rpm WD6400AARS - WD Caviar Green, 640GB, 64MB, variable rpm WD8000AARS - WD Caviar Green, 800GB, 64MB, variable rpm WD10EARS - WD Caviar Green, 1TB, 64MB, variable rpm WD15EARS - WD Caviar Green, 1.5TB, 64MB, variable rpm WD20EARS - WD Caviar Green, 2TB, 64MB, variable rpm WD5001AALS - WD Caviar Black, 500GB, 32MB, 7200rpm WD6401AALS - WD Caviar Black, 640GB, 32MB, 7200rpm WD7501AALS - WD Caviar Black, 750GB, 32MB, 7200rpm WD1001FALS - WD Caviar Black, 1TB, 32MB, 7200rpm WD2001FAAS - WD Caviar Black, 2TB, 64MB, 7200rpm So which drive models above are experiencing a continual increase in SMART attribute 193 (Load Cycle Count)? My guess is that some of the WD Caviar Green models, and possibly all of the RE2-GP and RE4-GP models are experiencing this problem. I say "some" with regards to WD Caviar Green since I have some which do not appear to exhibit the heads/actuator arm moved into the landing/park zone. I'm at work right now, but when I get home I can verify what models I've used which didn't experience this problem, as well as what the manufacturing date and F/W revisions are. I should note I don't have said Green drives in use (I use WD1001FALS drives now). -- | 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 Jan 19 12:48:31 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 E8FE0106566B for ; Tue, 19 Jan 2010 12:48:30 +0000 (UTC) (envelope-from gerrit@pmp.uni-hannover.de) Received: from mrelay1.uni-hannover.de (mrelay1.uni-hannover.de [130.75.2.106]) by mx1.freebsd.org (Postfix) with ESMTP id 71BB18FC14 for ; Tue, 19 Jan 2010 12:48:30 +0000 (UTC) Received: from www.pmp.uni-hannover.de (www.pmp.uni-hannover.de [130.75.117.2]) by mrelay1.uni-hannover.de (8.14.2/8.14.2) with ESMTP id o0JCmRob016204; Tue, 19 Jan 2010 13:48:28 +0100 Received: from pmp.uni-hannover.de (arc.pmp.uni-hannover.de [130.75.117.1]) by www.pmp.uni-hannover.de (Postfix) with SMTP id 8D47C24; Tue, 19 Jan 2010 13:48:27 +0100 (CET) Date: Tue, 19 Jan 2010 13:48:27 +0100 From: Gerrit =?ISO-8859-1?Q?K=FChn?= To: Jeremy Chadwick Message-Id: <20100119134827.250abc50.gerrit@pmp.uni-hannover.de> In-Reply-To: <20100119112449.GA73052@icarus.home.lan> References: <4B54C100.9080906@mail.zedat.fu-berlin.de> <4B54C5EE.5070305@pp.dyndns.biz> <201001191250.23625.doconnor@gsoft.com.au> <7346c5c61001181841j3653a7c3m32bc033c8c146a92@mail.gmail.com> <4B557B5A.8040902@pp.dyndns.biz> <20100119095736.GA71824@icarus.home.lan> <20100119110724.ec01a3ed.gerrit@pmp.uni-hannover.de> <20100119112449.GA73052@icarus.home.lan> Organization: Albert-Einstein-Institut (MPI =?ISO-8859-1?Q?f=FCr?= Gravitationsphysik & IGP =?ISO-8859-1?Q?Universit=E4t?= Hannover) X-Mailer: Sylpheed 2.7.1 (GTK+ 2.18.4; i386-portbld-freebsd7.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-PMX-Version: 5.5.9.388399, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2010.1.19.123620 Cc: freebsd-stable@freebsd.org Subject: Re: immense delayed write to file system (ZFS and UFS2), performance issues X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 19 Jan 2010 12:48:31 -0000 On Tue, 19 Jan 2010 03:24:49 -0800 Jeremy Chadwick wrote about Re: immense delayed write to file system (ZFS and UFS2), performance issues: JC> > JC> If you want a consumer-edition drive that's better tuned for JC> > JC> server work, you should really be looking at the WD Caviar Black JC> > JC> series or their RE/RE2 series. JC> > That's exactly what I did. I have WD-RE2 drives here that show JC> > exactly this problem (RE2/GP)! The model number is WD1000FYPS-01ZKB0. JC> I should have been more specific. WD makes RE-series drives which JC> don't have GP applied to them; those are what I was referring to. Well, when I bought these drives I was not aware of this issue. Buying a drive intended for 24/7 use in RAID configurations is basically the right idea, I think. From what was written about the GP feature back then I could not anticipate such problems. I would have liked to buy the 2TB drives without GP lately, but they have lead times into April here. So I went for the GP model, which now shows the same problem as the 1TB drive... :-( JC> WD1000FYPS - WD RE2-GP, 1TB, 16MB, variable rpm JC> WD2002FYPS - WD RE4-GP, 2TB, 64MB, variable rpm JC> So which drive models above are experiencing a continual increase in JC> SMART attribute 193 (Load Cycle Count)? My guess is that some of the JC> WD Caviar Green models, and possibly all of the RE2-GP and RE4-GP JC> models are experiencing this problem. I can confirm that the two models above show this problem. Furthermore I can confirm that at least in my setup here this drive type works fine: WD5001ABYS I have some of the RE3 drives sitting around here and will probably try them later. Can anyone here report anything about the fixed firmware from ? Does this remedy the problem for the 1TB RE2 drive? JC> I say "some" with regards to WD Caviar Green since I have some which do JC> not appear to exhibit the heads/actuator arm moved into the JC> landing/park zone. I'm at work right now, but when I get home I can JC> verify what models I've used which didn't experience this problem, as JC> well as what the manufacturing date and F/W revisions are. I should JC> note I don't have said Green drives in use (I use WD1001FALS drives JC> now). Thanks for sharing this information. cu Gerrit From owner-freebsd-stable@FreeBSD.ORG Tue Jan 19 14:20: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 E0253106566C for ; Tue, 19 Jan 2010 14:20:55 +0000 (UTC) (envelope-from emikulic@gmail.com) Received: from ipmail03.adl6.internode.on.net (ipmail03.adl6.internode.on.net [203.16.214.141]) by mx1.freebsd.org (Postfix) with ESMTP id 66B268FC0A for ; Tue, 19 Jan 2010 14:20:54 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApsEAMtLVUuWZZrw/2dsb2JhbACRZLdqhk6HAIQzBA Received: from ppp154-240.static.internode.on.net ([150.101.154.240]) by ipmail03.adl6.internode.on.net with ESMTP; 20 Jan 2010 00:50:53 +1030 Received: by ppp154-240.static.internode.on.net (Poo-fix, from userid 1001) id 8935B5C45; Wed, 20 Jan 2010 01:20:52 +1100 (EST) Date: Wed, 20 Jan 2010 01:20:52 +1100 From: Emil Mikulic To: freebsd-stable@freebsd.org Message-ID: <20100119142052.GA77230@dmr.ath.cx> References: <4B54C100.9080906@mail.zedat.fu-berlin.de> <4B54C5EE.5070305@pp.dyndns.biz> <201001191250.23625.doconnor@gsoft.com.au> <7346c5c61001181841j3653a7c3m32bc033c8c146a92@mail.gmail.com> <20100119091641.cc59f03f.gerrit@pmp.uni-hannover.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100119091641.cc59f03f.gerrit@pmp.uni-hannover.de> User-Agent: Mutt/1.5.20 (2009-06-14) Subject: Re: immense delayed write to file system (ZFS and UFS2), performance issues X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 19 Jan 2010 14:20:56 -0000 On Tue, Jan 19, 2010 at 09:16:41AM +0100, Gerrit K?hn wrote: > Thanks for bringing up this topic here. I have drives showing up close to > 800000 load cycle counts here. Guess it's time for that fix... :-| Device Model: WDC WD10EACS-00ZJB0 Firmware Version: 01.01B01 Serial Number: WD-WCASxxxxxxxx [...] 9 Power_On_Hours 17046 193 Load_Cycle_Count 1045512 The above drive is in a raidz of three. The other two drives from that batch have already failed. :( In another system: Device Model: WDC WD10EACS-00D6B0 Firmware Version: 01.01A01 Serial Number: WD-WCAUxxxxxxxx [...] 9 Power_On_Hours 13111 193 Load_Cycle_Count 7 From owner-freebsd-stable@FreeBSD.ORG Tue Jan 19 15:32: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 442D2106566C for ; Tue, 19 Jan 2010 15:32:38 +0000 (UTC) (envelope-from freebsd-questions@pp.dyndns.biz) Received: from proxy1.bredband.net (proxy1.bredband.net [195.54.101.71]) by mx1.freebsd.org (Postfix) with ESMTP id EBD2F8FC12 for ; Tue, 19 Jan 2010 15:32:37 +0000 (UTC) Received: from ipb2.telenor.se (195.54.127.165) by proxy1.bredband.net (7.3.140.3) id 4AD3E1C00278CF58 for freebsd-stable@freebsd.org; Tue, 19 Jan 2010 16:32:36 +0100 X-SMTPAUTH-B2: X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AtBCAMdeVUtV4js3PGdsb2JhbACBRoZwkz8BAQEBN7tDhDME X-IronPort-AV: E=Sophos;i="4.49,303,1262559600"; d="scan'208";a="27718978" Received: from c-373be255.107-1-64736c10.cust.bredbandsbolaget.se (HELO gatekeeper.pp.dyndns.biz) ([85.226.59.55]) by ipb2.telenor.se with ESMTP; 19 Jan 2010 16:32:36 +0100 Received: from [192.168.69.67] (phobos [192.168.69.67]) by gatekeeper.pp.dyndns.biz (8.14.3/8.14.3) with ESMTP id o0JFWY77043322; Tue, 19 Jan 2010 16:32:35 +0100 (CET) (envelope-from freebsd-questions@pp.dyndns.biz) Message-ID: <4B55D092.30509@pp.dyndns.biz> Date: Tue, 19 Jan 2010 16:32:34 +0100 From: =?ISO-8859-1?Q?Morgan_Wesstr=F6m?= User-Agent: Thunderbird 2.0.0.23 (X11/20091010) MIME-Version: 1.0 To: Emil Mikulic References: <4B54C100.9080906@mail.zedat.fu-berlin.de> <4B54C5EE.5070305@pp.dyndns.biz> <201001191250.23625.doconnor@gsoft.com.au> <7346c5c61001181841j3653a7c3m32bc033c8c146a92@mail.gmail.com> <20100119091641.cc59f03f.gerrit@pmp.uni-hannover.de> <20100119142052.GA77230@dmr.ath.cx> In-Reply-To: <20100119142052.GA77230@dmr.ath.cx> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org Subject: Re: immense delayed write to file system (ZFS and UFS2), performance issues X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 19 Jan 2010 15:32:38 -0000 Emil Mikulic wrote: > On Tue, Jan 19, 2010 at 09:16:41AM +0100, Gerrit K?hn wrote: >> Thanks for bringing up this topic here. I have drives showing up close to >> 800000 load cycle counts here. Guess it's time for that fix... :-| > > Device Model: WDC WD10EACS-00ZJB0 > Firmware Version: 01.01B01 > Serial Number: WD-WCASxxxxxxxx > [...] > 9 Power_On_Hours 17046 > 193 Load_Cycle_Count 1045512 > > The above drive is in a raidz of three. > The other two drives from that batch have already failed. :( Did you RMA the failing drives? Did WD comment the Load_Cycle_Count? /Morgan From owner-freebsd-stable@FreeBSD.ORG Tue Jan 19 15:45: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 90A4D1065670 for ; Tue, 19 Jan 2010 15:45:00 +0000 (UTC) (envelope-from gpalmer@freebsd.org) Received: from noop.in-addr.com (mail.in-addr.com [IPv6:2001:470:8:162::1]) by mx1.freebsd.org (Postfix) with ESMTP id 6449E8FC18 for ; Tue, 19 Jan 2010 15:45:00 +0000 (UTC) Received: from gjp by noop.in-addr.com with local (Exim 4.54 (FreeBSD)) id 1NXGGJ-0000s8-6X; Tue, 19 Jan 2010 10:44:59 -0500 Date: Tue, 19 Jan 2010 10:44:59 -0500 From: Gary Palmer To: Jeremy Chadwick Message-ID: <20100119154459.GB52605@in-addr.com> References: <4B54C100.9080906@mail.zedat.fu-berlin.de> <4B54C5EE.5070305@pp.dyndns.biz> <201001191250.23625.doconnor@gsoft.com.au> <7346c5c61001181841j3653a7c3m32bc033c8c146a92@mail.gmail.com> <4B557B5A.8040902@pp.dyndns.biz> <20100119095736.GA71824@icarus.home.lan> <20100119110724.ec01a3ed.gerrit@pmp.uni-hannover.de> <20100119112449.GA73052@icarus.home.lan> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100119112449.GA73052@icarus.home.lan> Cc: freebsd-stable@freebsd.org Subject: Re: immense delayed write to file system (ZFS and UFS2), performance issues X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 19 Jan 2010 15:45:00 -0000 On Tue, Jan 19, 2010 at 03:24:49AM -0800, Jeremy Chadwick wrote: > WD2001FAAS - WD Caviar Black, 2TB, 64MB, 7200rpm Do you mean WD2001FASS? I can't find a WD2001FAAS. Thanks, Gary From owner-freebsd-stable@FreeBSD.ORG Tue Jan 19 15:49: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 4398C1065692 for ; Tue, 19 Jan 2010 15:49:39 +0000 (UTC) (envelope-from wsk@gddsn.org.cn) Received: from gddsn.org.cn (gddsn.org.cn [218.19.164.145]) by mx1.freebsd.org (Postfix) with ESMTP id BEFCF8FC08 for ; Tue, 19 Jan 2010 15:49:38 +0000 (UTC) Received: from lp.gddsn.org.cn (unknown [10.44.8.159]) (Authenticated sender: wsk) by gddsn.org.cn (Postfix) with ESMTPA id 4F5432E08A; Tue, 19 Jan 2010 12:39:12 +0800 (CST) Message-ID: <4B5546B0.1050102@gddsn.org.cn> Date: Tue, 19 Jan 2010 13:44:16 +0800 From: wsk User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; zh-CN; rv:1.9.1.5) Gecko/20100116 Thunderbird/3.0 MIME-Version: 1.0 To: stable@freebsd.org, net@freebsd.org Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: 8.0 stable if_bwi kmod not exist? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 19 Jan 2010 15:49:39 -0000 folks, There is not exist if_bwi.ko module in /boot/kernel under 8.0 Stable why? From owner-freebsd-stable@FreeBSD.ORG Tue Jan 19 15:57: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 DA7E510657D6 for ; Tue, 19 Jan 2010 15:57:14 +0000 (UTC) (envelope-from Johan@double-l.nl) Received: from smtp-vbr5.xs4all.nl (smtp-vbr5.xs4all.nl [194.109.24.25]) by mx1.freebsd.org (Postfix) with ESMTP id 5AAE38FC0C for ; Tue, 19 Jan 2010 15:57:13 +0000 (UTC) Received: from w2003s01.double-l.local (double-l.xs4all.nl [80.126.205.144]) by smtp-vbr5.xs4all.nl (8.13.8/8.13.8) with ESMTP id o0JFvCox004628 for ; Tue, 19 Jan 2010 16:57:12 +0100 (CET) (envelope-from Johan@double-l.nl) Content-class: urn:content-classes:message MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Tue, 19 Jan 2010 16:57:10 +0100 Message-ID: <57200BF94E69E54880C9BB1AF714BBCBA574DF@w2003s01.double-l.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: scp from livecd (fixit option) cd can not find /usr/bin/ssh Thread-Index: AcqZIA9fO7K3LgFnQH+1jVDgmQ7x2w== From: "Johan Hendriks" To: X-Virus-Scanned: by XS4ALL Virus Scanner Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: scp from livecd (fixit option) cd can not find /usr/bin/ssh X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 19 Jan 2010 15:57:14 -0000 Hello i use the livecd to save an old pc. But when i try to use scp to copy some data to our network i get the message that /usr/bin/ssh could not be found. =20 This is on 8.0 i386 livecd =20 Regards, Johan Hendriks =20 From owner-freebsd-stable@FreeBSD.ORG Tue Jan 19 16:10:13 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 17AF61065670 for ; Tue, 19 Jan 2010 16:10:13 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta12.westchester.pa.mail.comcast.net (qmta12.westchester.pa.mail.comcast.net [76.96.59.227]) by mx1.freebsd.org (Postfix) with ESMTP id B1DE38FC14 for ; Tue, 19 Jan 2010 16:10:12 +0000 (UTC) Received: from omta19.westchester.pa.mail.comcast.net ([76.96.62.98]) by qmta12.westchester.pa.mail.comcast.net with comcast id XTs31d00a27AodY5CUACxQ; Tue, 19 Jan 2010 16:10:12 +0000 Received: from koitsu.dyndns.org ([98.248.46.159]) by omta19.westchester.pa.mail.comcast.net with comcast id XUAS1d00Q3S48mS3fUAUVX; Tue, 19 Jan 2010 16:10:28 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 545321E3035; Tue, 19 Jan 2010 08:10:09 -0800 (PST) Date: Tue, 19 Jan 2010 08:10:09 -0800 From: Jeremy Chadwick To: freebsd-stable@freebsd.org Message-ID: <20100119161009.GA80133@icarus.home.lan> References: <4B54C100.9080906@mail.zedat.fu-berlin.de> <4B54C5EE.5070305@pp.dyndns.biz> <201001191250.23625.doconnor@gsoft.com.au> <7346c5c61001181841j3653a7c3m32bc033c8c146a92@mail.gmail.com> <4B557B5A.8040902@pp.dyndns.biz> <20100119095736.GA71824@icarus.home.lan> <20100119110724.ec01a3ed.gerrit@pmp.uni-hannover.de> <20100119112449.GA73052@icarus.home.lan> <20100119154459.GB52605@in-addr.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100119154459.GB52605@in-addr.com> User-Agent: Mutt/1.5.20 (2009-06-14) Subject: Re: immense delayed write to file system (ZFS and UFS2), performance issues X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 19 Jan 2010 16:10:13 -0000 On Tue, Jan 19, 2010 at 10:44:59AM -0500, Gary Palmer wrote: > On Tue, Jan 19, 2010 at 03:24:49AM -0800, Jeremy Chadwick wrote: > > WD2001FAAS - WD Caviar Black, 2TB, 64MB, 7200rpm > > Do you mean WD2001FASS? I can't find a WD2001FAAS. Yup, typo -- bound to be at least one given the amount of data I typed in. :-) Good catch! -- | 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 Jan 19 16:12: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 950D61065692; Tue, 19 Jan 2010 16:12:59 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-fx0-f218.google.com (mail-fx0-f218.google.com [209.85.220.218]) by mx1.freebsd.org (Postfix) with ESMTP id CE3848FC19; Tue, 19 Jan 2010 16:12:58 +0000 (UTC) Received: by fxm10 with SMTP id 10so877465fxm.14 for ; Tue, 19 Jan 2010 08:12:57 -0800 (PST) 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 :user-agent:mime-version:to:subject:x-enigmail-version:content-type :content-transfer-encoding; bh=/XHocK1ofq9DAD5JeBrI99DGHRuJIV+P/uZBNZX+i2o=; b=P1jeLhwD/fUM8znN/9CMDzIMZz4TGQYR8C/4nncSZWrQsQ4cF85/DZtJ/czMlqBPgo 5bYXtci7QBsigk0B0yDCNijR3thZrLNelyQIsokpJqoSuKetvxI6QyKS065XLOpB9m5G 83KlEtEtyqu8EDRDSevszdbciNimJptN0kRIc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:subject :x-enigmail-version:content-type:content-transfer-encoding; b=JGBL5rHYs/SEzwZtSCOBonerveCTjFGm2SJMWqcuZT4m9iUPrM/PojnYyLGYzvIlpG C2cR7mfRMImk23z/IuouUEmLZFEN7oY+gELU8UoumndXxh6Wk3CfPs9bo1cg5IpH197z wPoHf+9gNiCSL3GfOOl/rl4Vt6zdwZEQ7cDt4= Received: by 10.223.76.77 with SMTP id b13mr4657539fak.74.1263917577637; Tue, 19 Jan 2010 08:12:57 -0800 (PST) Received: from mavbook.mavhome.dp.ua (pc.mavhome.dp.ua [212.86.226.226]) by mx.google.com with ESMTPS id 16sm2598706fxm.4.2010.01.19.08.12.56 (version=SSLv3 cipher=RC4-MD5); Tue, 19 Jan 2010 08:12:56 -0800 (PST) Sender: Alexander Motin Message-ID: <4B55D9D4.1000008@FreeBSD.org> Date: Tue, 19 Jan 2010 18:12:04 +0200 From: Alexander Motin User-Agent: Thunderbird 2.0.0.23 (X11/20091212) MIME-Version: 1.0 To: FreeBSD-Current , FreeBSD Stable X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: 7bit Cc: Subject: Pack of CAM improvements X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 19 Jan 2010 16:12:59 -0000 Hi. I've made a patch, that should solve set of problems of CAM ATA and CAM generally. I would like to ask for testing and feedback. What patch does: - It unifies bus reset/probe sequence. Whenever bus attached at boot or later, CAM will automatically reset and scan it. It allows to remove duplicate code from many drivers. - Any bus, attached before CAM completed it's boot-time initialization, will equally join to the process, delaying boot if needed. - New kern.cam.boot_delay loader tunable should help controllers that are still unable to register their buses in time (such as slow USB/ PCCard/ CardBus devices). - To allow synchronization between different CAM levels, concept of requests priorities was extended. Priorities now split between several "run levels". Device can be freezed at specified level, allowing higher priority requests to pass. For example, no payload requests allowed, until PMP driver enable port. ATA XPT negotiate transfer parameters, periph driver configure caching and so on. - Frozen requests are no more counted by request allocation scheduler. It fixes deadlocks, when frozen low priority payload requests occupying slots, required by higher levels to manage theit execution. - Two last changes were holding proper ATA reinitialization and error recovery implementation. Now it is done: SATA controllers and Port Multipliers now implement automatic hot-plug and should correctly recover from timeouts and bus resets. Patch can be found here: http://people.freebsd.org/~mav/cam-ata.20100119.patch Feedback as always welcome. -- Alexander Motin From owner-freebsd-stable@FreeBSD.ORG Tue Jan 19 16:40: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 9E08A106566B for ; Tue, 19 Jan 2010 16:40:52 +0000 (UTC) (envelope-from garrettmoore@gmail.com) Received: from mail-iw0-f177.google.com (mail-iw0-f177.google.com [209.85.223.177]) by mx1.freebsd.org (Postfix) with ESMTP id 632908FC0C for ; Tue, 19 Jan 2010 16:40:52 +0000 (UTC) Received: by iwn7 with SMTP id 7so2955824iwn.7 for ; Tue, 19 Jan 2010 08:40:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type; bh=sn2VuBXJmks5LEFL/IIiNzCvstRoVyHtdHIw1BszUeQ=; b=Klp4RJlekB33hnRjcRmHJpH1dYW/QJ5mO0p0pPzFQOCbYFkAtulXjKRqkK9fm1Ao8+ /SEzOVUPSt0/IemckD9LmoGt09bHKFlIwZFfbF+NS1KMvr09ykvlxhAOn330uDGUm9OU KS1pop1eD4tonsVQU2i4Mc5HQc07oYnrA3ZLQ= 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=eKao5MGnc7bFSmU0uW8UgO3dsivQVBlyTXndw1VysTXTLuWtbNqHrrxinq55+Z7Tp/ cQjlXWkz0q+uESeuJ1xI9zwkNnxUIsxKfDj5errMUJHL90YliRF81OemgK0EJyC9uQFD wHfegyZUrygpzGoN8wkjHPH9pXJtYP9B4+2sM= MIME-Version: 1.0 Received: by 10.231.157.83 with SMTP id a19mr898058ibx.41.1263919251012; Tue, 19 Jan 2010 08:40:51 -0800 (PST) In-Reply-To: <201001180829.48126.npapke@acm.org> References: <7346c5c61001030842r7dc76199y51e4c1c90a3eea6e@mail.gmail.com> <7346c5c61001091706m45a3a2a5k3ca8bb0c4bec5ea8@mail.gmail.com> <7346c5c61001171521w1ca4738w98e8fcca24643cda@mail.gmail.com> <201001180829.48126.npapke@acm.org> Date: Tue, 19 Jan 2010 11:40:50 -0500 Message-ID: <7346c5c61001190840k31466754i32b2ae833390b79b@mail.gmail.com> From: Garrett Moore To: freebsd-stable@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Re: ZFS performance degradation over time X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 19 Jan 2010 16:40:52 -0000 I've been watching my memory usage and I have no idea what is consuming memory as 'Active'. Last night I had around 6500MB 'Active' again, 1500MB Wired, no inact, ~30MB buf, no free, and ~100MB swap used. My performance copying ZFS->ZFS was again slow (<1MB/s). I tried killing rTorrent and no significant amount of memory was reclaimed - maybe 100MB. `ps aux` showed no processes using any significant amount of memory, and I was definitely nowhere near 6500MB usage. I tried running the perl oneliner again to hog a bunch of memory, and almost all of the Active memory was IMMEDIATELY marked as Free, and my performance was excellent again. I'm not sure what in userland could be causing the issue. The only things I've installed are rTorrent, lighttpd, samba, smartmontools, vim, bash, Python, Perl, and SABNZBd. There is nothing that *should* be consuming any serious amount of memory. On Mon, Jan 18, 2010 at 11:29 AM, Norbert Papke wrote: > On January 17, 2010, Garrett Moore wrote: > > I upgraded my system to 8GB of ram to see if that would help. It hasn't > > made much of a difference. After having rTorrent running for a while, my > > performance again tanked. Around 6.5GB of memory was showing as 'Active' > > according to top. > > 6.5GB of "active" memory seems to imply that a user process is growing or a > large number of user processes are being created. I would expect ZFS's > cache > to increase the size of "wired" memory. > > Sorry, I have not followed this thread closely. Are you sure that the > degradation is ZFS related? Could it be caused by, for instance, a > userland > memory leak? What happens to active memory when you restart rtorrent? > > Cheers, > > -- Norbert Papke. > npapke@acm.org > > http://saveournet.ca > Protecting your Internet's level playing field > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" > From owner-freebsd-stable@FreeBSD.ORG Tue Jan 19 17: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 AD0B6106566B for ; Tue, 19 Jan 2010 17:01:04 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta14.westchester.pa.mail.comcast.net (qmta14.westchester.pa.mail.comcast.net [76.96.59.212]) by mx1.freebsd.org (Postfix) with ESMTP id 52B688FC18 for ; Tue, 19 Jan 2010 17:01:03 +0000 (UTC) Received: from omta12.westchester.pa.mail.comcast.net ([76.96.62.44]) by qmta14.westchester.pa.mail.comcast.net with comcast id XT9h1d0060xGWP85EV149a; Tue, 19 Jan 2010 17:01:04 +0000 Received: from koitsu.dyndns.org ([98.248.46.159]) by omta12.westchester.pa.mail.comcast.net with comcast id XV131d0053S48mS3YV13v8; Tue, 19 Jan 2010 17:01:04 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id E9B041E3033; Tue, 19 Jan 2010 09:01:01 -0800 (PST) Date: Tue, 19 Jan 2010 09:01:01 -0800 From: Jeremy Chadwick To: freebsd-stable@freebsd.org Message-ID: <20100119170101.GA80917@icarus.home.lan> References: <7346c5c61001030842r7dc76199y51e4c1c90a3eea6e@mail.gmail.com> <7346c5c61001091706m45a3a2a5k3ca8bb0c4bec5ea8@mail.gmail.com> <7346c5c61001171521w1ca4738w98e8fcca24643cda@mail.gmail.com> <201001180829.48126.npapke@acm.org> <7346c5c61001190840k31466754i32b2ae833390b79b@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <7346c5c61001190840k31466754i32b2ae833390b79b@mail.gmail.com> User-Agent: Mutt/1.5.20 (2009-06-14) Subject: Re: ZFS performance degradation over time X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 19 Jan 2010 17:01:04 -0000 On Tue, Jan 19, 2010 at 11:40:50AM -0500, Garrett Moore wrote: > I've been watching my memory usage and I have no idea what is consuming > memory as 'Active'. > > Last night I had around 6500MB 'Active' again, 1500MB Wired, no inact, ~30MB > buf, no free, and ~100MB swap used. My performance copying ZFS->ZFS was > again slow (<1MB/s). I tried killing rTorrent and no significant amount of > memory was reclaimed - maybe 100MB. `ps aux` showed no processes using any > significant amount of memory, and I was definitely nowhere near 6500MB > usage. > > I tried running the perl oneliner again to hog a bunch of memory, and almost > all of the Active memory was IMMEDIATELY marked as Free, and my performance > was excellent again. > > I'm not sure what in userland could be causing the issue. The only things > I've installed are rTorrent, lighttpd, samba, smartmontools, vim, bash, > Python, Perl, and SABNZBd. There is nothing that *should* be consuming any > serious amount of memory. I've two recommendations: 1) Have you considered "upgrading" to RELENG_8 (e.g. 8.0-STABLE) instead of sticking with 8.0-RELEASE? There's been a recent MFC to RELENG_8 which pertain to ARC drainage. I'm referring to the commit labelled revision 1.22.2.2 (RELENG_8): http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/arc.c 2) Have you tried using vfs.zfs.arc_max in loader.conf to limit the ARC size? I'd recommend picking something like 1GB as a cap (your machine has 8GB total at present, if I remember right). I believe long ago someone said this isn't an explicit hard limit on the maximum size of the ARC, but I believe this was during the RELENG_7 days and the ARC "stuff" on FreeBSD has changed since then. I wish the tunables were better documented, or at least explained in detail (hello Wiki!). Finally: Does anyone have reservations about me crossposting this thread to freebsd-fs@freebsd.org, to get some additional eyes? Reports like this often scare/worry those of us who run servers. :-) > On Mon, Jan 18, 2010 at 11:29 AM, Norbert Papke wrote: > > > On January 17, 2010, Garrett Moore wrote: > > > I upgraded my system to 8GB of ram to see if that would help. It hasn't > > > made much of a difference. After having rTorrent running for a while, my > > > performance again tanked. Around 6.5GB of memory was showing as 'Active' > > > according to top. > > > > 6.5GB of "active" memory seems to imply that a user process is growing or a > > large number of user processes are being created. I would expect ZFS's > > cache > > to increase the size of "wired" memory. > > > > Sorry, I have not followed this thread closely. Are you sure that the > > degradation is ZFS related? Could it be caused by, for instance, a > > userland > > memory leak? What happens to active memory when you restart rtorrent? -- | 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 Jan 19 17:11: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 D429410656AE; Tue, 19 Jan 2010 17:11:27 +0000 (UTC) (envelope-from dan.naumov@gmail.com) Received: from mail-yw0-f172.google.com (mail-yw0-f172.google.com [209.85.211.172]) by mx1.freebsd.org (Postfix) with ESMTP id 5851C8FC1C; Tue, 19 Jan 2010 17:11:27 +0000 (UTC) Received: by ywh2 with SMTP id 2so1742622ywh.27 for ; Tue, 19 Jan 2010 09:11:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:cc:content-type; bh=m8xAPoNUEf7JoC3Ekzyc+4ry8GMnGdrNKJ+AaobFWnU=; b=gy0rdU9oh1XJgffgIZSBTIZf7WTr5jmvj9iHhkumx1j04qUtCmL+GYGfzBu1f2aNHa S90DkdAKGW8ZYYFW4KbIY/nCRId6GdWOwwSKMngXisxrQBib6rV6Ygva/UFkp814JtEU Sx2BLyiFoQE5M/TZBG64x3iSHnxSwVJTgpXL8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:cc:content-type; b=mFFUo4OqxCv66d8StOr9omm/vwotfe3riQqjTMvZDwO7uQBWAUezn0Yh1IbqDTBXhd rjmGUcAW8e8zC8d4K9hhjIUJLDM0JoiB4nGPyaCs/PhlB6fGDguNFHYUqw8uJOTcs1OD tqoJUY8o52lu6dY+rixkBR6IWbfmjUbzvvO0Q= MIME-Version: 1.0 Received: by 10.101.44.14 with SMTP id w14mr12053734anj.139.1263921086362; Tue, 19 Jan 2010 09:11:26 -0800 (PST) Date: Tue, 19 Jan 2010 19:11:26 +0200 Message-ID: From: Dan Naumov To: FreeBSD-STABLE Mailing List , freebsd-questions@freebsd.org, freebsd-geom@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Cc: rnoland@freebsd.org Subject: 8.0-RELEASE / gpart / GPT / marking a partition as "active" X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 19 Jan 2010 17:11:28 -0000 It seems that quite a few BIOSes have serious issues booting off disks using GPT partitioning when no partition present is marked as "active". See http://www.freebsd.org/cgi/query-pr.cgi?pr=115406&cat=bin for a prime example. In 8.0-RELEASE, using gpart, setting a slice as "active" in MBR partitioning mode is trivial, ie: gpart set -a active -i 1 DISKNAME However, trying to do the same thing with GPT partitioning yields no results: gpart set -a active -i 1 DISKNAME gpart: attrib 'active': Device not configured As a result of this issue, I can configure and make a succesfull install using GPT in 8.0, but I cannot boot off it using my Intel D945GCLF2 board. I have found this discussion from about a month ago: http://www.mail-archive.com/freebsd-stable@freebsd.org/msg106918.html where Robert mentions that "gpart set -a active -i 1" is no longer needed in 8-STABLE, because the pmbr will be marked as active during the installation of the bootcode. Is there anything I can do to archieve the same result in 8.0-RELEASE or is installing from a snapshop of 8-STABLE my only option? Thanks. - Sincerely, Dan Naumov From owner-freebsd-stable@FreeBSD.ORG Tue Jan 19 17:13: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 896BF1065698 for ; Tue, 19 Jan 2010 17:13:02 +0000 (UTC) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (lurza.secnetix.de [IPv6:2a01:170:102f::2]) by mx1.freebsd.org (Postfix) with ESMTP id 11FD68FC15 for ; Tue, 19 Jan 2010 17:13:01 +0000 (UTC) Received: from lurza.secnetix.de (localhost [127.0.0.1]) by lurza.secnetix.de (8.14.3/8.14.3) with ESMTP id o0JHCjco056571; Tue, 19 Jan 2010 18:13:00 +0100 (CET) (envelope-from oliver.fromme@secnetix.de) Received: (from olli@localhost) by lurza.secnetix.de (8.14.3/8.14.3/Submit) id o0JHCjPj056570; Tue, 19 Jan 2010 18:12:45 +0100 (CET) (envelope-from olli) Date: Tue, 19 Jan 2010 18:12:45 +0100 (CET) Message-Id: <201001191712.o0JHCjPj056570@lurza.secnetix.de> From: Oliver Fromme To: freebsd-stable@FreeBSD.ORG, jespasac@minibofh.org In-Reply-To: <4B50737A.4090007@minibofh.org> X-Newsgroups: list.freebsd-stable User-Agent: tin/1.8.3-20070201 ("Scotasay") (UNIX) (FreeBSD/6.4-PRERELEASE-20080904 (i386)) MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.1.2 (lurza.secnetix.de [127.0.0.1]); Tue, 19 Jan 2010 18:13:01 +0100 (CET) Cc: Subject: Re: About nice(1), renice(8) and ULE scheduler X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: freebsd-stable@FreeBSD.ORG, jespasac@minibofh.org List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jan 2010 17:13:02 -0000 Jordi Espasa Clofent wrote: > I've realized that the nice(1) code hasn't been modified for a long time > (last code change seems from 4 years ago according the sources). > > Is the nice(1) behaviour the expected? I mean, Has been the ULE > scheduler adapted to nice(1) command or not? > > nice(1) is a very old command based on old concepts and created in times > when SMP didn't exist. So it works correctly when a modern an > re-designed scheduler as ULE is used? In fact nice is a very simple program. It only changes the priority value of a process in a POSIX-compliant way. There is no need to change or adapt it; it still works fine in the SMP world and with new schedulers. It's up to the scheduler to interpret and handle the priority values of processes. In other words: The nice(1) tool only attaches a number to a process, nothing more. Only the scheduler knows what that number means. So there's no need to change nice(1). By the way, the source code of nice(1) is almost trivial. Basically it just calls the setpriority(2) and execve(2) syscalls. 99% of the source file consists of the BSD license test, arguments parsing and C syntax overhead. Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mn- chen, HRB 125758, Geschftsfhrer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd "I have stopped reading Stephen King novels. Now I just read C code instead." -- Richard A. O'Keefe From owner-freebsd-stable@FreeBSD.ORG Tue Jan 19 17:36:25 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 B1B0E106566B for ; Tue, 19 Jan 2010 17:36:25 +0000 (UTC) (envelope-from jhellenthal@gmail.com) Received: from mail-qy0-f174.google.com (mail-qy0-f174.google.com [209.85.221.174]) by mx1.freebsd.org (Postfix) with ESMTP id 5B23C8FC0C for ; Tue, 19 Jan 2010 17:36:25 +0000 (UTC) Received: by qyk4 with SMTP id 4so2452911qyk.7 for ; Tue, 19 Jan 2010 09:36:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:date:from:to:cc :subject:in-reply-to:message-id:references:user-agent :x-openpgp-key-id:x-openpgp-key-fingerprint:mime-version :content-type; bh=hU8UyUa/nCgYe1ZcPr+XHm5eTQB1lhDquwk5Jyzmo8g=; b=Z+LNRQtd/pxcOTEOywGgGrVwxsn/tlNUWE9XbyF3ku7PmKvhl1XZv5tTr6qBSpext8 8KAxcZro8EdybpJBtPeRu0BXPGxcEFeckz8tiaPw2BBnoBu++fQkuZcLhpYkrvznaTOM 7Dm08UZCT3uz9zvHAEmcuyEDgEltObZGfQr7s= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:date:from:to:cc:subject:in-reply-to:message-id:references :user-agent:x-openpgp-key-id:x-openpgp-key-fingerprint:mime-version :content-type; b=u2Jwe74YhKxnCm+T7En8V6npRjVowFPUEiLxOxZFoxpAffNFqta59ryF/BJB/WOHkw aslaFt3ULmHI908jjsJFm0tHAp9QbmKn0wCHeqlW0Dyu9cLP+MDUqYj2OKAPk+sM3rXl FTGvV9P32SS71VqbjJ1mTqMeGVubfNkgd7J78= Received: by 10.224.7.19 with SMTP id b19mr2202649qab.240.1263922584361; Tue, 19 Jan 2010 09:36:24 -0800 (PST) Received: from centel.dataix.local (ppp-22.108.dialinfree.com [209.172.22.108]) by mx.google.com with ESMTPS id 23sm6211430qyk.11.2010.01.19.09.36.20 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 19 Jan 2010 09:36:22 -0800 (PST) Sender: "J. Hellenthal" Date: Tue, 19 Jan 2010 12:36:12 -0500 From: jhell To: Johan Hendriks In-Reply-To: <57200BF94E69E54880C9BB1AF714BBCBA574DF@w2003s01.double-l.local> Message-ID: References: <57200BF94E69E54880C9BB1AF714BBCBA574DF@w2003s01.double-l.local> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) X-OpenPGP-Key-Id: 0x89D8547E X-OpenPGP-Key-Fingerprint: 85EF E26B 07BB 3777 76BE B12A 9057 8789 89D8 547E MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: FreeBSD Stable Subject: Re: scp from livecd (fixit option) cd can not find /usr/bin/ssh X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 19 Jan 2010 17:36:25 -0000 On Tue, 19 Jan 2010 10:57, Johan@ wrote: > Hello i use the livecd to save an old pc. > > But when i try to use scp to copy some data to our network i get the > message that /usr/bin/ssh could not be found. > > > > This is on 8.0 i386 livecd > This is the same for snapshots of stable/7 livecd too. -- jhell From owner-freebsd-stable@FreeBSD.ORG Tue Jan 19 17:43: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 6375E10656A6 for ; Tue, 19 Jan 2010 17:43:20 +0000 (UTC) (envelope-from jfb@mr-paradox.net) Received: from vexbert.mr-paradox.net (vexbert.mr-paradox.net [IPv6:2001:470:b:28:f::1]) by mx1.freebsd.org (Postfix) with ESMTP id 491EE8FC21 for ; Tue, 19 Jan 2010 17:43:20 +0000 (UTC) Received: by vexbert.mr-paradox.net (Postfix, from userid 16139) id BE4DE845A5; Tue, 19 Jan 2010 12:43:19 -0500 (EST) Date: Tue, 19 Jan 2010 12:43:17 -0500 From: Jeff Blank To: jhell Message-ID: <20100119174317.GA75173@mr-happy.com> References: <57200BF94E69E54880C9BB1AF714BBCBA574DF@w2003s01.double-l.local> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Face: #0jV*~a}VtKS-&E/!EJpH('H1Va}24dxF0oT&+.R3Gu8C; xhSC+<|+H84&YLbMvphuRT4cp3.|8EN_(2Eix/6{.Up~u`a^}0Ln&b+9Fw|BPig@-{y\pL_46d&ZwA]5%_AU?}DezfE&1!>H?3E$!Yve7.O<+..Jnb4:'6Ey_]FtFzU9=*l$1p/@gA,Ze>^5<]+r(XJ+m7`/vMDc$'wy|`e Cc: Johan Hendriks , FreeBSD Stable Subject: Re: scp from livecd (fixit option) cd can not find /usr/bin/ssh X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 19 Jan 2010 17:43:20 -0000 On Tue, Jan 19, 2010 at 12:36:12PM -0500, jhell wrote: > On Tue, 19 Jan 2010 10:57, Johan@ wrote: > >Hello i use the livecd to save an old pc. > > > >But when i try to use scp to copy some data to our network i get the > >message that /usr/bin/ssh could not be found. > > This is the same for snapshots of stable/7 livecd too. Fixit# which ssh /mnt2/usr/bin/ssh Fixit# scp -S /mnt2/usr/bin/ssh ... Jeff From owner-freebsd-stable@FreeBSD.ORG Tue Jan 19 18:51: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 713B7106566B; Tue, 19 Jan 2010 18:51:54 +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 02C328FC19; Tue, 19 Jan 2010 18:51:52 +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 UAA28706; Tue, 19 Jan 2010 20:51:49 +0200 (EET) (envelope-from avg@icyb.net.ua) Message-ID: <4B55FF44.4040308@icyb.net.ua> Date: Tue, 19 Jan 2010 20:51:48 +0200 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.23 (X11/20091206) MIME-Version: 1.0 To: Dan Naumov References: In-Reply-To: X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: FreeBSD-STABLE Mailing List , freebsd-questions@freebsd.org, rnoland@freebsd.org, freebsd-geom@freebsd.org Subject: Re: 8.0-RELEASE / gpart / GPT / marking a partition as "active" X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 19 Jan 2010 18:51:54 -0000 on 19/01/2010 19:11 Dan Naumov said the following: > I have found this discussion from about a month ago: > http://www.mail-archive.com/freebsd-stable@freebsd.org/msg106918.html > where Robert mentions that "gpart set -a active -i 1" is no longer > needed in 8-STABLE, because the pmbr will be marked as active during It was never ever "needed", because it never worked. > the installation of the bootcode. Is there anything I can do to > archieve the same result in 8.0-RELEASE or is installing from a > snapshop of 8-STABLE my only option? People did it using fdisk -a, google should have turned that up. -- Andriy Gapon From owner-freebsd-stable@FreeBSD.ORG Tue Jan 19 18:57: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 2C5641065670 for ; Tue, 19 Jan 2010 18:57:26 +0000 (UTC) (envelope-from lehmann@ans-netz.de) Received: from avocado.salatschuessel.net (avocado.salatschuessel.net [78.111.72.186]) by mx1.freebsd.org (Postfix) with SMTP id 5E6968FC16 for ; Tue, 19 Jan 2010 18:57:24 +0000 (UTC) Received: (qmail 48709 invoked by uid 89); 19 Jan 2010 18:57:22 -0000 Received: from unknown (HELO kartoffel.salatschuessel.net) (78.111.72.187) by avocado.salatschuessel.net with SMTP; 19 Jan 2010 18:57:22 -0000 Date: Tue, 19 Jan 2010 19:57:22 +0100 From: Oliver Lehmann To: Jeremy Chadwick Message-Id: <20100119195722.ee6e799b.lehmann@ans-netz.de> In-Reply-To: <20100119112449.GA73052@icarus.home.lan> References: <4B54C100.9080906@mail.zedat.fu-berlin.de> <4B54C5EE.5070305@pp.dyndns.biz> <201001191250.23625.doconnor@gsoft.com.au> <7346c5c61001181841j3653a7c3m32bc033c8c146a92@mail.gmail.com> <4B557B5A.8040902@pp.dyndns.biz> <20100119095736.GA71824@icarus.home.lan> <20100119110724.ec01a3ed.gerrit@pmp.uni-hannover.de> <20100119112449.GA73052@icarus.home.lan> X-Mailer: Sylpheed 2.7.1 (GTK+ 2.18.5; amd64-portbld-freebsd8.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org Subject: Re: immense delayed write to file system (ZFS and UFS2), performance issues X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 19 Jan 2010 18:57:26 -0000 Hi, it seems that I'm not experiencing this at all... Jeremy Chadwick wrote: > WD10EACS - WD Caviar Green, 1TB, 16MB, variable rpm have one (external HDD, "always" powered on) Model = WDC WD10EAVS-00D7B1 Firmware Version = 01.01A01 Power_On_Hours 5757 Power_Cycle_Count 75 Load_Cycle_Count 127 > WD10EADS - WD Caviar Green, 1TB, 32MB, variable rpm have four, got them in Sep/09. one is RMAed right now because it had defective sectors in Dec/09 (surprisingly the first WDC I encountered problems so far). All four are used as a RAID-5 configured with my 3ware 9500-4LP. I don't know if the controller requests data from the drives in a very short period of time. I'm MRTGing some SMART attributes which should at least query the drive every minute. The ata idle feature is not supported at all trough the 3ware controllers. For the remaining 3 drives: Model = WDC WD10EADS-00L5B1 Firmware Version = 01.01A01 Power_On_Hours 2538 Power_Cycle_Count 140 Load_Cycle_Count 141 Power_On_Hours 2526 Power_Cycle_Count 133 Load_Cycle_Count 134 Power_On_Hours 2490 Power_Cycle_Count 126 Load_Cycle_Count 128 So - I'm not experiencing this problem at all but I "feel" that the drives are reacting more slowly than my previous WD2500KS-00MJB0 are. changing a directory and then typing ls takes some time until the result is displayed... I can live with that but it doesn't feel "good" And - it is not really something I would call "fast" - but it saves power :) The 3ware RAID-5 over 4 disks (using the EAVS from above as replacement right now until WDC sends a new drive back): Version 1.96 ------Sequential Output------ --Sequential Input- --Random- Concurrency 1 -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks-- Machine Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP /sec %CP nudel.salatschue 6G 89 99 76321 38 29285 21 249 99 111225 33 201.7 13 Latency 106ms 247ms 1155ms 63744us 145ms 382ms Version 1.96 ------Sequential Create------ --------Random Create-------- nudel.salatschuesse -Create-- --Read--- -Delete-- -Create-- --Read--- -Delete-- files /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP 16 571 6 +++++ +++ 1095 8 617 6 +++++ +++ 611 5 Latency 523ms 61us 125ms 103ms 87us 159ms -- Oliver Lehmann http://www.pofo.de/ http://wishlist.ans-netz.de/ From owner-freebsd-stable@FreeBSD.ORG Tue Jan 19 19:20: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 9F9A61065670 for ; Tue, 19 Jan 2010 19:20:57 +0000 (UTC) (envelope-from spork@bway.net) Received: from xena.bway.net (xena.bway.net [216.220.96.26]) by mx1.freebsd.org (Postfix) with ESMTP id 399CE8FC0A for ; Tue, 19 Jan 2010 19:20:56 +0000 (UTC) Received: (qmail 6082 invoked by uid 0); 19 Jan 2010 19:20:56 -0000 Received: from unknown (HELO ?192.168.0.103?) (spork@68.165.143.83) by smtp.bway.net with (DHE-RSA-AES256-SHA encrypted) SMTP; 19 Jan 2010 19:20:56 -0000 Date: Tue, 19 Jan 2010 14:20:54 -0500 (EST) From: Charles Sprickman X-X-Sender: spork@hotlap.local To: =?ISO-8859-15?Q?Gerrit_K=FChn?= In-Reply-To: <20100119134827.250abc50.gerrit@pmp.uni-hannover.de> Message-ID: References: <4B54C100.9080906@mail.zedat.fu-berlin.de> <4B54C5EE.5070305@pp.dyndns.biz> <201001191250.23625.doconnor@gsoft.com.au> <7346c5c61001181841j3653a7c3m32bc033c8c146a92@mail.gmail.com> <4B557B5A.8040902@pp.dyndns.biz> <20100119095736.GA71824@icarus.home.lan> <20100119110724.ec01a3ed.gerrit@pmp.uni-hannover.de> <20100119112449.GA73052@icarus.home.lan> <20100119134827.250abc50.gerrit@pmp.uni-hannover.de> User-Agent: Alpine 2.00 (OSX 1167 2008-08-23) MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="0-149292284-1263928854=:53123" Cc: freebsd-stable@freebsd.org, Jeremy Chadwick Subject: Re: immense delayed write to file system (ZFS and UFS2), performance issues X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 19 Jan 2010 19:20:57 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --0-149292284-1263928854=:53123 Content-Type: TEXT/PLAIN; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 8BIT On Tue, 19 Jan 2010, Gerrit Khn wrote: > On Tue, 19 Jan 2010 03:24:49 -0800 Jeremy Chadwick > wrote about Re: immense delayed write to file > system (ZFS and UFS2), performance issues: > > JC> > JC> If you want a consumer-edition drive that's better tuned for > JC> > JC> server work, you should really be looking at the WD Caviar Black > JC> > JC> series or their RE/RE2 series. > > JC> > That's exactly what I did. I have WD-RE2 drives here that show > JC> > exactly this problem (RE2/GP)! The model number is WD1000FYPS-01ZKB0. > > JC> I should have been more specific. WD makes RE-series drives which > JC> don't have GP applied to them; those are what I was referring to. > > Well, when I bought these drives I was not aware of this issue. Buying a > drive intended for 24/7 use in RAID configurations is basically the right > idea, I think. From what was written about the GP feature back then I > could not anticipate such problems. > I would have liked to buy the 2TB drives without GP lately, but they have > lead times into April here. So I went for the GP model, which now shows > the same problem as the 1TB drive... :-( > > JC> WD1000FYPS - WD RE2-GP, 1TB, 16MB, variable rpm > JC> WD2002FYPS - WD RE4-GP, 2TB, 64MB, variable rpm > > JC> So which drive models above are experiencing a continual increase in > JC> SMART attribute 193 (Load Cycle Count)? My guess is that some of the > JC> WD Caviar Green models, and possibly all of the RE2-GP and RE4-GP > JC> models are experiencing this problem. > > I can confirm that the two models above show this problem. > Furthermore I can confirm that at least in my setup here this drive > type works fine: > > WD5001ABYS > > I have some of the RE3 drives sitting around here and will probably try > them later. I specifically bought RE3 drives recently because of the whole fiasco regarding "raid compatibility". I paid about $20 each more for these in the interest of things "just working", since I saw some debate about whether or not the TLER setting can be flipped on the "non-RAID" drives. FWIW, 4 1TB RE3's in a zfs raidz (an excerpt from bonnie++, block read/write 8G on 4G RAM): Write Read K/sec K/sec 123207 142749 Both zfs and these drives kind of surprised me, that seems pretty good for software raid with parity... Seagate is currently on my blacklist after we had a large number of them fail a year or two in the past year or two. I've had good luck so far with WD RE2 and RE3 drives. I'll probably give seagate another shot in a year or two. C > Can anyone here report anything about the fixed firmware from > ? > Does this remedy the problem for the 1TB RE2 drive? > > JC> I say "some" with regards to WD Caviar Green since I have some which do > JC> not appear to exhibit the heads/actuator arm moved into the > JC> landing/park zone. I'm at work right now, but when I get home I can > JC> verify what models I've used which didn't experience this problem, as > JC> well as what the manufacturing date and F/W revisions are. I should > JC> note I don't have said Green drives in use (I use WD1001FALS drives > JC> now). > > Thanks for sharing this information. > > > cu > Gerrit > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" > --0-149292284-1263928854=:53123-- From owner-freebsd-stable@FreeBSD.ORG Tue Jan 19 19:26: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 184401065670; Tue, 19 Jan 2010 19:26:12 +0000 (UTC) (envelope-from freebsd@insightbb.com) Received: from mxsf15.insightbb.com (mxsf15.insightbb.com [74.128.0.97]) by mx1.freebsd.org (Postfix) with ESMTP id C8C808FC15; Tue, 19 Jan 2010 19:26:11 +0000 (UTC) X-IronPort-AV: E=Sophos;i="4.49,305,1262581200"; d="scan'208";a="19681314" Received: from unknown (HELO asav02.insightbb.com) ([172.31.249.123]) by mxsf15.insightbb.com with ESMTP; 19 Jan 2010 13:57:40 -0500 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAIaPVUvQLicL/2dsb2JhbACBRoIbxmOOFIEtgjBWBIV2 X-IronPort-AV: E=Sophos;i="4.49,305,1262581200"; d="scan'208";a="344310560" Received: from 208-46-39-11.dia.static.qwest.net (HELO laptop2.stevenfriedrich.org) ([208.46.39.11]) by asavout02.manage.insightbb.com with ESMTP; 19 Jan 2010 13:57:39 -0500 From: Steven Friedrich To: freebsd-net@freebsd.org Date: Tue, 19 Jan 2010 13:57:33 -0500 User-Agent: KMail/1.12.4 (FreeBSD/8.0-STABLE; KDE/4.3.4; i386; ; ) References: <4B5546B0.1050102@gddsn.org.cn> In-Reply-To: <4B5546B0.1050102@gddsn.org.cn> MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <201001191357.33267.freebsd@insightbb.com> Cc: stable@freebsd.org, wsk , net@freebsd.org Subject: Re: 8.0 stable if_bwi kmod not exist? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 19 Jan 2010 19:26:12 -0000 On Tuesday 19 January 2010 12:44:16 am wsk wrote: > folks, > There is not exist if_bwi.ko module in /boot/kernel under 8.0 Stable > why? _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > Perhaps in /etc/make.conf, you define modules you want to build and this is a new one to be added? Look at variables MODULES_OVERRIDE and WITHOUT_MODULES. From owner-freebsd-stable@FreeBSD.ORG Tue Jan 19 19:29: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 21F6E106568F for ; Tue, 19 Jan 2010 19:29:16 +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 C74BB8FC1E for ; Tue, 19 Jan 2010 19:29:15 +0000 (UTC) Received: from amavis.netlife.no (amavishost [10.115.1.11]) by mta1-filtered.netlife.no (Postfix) with ESMTP id C9AA05744C; Tue, 19 Jan 2010 19:09:58 +0000 (UTC) X-Virus-Scanned: amavisd-new at netlife.no Received: from mta1-submission.netlife.no ([62.92.26.226]) by amavis.netlife.no (amavis.netlife.no [10.115.1.11]) (amavisd-new, port 10026) with ESMTP id kUoTynD+MQ+Z; Tue, 19 Jan 2010 20:09:58 +0100 (CET) Received: from baviandesktop.netlife.no (kontor.netlife.no [217.13.28.50]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: erik_pop@netlife.no) by mta1-submission.netlife.no (Postfix) with ESMTPSA id 7E92D57447; Tue, 19 Jan 2010 19:09:58 +0000 (UTC) Message-ID: <4B560386.8060007@tefre.com> Date: Tue, 19 Jan 2010 20:09:58 +0100 From: Erik Stian Tefre User-Agent: Thunderbird 2.0.0.23 (X11/20091005) MIME-Version: 1.0 To: =?ISO-8859-1?Q?Morgan_Wesstr=F6m?= References: <4B54C100.9080906@mail.zedat.fu-berlin.de> <4B54C5EE.5070305@pp.dyndns.biz> <201001191250.23625.doconnor@gsoft.com.au> <7346c5c61001181841j3653a7c3m32bc033c8c146a92@mail.gmail.com> <4B557B5A.8040902@pp.dyndns.biz> In-Reply-To: <4B557B5A.8040902@pp.dyndns.biz> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Cc: freebsd-stable@freebsd.org Subject: Re: immense delayed write to file system (ZFS and UFS2), performance issues X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 19 Jan 2010 19:29:16 -0000 Morgan Wesstrm wrote: > Garrett Moore wrote: >> The drives being discussed in my related thread (regarding poor performance) >> are all WD Green drives. I have used wdidle3 to set all of my drive timeouts >> to 5 minutes. I'll see what sort of difference this makes for performance. >> >> Even if it makes no difference to performance, thank you for pointing it out >> -- my drives have less than 2,000 hours on them and were all over 90,000 >> load cycles due to this moronic factory setting. Since changing the timeout, >> they haven't parked (which is what I would expect). >> > > You're welcome. I just feel as bad for you as for everyone else who has > bought these obviously Windoze optimized harddrives. Unfortunately > neither wdidle3 nor an updated firmware is available or functioning on > the latest models in the Green series. At least that's what I've read > from other people having this issue. WD only claims they don't support > Linux and they probably have never heard of FreeBSD. > > If anyone successfully has fixed their WD15EADS drives this way I'd be > interested in hearing from you. One of my drives has 216,000 load cycles > accumulated over 8 months. That's one every 2nd minute... and I was hit > by the Seagate 7200.11 fiasco too. Running on Samsungs now :-) Keeping this python script running prevents Load_Cycle_Count from incrementing on my WD15EADS drives by forcing a write every 5 seconds (2 drive zfs mirror pool, average of 2 load cycles per minute when the script is not running): import time,os mypool = "/zfspool" # ^^ Change to your pool! fname = os.path.join(mypool, "wd_green_anti_idle.pyfile") c = 0 f = open(fname, "w") while True: if c == 100: f.close() f = open(fname, "w") c = 0 c += 1 time.sleep(5) f.write("a") f.flush() os.fsync(f.fileno()) -- Erik From owner-freebsd-stable@FreeBSD.ORG Tue Jan 19 19:49: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 359481065670 for ; Tue, 19 Jan 2010 19:49:37 +0000 (UTC) (envelope-from mandrews@bit0.com) Received: from magnum.bit0.com (magnum.bit0.com [207.246.88.226]) by mx1.freebsd.org (Postfix) with ESMTP id 0CAB18FC1D for ; Tue, 19 Jan 2010 19:49:36 +0000 (UTC) Received: from [172.27.0.11] (nat.bit0.com [207.246.88.210]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by magnum.bit0.com (Postfix) with ESMTPSA id CD257E072 for ; Tue, 19 Jan 2010 14:49:35 -0500 (EST) Message-ID: <4B560D2D.30404@bit0.com> Date: Tue, 19 Jan 2010 14:51:09 -0500 From: Mike Andrews User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.5) Gecko/20091204 Thunderbird/3.0 MIME-Version: 1.0 To: freebsd-stable@freebsd.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: 8.0-RELEASE / gpart / GPT / marking a partition as "active" X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 19 Jan 2010 19:49:37 -0000 On 1/19/2010 12:11 PM, Dan Naumov wrote: > It seems that quite a few BIOSes have serious issues booting off disks > using GPT partitioning when no partition present is marked as > "active". See http://www.freebsd.org/cgi/query-pr.cgi?pr=115406&cat=bin > for a prime example. > > In 8.0-RELEASE, using gpart, setting a slice as "active" in MBR > partitioning mode is trivial, ie: > > gpart set -a active -i 1 DISKNAME > > However, trying to do the same thing with GPT partitioning yields no results: > > gpart set -a active -i 1 DISKNAME > gpart: attrib 'active': Device not configured > > As a result of this issue, I can configure and make a succesfull > install using GPT in 8.0, but I cannot boot off it using my Intel > D945GCLF2 board. > > I have found this discussion from about a month ago: > http://www.mail-archive.com/freebsd-stable@freebsd.org/msg106918.html > where Robert mentions that "gpart set -a active -i 1" is no longer > needed in 8-STABLE, because the pmbr will be marked as active during > the installation of the bootcode. Is there anything I can do to > archieve the same result in 8.0-RELEASE or is installing from a > snapshop of 8-STABLE my only option? After using gpart to create the GPT (and thus the PMBR and its bootcode), why not simply use "fdisk -a -1 DISKNAME" to set the PMBR partition active? From owner-freebsd-stable@FreeBSD.ORG Tue Jan 19 21:09: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 63B6D106566C; Tue, 19 Jan 2010 21:09:11 +0000 (UTC) (envelope-from dan.naumov@gmail.com) Received: from mail-yw0-f172.google.com (mail-yw0-f172.google.com [209.85.211.172]) by mx1.freebsd.org (Postfix) with ESMTP id 89F668FC15; Tue, 19 Jan 2010 21:09:10 +0000 (UTC) Received: by ywh2 with SMTP id 2so1986552ywh.27 for ; Tue, 19 Jan 2010 13:09:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=NQEgV5NARJzpbaq9Uooon9S7qJyclIgxOnbfJP3IpMs=; b=F8WCyt3oK8dZ8wbfI4HZ8ZdFGhgwN+qD+17LHZZdDAA+I25948AYsOsVff/2TRpcpd LxaiOvV0Kc1tbsFZOWwUEmrB8EAnUfc5F5IwdrR9HrXUy9tDTBmdfD3tDM7r/UuIrqlq k1ltgbQhDzgJ8scou3E9b0Hjo4T3k9ufjmMSM= 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=LubdlYVCncBjC82b2WVd58pw9mnGJFfHSeX2WrVPx4jb2GMxD0sEEHEZSGoqxlqz11 X/IUeItsN7v1ZGQv5h9rnlYYAN9fGkuRCh9+4LDMx/ht3r/i0nmVj94TRt02YJhoi4NB 4edXJ9/ThbcKtb14OLk5OAI8FnSz0pz0XiWeQ= MIME-Version: 1.0 Received: by 10.101.3.18 with SMTP id f18mr12157921ani.180.1263935349705; Tue, 19 Jan 2010 13:09:09 -0800 (PST) In-Reply-To: <4B55FF44.4040308@icyb.net.ua> References: <4B55FF44.4040308@icyb.net.ua> Date: Tue, 19 Jan 2010 23:09:09 +0200 Message-ID: From: Dan Naumov To: Andriy Gapon , mandrews@bit0.com Content-Type: text/plain; charset=ISO-8859-1 Cc: FreeBSD-STABLE Mailing List , freebsd-questions@freebsd.org, rnoland@freebsd.org, freebsd-geom@freebsd.org Subject: Re: 8.0-RELEASE / gpart / GPT / marking a partition as "active" X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 19 Jan 2010 21:09:11 -0000 On 1/19/2010 12:11 PM, Dan Naumov wrote: > It seems that quite a few BIOSes have serious issues booting off disks > using GPT partitioning when no partition present is marked as > "active". See http://www.freebsd.org/cgi/query-pr.cgi?pr=115406&cat=bin > for a prime example. > > In 8.0-RELEASE, using gpart, setting a slice as "active" in MBR > partitioning mode is trivial, ie: > > gpart set -a active -i 1 DISKNAME > > However, trying to do the same thing with GPT partitioning yields no results: > > gpart set -a active -i 1 DISKNAME > gpart: attrib 'active': Device not configured > > As a result of this issue, I can configure and make a succesfull > install using GPT in 8.0, but I cannot boot off it using my Intel > D945GCLF2 board. > > I have found this discussion from about a month ago: > http://www.mail-archive.com/freebsd-stable@freebsd.org/msg106918.html > where Robert mentions that "gpart set -a active -i 1" is no longer > needed in 8-STABLE, because the pmbr will be marked as active during > the installation of the bootcode. Is there anything I can do to > archieve the same result in 8.0-RELEASE or is installing from a > snapshop of 8-STABLE my only option? > After using gpart to create the GPT (and thus the PMBR and its > bootcode), why not simply use "fdisk -a -1 DISKNAME" to set the PMBR > partition active? According to the fdisk output, the partition flag did change from 0 to 80. Can the "fdisk: Class not found" error showing up at the very end of the procedure of doing "fdisk -a -1 DISKNAME" be safely ignored? - Dan Naumov From owner-freebsd-stable@FreeBSD.ORG Tue Jan 19 21:23: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 91D821065672; Tue, 19 Jan 2010 21:23:40 +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 344E08FC0C; Tue, 19 Jan 2010 21:23:38 +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 XAA06871; Tue, 19 Jan 2010 23:23:33 +0200 (EET) (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 1NXLXx-000IVb-Ak; Tue, 19 Jan 2010 23:23:33 +0200 Message-ID: <4B5622D4.2070602@icyb.net.ua> Date: Tue, 19 Jan 2010 23:23:32 +0200 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.23 (X11/20091128) MIME-Version: 1.0 To: Dan Naumov References: <4B55FF44.4040308@icyb.net.ua> In-Reply-To: X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: FreeBSD-STABLE Mailing List , mandrews@bit0.com, freebsd-questions@freebsd.org, rnoland@freebsd.org, freebsd-geom@freebsd.org Subject: Re: 8.0-RELEASE / gpart / GPT / marking a partition as "active" X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 19 Jan 2010 21:23:40 -0000 on 19/01/2010 23:09 Dan Naumov said the following: >> After using gpart to create the GPT (and thus the PMBR and its >> bootcode), why not simply use "fdisk -a -1 DISKNAME" to set the PMBR >> partition active? > > According to the fdisk output, the partition flag did change from 0 to > 80. Can the "fdisk: Class not found" error showing up at the very end > of the procedure of doing "fdisk -a -1 DISKNAME" be safely ignored? Yes, I think so. -- Andriy Gapon From owner-freebsd-stable@FreeBSD.ORG Tue Jan 19 21:39:13 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 01A9A106566B for ; Tue, 19 Jan 2010 21:39:13 +0000 (UTC) (envelope-from bsd4life@googlemail.com) Received: from mail-bw0-f209.google.com (mail-bw0-f209.google.com [209.85.218.209]) by mx1.freebsd.org (Postfix) with ESMTP id 7AA7A8FC1B for ; Tue, 19 Jan 2010 21:39:12 +0000 (UTC) Received: by bwz1 with SMTP id 1so1998103bwz.13 for ; Tue, 19 Jan 2010 13:39:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type; bh=BWlA0LCXb1QDyev4YdxRL9nOlzPLz8xkvoLDgvySF+s=; b=ctfg0MNijak9Uq0s7f4H0XkqVdaQsXXVeVPSJUwJSf5BkDhMgW6FewoQWoj+6RgyEt eOwuM4hFE8qAKIv1Ztd6/eWC8DuDe+XUNK2dhZp6bU/6ROm6Xq3dUSMhlHmhLewZ8kbD PPrPa5sp2HiZwuMXTF4mGnGPm6/J2/ttcU+gw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=wcttEqm6Y27xNaT3CbMUkguggryiXuO0OxuvIIZp/YmFF/XSKwqACYme7aA/L79APo bLzqIyVjRh4y0JUZhlFhRuR7GqEoAEq+KnOx/IJ2fFgD1uTy9AWcZhwXQ7oZygToNjt3 /Xm0N28G00TfYv1V8IjbDMnT5m237Iu5uGBJA= MIME-Version: 1.0 Received: by 10.204.25.208 with SMTP id a16mr4597633bkc.133.1263935712153; Tue, 19 Jan 2010 13:15:12 -0800 (PST) In-Reply-To: <201001191250.23625.doconnor@gsoft.com.au> References: <4B54C100.9080906@mail.zedat.fu-berlin.de> <4B54C5EE.5070305@pp.dyndns.biz> <201001191250.23625.doconnor@gsoft.com.au> Date: Tue, 19 Jan 2010 22:15:12 +0100 Message-ID: From: BSD Life To: freebsd-stable@freebsd.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Re: immense delayed write to file system (ZFS and UFS2), performance issues X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 19 Jan 2010 21:39:13 -0000 2010/1/19 Daniel O'Connor > On Tue, 19 Jan 2010, Morgan Wesstr=C3=B6m wrote: > > The disks involved don't happen to be Western Digital Green Power > > disks, do they? The Intelli-Park function in these disks are wrecking > > havoc with I/O in Linux-land at least, causing massive stalls and > > iowait through the roof during the 25-30 seconds it takes for the > > heads to unload after parking. I have two of these disks sitting on > > my desk now collecting dust... > > There's this.. > http://www.silentpcreview.com/Terabyte_Drive_Fix > > and you can get the tool at.. > http://home.arcor.de/ghostadmin/wdidle3_1_00.zip > > I am planning to try this out tonight.. > > I just put my WD5000AACS (it has the same problem) in my Windows PC and d= id a SMART drive quick self-test with the WD utility (Data Lifeguard Diagnosti= c for Windows). I also tried this Idle Mode Updade Utility but it did not attach to my drive. So i put it back to my FreeBSD box (8.0-Stable) and recognized that I am no= t able to decrypt it anymore with geli. It keeps telling: "# geli attach -k /etc/keys/keyfile /dev/ada0 geli: Cannot read metadata from /dev/ada0: Invalid argument." A geli backup command failed with "geli: MD5 hash mismatch: not a geli provider?" I think Windows has messed up something on my disk, but a fdisk dump looks still the same as before: "# fdisk /dev/ada0 ******* Working on device /dev/ada0 ******* parameters extracted from in-core disklabel are: cylinders=3D969021 heads=3D16 sectors/track=3D63 (1008 blks/cyl) Figures below won't work with BIOS for partitions not in cyl 1 parameters to be used for BIOS calculations are: cylinders=3D969021 heads=3D16 sectors/track=3D63 (1008 blks/cyl) fdisk: invalid fdisk partition table found Media sector size is 512 Warning: BIOS sector numbering starts with sector 1 Information from DOS bootblock is: The data for partition 1 is: sysid 165 (0xa5),(FreeBSD/NetBSD/386BSD) start 63, size 976773105 (476939 Meg), flag 80 (active) beg: cyl 0/ head 1/ sector 1; end: cyl 316/ head 15/ sector 63 The data for partition 2 is: The data for partition 3 is: The data for partition 4 is: " Are there any things I could try or is all my data gone? Thanks in advance From owner-freebsd-stable@FreeBSD.ORG Tue Jan 19 22:07: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 21FD4106566C; Tue, 19 Jan 2010 22:07:16 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.freebsd.org (Postfix) with ESMTP id CC3068FC1B; Tue, 19 Jan 2010 22:07:15 +0000 (UTC) Received: from [IPv6:::1] (pooker.samsco.org [168.103.85.57]) (authenticated bits=0) by pooker.samsco.org (8.14.2/8.14.2) with ESMTP id o0JM7C3f045321; Tue, 19 Jan 2010 15:07:12 -0700 (MST) (envelope-from scottl@samsco.org) Mime-Version: 1.0 (Apple Message framework v1076) Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes From: Scott Long In-Reply-To: <4B55D9D4.1000008@FreeBSD.org> Date: Tue, 19 Jan 2010 15:07:12 -0700 Content-Transfer-Encoding: 7bit Message-Id: <823F6536-32A7-4BC6-9C6A-C84865A38458@samsco.org> References: <4B55D9D4.1000008@FreeBSD.org> To: Alexander Motin X-Mailer: Apple Mail (2.1076) X-Spam-Status: No, score=-7.4 required=3.8 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.8 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on pooker.samsco.org Cc: FreeBSD-Current , FreeBSD Stable Subject: Re: Pack of CAM improvements X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 19 Jan 2010 22:07:17 -0000 On Jan 19, 2010, at 9:12 AM, Alexander Motin wrote: > Hi. > > I've made a patch, that should solve set of problems of CAM ATA and > CAM > generally. I would like to ask for testing and feedback. > > What patch does: > - It unifies bus reset/probe sequence. Whenever bus attached at boot > or > later, CAM will automatically reset and scan it. It allows to remove > duplicate code from many drivers. > - Any bus, attached before CAM completed it's boot-time > initialization, > will equally join to the process, delaying boot if needed. > - New kern.cam.boot_delay loader tunable should help controllers that > are still unable to register their buses in time (such as slow USB/ > PCCard/ CardBus devices). I've fought many times against delay values like this. They never work well enough. Drivers that have delayed scans should set up their own intrhook to delay the boot until their scan is done. To help this out, CAM should move to its own hook that is guaranteed to run after the normal intrhooks. However, this isn't required. Here's my alternate proposal: - move xpt_config() execution to a new config hook that runs after the normal intrhooks. - For self identifying buses (i.e. anything where device presence is known to the controller), have the SIM notify CAM of each target device, instead of assuming that CAM will scan for it. - Teach USB and whatnot to use a confighook to drive their discovery, instead of estimated timeouts. I'm doing exactly this for the new MPT2SAS driver. Scott From owner-freebsd-stable@FreeBSD.ORG Tue Jan 19 23:18:58 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 E6DFD1065670; Tue, 19 Jan 2010 23:18:58 +0000 (UTC) (envelope-from mi+thun@aldan.algebra.com) Received: from mail2.timeinc.net (mail2.timeinc.net [64.236.74.30]) by mx1.freebsd.org (Postfix) with ESMTP id 8C1F38FC18; Tue, 19 Jan 2010 23:18:57 +0000 (UTC) Received: from mail.timeinc.net (mail.timeinc.net [64.12.55.166]) by mail2.timeinc.net (8.13.8/8.13.8) with ESMTP id o0JNIns6014769 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 19 Jan 2010 18:18:50 -0500 Received: from ws-mteterin.dev.pathfinder.com (ws-mteterin.dev.pathfinder.com [209.251.223.173]) by mail.timeinc.net (8.13.8/8.13.8) with SMTP id o0JNIm62007863; Tue, 19 Jan 2010 18:18:49 -0500 Message-ID: <4B563DD8.9050303@aldan.algebra.com> Date: Tue, 19 Jan 2010 18:18:48 -0500 From: "Mikhail T." Organization: Virtual Estates, Inc. User-Agent: Mozilla/5.0 (X11; U; Linux i686; uk; rv:1.9.1.5) Gecko/20091204 Lightning/1.0b1 Thunderbird/3.0 MIME-Version: 1.0 To: Matthew Dillon References: <200603232352.k2NNqPS8018729@gate.bitblocks.com> <200603241518.01027.mi+mx@aldan.algebra.com> <20060325103927.GE703@turion.vk2pj.dyndns.org> <200603250920.14208@aldan> <20060325190333.GD7001@funkthat.com> <4B4F7CF5.4040307@aldan.algebra.com> <201001150256.o0F2ucOx080837@apollo.backplane.com> In-Reply-To: <201001150256.o0F2ucOx080837@apollo.backplane.com> Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 8bit Cc: alc@freebsd.org, Peter Jeremy , stable@freebsd.org Subject: Re: An old gripe: Reading via mmap stinks X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 19 Jan 2010 23:18:59 -0000 01/14/10 21:56, Matthew Dillon (): > This would explain why the performance is not as bad as linux but > is not as good as a properly pipelined case. For what it may be worth, here are the stats for Solaris as well: * Solaris 8, native, 32-bit binary (using -lcrypto instead of -lmd): mmap: 103.54u 27.18s 2:56.46 74.0% read: 99.12u 40.37s 2:53.06 80.6% * Solaris 10, native, 32-bit binary (using -lcrypto instead of -lmd): mmap: 159.36u 83.23s 5:28.25 73.9% read: 173.50u 104.16s 4:48.30 96.3% * Solaris 10, using the 32-bit binary built on Solaris-8: mmap: 217.74u 101.20s 5:58.89 88.8% All of the "read" results on Solaris (and earlier on Linux) were obtained from using ``openssl md5 < largefile''. Seems like BSD is not the only OS, where the mmap's theoretical promise lags behind the actual offering -- read wins on Solaris overall too, despite being quite a bit more expensive in sys-time. Would still be nice to be the first to deliver... -mi From owner-freebsd-stable@FreeBSD.ORG Tue Jan 19 23:58: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 EEA0B106566B; Tue, 19 Jan 2010 23:58:52 +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 7695C8FC18; Tue, 19 Jan 2010 23:58:52 +0000 (UTC) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost1.zedat.fu-berlin.de (Exim 4.69) with esmtp (envelope-from ) id <1NXNyE-00056D-3d>; Wed, 20 Jan 2010 00:58:50 +0100 Received: from e178038234.adsl.alicedsl.de ([85.178.38.234] helo=thor.walstatt.dyndns.org) by inpost2.zedat.fu-berlin.de (Exim 4.69) with esmtpsa (envelope-from ) id <1NXNyD-00018i-Ue>; Wed, 20 Jan 2010 00:58:50 +0100 Message-ID: <4B564739.5060203@mail.zedat.fu-berlin.de> Date: Wed, 20 Jan 2010 00:58:49 +0100 From: "O. Hartmann" User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.1.5) Gecko/20091219 Thunderbird/3.0 MIME-Version: 1.0 To: Guido Falsi References: <25538.130.133.86.198.1263210888.webmail@portal.zedat.fu-berlin.de> <4B4C7499.3080003@icyb.net.ua> <20100112143056.277ae59b@ernst.jennejohn.org> <20100112143129.GA14549@megatron.madpilot.net> In-Reply-To: <20100112143129.GA14549@megatron.madpilot.net> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: 85.178.38.234 Cc: freebsd-stable@freebsd.org, Hajimu UMEMOTO , Andriy Gapon , freebsd-ports@freebsd.org, ohartman@zedat.fu-berlin.de, Gary Jennejohn Subject: Re: thunderbird3: dies with socket(): Protocol not supported Illegal instruction (core dumped) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 19 Jan 2010 23:58:53 -0000 On 01/12/10 15:31, Guido Falsi wrote: > On Tue, Jan 12, 2010 at 02:30:56PM +0100, Gary Jennejohn wrote: >>>>>>>>> On Mon, 11 Jan 2010 12:54:48 +0100 >>>>>>>>> ohartman@zedat.fu-berlin.de said: >>>> >>>> ohartman> Since friday after the last FreeBSD 8.0-STABLE/amd64 update, thunderbird3 >>>> ohartman> crashes immmediately or after a view seconds with >>>> >>>> ohartman> socket(): Protocol not supported >>>> ohartman> Illegal instruction (core dumped) >>>> >>>> I'm not sure but I suspect you are using custom kernel built without >>>> INET6 option. If so, thunderbird3 is depending upon IPv6. >>> >>> Can it be made to not require IPv6? (especially when there is no actual IPv6 >>> connectivity). >>> >> >> Seems to be hardcoded all over the place. Looks like it would require major >> modifications. > > This is strange. I'm using an 8.0-STABL:E/amd64 compiled yesterday here. > Custom kernel without INET6 and thunderbird3 works quite fine. > Sorry for the long delay. Well, after recompiling several ports the situation seems to get relxed, but thunderbird3 is crashing on SMP boxes more frequent than on non-SMP FreeBSD 8/amd64 boxes. So far. I tried to rebuild via portmaster every thunderbird-dependencies (ports on which tunderbird3 depends on, if my English isn't clear). No success. I realise those crashes when I try to abort message sending, then thunderbird crahes immediately. Sometimes it vanishes silently, leaving a dead-mark (core dump) behind. No idea what's going wrong. On my private slwo UP box (FBSD 8.0/amd64 STABLE) thunderbird is stable, but really slow ... Regards, Oliver From owner-freebsd-stable@FreeBSD.ORG Wed Jan 20 00:03: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 47BAE1065676; Wed, 20 Jan 2010 00:03:43 +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 008748FC16; Wed, 20 Jan 2010 00:03:42 +0000 (UTC) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost1.zedat.fu-berlin.de (Exim 4.69) with esmtp (envelope-from ) id <1NXO2w-0005W6-3B>; Wed, 20 Jan 2010 01:03:42 +0100 Received: from e178038234.adsl.alicedsl.de ([85.178.38.234] helo=thor.walstatt.dyndns.org) by inpost2.zedat.fu-berlin.de (Exim 4.69) with esmtpsa (envelope-from ) id <1NXO2v-0001KP-Un>; Wed, 20 Jan 2010 01:03:42 +0100 Message-ID: <4B56485D.2010303@mail.zedat.fu-berlin.de> Date: Wed, 20 Jan 2010 01:03:41 +0100 From: "O. Hartmann" User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.1.5) Gecko/20091219 Thunderbird/3.0 MIME-Version: 1.0 To: =?UTF-8?B?TW9yZ2FuIFdlc3N0csO2bQ==?= References: <4B54C100.9080906@mail.zedat.fu-berlin.de> <4B54C5EE.5070305@pp.dyndns.biz> In-Reply-To: <4B54C5EE.5070305@pp.dyndns.biz> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Originating-IP: 85.178.38.234 Cc: FreeBSD Stable , freebsd-questions@freebsd.org Subject: Re: immense delayed write to file system (ZFS and UFS2), performance issues X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 20 Jan 2010 00:03:43 -0000 On 01/18/10 21:34, =EF=BF=BD wrote: > O. Hartmann wrote: >> I realise a strange behaviour of several FreeBSD 8.0-STABLE/amd64 boxe= s. >> All boxes have the most recent STABLE. One box is a UP system, two >> others SMP boxes, one with a Q6600 4-core, another XEON with 2x 4-core= s >> (Dell Poweredge III). >> >> Symptome: All boxes have ZFS and UFS2 filesystems. Since two weeks or >> so, sometimes the I/O performance drops massively when doing 'svn >> update', 'make world' or even 'make kernel'. It doesn't matter what >> memory and how many cpu the box has, it get stuck for several seconds >> and freezing. On the UP box, this is sometimes for 10 - 20 seconds. >> A very interesting phenomenon is the massively delayed file writing on= >> ZFS filesystems I realise. Editing a file in 'vi' running on one XTerm= >> and having in another Xterminal my shell for compiling this file, it >> takes sometimes up to 20 seconds to get the file updated after it has >> been written. It's like having an old, slow NFS connection with long >> cache delays. >> These massively delayed file transactions are not necessarely under >> heavy load, sometimes they occur in a relaxed situation. They seem to >> occur much more often on the UP box than on the SMP boxes, but this >> strange phenomenon also occur on the Dell Poweredge II, which has 16GB= >> RAM and summa summarum 16 cores. This phenomenon does occur on ZFS- an= d >> UFS2 filesystems as well. It is hardly reproducable. >> >> Is there any known issue? >> >> Ragrds, >> Oliver > > > The disks involved don't happen to be Western Digital Green Power disks= , > do they? The Intelli-Park function in these disks are wrecking havoc > with I/O in Linux-land at least, causing massive stalls and iowait > through the roof during the 25-30 seconds it takes for the heads to > unload after parking. I have two of these disks sitting on my desk now > collecting dust... > /Morgan > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.or= g" The disks in question are indeed WD on one box, but they are all Caviar=20 Black and they performed well months ago with the very same hardware and = an earlier FreeBSD 8 version. The other boxes in questions do have a set of mixed type, Seagate, WD,=20 Samsung (mostly Samsung F1 types). We do not use 'Green' drives, due to=20 every box acts as a server and we found green-disks, even from WD, too sl= ow. Oliver From owner-freebsd-stable@FreeBSD.ORG Wed Jan 20 00:16: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 A4A3C1065670; Wed, 20 Jan 2010 00:16:43 +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 4B6308FC1C; Wed, 20 Jan 2010 00:16:43 +0000 (UTC) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost1.zedat.fu-berlin.de (Exim 4.69) with esmtp (envelope-from ) id <1NXOFW-0006mw-4d>; Wed, 20 Jan 2010 01:16:42 +0100 Received: from e178038234.adsl.alicedsl.de ([85.178.38.234] helo=thor.walstatt.dyndns.org) by inpost2.zedat.fu-berlin.de (Exim 4.69) with esmtpsa (envelope-from ) id <1NXOFW-0001qD-06>; Wed, 20 Jan 2010 01:16:42 +0100 Message-ID: <4B564B69.6080102@mail.zedat.fu-berlin.de> Date: Wed, 20 Jan 2010 01:16:41 +0100 From: "O. Hartmann" User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.1.5) Gecko/20091219 Thunderbird/3.0 MIME-Version: 1.0 To: krad References: <4B54C100.9080906@mail.zedat.fu-berlin.de> <4B54C5EE.5070305@pp.dyndns.biz> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Originating-IP: 85.178.38.234 Cc: =?UTF-8?B?TW9yZ2FuIFdlc3N0csO2bQ==?= , FreeBSD Stable , freebsd-questions@freebsd.org Subject: Re: immense delayed write to file system (ZFS and UFS2), performance issues X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 20 Jan 2010 00:16:43 -0000 On 01/19/10 10:09, krad wrote: > 2010/1/18 Morgan Wesstr=EF=BF=BDm > >> O. Hartmann wrote: >>> I realise a strange behaviour of several FreeBSD 8.0-STABLE/amd64 box= es. >>> All boxes have the most recent STABLE. One box is a UP system, two >>> others SMP boxes, one with a Q6600 4-core, another XEON with 2x 4-cor= es >>> (Dell Poweredge III). >>> >>> Symptome: All boxes have ZFS and UFS2 filesystems. Since two weeks or= >>> so, sometimes the I/O performance drops massively when doing 'svn >>> update', 'make world' or even 'make kernel'. It doesn't matter what >>> memory and how many cpu the box has, it get stuck for several seconds= >>> and freezing. On the UP box, this is sometimes for 10 - 20 seconds. >>> A very interesting phenomenon is the massively delayed file writing o= n >>> ZFS filesystems I realise. Editing a file in 'vi' running on one XTer= m >>> and having in another Xterminal my shell for compiling this file, it >>> takes sometimes up to 20 seconds to get the file updated after it has= >>> been written. It's like having an old, slow NFS connection with long >>> cache delays. >>> These massively delayed file transactions are not necessarely under >>> heavy load, sometimes they occur in a relaxed situation. They seem to= >>> occur much more often on the UP box than on the SMP boxes, but this >>> strange phenomenon also occur on the Dell Poweredge II, which has 16G= B >>> RAM and summa summarum 16 cores. This phenomenon does occur on ZFS- a= nd >>> UFS2 filesystems as well. It is hardly reproducable. >>> >>> Is there any known issue? >>> >>> Ragrds, >>> Oliver >> >> >> The disks involved don't happen to be Western Digital Green Power disk= s, >> do they? The Intelli-Park function in these disks are wrecking havoc >> with I/O in Linux-land at least, causing massive stalls and iowait >> through the roof during the 25-30 seconds it takes for the heads to >> unload after parking. I have two of these disks sitting on my desk now= >> collecting dust... >> /Morgan >> _______________________________________________ >> freebsd-questions@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-questions >> To unsubscribe, send any mail to " >> freebsd-questions-unsubscribe@freebsd.org" >> > > > ZFS is copy on write, therefore to optimize the write performance it de= lays > writes for a long as possible, upto a set maximum time. It will then fl= ush > to the disks. How long this time is depends on how much free ram you ha= ve > available. Assuming processes are eating up all your ram I would imagin= e you > are hitting the max limit. I'm not sure exactly what its set to on bsd = but I > know the default on opensolaris is 30s. I think this explains your dela= yed > writes. > > Not sure what will cause the lock ups though. > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.or= g" This could end in a bad situation, where one process writes a files, say = with some arbitrary stuff and another successing process is intended to=20 read this file. even if the processes are run serial, those 'delays'=20 could break the chain! The delay situation in a development environment=20 is harsh, but in other circumstances it could develop very bad. I see this strange behaviour now for several weeks, something essential=20 has changed in the code, I guess. On UP boxes the situation is worse sometimes, on SMp boxes with lots of=20 RAM ( 8 and 16 GB and 4 or 8 CPU cores) it is still bad. I have a server = that acts as a 'rsync' backup system gathering data from satellite=20 servers from time to time. Since this problem of slowness occured, this=20 4-core 8 gig RAM box crawls for minutes. Even when X11 is disabled=20 working on console is 'bumpy': terminal out slows down, mouse pointer=20 jumps etc.As I wrote, the same on a 8 core/16 gig box, but not that harsh= =2E From owner-freebsd-stable@FreeBSD.ORG Wed Jan 20 01:24:08 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 9BF31106566C for ; Wed, 20 Jan 2010 01:24:08 +0000 (UTC) (envelope-from wsk@gddsn.org.cn) Received: from gddsn.org.cn (gddsn.org.cn [218.19.164.145]) by mx1.freebsd.org (Postfix) with ESMTP id 44F418FC18 for ; Wed, 20 Jan 2010 01:24:06 +0000 (UTC) Received: from lp.gddsn.org.cn (unknown [10.44.8.159]) (Authenticated sender: wsk) by gddsn.org.cn (Postfix) with ESMTPA id C7D092E03E; Wed, 20 Jan 2010 08:18:45 +0800 (CST) Message-ID: <4B565B37.2000008@gddsn.org.cn> Date: Wed, 20 Jan 2010 09:24:07 +0800 From: wsk User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; zh-CN; rv:1.9.1.5) Gecko/20100116 Thunderbird/3.0 MIME-Version: 1.0 To: Steven Friedrich References: <4B5546B0.1050102@gddsn.org.cn> <201001191357.33267.freebsd@insightbb.com> In-Reply-To: <201001191357.33267.freebsd@insightbb.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: freebsd-net@freebsd.org, stable@freebsd.org Subject: Re: 8.0 stable if_bwi kmod not exist? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 20 Jan 2010 01:24:08 -0000 于 2010/01/20 02:57, Steven Friedrich 写道: > On Tuesday 19 January 2010 12:44:16 am wsk wrote: > >> folks, >> There is not exist if_bwi.ko module in /boot/kernel under 8.0 Stable >> why? _______________________________________________ >> freebsd-net@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-net >> To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" >> >> > Perhaps in /etc/make.conf, you define modules you want to build and this is a > new one to be added? > > Look at variables MODULES_OVERRIDE and WITHOUT_MODULES. > > but not any define in my make.conf. it is bizarre # added by use.perl 2010-01-18 15:02:07 PERL_VERSION=5.8.9 From owner-freebsd-stable@FreeBSD.ORG Wed Jan 20 01:32:02 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 A2D31106566B for ; Wed, 20 Jan 2010 01:32:02 +0000 (UTC) (envelope-from yuri.pankov@gmail.com) Received: from mail-fx0-f227.google.com (mail-fx0-f227.google.com [209.85.220.227]) by mx1.freebsd.org (Postfix) with ESMTP id 06F698FC16 for ; Wed, 20 Jan 2010 01:32:00 +0000 (UTC) Received: by fxm27 with SMTP id 27so4114445fxm.3 for ; Tue, 19 Jan 2010 17:32:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:received :x-authentication-warning:date:from:to:cc:subject:message-id :references:mime-version:content-type:content-disposition :in-reply-to:user-agent; bh=IucJ4bnbmFmHd3jFs0AsLqZuKmC8vnsjLyelupNQIdI=; b=ghVyUVEQj+W2R8ql2+Tt5JPo4+Gunzgm9pJIjkqB1ak8kwWyGITFYH03Usebu6QVXd hy+tnm+SMuZfpwKATorqhEaSyIXh8xJvJACwcY150IIhvIDFf+xBb6OSKRCu049PonTp MWTyzsAfrqmpf3u4++lgcqPWUuD76cYD4rcYM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=x-authentication-warning:date:from:to:cc:subject:message-id :references:mime-version:content-type:content-disposition :in-reply-to:user-agent; b=uJJ8rFDd2o+HHsFo/ICWo1FTKTXO4eSvzqCPnZYfMcS1iIWbsyf1X+JS3vodtNyrtY /WW2IF6dmhmxrndXpqL8+OX6uPecdbeQg2GCe1Uf8UMqxoYgWUN+8k5xsDGTCvUgES+K +mwjcVKdGq+Q2yQbPYkZ+gXMoX2HuuC+Ic4XM= Received: by 10.87.67.28 with SMTP id u28mr8143258fgk.38.1263951120110; Tue, 19 Jan 2010 17:32:00 -0800 (PST) Received: from darklight.org.ru ([213.132.76.16]) by mx.google.com with ESMTPS id e20sm14454834fga.2.2010.01.19.17.31.59 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 19 Jan 2010 17:31:59 -0800 (PST) Received: from darklight.org.ru (yuri@darklight.org.ru [127.0.0.1]) by darklight.org.ru (8.14.3/8.14.3) with ESMTP id o0K1Vvh0046465; Wed, 20 Jan 2010 04:31:57 +0300 (MSK) (envelope-from yuri.pankov@gmail.com) Received: (from yuri@localhost) by darklight.org.ru (8.14.3/8.14.3/Submit) id o0K1VutZ046464; Wed, 20 Jan 2010 04:31:56 +0300 (MSK) (envelope-from yuri.pankov@gmail.com) X-Authentication-Warning: darklight.org.ru: yuri set sender to yuri.pankov@gmail.com using -f Date: Wed, 20 Jan 2010 04:31:56 +0300 From: Yuri Pankov To: wsk Message-ID: <20100120013156.GA1767@darklight.org.ru> References: <4B5546B0.1050102@gddsn.org.cn> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4B5546B0.1050102@gddsn.org.cn> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: stable@freebsd.org, net@freebsd.org Subject: Re: 8.0 stable if_bwi kmod not exist? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 20 Jan 2010 01:32:02 -0000 On Tue, Jan 19, 2010 at 01:44:16PM +0800, wsk wrote: > folks, > There is not exist if_bwi.ko module in /boot/kernel under 8.0 Stable why? Looks like it wasn't hooked up to the build for some reason, no bwi here: http://svn.freebsd.org/viewvc/base/stable/8/sys/modules/Makefile?revision=202410&view=markup HTH, Yuri From owner-freebsd-stable@FreeBSD.ORG Wed Jan 20 01:55: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 407FD106568F for ; Wed, 20 Jan 2010 01:55:07 +0000 (UTC) (envelope-from mloftis@wgops.com) Received: from juggler.wgops.com (juggler.wgops.com [204.11.247.41]) by mx1.freebsd.org (Postfix) with ESMTP id 0BDED8FC13 for ; Wed, 20 Jan 2010 01:55:06 +0000 (UTC) Received: by juggler.wgops.com (Postfix, from userid 65534) id 0CA4EA80C9; Tue, 19 Jan 2010 18:55:05 -0700 (MST) X-Spam-ASN: X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on juggler.wgops.com X-Spam-Level: X-Spam-Status: No, score=-1.3 required=5.0 tests=ALL_TRUSTED, SARE_SUB_OBFU_OTHER autolearn=no version=3.2.5 Received: from [192.168.1.44] (host-72-174-39-176.msl-mt.client.bresnan.net [72.174.39.176]) by juggler.wgops.com (Postfix) with ESMTPSA id C8E98A80B9 for ; Tue, 19 Jan 2010 18:55:03 -0700 (MST) Date: Tue, 19 Jan 2010 18:55:05 -0700 From: Michael Loftis To: FreeBSD Stable Message-ID: <812617E02A50CDE76BFBB81A@[192.168.1.44]> In-Reply-To: <4B564B69.6080102@mail.zedat.fu-berlin.de> References: <4B54C100.9080906@mail.zedat.fu-berlin.de> <4B54C5EE.5070305@pp.dyndns.biz> <4B564B69.6080102@mail.zedat.fu-berlin.de> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Virus-Scanned: clamav-milter 0.95.3 at juggler X-Virus-Status: Clean Subject: Re: immense delayed write to file system (ZFS and UFS2), performance issues X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 20 Jan 2010 01:55:07 -0000 --On Wednesday, January 20, 2010 1:16 AM +0100 "O. Hartmann" wrote: > This could end in a bad situation, where one process writes a files, say > with some arbitrary stuff and another successing process is intended to > read this file. even if the processes are run serial, those 'delays' > could break the chain! The delay situation in a development environment > is harsh, but in other circumstances it could develop very bad. The read occurs from the write cache. Thus the reader would see the writers data (given the usual POSIX semantics). ZFS delayed writes are handled by the cache/ZIL layers, reads and writes go through these layers. The ZIL is normally written very quickly. ZFS actually (through the ZIL) has better journalling and recovery semantics than most journalling filesystems. > > I see this strange behaviour now for several weeks, something essential > has changed in the code, I guess. > On UP boxes the situation is worse sometimes, on SMp boxes with lots of > RAM ( 8 and 16 GB and 4 or 8 CPU cores) it is still bad. I have a server > that acts as a 'rsync' backup system gathering data from satellite > servers from time to time. Since this problem of slowness occured, this > 4-core 8 gig RAM box crawls for minutes. Even when X11 is disabled > working on console is 'bumpy': terminal out slows down, mouse pointer > jumps etc.As I wrote, the same on a 8 core/16 gig box, but not that harsh. > > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" From owner-freebsd-stable@FreeBSD.ORG Wed Jan 20 04:03: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 15FB0106566C for ; Wed, 20 Jan 2010 04:03:03 +0000 (UTC) (envelope-from mandrews@bit0.com) Received: from magnum.bit0.com (magnum.bit0.com [207.246.88.226]) by mx1.freebsd.org (Postfix) with ESMTP id E09568FC13 for ; Wed, 20 Jan 2010 04:03:02 +0000 (UTC) Received: from millenniumforce.int.bit0.com (nat.bit0.com [207.246.88.210]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by magnum.bit0.com (Postfix) with ESMTPSA id E59D8E0D2 for ; Tue, 19 Jan 2010 23:03:01 -0500 (EST) Message-ID: <4B568074.4020909@bit0.com> Date: Tue, 19 Jan 2010 23:03:00 -0500 From: Mike Andrews User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.5) Gecko/20091204 Thunderbird/3.0 MIME-Version: 1.0 To: freebsd-stable@freebsd.org References: <4B55FF44.4040308@icyb.net.ua> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: 8.0-RELEASE / gpart / GPT / marking a partition as "active" X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 20 Jan 2010 04:03:03 -0000 On 1/19/10 4:09 PM, Dan Naumov wrote: > On 1/19/2010 12:11 PM, Dan Naumov wrote: >> It seems that quite a few BIOSes have serious issues booting off disks >> using GPT partitioning when no partition present is marked as >> "active". See http://www.freebsd.org/cgi/query-pr.cgi?pr=115406&cat=bin >> for a prime example. >> >> In 8.0-RELEASE, using gpart, setting a slice as "active" in MBR >> partitioning mode is trivial, ie: >> >> gpart set -a active -i 1 DISKNAME >> >> However, trying to do the same thing with GPT partitioning yields no results: >> >> gpart set -a active -i 1 DISKNAME >> gpart: attrib 'active': Device not configured >> >> As a result of this issue, I can configure and make a succesfull >> install using GPT in 8.0, but I cannot boot off it using my Intel >> D945GCLF2 board. >> >> I have found this discussion from about a month ago: >> http://www.mail-archive.com/freebsd-stable@freebsd.org/msg106918.html >> where Robert mentions that "gpart set -a active -i 1" is no longer >> needed in 8-STABLE, because the pmbr will be marked as active during >> the installation of the bootcode. Is there anything I can do to >> archieve the same result in 8.0-RELEASE or is installing from a >> snapshop of 8-STABLE my only option? > >> After using gpart to create the GPT (and thus the PMBR and its >> bootcode), why not simply use "fdisk -a -1 DISKNAME" to set the PMBR >> partition active? > > According to the fdisk output, the partition flag did change from 0 to > 80. Can the "fdisk: Class not found" error showing up at the very end > of the procedure of doing "fdisk -a -1 DISKNAME" be safely ignored? Yes, just ignore it. From owner-freebsd-stable@FreeBSD.ORG Wed Jan 20 06:46: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 1A206106566B; Wed, 20 Jan 2010 06:46:51 +0000 (UTC) (envelope-from dnaeon@gmail.com) Received: from mail-ew0-f213.google.com (mail-ew0-f213.google.com [209.85.219.213]) by mx1.freebsd.org (Postfix) with ESMTP id 7263D8FC20; Wed, 20 Jan 2010 06:46:50 +0000 (UTC) Received: by ewy5 with SMTP id 5so5489098ewy.14 for ; Tue, 19 Jan 2010 22:46:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=TXYTK+Sah6uKQ2SMN2ErEUU/vZnbdLvRfAcdcJP6eak=; b=UO9i1j3E87Bd8+zdt3fLeG8e5AYFLYPV0B70zLPvSdOrAHAtrC0PNUOVEmxq7fURqI qEwU5af4jHNgd+TKyYcebn/CbCaWwAHYVbuX27+ZnyK7zkcHVaKM6kYf2HsSDQjgSTus PGmBSR613DaU9MeEobmJosvkx+JRbPjM9KEP4= 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=voL83u5C74hIveS6Uv/cLrzG+eZJtl3nXo6k4OctDRalo4oKe36n6+71nVZbbZkfTR 5WD+IKixBwDmH2sfVL0WL1LX1T5vzA1+96TGOvpUQoGDNS3st3TM8JPZ9D8ATLYf1I3u C+AG4nms6ZY63G69q31nsnAwjVmffoOfI2FG0= MIME-Version: 1.0 Received: by 10.216.88.206 with SMTP id a56mr1119196wef.64.1263970008836; Tue, 19 Jan 2010 22:46:48 -0800 (PST) In-Reply-To: References: <717f7a3e1001120714m37aada69gfaa35f0f9b17f435@mail.gmail.com> <44678539@bb.ipt.ru> <717f7a3e1001142234y1de7ae15x6853e3ddcab4add9@mail.gmail.com> Date: Wed, 20 Jan 2010 08:46:48 +0200 Message-ID: <717f7a3e1001192246o4dce4a82q57c05ff3f41b5feb@mail.gmail.com> From: Marin Atanasov To: Ronald Klop Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-stable@freebsd.org, freebsd-hardware@freebsd.org Subject: Re: Multiple serial consoles via null modem cable X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 20 Jan 2010 06:46:51 -0000 Hello, Using `cu' only works with COM1 for me. Currently I have two serial ports on the system, and only the first is able to make the connection - the serial consoles are enabled in /etc/tty, but as I said only COM1 is able to make the connection. Regards, Marin On Sun, Jan 17, 2010 at 3:32 PM, Ronald Klop wrote: > On Fri, 15 Jan 2010 07:34:17 +0100, Marin Atanasov > wrote: > > Thank you a lot for your feedback! >> >> Now to the real question again, because I'm a little confused now - can I >> still get a usb-to-serial port converter having let's say 8 serial ports >> and >> then connect each machine to the usb-to-serial hub and manage them >> remotely >> from a single location (the host having the usb-to-serial hub)? That way I >> just specify a serial port number and I get to a specific machine? >> >> The model provided by Boris looks nice, and that was my initial idea, but >> I'm not sure if I could get it working under FreeBSD. Is conserver or >> conserver-com able to handle this? I know that cu uses COM1 only, but will >> conserver able to handle serial consoles on different ports, since the >> usb-to-serial port would appear as multiple serial ports. >> > > You can provide cu with the port to connect to on the command line. > > cu -l cuaU0 -s 115200 > cu -l cuaU1 -s 115200 > etc. > > You can not connect several servers on 1 serial port, but you can connect > several servers on several serial ports. With serial-over-usb it scales to > many serial ports. > > Ronald. > > > > >> Thank you and regards, >> Marin >> >> >> On Tue, Jan 12, 2010 at 7:04 PM, Boris Samorodov wrote: >> >> On Tue, 12 Jan 2010 17:14:44 +0200 Marin Atanasov wrote: >>> >>> > I'm thinking about the following situation - 1 system acting like a >>> host >>> > with a serial port hub, each port of the hub is connected to a >>> different >>> > machine on sio0, using null modem cables. >>> >>> Along with milti-io serial cards we use multi-usb serial >>> converters, such as SUNIX UTS7009P (7 USB to serial adapter): >>> http://www.sunix.com.tw/it/en/LinkCraft/UTS4009P_UTS7009P.htm >>> >>> -- >>> WBR, Boris Samorodov (bsam) >>> Research Engineer, http://www.ipt.ru Telephone & Internet SP >>> FreeBSD Committer, http://www.FreeBSD.org The Power To Serve >>> >>> >> >> >> > -- Marin Atanasov Nikolov dnaeon AT gmail DOT com daemon AT unix-heaven DOT org From owner-freebsd-stable@FreeBSD.ORG Wed Jan 20 07:21: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 451531065670 for ; Wed, 20 Jan 2010 07:21:28 +0000 (UTC) (envelope-from h.schmalzbauer@omnilan.de) Received: from host.omnilan.net (host.omnilan.net [62.245.232.135]) by mx1.freebsd.org (Postfix) with ESMTP id 6A2B38FC08 for ; Wed, 20 Jan 2010 07:21:27 +0000 (UTC) Received: from titan.flintsbach.schmalzbauer.de (titan.flintsbach.schmalzbauer.de [172.21.1.150]) (authenticated bits=0) by host.omnilan.net (8.13.8/8.13.8) with ESMTP id o0K76UO0040678 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 20 Jan 2010 08:06:34 +0100 (CET) (envelope-from h.schmalzbauer@omnilan.de) Message-ID: <4B56AB6F.9010303@omnilan.de> Date: Wed, 20 Jan 2010 08:06:23 +0100 From: Harald Schmalzbauer Organization: OmniLAN User-Agent: Thunderbird 2.0.0.23 (X11/20090906) MIME-Version: 1.0 To: freebsd-stable@freebsd.org X-Enigmail-Version: 0.95.6 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig705489DEF1C49240110282E5" Subject: top Segmentation faulting on 8.0p2 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: Wed, 20 Jan 2010 07:21:28 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig705489DEF1C49240110282E5 Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: quoted-printable Dear all, I have no idea why top crashes with segmentation fault on my amd64=20 machine running FreeBSD 8.0-RELEASE-p2. If someone wants to have a loot at the core dump:=20 http://www.schmalzbauer.de/downloads/top.core But I think I should recompile it with DEBUG=3D-g first, right? World and kernel are in sync, I ran an extra build to make that sure. My kernconf follows. Any help appreciated. Thanks, FreeBSD qaweb.hn.sand.spsnetz.de 8.0-RELEASE-p2 FreeBSD 8.0-RELEASE-p2=20 #0: Tue Jan 19 22:00:17 CET 2010=20 admin@qaweb.hn.sand.spsnetz.de:/usr/obj/usr/src/sys/FJS-RX100S3 amd64 include GENERIC makeoptions none nooptions COMPAT_FREEBSD4 # Compatible with FreeBSD4 nooptions COMPAT_FREEBSD5 # Compatible with FreeBSD5 # Floppy drives nodevice fdc # ATA and ATAPI devices #device ata #device atadisk # ATA disk drives nodevice ataraid # ATA RAID drives #device atapicd # ATAPI CDROM drives nodevice atapifd # ATAPI floppy drives nodevice atapist # ATAPI tape drives #options ATA_STATIC_ID # Static device numbering # SCSI Controllers nodevice ahb # EISA AHA1742 family nodevice ahc # AHA2940 and onboard AIC7xxx devices nooptions AHC_REG_PRETTY_PRINT # Print register bitfields in debug # output. Adds ~128k to driver. nodevice ahd # AHA39320/29320 and onboard AIC79xx devices nooptions AHD_REG_PRETTY_PRINT # Print register bitfields in debug # output. Adds ~215k to driver. nodevice amd # AMD 53C974 (Tekram DC-390(T)) nodevice hptiop # Highpoint RocketRaid 3xxx series nodevice isp # Qlogic family ##device ispfw # Firmware for QLogic HBAs- normally a module nodevice mpt # LSI-Logic MPT-Fusion ##device ncr # NCR/Symbios Logic nodevice sym # NCR/Symbios Logic (newer chipsets + those of `ncr') nodevice trm # Tekram DC395U/UW/F DC315U adapters nodevice adv # Advansys SCSI adapters nodevice adw # Advansys wide SCSI adapters nodevice aha # Adaptec 154x SCSI adapters nodevice aic # Adaptec 15[012]x SCSI adapters, AIC-6[23]60. nodevice bt # Buslogic/Mylex MultiMaster SCSI adapters nodevice ncv # NCR 53C500 nodevice nsp # Workbit Ninja SCSI-3 nodevice stg # TMC 18C30/18C50 # SCSI peripherals device scbus # SCSI bus (required for SCSI) device ch # SCSI media changers #device da # Direct Access (disks) #device sa # Sequential Access (tape etc) #device cd # CD #device pass # Passthrough device (direct SCSI access) #device ses # SCSI Environmental Services (and SAF-TE) # RAID controllers interfaced to the SCSI subsystem nodevice amr # AMI MegaRAID nodevice arcmsr # Areca SATA II RAID ##XXX it is not 64-bit clean, -scottl ##device asr # DPT SmartRAID V, VI and Adaptec SCSI RAID nodevice ciss # Compaq Smart RAID 5* nodevice dpt # DPT Smartcache III, IV - See NOTES for options nodevice hptmv # Highpoint RocketRAID 182x nodevice hptrr # Highpoint RocketRAID 17xx, 22xx, 23xx, 25xx nodevice iir # Intel Integrated RAID nodevice ips # IBM (Adaptec) ServeRAID nodevice mly # Mylex AcceleRAID/eXtremeRAID nodevice twa # 3ware 9000 series PATA/SATA RAID # RAID controllers nodevice aac # Adaptec FSA RAID nodevice aacp # SCSI passthrough for aac (requires CAM) nodevice ida # Compaq Smart RAID nodevice mfi # LSI MegaRAID SAS nodevice mlx # Mylex DAC960 family #XXX pointer/int warnings ##device pst # Promise Supertrak SX6000 nodevice twe # 3ware ATA RAID # atkbdc0 controls both the keyboard and the PS/2 mouse #device atkbdc # AT keyboard controller #device atkbd # AT keyboard #device psm # PS/2 mouse nodevice kbdmux # keyboard multiplexer #device vga # VGA video card driver #device splash # Splash screen and screen saver support # syscons is the default console driver, resembling an SCO console #device sc #device agp # support several AGP chipsets # PCCARD (PCMCIA) support # PCMCIA and cardbus bridge support nodevice cbb # cardbus (yenta) bridge nodevice pccard # PC Card (16-bit) bus nodevice cardbus # CardBus (32-bit) bus # Parallel port nodevice ppc nodevice ppbus # Parallel port bus (required) nodevice lpt # Printer nodevice plip # TCP/IP over parallel nodevice ppi # Parallel port interface device ##device vpo # Requires scbus and da # If you've got a "dumb" serial or parallel PCI card that is # supported by the puc(4) glue driver, uncomment the following # line to enable it (connects to sio, uart and/or ppc drivers): #device puc # PCI Ethernet NICs. #device de # DEC/Intel DC21x4x (``Tulip'') #device em # Intel PRO/1000 Gigabit Ethernet Family #device igb # Intel PRO/1000 PCIE Server Gigabit Family #device ixgb # Intel PRO/10GbE Ethernet Card #device le # AMD Am7900 LANCE and Am79C9xx PCnet #device ti # Alteon Networks Tigon I/II gigabit Ethernet #device txp # 3Com 3cR990 (``Typhoon'') #device vx # 3Com 3c590, 3c595 (``Vortex'') # PCI Ethernet NICs that use the common MII bus controller code. # NOTE: Be sure to keep the 'device miibus' line in order to use these NI= Cs! #device miibus # MII bus support nodevice ae # Attansic/Atheros L2 FastEthernet nodevice age # Attansic/Atheros L1 Gigabit Ethernet nodevice alc # Atheros AR8131/AR8132 Ethernet nodevice ale # Atheros AR8121/AR8113/AR8114 Ethernet nodevice bce # Broadcom BCM5706/BCM5708 Gigabit Ethernet nodevice bfe # Broadcom BCM440x 10/100 Ethernet #device bge # Broadcom BCM570xx Gigabit Ethernet nodevice dc # DEC/Intel 21143 and various workalikes nodevice et # Agere ET1310 10/100/Gigabit Ethernet nodevice fxp # Intel EtherExpress PRO/100B (82557, 82558) nodevice jme # JMicron JMC250 Gigabit/JMC260 Fast Ethernet nodevice lge # Level 1 LXT1001 gigabit Ethernet nodevice msk # Marvell/SysKonnect Yukon II Gigabit Ethernet nodevice nfe # nVidia nForce MCP on-board Ethernet nodevice nge # NatSemi DP83820 gigabit Ethernet ##device nve # nVidia nForce MCP on-board Ethernet Networking nodevice pcn # AMD Am79C97x PCI 10/100 (precedence over 'le') nodevice re # RealTek 8139C+/8169/8169S/8110S nodevice rl # RealTek 8129/8139 nodevice sf # Adaptec AIC-6915 (``Starfire'') nodevice sis # Silicon Integrated Systems SiS 900/SiS 7016 nodevice sk # SysKonnect SK-984x & SK-982x gigabit Ethernet nodevice ste # Sundance ST201 (D-Link DFE-550TX) nodevice stge # Sundance/Tamarack TC9021 gigabit Ethernet nodevice tl # Texas Instruments ThunderLAN nodevice tx # SMC EtherPower II (83c170 ``EPIC'') nodevice vge # VIA VT612x gigabit Ethernet nodevice vr # VIA Rhine, Rhine II nodevice wb # Winbond W89C840F nodevice xl # 3Com 3c90x (``Boomerang'', ``Cyclone'') # ISA Ethernet NICs. pccard NICs included. device cs # Crystal Semiconductor CS89x0 NIC # 'device ed' requires 'device miibus' nodevice ed # NE[12]000, SMC Ultra, 3c503, DS8390 cards nodevice ex # Intel EtherExpress Pro/10 and Pro/10+ nodevice ep # Etherlink III based cards nodevice fe # Fujitsu MB8696x based cards nodevice ie # EtherExpress 8/16, 3C507, StarLAN 10 etc. nodevice sn # SMC's 9000 series of Ethernet chips nodevice xe # Xircom pccard Ethernet # Wireless NIC cards nodevice wlan # 802.11 support nooptions IEEE80211_DEBUG # enable debug msgs nooptions IEEE80211_AMPDU_AGE # age frames in AMPDU reorder q's nooptions IEEE80211_SUPPORT_MESH # enable 802.11s draft support nodevice wlan_wep # 802.11 WEP support nodevice wlan_ccmp # 802.11 CCMP support nodevice wlan_tkip # 802.11 TKIP support nodevice wlan_amrr # AMRR transmit rate control algorithm nodevice an # Aironet 4500/4800 802.11 wireless NICs. nodevice ath # Atheros pci/cardbus NIC's nodevice ath_hal # pci/cardbus chip support nooptions AH_SUPPORT_AR5416 # enable AR5416 tx/rx descriptors nodevice ath_rate_sample # SampleRate tx rate control for ath nodevice ral # Ralink Technology RT2500 wireless NICs. nodevice wi # WaveLAN/Intersil/Symbol 802.11 wireless NICs. ##device wl # Older non 802.11 Wavelan wireless NIC. # Pseudo devices. #device loop # Network loopback #device random # Entropy device #device ether # Ethernet support #device tun # Packet tunnel. #device pty # BSD-style compatibility pseudo ttys #device md # Memory "disks" #device gif # IPv6 and IPv4 tunneling #device faith # IPv6-to-IPv4 relaying (translation) #device firmware # firmware assist module # The `bpf' device enables the Berkeley Packet Filter. # Be aware of the administrative consequences of enabling this! # Note that 'bpf' is required for DHCP. #device bpf # Berkeley packet filter # USB support #device uhci # UHCI PCI->USB interface nodevice ohci # OHCI PCI->USB interface #device ehci # EHCI PCI->USB interface (USB 2.0) #device usb # USB Bus (required) ##device udbp # USB Double Bulk Pipe devices #device uhid # "Human Interface Devices" #device ukbd # Keyboard nodevice ulpt # Printer #device umass # Disks/Mass storage - Requires scbus and da #device ums # Mouse nodevice rum # Ralink Technology RT2501USB wireless NICs nodevice ural # Ralink Technology RT2500USB wireless NICs nodevice uath # Atheros AR5523 wireless NICs nodevice zyd # ZyDAS zb1211/zb1211b wireless NICs nodevice urio # Diamond Rio 500 MP3 player # USB Serial devices #device u3g # USB-based 3G modems (Option, Huawei, Sierra) #device uark # Technologies ARK3116 based serial adapters #device ubsa # Belkin F5U103 and compatible serial adapters #device uftdi # For FTDI usb serial adapters #device uipaq # Some WinCE based devices #device uplcom # Prolific PL-2303 serial adapters #device uslcom # SI Labs CP2101/CP2102 serial adapters #device uvisor # Visor and Palm devices #device uvscom # USB serial support for DDI pocket's PHS # USB Ethernet, requires miibus nodevice aue # ADMtek USB Ethernet nodevice axe # ASIX Electronics USB Ethernet nodevice cdce # Generic USB over Ethernet nodevice cue # CATC USB Ethernet nodevice kue # Kawasaki LSI USB Ethernet nodevice rue # RealTek RTL8150 USB Ethernet nodevice udav # Davicom DM9601E USB # FireWire support nodevice firewire # FireWire bus code nodevice sbp # SCSI over FireWire (Requires scbus and da) nodevice fwe # Ethernet over FireWire (non-standard!) nodevice fwip # IP over FireWire (RFC 2734,3146) nodevice dcons # Dumb console driver nodevice dcons_crom # Configuration ROM for dcons ############## ### Extras ### ############## ident FJS-RX100S3 device ahci device smbus # Bus support, required for smb below. device smb device ichsmb #device coretemp device ichwd options ZERO_COPY_SOCKETS options GEOM_MIRROR options GEOM_JOURNAL options MAXCONS=3D12 options SC_HISTORY_SIZE=3D2000 options SC_PIXEL_MODE options SC_DFLT_FONT makeoptions SC_DFLT_FONT=3Diso15 options ATKBD_DFLT_KEYMAP makeoptions ATKBD_DFLT_KEYMAP=3Dgerman.iso options UKBD_DFLT_KEYMAP makeoptions UKBD_DFLT_KEYMAP=3Dgerman.iso --------------enig705489DEF1C49240110282E5 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.13 (FreeBSD) iEYEARECAAYFAktWq3YACgkQLDqVQ9VXb8gzjwCcC3wKNOBbH7IMq+fKNPjx9FrY uLEAnjdEJHmiu1jbhvUurDSSXhXf+UMp =BbRH -----END PGP SIGNATURE----- --------------enig705489DEF1C49240110282E5-- From owner-freebsd-stable@FreeBSD.ORG Wed Jan 20 07:29: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 BE29C106566B; Wed, 20 Jan 2010 07:29:30 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-fx0-f227.google.com (mail-fx0-f227.google.com [209.85.220.227]) by mx1.freebsd.org (Postfix) with ESMTP id 1E2EB8FC17; Wed, 20 Jan 2010 07:29:29 +0000 (UTC) Received: by fxm27 with SMTP id 27so4262784fxm.3 for ; Tue, 19 Jan 2010 23:29:29 -0800 (PST) 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 :user-agent:mime-version:to:cc:subject:references:in-reply-to :x-enigmail-version:content-type:content-transfer-encoding; bh=JOfDSkhhB5roFhqWDu9cB8XzbbKalwDJiIKcpNdr9k4=; b=dKerXfj0GuiFCDDwh+LQx6MeDG7QUFmDSzQ7AJ2L/5F4vTbkDhaDj9XTa1nxlNGZ+a Jeh5/9BIqG2xaBConAgVHKRYbddogXfjgxFMQfQUlxpWZXfVsnYhO+0pMFHZVvTxI+Ib 8BcZ8zEuKBl4T8z8T2rsJVrnHzVvm6pUFq3/E= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; b=Oj3FsakP6fU5vxUSwn+X5BWV8/MgBQwUVbrqj41PN/0L94V53WMG88xY4BgftR+Os/ IKqvjxk7yWDoxtJ0Ga6eFeI2DPTFX43yPqHv4xq6No8fJnxbiVXW9pJT/XBOoWp158/r Y7Dy3br7WzeGFQDDqh3ObfQmrN3iqvHB5QLBc= Received: by 10.223.68.155 with SMTP id v27mr7514453fai.10.1263972568709; Tue, 19 Jan 2010 23:29:28 -0800 (PST) Received: from mavbook.mavhome.dp.ua (pc.mavhome.dp.ua [212.86.226.226]) by mx.google.com with ESMTPS id 13sm3492966fxm.1.2010.01.19.23.29.27 (version=SSLv3 cipher=RC4-MD5); Tue, 19 Jan 2010 23:29:28 -0800 (PST) Sender: Alexander Motin Message-ID: <4B56B0D6.1000402@FreeBSD.org> Date: Wed, 20 Jan 2010 09:29:26 +0200 From: Alexander Motin User-Agent: Thunderbird 2.0.0.23 (X11/20091212) MIME-Version: 1.0 To: Scott Long References: <4B55D9D4.1000008@FreeBSD.org> <823F6536-32A7-4BC6-9C6A-C84865A38458@samsco.org> In-Reply-To: <823F6536-32A7-4BC6-9C6A-C84865A38458@samsco.org> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: FreeBSD-Current , FreeBSD Stable Subject: Re: Pack of CAM improvements X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 20 Jan 2010 07:29:30 -0000 Scott Long wrote: > On Jan 19, 2010, at 9:12 AM, Alexander Motin wrote: >> I've made a patch, that should solve set of problems of CAM ATA and CAM >> generally. I would like to ask for testing and feedback. >> >> What patch does: >> - It unifies bus reset/probe sequence. Whenever bus attached at boot or >> later, CAM will automatically reset and scan it. It allows to remove >> duplicate code from many drivers. >> - Any bus, attached before CAM completed it's boot-time initialization, >> will equally join to the process, delaying boot if needed. >> - New kern.cam.boot_delay loader tunable should help controllers that >> are still unable to register their buses in time (such as slow USB/ >> PCCard/ CardBus devices). > > I've fought many times against delay values like this. They never work > well enough. Drivers that have delayed scans should set up their own > intrhook to delay the boot until their scan is done. To help this out, > CAM should move to its own hook that is guaranteed to run after the > normal intrhooks. However, this isn't required. I am sure that using delay is not a perfect solution, but it nicely fits new scanning procedure and costs just a few lines of code. Nobody denies to add _more_ events to wait there. This is just a band-aid for cases when nothing else helps. May be I am mixing something, but AFAIR there were some USB devices, which doesn't appear on a first bus scan, but register later. > Here's my alternate proposal: > > - move xpt_config() execution to a new config hook that runs after the > normal intrhooks. To make scanning work in background, it is better to call xpt_config() same as now, as early as possible, to start scanning for already registered buses, but call xpt_release_boot() on some later event (or even several different events). > - For self identifying buses (i.e. anything where device presence is > known to the controller), have the SIM notify CAM of each target device, > instead of assuming that CAM will scan for it. Nobody denies your driver to call xpt_rescan on per-known-device basis. In such case CAM will still wait until all of your scan requests will be fulfilled. You may see it is already done by some SIMs and PMP driver. If you need a way to avoid full scan, it also can be done, while it is separate question. > - Teach USB and whatnot to use a confighook to drive their discovery, > instead of estimated timeouts. > > I'm doing exactly this for the new MPT2SAS driver. -- Alexander Motin From owner-freebsd-stable@FreeBSD.ORG Wed Jan 20 07:46: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 090CC106568B for ; Wed, 20 Jan 2010 07:46:17 +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 A2B958FC0C for ; Wed, 20 Jan 2010 07:46:16 +0000 (UTC) Received: from omta11.westchester.pa.mail.comcast.net ([76.96.62.36]) by QMTA11.westchester.pa.mail.comcast.net with comcast id Xjm31d0040mv7h05BjmGn8; Wed, 20 Jan 2010 07:46:16 +0000 Received: from koitsu.dyndns.org ([98.248.46.159]) by omta11.westchester.pa.mail.comcast.net with comcast id XjmD1d0013S48mS3XjmDps; Wed, 20 Jan 2010 07:46:16 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id ED1FF1E3033; Tue, 19 Jan 2010 23:46:11 -0800 (PST) Date: Tue, 19 Jan 2010 23:46:11 -0800 From: Jeremy Chadwick To: Marin Atanasov Message-ID: <20100120074611.GA405@icarus.home.lan> References: <717f7a3e1001120714m37aada69gfaa35f0f9b17f435@mail.gmail.com> <44678539@bb.ipt.ru> <717f7a3e1001142234y1de7ae15x6853e3ddcab4add9@mail.gmail.com> <717f7a3e1001192246o4dce4a82q57c05ff3f41b5feb@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <717f7a3e1001192246o4dce4a82q57c05ff3f41b5feb@mail.gmail.com> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: freebsd-hardware@freebsd.org, freebsd-stable@freebsd.org, Ronald Klop Subject: Re: Multiple serial consoles via null modem cable X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 20 Jan 2010 07:46:17 -0000 On Wed, Jan 20, 2010 at 08:46:48AM +0200, Marin Atanasov wrote: > Hello, > > Using `cu' only works with COM1 for me. > > Currently I have two serial ports on the system, and only the first is able > to make the connection - the serial consoles are enabled in /etc/tty, but as > I said only COM1 is able to make the connection. I'm a little confused by this statement, so I'll add some clarify: /etc/ttys is for configuring a machine to tie getty (think login prompt) to a device (in this case, a serial port). Meaning: the device on the other end of the serial cable will start seeing "login:" and so on assuming you attach to the serial port there. For example: box1 COM1/ttyu0 is wired to box2 COM3/ttyu2 using a null modem cable. box1 COM2/ttyu1 is wired to box2 COM4/ttyu3 using a null modem cable. On box1, you'd have something like this in /etc/ttys: ttyu0 "/usr/libexec/getty std.9600" vt100 on secure ttyu1 "/usr/libexec/getty std.9600" vt100 on secure This means that login prompts for box1 will be spawned/available on both serial ports (ttyu0 and ttyu1). If you get on box2 and do "cu -l ttyu2", this will connect you to box2's COM3 port, which is physically connected to box1's COM1 port. Hit enter and you should see a login: prompt for box1. The same applies if you get on box2 and do "cu -l ttyu3" (but for box2's COM4 port, which is wired to box1's COM2 port). With the above configuration in mind, you SHOULD NOT: - Mess with /etc/ttys on box2 - Execute "cu -l ttyu0" or "cu -l ttyu1" on box1 -- this probably won't work (likely will return some message about the device being locked or in use already). You cannot do something like where box1 COM1 is wired to box2 COM1, and depending on what box you're on doing the "cu -l ttyu0" from, get a login prompt on the other. It doesn't work like that. :-) Now, about actual *serial console* itself -- that is to say, kernel output during boot, etc... on a serial port. AFAIK, on FreeBSD you can only set serial console to a single serial port, and that defaults to COM1/ttyu0. You can change what port/device, but there can only be one. HTH... > On Sun, Jan 17, 2010 at 3:32 PM, Ronald Klop wrote: > > > On Fri, 15 Jan 2010 07:34:17 +0100, Marin Atanasov > > wrote: > > > > Thank you a lot for your feedback! > >> > >> Now to the real question again, because I'm a little confused now - can I > >> still get a usb-to-serial port converter having let's say 8 serial ports > >> and > >> then connect each machine to the usb-to-serial hub and manage them > >> remotely > >> from a single location (the host having the usb-to-serial hub)? That way I > >> just specify a serial port number and I get to a specific machine? > >> > >> The model provided by Boris looks nice, and that was my initial idea, but > >> I'm not sure if I could get it working under FreeBSD. Is conserver or > >> conserver-com able to handle this? I know that cu uses COM1 only, but will > >> conserver able to handle serial consoles on different ports, since the > >> usb-to-serial port would appear as multiple serial ports. > >> > > > > You can provide cu with the port to connect to on the command line. > > > > cu -l cuaU0 -s 115200 > > cu -l cuaU1 -s 115200 > > etc. > > > > You can not connect several servers on 1 serial port, but you can connect > > several servers on several serial ports. With serial-over-usb it scales to > > many serial ports. > > > > Ronald. > > > > > >> Thank you and regards, > >> Marin > >> > >> > >> On Tue, Jan 12, 2010 at 7:04 PM, Boris Samorodov wrote: > >> > >> On Tue, 12 Jan 2010 17:14:44 +0200 Marin Atanasov wrote: > >>> > >>> > I'm thinking about the following situation - 1 system acting like a > >>> host > >>> > with a serial port hub, each port of the hub is connected to a > >>> different > >>> > machine on sio0, using null modem cables. > >>> > >>> Along with milti-io serial cards we use multi-usb serial > >>> converters, such as SUNIX UTS7009P (7 USB to serial adapter): > >>> http://www.sunix.com.tw/it/en/LinkCraft/UTS4009P_UTS7009P.htm -- | 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 Jan 20 11:46: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 D2B011065679; Wed, 20 Jan 2010 11:46:01 +0000 (UTC) (envelope-from rnoland@FreeBSD.org) Received: from gizmo.2hip.net (gizmo.2hip.net [64.74.207.195]) by mx1.freebsd.org (Postfix) with ESMTP id 80FF78FC27; Wed, 20 Jan 2010 11:46:01 +0000 (UTC) Received: from [192.168.1.4] (adsl-1-207-120.bna.bellsouth.net [65.1.207.120]) (authenticated bits=0) by gizmo.2hip.net (8.14.3/8.14.3) with ESMTP id o0KBjwkL034427 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Wed, 20 Jan 2010 06:45:59 -0500 (EST) (envelope-from rnoland@FreeBSD.org) From: Robert Noland To: Dan Naumov In-Reply-To: References: Content-Type: text/plain Organization: FreeBSD Date: Wed, 20 Jan 2010 05:45:53 -0600 Message-Id: <1263987953.48755.4.camel@balrog.2hip.net> Mime-Version: 1.0 X-Mailer: Evolution 2.26.3 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=0.3 required=5.0 tests=AWL, BAYES_00, FH_DATE_PAST_20XX, RCVD_IN_PBL, RCVD_IN_SORBS_DUL, RDNS_DYNAMIC, SPF_SOFTFAIL, SUBJECT_FUZZY_TION autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on gizmo.2hip.net Cc: FreeBSD-STABLE Mailing List , freebsd-questions@freebsd.org, freebsd-geom@freebsd.org Subject: Re: 8.0-RELEASE / gpart / GPT / marking a partition as "active" X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 20 Jan 2010 11:46:01 -0000 On Tue, 2010-01-19 at 19:11 +0200, Dan Naumov wrote: > It seems that quite a few BIOSes have serious issues booting off disks > using GPT partitioning when no partition present is marked as > "active". See http://www.freebsd.org/cgi/query-pr.cgi?pr=115406&cat=bin > for a prime example. > > In 8.0-RELEASE, using gpart, setting a slice as "active" in MBR > partitioning mode is trivial, ie: > > gpart set -a active -i 1 DISKNAME > > However, trying to do the same thing with GPT partitioning yields no results: > > gpart set -a active -i 1 DISKNAME > gpart: attrib 'active': Device not configured > > As a result of this issue, I can configure and make a succesfull > install using GPT in 8.0, but I cannot boot off it using my Intel > D945GCLF2 board. I have the same board... > I have found this discussion from about a month ago: > http://www.mail-archive.com/freebsd-stable@freebsd.org/msg106918.html > where Robert mentions that "gpart set -a active -i 1" is no longer > needed in 8-STABLE, because the pmbr will be marked as active during > the installation of the bootcode. Is there anything I can do to > archieve the same result in 8.0-RELEASE or is installing from a > snapshop of 8-STABLE my only option? Prior to fixing gpart to take care of this, I used fdisk to set the active partition. gpart knows the disk is GPT and GPT doesn't have an "active" parameter, so the above command doesn't (perhaps never) worked. Basically, an "fdisk -a /dev/devX" is what you want... robert. > Thanks. > > - Sincerely, > Dan Naumov -- Robert Noland FreeBSD From owner-freebsd-stable@FreeBSD.ORG Wed Jan 20 09:31: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 24D9C106566B for ; Wed, 20 Jan 2010 09:31:01 +0000 (UTC) (envelope-from tuxper@mail.ru) Received: from www.saimatelecom.kg (name.saimanet.kg [217.29.16.249]) by mx1.freebsd.org (Postfix) with ESMTP id C12938FC0A for ; Wed, 20 Jan 2010 09:31:00 +0000 (UTC) Received: from 192.168.0.196 (unknown [217.29.21.6]) by www.saimatelecom.kg (Postfix) with ESMTP id 2477818343C for ; Wed, 20 Jan 2010 15:15:54 +0600 (GMT-6) Date: Wed, 20 Jan 2010 15:16:02 +0600 From: "Rabidinov M.A." X-Mailer: The Bat! (v4.0.24) Professional X-Priority: 3 (Normal) Message-ID: <659350866.20100120151602@mail.ru> To: freebsd-stable@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=windows-1251 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Wed, 20 Jan 2010 12:31:42 +0000 Subject: IPSec NAT-T in transport 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: Wed, 20 Jan 2010 09:31:01 -0000 Hello, Freebsd-stable. Does FreeBSD 8.0 support IPSec NAT-T in transport mode? I want to create a L2TP/IPSec server. My VPN clients are NATed. L2TP server (MPD5.x) makes tunnel, so I need working IPSec NAT-T in transpo= rt mode. Thanks a lot. --=20 =D1 =F3=E2=E0=E6=E5=ED=E8=E5=EC, Rabidinov mailto:tuxper@mail.ru From owner-freebsd-stable@FreeBSD.ORG Wed Jan 20 13:22: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 51665106566B for ; Wed, 20 Jan 2010 13:22:45 +0000 (UTC) (envelope-from crest@cyb0rg.org) Received: from cyb0rg.org (tomakin.niobe.h-ix.net [IPv6:2001:6f8:1c12:23::2]) by mx1.freebsd.org (Postfix) with ESMTP id 18A3F8FC18 for ; Wed, 20 Jan 2010 13:22:45 +0000 (UTC) Received: from macbook-4.local (unknown [134.102.115.16]) by cyb0rg.org (Postfix) with ESMTPA id 4C1B41FC40F; Wed, 20 Jan 2010 14:22:58 +0100 (CET) Message-ID: <4B5703A3.6010507@cyb0rg.org> Date: Wed, 20 Jan 2010 14:22:43 +0100 From: Crest User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: "Rabidinov M.A." References: <659350866.20100120151602@mail.ru> In-Reply-To: <659350866.20100120151602@mail.ru> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=windows-1251 Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org Subject: Re: IPSec NAT-T in transport 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: Wed, 20 Jan 2010 13:22:45 -0000 Rabidinov M.A. schrieb: > Hello, Freebsd-stable. > > Does FreeBSD 8.0 support IPSec NAT-T in transport mode? > I want to create a L2TP/IPSec server. My VPN clients are NATed. > L2TP server (MPD5.x) makes tunnel, so I need working IPSec NAT-T in transport mode. > Thanks a lot. > Yes the NAT-T Patch has been integrated into FreeBSD 8.0. Just rebuild your kernel with this options: device crypto # IPsec depends on this options IPSEC options IPSEC_DEBUG options IPSEC_NAT_T From owner-freebsd-stable@FreeBSD.ORG Wed Jan 20 13:23: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 8CB0E1065670 for ; Wed, 20 Jan 2010 13:23:28 +0000 (UTC) (envelope-from vanhu@zeninc.net) Received: from smtp.zeninc.net (smtp.zeninc.net [80.67.176.25]) by mx1.freebsd.org (Postfix) with ESMTP id 48F048FC1F for ; Wed, 20 Jan 2010 13:23:27 +0000 (UTC) Received: from astro.zen.inc (astro.zen.inc [192.168.1.239]) by smtp.zeninc.net (smtpd) with ESMTP id 8801C2798BC; Wed, 20 Jan 2010 14:04:24 +0100 (CET) Received: by astro.zen.inc (Postfix, from userid 1000) id 88F8717058; Wed, 20 Jan 2010 14:04:24 +0100 (CET) Date: Wed, 20 Jan 2010 14:04:24 +0100 From: VANHULLEBUS Yvan To: "Rabidinov M.A." Message-ID: <20100120130424.GA44272@zeninc.net> References: <659350866.20100120151602@mail.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <659350866.20100120151602@mail.ru> User-Agent: All mail clients suck. This one just sucks less. Cc: freebsd-stable@freebsd.org Subject: Re: IPSec NAT-T in transport 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: Wed, 20 Jan 2010 13:23:28 -0000 On Wed, Jan 20, 2010 at 03:16:02PM +0600, Rabidinov M.A. wrote: > Hello, Freebsd-stable. Hi. > Does FreeBSD 8.0 support IPSec NAT-T in transport mode? > I want to create a L2TP/IPSec server. My VPN clients are NATed. > L2TP server (MPD5.x) makes tunnel, so I need working IPSec NAT-T in transport mode. > Thanks a lot. It may work..... or not.... The missing part is support of NAT-OA payloads, which are used to update checksums when receiving packets. For TCP, this is mandatory. For UDP (so for L2TP), checksums of 0 are allowed, and of course not checked, so packet will go to destination. But afaik, most L2TP implementations computes checksums, so they will be checked, and of course will be wrong.... Yvan. From owner-freebsd-stable@FreeBSD.ORG Wed Jan 20 13:34: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 7492D1065692; Wed, 20 Jan 2010 13:34:16 +0000 (UTC) (envelope-from hlh@restart.be) Received: from tignes.restart.be (tignes.restart.be [IPv6:2001:41d0:2:2d29:0:1::]) by mx1.freebsd.org (Postfix) with ESMTP id 00A1E8FC1F; Wed, 20 Jan 2010 13:34:16 +0000 (UTC) Received: from restart.be (avoriaz.tunnel.bel [IPv6:2001:41d0:2:2d29:1:ffff::]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "smtp.restart.be", Issuer "CA master" (verified OK)) by tignes.restart.be (Postfix) with ESMTPS id 02813FC43; Wed, 20 Jan 2010 14:34:14 +0100 (CET) Received: from meribel.restart.bel (meribel.restart.bel [IPv6:2001:41d0:2:2d29:1:8::]) (authenticated bits=0) by restart.be (8.14.4/8.14.4) with ESMTP id o0KDY7AH037848 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Wed, 20 Jan 2010 14:34:08 +0100 (CET) (envelope-from hlh@restart.be) X-DKIM: Sendmail DKIM Filter v2.8.3 restart.be o0KDY7AH037848 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=restart.be; s=avoriaz; t=1263994451; bh=uVHv5by+HJopdtcAk+ij7iaJpsb9Eztlw3KOmlqRwd0=; h=Message-ID:Date:From:MIME-Version:To:CC:Subject:References: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=lti5mxa6eF3Bs1wNK2rCNGI54UNrnE/IaHYdJRJLr/magAlkiekLeE7VR6OqjKxf4 ThnXg7sWS2ja7Ta8WmpHw== X-DomainKeys: Sendmail DomainKeys Filter v1.0.2 restart.be o0KDY7AH037848 DomainKey-Signature: a=rsa-sha1; s=avoriaz; d=restart.be; c=nofws; q=dns; h=message-id:date:from:user-agent:mime-version:to:cc:subject: references:in-reply-to:content-type: content-transfer-encoding:x-scanned-by; b=1IbvqdhW+71pCj9JYKR30rFvAE4t7J8xGfySEH4m/ufnOyI434R4Udv450EzmHQem JCwTHFoAopDepFnq44f3w== Message-ID: <4B57064F.9060704@restart.be> Date: Wed, 20 Jan 2010 14:34:07 +0100 From: Henri Hennebert User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.9.1.5) Gecko/20091220 Thunderbird/3.0 MIME-Version: 1.0 To: Alexander Motin References: <4B55D9D4.1000008@FreeBSD.org> In-Reply-To: <4B55D9D4.1000008@FreeBSD.org> Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.67 on IPv6:2001:41d0:2:2d29:1:1:: Cc: FreeBSD-Current , FreeBSD Stable Subject: Re: Pack of CAM improvements X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 20 Jan 2010 13:34:16 -0000 On 01/19/2010 17:12, Alexander Motin wrote: > Hi. > > I've made a patch, that should solve set of problems of CAM ATA and CAM > generally. I would like to ask for testing and feedback. > > What patch does: > - It unifies bus reset/probe sequence. Whenever bus attached at boot or > later, CAM will automatically reset and scan it. It allows to remove > duplicate code from many drivers. > - Any bus, attached before CAM completed it's boot-time initialization, > will equally join to the process, delaying boot if needed. > - New kern.cam.boot_delay loader tunable should help controllers that > are still unable to register their buses in time (such as slow USB/ > PCCard/ CardBus devices). With kern.cam.boot_delay=15000 (I suppose that it was in ms) I can now boot from my sim card reader. Thanks Henri > - To allow synchronization between different CAM levels, concept of > requests priorities was extended. Priorities now split between several > "run levels". Device can be freezed at specified level, allowing higher > priority requests to pass. For example, no payload requests allowed, > until PMP driver enable port. ATA XPT negotiate transfer parameters, > periph driver configure caching and so on. > - Frozen requests are no more counted by request allocation scheduler. > It fixes deadlocks, when frozen low priority payload requests occupying > slots, required by higher levels to manage theit execution. > - Two last changes were holding proper ATA reinitialization and error > recovery implementation. Now it is done: SATA controllers and Port > Multipliers now implement automatic hot-plug and should correctly > recover from timeouts and bus resets. > > Patch can be found here: > http://people.freebsd.org/~mav/cam-ata.20100119.patch > > Feedback as always welcome. > From owner-freebsd-stable@FreeBSD.ORG Wed Jan 20 16:29: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 073D91065781 for ; Wed, 20 Jan 2010 16:29:10 +0000 (UTC) (envelope-from wjw@digiware.nl) Received: from mail.digiware.nl (mail.ip6.digiware.nl [IPv6:2001:4cb8:1:106::2]) by mx1.freebsd.org (Postfix) with ESMTP id 9BF3A8FC20 for ; Wed, 20 Jan 2010 16:29:09 +0000 (UTC) Received: from localhost (localhost.digiware.nl [127.0.0.1]) by mail.digiware.nl (Postfix) with ESMTP id E2D57153433 for ; Wed, 20 Jan 2010 17:29:07 +0100 (CET) X-Virus-Scanned: amavisd-new at digiware.nl Received: from mail.digiware.nl ([127.0.0.1]) by localhost (rack1.digiware.nl [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PaS+fT8QbwAK; Wed, 20 Jan 2010 17:29:06 +0100 (CET) Received: from [192.168.10.67] (opteron [192.168.10.67]) by mail.digiware.nl (Postfix) with ESMTP id 2498115342F for ; Wed, 20 Jan 2010 17:29:06 +0100 (CET) Message-ID: <4B572F4E.4010503@digiware.nl> Date: Wed, 20 Jan 2010 17:29:02 +0100 From: Willem Jan Withagen Organization: Digiware User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: FreeBSD Stable Users Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: run_interrupt_driven_hooks: still waiting... for xpt_config X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 20 Jan 2010 16:29:10 -0000 Hi, This has passed several times on and of the lists. And is hindering me too. I'm trying to revive an old dual optern Tyan Tomcat S2875 board. Even upgraded it to the most recent BIOS. But still no go. Both with 8.0 and 7.2 RELEASE. I've also disabled P1394 and all USB in the BIOS, that did not work either. Only thing that is "extra" in the box is a an Areca 1120 controller. In previous cases Scott Long has worked on fixes, and most of the time there the discussion stop. And I assume things are fixed for that problem. Last time I can find is around July 2009. Problem is sort of how to get a working system on it. Now it is completely bare. Perhaps to install/rebuild on a different system, and then move the disk over? regards, --WjW From owner-freebsd-stable@FreeBSD.ORG Wed Jan 20 17:48: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 F00A2106566B for ; Wed, 20 Jan 2010 17:48:53 +0000 (UTC) (envelope-from jespasac@minibofh.org) Received: from smtp02.cdmon.com (smtp02.cdmon.com [212.36.74.55]) by mx1.freebsd.org (Postfix) with ESMTP id AD7628FC16 for ; Wed, 20 Jan 2010 17:48:53 +0000 (UTC) Received: from jespasac.cdmon.com (62.Red-217-126-43.staticIP.rima-tde.net [217.126.43.62]) (Authenticated sender: jespasac@noverificar) by smtp02.cdmon.com (Postfix) with ESMTP id 7002746316 for ; Wed, 20 Jan 2010 18:48:51 +0100 (CET) Message-ID: <4B574202.3020501@minibofh.org> Date: Wed, 20 Jan 2010 18:48:50 +0100 From: Jordi Espasa Clofent User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.5) Gecko/20091209 Fedora/3.0-4.fc12 Lightning/1.0b1 Thunderbird/3.0 MIME-Version: 1.0 To: freebsd-stable@FreeBSD.ORG References: <201001191712.o0JHCjPj056570@lurza.secnetix.de> In-Reply-To: <201001191712.o0JHCjPj056570@lurza.secnetix.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: Re: About nice(1), renice(8) and ULE scheduler X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 20 Jan 2010 17:48:54 -0000 > In fact nice is a very simple program. It only changes the > priority value of a process in a POSIX-compliant way. > There is no need to change or adapt it; it still works fine > in the SMP world and with new schedulers. It's up to the > scheduler to interpret and handle the priority values of > processes. > > In other words: The nice(1) tool only attaches a number to > a process, nothing more. Only the scheduler knows what that > number means. So there's no need to change nice(1). Great. So, the key is the scheduler; it makes sense. > By the way, the source code of nice(1) is almost trivial. > Basically it just calls the setpriority(2) and execve(2) > syscalls. 99% of the source file consists of the BSD > license test, arguments parsing and C syntax overhead. Thanks for aclaration. ;) -- I must not fear. Fear is the mind-killer. Fear is the little-death that brings total obliteration. I will face my fear. I will permit it to pass over me and through me. And when it has gone past I will turn the inner eye to see its path. Where the fear has gone there will be nothing. Only I will remain. Bene Gesserit Litany Against Fear. From owner-freebsd-stable@FreeBSD.ORG Wed Jan 20 23:12: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 330D4106568D for ; Wed, 20 Jan 2010 23:12:52 +0000 (UTC) (envelope-from erik@malcolm.berkeley.edu) Received: from malcolm.berkeley.edu (malcolm.Berkeley.EDU [IPv6:2607:f140:ffff:ffff::239]) by mx1.freebsd.org (Postfix) with ESMTP id 0E0768FC1A for ; Wed, 20 Jan 2010 23:12:52 +0000 (UTC) Received: from malcolm.berkeley.edu (localhost [127.0.0.1]) by malcolm.berkeley.edu (8.14.3/8.13.8m1) with ESMTP id o0KNCp06086724 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 20 Jan 2010 15:12:51 -0800 (PST) (envelope-from erik@malcolm.berkeley.edu) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.95.3 at malcolm.berkeley.edu Received: (from erik@localhost) by malcolm.berkeley.edu (8.14.3/8.13.3/Submit) id o0KNCpW2086723; Wed, 20 Jan 2010 15:12:51 -0800 (PST) (envelope-from erik) Date: Wed, 20 Jan 2010 15:12:51 -0800 From: Erik Klavon To: Pyun YongHyeon Message-ID: <20100120231251.GA85328@malcolm.berkeley.edu> References: <20100114014719.GA11284@malcolm.berkeley.edu> <20100114020640.GT1228@michelle.cdnetworks.com> <20100114232618.GA27380@malcolm.berkeley.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100114232618.GA27380@malcolm.berkeley.edu> User-Agent: Mutt/1.4.2.3i X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.3 (malcolm.berkeley.edu [127.0.0.1]); Wed, 20 Jan 2010 15:12:51 -0800 (PST) Cc: freebsd-stable@freebsd.org Subject: Re: bge panic in 8.0 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 20 Jan 2010 23:12:52 -0000 On Thu, Jan 14, 2010 at 03:26:18PM -0800, Erik Klavon wrote: > On Wed, Jan 13, 2010 at 06:06:40PM -0800, Pyun YongHyeon wrote: > > On Wed, Jan 13, 2010 at 05:47:19PM -0800, Erik Klavon wrote: > > > One of my amd64 machines running 8.0p1 acting as a NAT system for many > > > network clients dropped into kdb today. tr indicates a problem in > > > bge. > > > > > > Tracing pid 12 tid 100033 td 0xffffff0001687000 > > > pmap_kextract() at pmap_kextract+0x4e > > > bus_dmamap_load() at bus_dmamap_load+0xab > > > bge_newbuf_std() at bge_newbuf_std+0xcc > > > bge_rxeof() at bge_rxeof+0x36a > > > bge_intr() at bge_intr+0x1c0 > > > intr_event_execute_handlers() at intr_event_execute_handlers+0xfd > > > ithread_loop() at ithread_loop+0x8e > > > fork_exit() at fork_exit+0x118 > > > fork_trampoline() at fork_trampoline+0xe > > > --- trap 0, rip = 0, rsp = 0xffffff8074c01d30, rbp = 0 --- > > > > > > I haven't been able to find a PR that matches this particular trace. > > > > > > Pyun recently MFCd to stable (hence my post to this list) some changes > > > to bge that involve functions in the above trace and according to the > > > commit log (r201685) may address a kernel panic. Is there any > > > indication in the above trace that this is the type of panic the > > > commit attempts to address? I don't have a core dump for this > > > panic. This machine has been unstable on 8, so I may be able to get a > > > core dump in the future. If there is other information you'd like me > > > to gather, please let me know. > > > > Yes, that part of code in trace above were rewritten to address > > bus_dma(9) issues. So it would be great if you can try latest > > bge(4) in stable/8 and let me know how it goes on your box. I guess > > you can just download if_bge.c and if_bgereg.h from stable/8 and > > rebuild bge(4) would be enough to run it on 8.0-RELEASE. > > Great, I will try this out on a test machine today. If it holds up > under testing, I will put it into production. These crashes can happen > weeks after a machine boots, so I won't know if the problem is solved > for some time. Thanks for your help, I didn't run into any problems while testing. I started running bge(4) from stable in production this morning. I had three kernel panics in a couple hours; here's an example Fatal trap 12: page fault while in kernel mode cpuid = 0; apic id = 00 fault virtual address = 0x18 fault code = supervisor read data, page not present instruction pointer = 0x20:0xffffffff805ccf17 stack pointer = 0x28:0xffffff800004f830 frame pointer = 0x28:0xffffff800004f890 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0 pres 1, long 1, def32 0, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 13 (ng_queue0) [thread pid 13 tid 100009 ] Stopped at m_copym+0x37: movl 0x18(%r12),%eax db> tr Tracing pid 13 tid 100009 td 0xffffff000189aab0 m_copym() at m_copym+0x37 ip_fragment() at ip_fragment+0x131 ip_output() at ip_output+0xeec ip_forward() at ip_forward+0x16a ip_input() at ip_input+0x57d ng_ipfw_rcvdata() at ng_ipfw_rcvdata+0xb9 ng_apply_item() at ng_apply_item+0x220 ngthread() at ngthread+0x16b fork_exit() at fork_exit+0x118 fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff800004fd30, rbp = 0 --- I tried the kdb command 'panic' to dump core, but this command only produced further faults. After the third panic related to m_copym, I reverted to the previous version of bge(4) from 8.0p1. A couple of hours has passed without these panics repeating while running the previous version of bge(4). There is a long open PR, 89070, that looks to be related to the above panic. I don't have any proof that these panics resulted from the newer version of bge(4). I haven't seen kernel panics such as these on any of the other machines with this same configuration. I have seen a kernel panic on systems running 8.0p1 with a different stack trace than the one I posted previous that also appears to be related to bge(4). Fatal trap 12: page fault while in kernel mode cpuid = 1; apic id = 01 fault virtual address = 0x28 fault code = supervisor write data, page not present instruction pointer = 0x20:0xffffffff802cdf0e stack pointer = 0x28:0xffffff8074c1ab10 frame pointer = 0x28:0xffffff8074c1ab70 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 12 (irq25: bge1) [thread pid 12 tid 100034 ] Stopped at bge_rxeof+0x1be: movq %r15,0x28(%r14) db> trace Tracing pid 12 tid 100034 td 0xffffff0001680ab0 bge_rxeof() at bge_rxeof+0x1be bge_intr() at bge_intr+0x1c0 intr_event_execute_handlers() at intr_event_execute_handlers+0xfd ithread_loop() at ithread_loop+0x8e fork_exit() at fork_exit+0x118 fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff8074c1ad30, rbp = 0 --- Erik From owner-freebsd-stable@FreeBSD.ORG Wed Jan 20 23:42: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 6711B106566C for ; Wed, 20 Jan 2010 23:42:20 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from mail-qy0-f190.google.com (mail-qy0-f190.google.com [209.85.221.190]) by mx1.freebsd.org (Postfix) with ESMTP id 181C28FC0A for ; Wed, 20 Jan 2010 23:42:19 +0000 (UTC) Received: by qyk28 with SMTP id 28so3530542qyk.28 for ; Wed, 20 Jan 2010 15:42:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:from:date:to:cc :subject:message-id:reply-to:references:mime-version:content-type :content-disposition:in-reply-to:user-agent; bh=M2Zq+muX9vVj3cWk/+dUfqZfaVzvOEj5p/5y3duXgR0=; b=gwf+gcz7lz6+eSEhllgScYyqgGnJsqoQkR4UM5I1430KObfMIyWygXOSCQ3toLxuSz v4SCshyB3RMTQltSTEe5arOPxBcMxOuqaDFe75dA7zMFEomCF4cnhw0opHyEnUDET8td MNT5GogIAq+e1zW951wk/7VAKZTTHLxl7zSfk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:date:to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; b=TGrvb9FuwTWK39b9sL1goxHrfa6vavZo+BAdY3Gsg0SKf2LgjmLSagg38+NqAs46B1 9pELgSUTEc6tGCayg+RJe75wWgAVrEft2VphXhyDAv+1TC3Wa3sekvV+Lbjqnbj9kf33 +8gK1W7tu+6yenty71RlUdnNZ6ueUCl3pz61w= Received: by 10.224.58.166 with SMTP id g38mr506554qah.32.1264030936138; Wed, 20 Jan 2010 15:42:16 -0800 (PST) Received: from pyunyh@gmail.com ([174.35.1.224]) by mx.google.com with ESMTPS id 7sm961572qwf.14.2010.01.20.15.42.12 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 20 Jan 2010 15:42:14 -0800 (PST) Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Wed, 20 Jan 2010 15:42:08 -0800 From: Pyun YongHyeon Date: Wed, 20 Jan 2010 15:42:08 -0800 To: Erik Klavon Message-ID: <20100120234208.GL6201@michelle.cdnetworks.com> References: <20100114014719.GA11284@malcolm.berkeley.edu> <20100114020640.GT1228@michelle.cdnetworks.com> <20100114232618.GA27380@malcolm.berkeley.edu> <20100120231251.GA85328@malcolm.berkeley.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100120231251.GA85328@malcolm.berkeley.edu> User-Agent: Mutt/1.4.2.3i Cc: freebsd-stable@freebsd.org Subject: Re: bge panic in 8.0 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jan 2010 23:42:20 -0000 On Wed, Jan 20, 2010 at 03:12:51PM -0800, Erik Klavon wrote: > On Thu, Jan 14, 2010 at 03:26:18PM -0800, Erik Klavon wrote: > > On Wed, Jan 13, 2010 at 06:06:40PM -0800, Pyun YongHyeon wrote: > > > On Wed, Jan 13, 2010 at 05:47:19PM -0800, Erik Klavon wrote: > > > > One of my amd64 machines running 8.0p1 acting as a NAT system for many > > > > network clients dropped into kdb today. tr indicates a problem in > > > > bge. > > > > > > > > Tracing pid 12 tid 100033 td 0xffffff0001687000 > > > > pmap_kextract() at pmap_kextract+0x4e > > > > bus_dmamap_load() at bus_dmamap_load+0xab > > > > bge_newbuf_std() at bge_newbuf_std+0xcc > > > > bge_rxeof() at bge_rxeof+0x36a > > > > bge_intr() at bge_intr+0x1c0 > > > > intr_event_execute_handlers() at intr_event_execute_handlers+0xfd > > > > ithread_loop() at ithread_loop+0x8e > > > > fork_exit() at fork_exit+0x118 > > > > fork_trampoline() at fork_trampoline+0xe > > > > --- trap 0, rip = 0, rsp = 0xffffff8074c01d30, rbp = 0 --- > > > > > > > > I haven't been able to find a PR that matches this particular trace. > > > > > > > > Pyun recently MFCd to stable (hence my post to this list) some changes > > > > to bge that involve functions in the above trace and according to the > > > > commit log (r201685) may address a kernel panic. Is there any > > > > indication in the above trace that this is the type of panic the > > > > commit attempts to address? I don't have a core dump for this > > > > panic. This machine has been unstable on 8, so I may be able to get a > > > > core dump in the future. If there is other information you'd like me > > > > to gather, please let me know. > > > > > > Yes, that part of code in trace above were rewritten to address > > > bus_dma(9) issues. So it would be great if you can try latest > > > bge(4) in stable/8 and let me know how it goes on your box. I guess > > > you can just download if_bge.c and if_bgereg.h from stable/8 and > > > rebuild bge(4) would be enough to run it on 8.0-RELEASE. > > > > Great, I will try this out on a test machine today. If it holds up > > under testing, I will put it into production. These crashes can happen > > weeks after a machine boots, so I won't know if the problem is solved > > for some time. Thanks for your help, > > I didn't run into any problems while testing. I started running bge(4) > from stable in production this morning. I had three kernel panics in a > couple hours; here's an example > > Fatal trap 12: page fault while in kernel mode > cpuid = 0; apic id = 00 > fault virtual address = 0x18 > fault code = supervisor read data, page not present > instruction pointer = 0x20:0xffffffff805ccf17 > stack pointer = 0x28:0xffffff800004f830 > frame pointer = 0x28:0xffffff800004f890 > code segment = base 0x0, limit 0xfffff, type 0x1b > = DPL 0 pres 1, long 1, def32 0, gran 1 > processor eflags = interrupt enabled, resume, IOPL = 0 > current process = 13 (ng_queue0) > [thread pid 13 tid 100009 ] > Stopped at m_copym+0x37: movl 0x18(%r12),%eax > > db> tr > Tracing pid 13 tid 100009 td 0xffffff000189aab0 > m_copym() at m_copym+0x37 > ip_fragment() at ip_fragment+0x131 > ip_output() at ip_output+0xeec > ip_forward() at ip_forward+0x16a > ip_input() at ip_input+0x57d > ng_ipfw_rcvdata() at ng_ipfw_rcvdata+0xb9 > ng_apply_item() at ng_apply_item+0x220 > ngthread() at ngthread+0x16b > fork_exit() at fork_exit+0x118 > fork_trampoline() at fork_trampoline+0xe > --- trap 0, rip = 0, rsp = 0xffffff800004fd30, rbp = 0 --- > > I tried the kdb command 'panic' to dump core, but this command only > produced further faults. After the third panic related to m_copym, I > reverted to the previous version of bge(4) from 8.0p1. A couple of > hours has passed without these panics repeating while running the > previous version of bge(4). > I guess this is NULL pointer dereference in m_copym(9). And I also see you're using netgraph(4). Can you run the server without netgraph(4) in your configuration and see how this make any difference? I'm not familiar with netgraph(4) but other developers can comment on this. Another thing to narrow down the cause would be trying other controllers and see you can reproduce the issue. But I think the above panic is not related with bge(4). > There is a long open PR, 89070, that looks to be related to the above > panic. I don't have any proof that these panics resulted from the > newer version of bge(4). I haven't seen kernel panics such as these on > any of the other machines with this same configuration. > > I have seen a kernel panic on systems running 8.0p1 with a different > stack trace than the one I posted previous that also appears to be > related to bge(4). > > Fatal trap 12: page fault while in kernel mode > cpuid = 1; apic id = 01 > fault virtual address = 0x28 > fault code = supervisor write data, page not present > instruction pointer = 0x20:0xffffffff802cdf0e > stack pointer = 0x28:0xffffff8074c1ab10 > frame pointer = 0x28:0xffffff8074c1ab70 > code segment = base 0x0, limit 0xfffff, type 0x1b > = DPL 0, pres 1, long 1, def32 0, gran 1 > processor eflags = interrupt enabled, resume, IOPL = 0 > current process = 12 (irq25: bge1) > [thread pid 12 tid 100034 ] > Stopped at bge_rxeof+0x1be: movq %r15,0x28(%r14) > > db> trace > Tracing pid 12 tid 100034 td 0xffffff0001680ab0 > bge_rxeof() at bge_rxeof+0x1be > bge_intr() at bge_intr+0x1c0 > intr_event_execute_handlers() at intr_event_execute_handlers+0xfd > ithread_loop() at ithread_loop+0x8e > fork_exit() at fork_exit+0x118 > fork_trampoline() at fork_trampoline+0xe I think this is a real bug of bge(4) and I believe it was fixed in stable. > --- trap 0, rip = 0, rsp = 0xffffff8074c1ad30, rbp = 0 --- > > Erik From owner-freebsd-stable@FreeBSD.ORG Thu Jan 21 06:19: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 559AD1065670 for ; Thu, 21 Jan 2010 06:19:14 +0000 (UTC) (envelope-from erik@malcolm.berkeley.edu) Received: from malcolm.berkeley.edu (malcolm.Berkeley.EDU [IPv6:2607:f140:ffff:ffff::239]) by mx1.freebsd.org (Postfix) with ESMTP id 339028FC24 for ; Thu, 21 Jan 2010 06:19:14 +0000 (UTC) Received: from malcolm.berkeley.edu (localhost [127.0.0.1]) by malcolm.berkeley.edu (8.14.3/8.13.8m1) with ESMTP id o0L6JDak097071 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 20 Jan 2010 22:19:13 -0800 (PST) (envelope-from erik@malcolm.berkeley.edu) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.95.3 at malcolm.berkeley.edu Received: (from erik@localhost) by malcolm.berkeley.edu (8.14.3/8.13.3/Submit) id o0L6JDUX097070; Wed, 20 Jan 2010 22:19:13 -0800 (PST) (envelope-from erik) Date: Wed, 20 Jan 2010 22:19:13 -0800 From: Erik Klavon To: Pyun YongHyeon Message-ID: <20100121061912.GA96603@malcolm.berkeley.edu> References: <20100114014719.GA11284@malcolm.berkeley.edu> <20100114020640.GT1228@michelle.cdnetworks.com> <20100114232618.GA27380@malcolm.berkeley.edu> <20100120231251.GA85328@malcolm.berkeley.edu> <20100120234208.GL6201@michelle.cdnetworks.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100120234208.GL6201@michelle.cdnetworks.com> User-Agent: Mutt/1.4.2.3i X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.3 (malcolm.berkeley.edu [127.0.0.1]); Wed, 20 Jan 2010 22:19:14 -0800 (PST) Cc: freebsd-stable@freebsd.org Subject: Re: bge panic in 8.0 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 21 Jan 2010 06:19:14 -0000 On Wed, Jan 20, 2010 at 03:42:08PM -0800, Pyun YongHyeon wrote: > On Wed, Jan 20, 2010 at 03:12:51PM -0800, Erik Klavon wrote: > > On Thu, Jan 14, 2010 at 03:26:18PM -0800, Erik Klavon wrote: > > > On Wed, Jan 13, 2010 at 06:06:40PM -0800, Pyun YongHyeon wrote: > > > > On Wed, Jan 13, 2010 at 05:47:19PM -0800, Erik Klavon wrote: > > > > > One of my amd64 machines running 8.0p1 acting as a NAT system for many > > > > > network clients dropped into kdb today. tr indicates a problem in > > > > > bge. > > > > > > > > > > Tracing pid 12 tid 100033 td 0xffffff0001687000 > > > > > pmap_kextract() at pmap_kextract+0x4e > > > > > bus_dmamap_load() at bus_dmamap_load+0xab > > > > > bge_newbuf_std() at bge_newbuf_std+0xcc > > > > > bge_rxeof() at bge_rxeof+0x36a > > > > > bge_intr() at bge_intr+0x1c0 > > > > > intr_event_execute_handlers() at intr_event_execute_handlers+0xfd > > > > > ithread_loop() at ithread_loop+0x8e > > > > > fork_exit() at fork_exit+0x118 > > > > > fork_trampoline() at fork_trampoline+0xe > > > > > --- trap 0, rip = 0, rsp = 0xffffff8074c01d30, rbp = 0 --- > > > > > > > > > > I haven't been able to find a PR that matches this particular trace. > > > > > > > > > > Pyun recently MFCd to stable (hence my post to this list) some changes > > > > > to bge that involve functions in the above trace and according to the > > > > > commit log (r201685) may address a kernel panic. Is there any > > > > > indication in the above trace that this is the type of panic the > > > > > commit attempts to address? I don't have a core dump for this > > > > > panic. This machine has been unstable on 8, so I may be able to get a > > > > > core dump in the future. If there is other information you'd like me > > > > > to gather, please let me know. > > > > > > > > Yes, that part of code in trace above were rewritten to address > > > > bus_dma(9) issues. So it would be great if you can try latest > > > > bge(4) in stable/8 and let me know how it goes on your box. I guess > > > > you can just download if_bge.c and if_bgereg.h from stable/8 and > > > > rebuild bge(4) would be enough to run it on 8.0-RELEASE. > > > > > > Great, I will try this out on a test machine today. If it holds up > > > under testing, I will put it into production. These crashes can happen > > > weeks after a machine boots, so I won't know if the problem is solved > > > for some time. Thanks for your help, > > > > I didn't run into any problems while testing. I started running bge(4) > > from stable in production this morning. I had three kernel panics in a > > couple hours; here's an example > > > > Fatal trap 12: page fault while in kernel mode > > cpuid = 0; apic id = 00 > > fault virtual address = 0x18 > > fault code = supervisor read data, page not present > > instruction pointer = 0x20:0xffffffff805ccf17 > > stack pointer = 0x28:0xffffff800004f830 > > frame pointer = 0x28:0xffffff800004f890 > > code segment = base 0x0, limit 0xfffff, type 0x1b > > = DPL 0 pres 1, long 1, def32 0, gran 1 > > processor eflags = interrupt enabled, resume, IOPL = 0 > > current process = 13 (ng_queue0) > > [thread pid 13 tid 100009 ] > > Stopped at m_copym+0x37: movl 0x18(%r12),%eax > > > > db> tr > > Tracing pid 13 tid 100009 td 0xffffff000189aab0 > > m_copym() at m_copym+0x37 > > ip_fragment() at ip_fragment+0x131 > > ip_output() at ip_output+0xeec > > ip_forward() at ip_forward+0x16a > > ip_input() at ip_input+0x57d > > ng_ipfw_rcvdata() at ng_ipfw_rcvdata+0xb9 > > ng_apply_item() at ng_apply_item+0x220 > > ngthread() at ngthread+0x16b > > fork_exit() at fork_exit+0x118 > > fork_trampoline() at fork_trampoline+0xe > > --- trap 0, rip = 0, rsp = 0xffffff800004fd30, rbp = 0 --- > > > > I tried the kdb command 'panic' to dump core, but this command only > > produced further faults. After the third panic related to m_copym, I > > reverted to the previous version of bge(4) from 8.0p1. A couple of > > hours has passed without these panics repeating while running the > > previous version of bge(4). > > > > I guess this is NULL pointer dereference in m_copym(9). And I also > see you're using netgraph(4). Can you run the server without > netgraph(4) in your configuration and see how this make any > difference? I'm not familiar with netgraph(4) but other developers > can comment on this. > Another thing to narrow down the cause would be trying other > controllers and see you can reproduce the issue. But I think the > above panic is not related with bge(4). netgraph(4) is key to what this system does; removing it isn't an option for us. Using a different controller on the current hardware isn't feasible. We're looking into different hardware for further testing, and we plan to include both bge(4) and non bge controllers. > > There is a long open PR, 89070, that looks to be related to the above > > panic. I don't have any proof that these panics resulted from the > > newer version of bge(4). I haven't seen kernel panics such as these on > > any of the other machines with this same configuration. > > > > I have seen a kernel panic on systems running 8.0p1 with a different > > stack trace than the one I posted previous that also appears to be > > related to bge(4). > > > > Fatal trap 12: page fault while in kernel mode > > cpuid = 1; apic id = 01 > > fault virtual address = 0x28 > > fault code = supervisor write data, page not present > > instruction pointer = 0x20:0xffffffff802cdf0e > > stack pointer = 0x28:0xffffff8074c1ab10 > > frame pointer = 0x28:0xffffff8074c1ab70 > > code segment = base 0x0, limit 0xfffff, type 0x1b > > = DPL 0, pres 1, long 1, def32 0, gran 1 > > processor eflags = interrupt enabled, resume, IOPL = 0 > > current process = 12 (irq25: bge1) > > [thread pid 12 tid 100034 ] > > Stopped at bge_rxeof+0x1be: movq %r15,0x28(%r14) > > > > db> trace > > Tracing pid 12 tid 100034 td 0xffffff0001680ab0 > > bge_rxeof() at bge_rxeof+0x1be > > bge_intr() at bge_intr+0x1c0 > > intr_event_execute_handlers() at intr_event_execute_handlers+0xfd > > ithread_loop() at ithread_loop+0x8e > > fork_exit() at fork_exit+0x118 > > fork_trampoline() at fork_trampoline+0xe > > I think this is a real bug of bge(4) and I believe it was fixed in > stable. Thanks for confirming this. So far I haven't been able to reproduce these problems in test; they only show up in production. Erik From owner-freebsd-stable@FreeBSD.ORG Thu Jan 21 06:51: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 2B1391065679 for ; Thu, 21 Jan 2010 06:51:38 +0000 (UTC) (envelope-from spork@bway.net) Received: from xena.bway.net (xena.bway.net [216.220.96.26]) by mx1.freebsd.org (Postfix) with ESMTP id C40278FC1B for ; Thu, 21 Jan 2010 06:51:37 +0000 (UTC) Received: (qmail 38094 invoked by uid 0); 21 Jan 2010 06:51:36 -0000 Received: from unknown (HELO ?10.3.2.41?) (spork@96.57.144.66) by smtp.bway.net with (DHE-RSA-AES256-SHA encrypted) SMTP; 21 Jan 2010 06:51:36 -0000 Date: Thu, 21 Jan 2010 01:51:36 -0500 (EST) From: Charles Sprickman X-X-Sender: spork@hotlap.local To: freebsd-stable@freebsd.org Message-ID: User-Agent: Alpine 2.00 (OSX 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Subject: 32-bit jails on a 64-bit system? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jan 2010 06:51:38 -0000 Howdy, I saw this little tidbit in the 8.0 Release Notes... ---- The jail(8) subsystem has been updated. Changes include: Compatibility support which permits 32-bit jail binaries to be used on 64-bit systems to manage jails has been added. ---- I know prior to 8.0 with some fancy footwork you could do some interesting things (for example, I have a jail running a bunch of 32-bit 4.11 stuff on a 7.2 amd64 box), but it was not easy. Looking at the jail manpage and handbook entries, I'm not seeing anything that further explains the changes. I've been able to get some things working in a test setup, but not everything. Any pointers to what exactly that blurb in the release notes actually means? Google is getting me nowhere. My current scenario is this... I have a backups server with a ton of space. Nightly backups run to this and get zfs-snapshotted each night. I also have created jails for a number of important hosts so that should I lose a host, I can bring up a jail on this box to replace it while I repair things. One host is a 7.2/i386 box. The backups host is 8.0/amd64. Ideally I'd like to copy everything, including the base OS into this jail, except for perhaps "ps", "top" and other utilities that might have issues. Any pointers appreciated... Thanks, Charles ___ Charles Sprickman NetEng/SysAdmin Bway.net - New York's Best Internet - www.bway.net spork@bway.net - 212.655.9344 From owner-freebsd-stable@FreeBSD.ORG Thu Jan 21 09:12:25 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 C70B5106568B; Thu, 21 Jan 2010 09:12:25 +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 847E18FC08; Thu, 21 Jan 2010 09:12:25 +0000 (UTC) Received: from elsa.codelab.cz (localhost.codelab.cz [127.0.0.1]) by elsa.codelab.cz (Postfix) with ESMTP id 97D0C19E023; Thu, 21 Jan 2010 10:12:23 +0100 (CET) Received: from [192.168.1.2] (r5bb235.net.upc.cz [86.49.61.235]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by elsa.codelab.cz (Postfix) with ESMTPSA id 7846319E019; Thu, 21 Jan 2010 10:12:21 +0100 (CET) Message-ID: <4B581A74.5060000@quip.cz> Date: Thu, 21 Jan 2010 10:12:20 +0100 From: Miroslav Lachman <000.fbsd@quip.cz> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9.1.7) Gecko/20100104 SeaMonkey/2.0.2 MIME-Version: 1.0 To: Charles Sprickman References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-jail@FreeBSD.org, freebsd-stable@freebsd.org Subject: Re: 32-bit jails on a 64-bit system? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jan 2010 09:12:25 -0000 Charles Sprickman wrote: > Howdy, > > I saw this little tidbit in the 8.0 Release Notes... > > ---- > The jail(8) subsystem has been updated. Changes include: > > Compatibility support which permits 32-bit jail binaries to be used on > 64-bit systems to manage jails has been added. > ---- > > I know prior to 8.0 with some fancy footwork you could do some > interesting things (for example, I have a jail running a bunch of 32-bit > 4.11 stuff on a 7.2 amd64 box), but it was not easy. > > Looking at the jail manpage and handbook entries, I'm not seeing > anything that further explains the changes. I've been able to get some > things working in a test setup, but not everything. Any pointers to what > exactly that blurb in the release notes actually means? Google is > getting me nowhere. > > My current scenario is this... I have a backups server with a ton of > space. Nightly backups run to this and get zfs-snapshotted each night. I > also have created jails for a number of important hosts so that should I > lose a host, I can bring up a jail on this box to replace it while I > repair things. One host is a 7.2/i386 box. The backups host is > 8.0/amd64. Ideally I'd like to copy everything, including the base OS > into this jail, except for perhaps "ps", "top" and other utilities that > might have issues. (freebsd-jail@ was added in to Cc:) I think it is nothing new to 8.0, it is the same as release note for 7.2. I didn't test it, but I think you can install (copy) i386 jail (or whole system) in to amd64 host and just run it as any other jail. Miroslav Lachman From owner-freebsd-stable@FreeBSD.ORG Thu Jan 21 09:37: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 0FB44106566B; Thu, 21 Jan 2010 09:37:10 +0000 (UTC) (envelope-from dnaeon@gmail.com) Received: from mail-ew0-f218.google.com (mail-ew0-f218.google.com [209.85.219.218]) by mx1.freebsd.org (Postfix) with ESMTP id 3C1838FC16; Thu, 21 Jan 2010 09:37:08 +0000 (UTC) Received: by ewy10 with SMTP id 10so672560ewy.34 for ; Thu, 21 Jan 2010 01:37:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=sqMIkumRMq9TlsPfLK2qQWp4vTtYohm6CdcFeeT/1X0=; b=pc/VYTpqAbnqSNzfQsOYiDz5G6VjIbdV2B9nPENmDqhxyK11T8VsKpmIiQ2Wu14bVs 58YsrvRnuXfCuJVNsKmCfq9LNdPGSdFYZy7k6o+f/mdcJgSZNgl6QnLfF+VXtsHAEVpI blqw7dnsskHj4jRV0EDgGgh1aZqVzqvOjKG4g= 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=l58jsdOKKqiVmKnsO5/lC9Pv5CkJtyFVtiZB0ZDdVX3qUOkpQ4WdQsHUGnDotEV9sS NcrPZldIgc0/OCsllsCM9NgSoSJ7f59rjGJYLz8hydzSqNPmrIxU9PLK3g9iZ1OCFcI4 TjamWMmzEmJk4cobopRSNjusITCNOnKDAMUBc= MIME-Version: 1.0 Received: by 10.216.87.79 with SMTP id x57mr439612wee.83.1264066626626; Thu, 21 Jan 2010 01:37:06 -0800 (PST) In-Reply-To: <20100120074611.GA405@icarus.home.lan> References: <717f7a3e1001120714m37aada69gfaa35f0f9b17f435@mail.gmail.com> <44678539@bb.ipt.ru> <717f7a3e1001142234y1de7ae15x6853e3ddcab4add9@mail.gmail.com> <717f7a3e1001192246o4dce4a82q57c05ff3f41b5feb@mail.gmail.com> <20100120074611.GA405@icarus.home.lan> Date: Thu, 21 Jan 2010 11:37:06 +0200 Message-ID: <717f7a3e1001210137p7884adcbxc66a4f7fff928821@mail.gmail.com> From: Marin Atanasov To: Jeremy Chadwick Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-hardware@freebsd.org, freebsd-stable@freebsd.org, Ronald Klop Subject: Re: Multiple serial consoles via null modem cable X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 21 Jan 2010 09:37:10 -0000 Hello Jeremy, Now I'm a little confused :) I've made some tests with my machines and a couple of null modem cables, and here's what I've got. On Wed, Jan 20, 2010 at 9:46 AM, Jeremy Chadwick wrote: > On Wed, Jan 20, 2010 at 08:46:48AM +0200, Marin Atanasov wrote: > > Hello, > > > > Using `cu' only works with COM1 for me. > > > > Currently I have two serial ports on the system, and only the first is > able > > to make the connection - the serial consoles are enabled in /etc/tty, but > as > > I said only COM1 is able to make the connection. > > I'm a little confused by this statement, so I'll add some clarify: > > /etc/ttys is for configuring a machine to tie getty (think login prompt) > to a device (in this case, a serial port). Meaning: the device on the > other end of the serial cable will start seeing "login:" and so on > assuming you attach to the serial port there. > > For example: > > box1 COM1/ttyu0 is wired to box2 COM3/ttyu2 using a null modem cable. > box1 COM2/ttyu1 is wired to box2 COM4/ttyu3 using a null modem cable. > > On box1, you'd have something like this in /etc/ttys: > > ttyu0 "/usr/libexec/getty std.9600" vt100 on secure > ttyu1 "/usr/libexec/getty std.9600" vt100 on secure > Here's what I did: box1 COM1/ttyd0 -> box2 COM1/ttyd0 -> using null modem cable box1 COM2/ttyd1 -> box3 COM1/ttyd0 -> using null modem cable On box1 I have this in /etc/ttys: ttyd0 "/usr/libexec/getty std.9600" vt100 on secure ttyd1 "/usr/libexec/getty std.9600" vt100 on secure Now if I want to connect to box1 from box2 or box3 through the serial connection it should work, right? But I only can connect to box1 from box2, because box2's COM port is connected to box1's COM1 port. >From box2 I can get a login prompt box2# cu -l /dev/cuad0 -s 9600 Connected login: ) (host.domain) (ttyd0) login: ~ [EOT] But if I try to connect to box1 from box3 - no success there. box3# cu -l /dev/cuad0 -s 9600 Connected ~ [EOT] > This means that login prompts for box1 will be spawned/available on both > serial ports (ttyu0 and ttyu1). > > If you get on box2 and do "cu -l ttyu2", this will connect you to box2's > COM3 port, which is physically connected to box1's COM1 port. Hit enter > and you should see a login: prompt for box1. > > The same applies if you get on box2 and do "cu -l ttyu3" (but for box2's > COM4 port, which is wired to box1's COM2 port). > > With the above configuration in mind, you SHOULD NOT: > > - Mess with /etc/ttys on box2 > - Execute "cu -l ttyu0" or "cu -l ttyu1" on box1 -- this probably won't > work (likely will return some message about the device being locked or > in use already). > > You cannot do something like where box1 COM1 is wired to box2 COM1, and > depending on what box you're on doing the "cu -l ttyu0" from, get a > login prompt on the other. It doesn't work like that. :-) > > Now, about actual *serial console* itself -- that is to say, kernel > output during boot, etc... on a serial port. AFAIK, on FreeBSD you can > only set serial console to a single serial port, and that defaults to > COM1/ttyu0. You can change what port/device, but there can only be one. > > Yes, probably I didn't explain myself better, but you did it good - what I was trying to say is that I can use only one COM port for serial console, which of course defaults to COM1. Also is conserver/conserver-com able to handle more than one serial consoles on a machine? I haven't tried conserver yet. Thanks for the good explanation again :) Marin > HTH... > Now > > > On Sun, Jan 17, 2010 at 3:32 PM, Ronald Klop < > ronald-freebsd8@klop.yi.org>wrote: > > > > > On Fri, 15 Jan 2010 07:34:17 +0100, Marin Atanasov > > > wrote: > > > > > > Thank you a lot for your feedback! > > >> > > >> Now to the real question again, because I'm a little confused now - > can I > > >> still get a usb-to-serial port converter having let's say 8 serial > ports > > >> and > > >> then connect each machine to the usb-to-serial hub and manage them > > >> remotely > > >> from a single location (the host having the usb-to-serial hub)? That > way I > > >> just specify a serial port number and I get to a specific machine? > > >> > > >> The model provided by Boris looks nice, and that was my initial idea, > but > > >> I'm not sure if I could get it working under FreeBSD. Is conserver or > > >> conserver-com able to handle this? I know that cu uses COM1 only, but > will > > >> conserver able to handle serial consoles on different ports, since the > > >> usb-to-serial port would appear as multiple serial ports. > > >> > > > > > > You can provide cu with the port to connect to on the command line. > > > > > > cu -l cuaU0 -s 115200 > > > cu -l cuaU1 -s 115200 > > > etc. > > > > > > You can not connect several servers on 1 serial port, but you can > connect > > > several servers on several serial ports. With serial-over-usb it scales > to > > > many serial ports. > > > > > > Ronald. > > > > > > > > >> Thank you and regards, > > >> Marin > > >> > > >> > > >> On Tue, Jan 12, 2010 at 7:04 PM, Boris Samorodov wrote: > > >> > > >> On Tue, 12 Jan 2010 17:14:44 +0200 Marin Atanasov wrote: > > >>> > > >>> > I'm thinking about the following situation - 1 system acting like a > > >>> host > > >>> > with a serial port hub, each port of the hub is connected to a > > >>> different > > >>> > machine on sio0, using null modem cables. > > >>> > > >>> Along with milti-io serial cards we use multi-usb serial > > >>> converters, such as SUNIX UTS7009P (7 USB to serial adapter): > > >>> http://www.sunix.com.tw/it/en/LinkCraft/UTS4009P_UTS7009P.htm > > -- > | 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 | > > -- Marin Atanasov Nikolov dnaeon AT gmail DOT com daemon AT unix-heaven DOT org From owner-freebsd-stable@FreeBSD.ORG Thu Jan 21 10:23:44 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 68B6D1065676 for ; Thu, 21 Jan 2010 10:23:44 +0000 (UTC) (envelope-from flo@smeets.im) Received: from mail.solomo.de (mail.solomo.de [85.214.124.163]) by mx1.freebsd.org (Postfix) with ESMTP id E9BED8FC16 for ; Thu, 21 Jan 2010 10:23:43 +0000 (UTC) Received: from mail.solomo.de (localhost [127.0.0.1]) by mail.solomo.de (Postfix) with ESMTP id 746B761CB3 for ; Thu, 21 Jan 2010 11:10:24 +0100 (CET) X-Virus-Scanned: amavisd-new at vistream.de Received: from mail.solomo.de ([127.0.0.1]) by mail.solomo.de (mail.solomo.de [127.0.0.1]) (amavisd-new, port 10024) with LMTP id CLILiLQOs7SY for ; Thu, 21 Jan 2010 11:10:21 +0100 (CET) Received: from nibbler.vistream.local (relay3.vistream.de [87.139.10.28]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mail.solomo.de (Postfix) with ESMTPSA id EAE8961C94 for ; Thu, 21 Jan 2010 11:10:20 +0100 (CET) Message-ID: <4B58280C.50602@smeets.im> Date: Thu, 21 Jan 2010 11:10:20 +0100 From: Florian Smeets User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2pre) Gecko/20100120 Lanikai/3.1b1pre MIME-Version: 1.0 To: stable@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: 7.2-STABLE page fault with kernel from 12.01.2010 / crashinfo available X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 21 Jan 2010 10:23:44 -0000 Hi, this firewall has been running happily with a kernel from August 8th 2009 and has only been rebooted to upgrade world/kernel on Jan 12th 2010, after only 7 days of uptime i got the page fault further down. There are quite a few services on this firewall it has 4 physical (sis(4)) interfaces of which all are used, 3 for Ethernet and one for PPPoE via mpd5, it uses a gif interface for IPv6 tunneling via IPv4, and a few IPsec tunnels are also configured and heavily used. arpwatch is beeing run on 2 of the ethernet interfaces so they are always in promiscuous mode, as a packet filter pf with altq is used. The crashinfo file can be found here http://webmail.smeets.im/~flo/crashinfo.txt Fatal trap 12: page fault while in kernel mode fault virtual address = 0xc fault code = supervisor read, page not present instruction pointer = 0x20:0xc0572e48 stack pointer = 0x28:0xc1f15b24 frame pointer = 0x28:0xc1f15b40 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 21 (irq5: sis0) trap number = 12 panic: page fault Uptime: 7d21h44m23s Physical memory: 245 MB Dumping 65 MB: 50 34 18 2 #0 doadump () at pcpu.h:196 196 pcpu.h: No such file or directory. in pcpu.h (kgdb) where #0 doadump () at pcpu.h:196 #1 0xc0525703 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:418 #2 0xc052590e in panic (fmt=Variable "fmt" is not available. ) at /usr/src/sys/kern/kern_shutdown.c:574 #3 0xc06f110c in trap_fatal (frame=0xc1f15ae4, eva=12) at /usr/src/sys/i386/i386/trap.c:950 #4 0xc06f1390 in trap_pfault (frame=0xc1f15ae4, usermode=0, eva=12) at /usr/src/sys/i386/i386/trap.c:863 #5 0xc06f1d65 in trap (frame=0xc1f15ae4) at /usr/src/sys/i386/i386/trap.c:541 #6 0xc06d910b in calltrap () at /usr/src/sys/i386/i386/exception.s:166 #7 0xc0572e48 in m_copydata (m=0x0, off=0, len=40, cp=0xc23cced8 "\203??b??\237\f)h?M\220\224?\023?\205K(e??s?\"???k?oQ?~\223\020g\030") at /usr/src/sys/kern/uipc_mbuf.c:815 #8 0xc05f8b28 in ip_forward (m=0xc23dc900, srcrt=0) at /usr/src/sys/netinet/ip_input.c:1307 #9 0xc05fa30c in ip_input (m=0xc23dc900) at /usr/src/sys/netinet/ip_input.c:609 #10 0xc05c83d5 in netisr_dispatch (num=2, m=0xc23dc900) at /usr/src/sys/net/netisr.c:185 #11 0xc05bf581 in ether_demux (ifp=0xc20a4800, m=0xc23dc900) at /usr/src/sys/net/if_ethersubr.c:834 #12 0xc05bf973 in ether_input (ifp=0xc20a4800, m=0xc23dc900) at /usr/src/sys/net/if_ethersubr.c:692 #13 0xc04b8749 in sis_rxeof (sc=0xc2093800) at /usr/src/sys/dev/sis/if_sis.c:1476 #14 0xc04b8973 in sis_intr (arg=0xc2093800) at /usr/src/sys/dev/sis/if_sis.c:1667 #15 0xc050344b in ithread_loop (arg=0xc20ab410) at /usr/src/sys/kern/kern_intr.c:1126 #16 0xc04ffe36 in fork_exit (callout=0xc05032a0 , arg=0xc20ab410, frame=0xc1f15d38) at /usr/src/sys/kern/kern_fork.c:811 #17 0xc06d9180 in fork_trampoline () at /usr/src/sys/i386/i386/exception.s:271 (kgdb) list *0xc0572e48 0xc0572e48 is in m_copydata (libkern.h:61). 56 static __inline int imax(int a, int b) { return (a > b ? a : b); } 57 static __inline int imin(int a, int b) { return (a < b ? a : b); } 58 static __inline long lmax(long a, long b) { return (a > b ? a : b); } 59 static __inline long lmin(long a, long b) { return (a < b ? a : b); } 60 static __inline u_int max(u_int a, u_int b) { return (a > b ? a : b); } 61 static __inline u_int min(u_int a, u_int b) { return (a < b ? a : b); } 62 static __inline quad_t qmax(quad_t a, quad_t b) { return (a > b ? a : b); } 63 static __inline quad_t qmin(quad_t a, quad_t b) { return (a < b ? a : b); } 64 static __inline u_long ulmax(u_long a, u_long b) { return (a > b ? a : b); } 65 static __inline u_long ulmin(u_long a, u_long b) { return (a < b ? a : b); } (kgdb) frame 7 #7 0xc0572e48 in m_copydata (m=0x0, off=0, len=40, cp=0xc23cced8 "\203??b??\237\f)h?M\220\224?\023?\205K(e??s?\"???k?oQ?~\223\020g\030") at /usr/src/sys/kern/uipc_mbuf.c:815 815 count = min(m->m_len - off, len); (kgdb) l 810 off -= m->m_len; 811 m = m->m_next; 812 } 813 while (len > 0) { 814 KASSERT(m != NULL, ("m_copydata, length > size of mbuf chain")); 815 count = min(m->m_len - off, len); 816 bcopy(mtod(m, caddr_t) + off, cp, count); 817 len -= count; 818 cp += count; 819 off = 0; Looking forward to suggestions what may be causing this. Thanks, Florian From owner-freebsd-stable@FreeBSD.ORG Thu Jan 21 13:12: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 6C6E710656BB for ; Thu, 21 Jan 2010 13:12:56 +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 3FEED8FC08 for ; Thu, 21 Jan 2010 13:12:56 +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 E76BF46B51; Thu, 21 Jan 2010 08:12:55 -0500 (EST) Received: from jhbbsd.localnet (smtp.hudson-trading.com [209.249.190.9]) by bigwig.baldwin.cx (Postfix) with ESMTPA id 478198A028; Thu, 21 Jan 2010 08:12:55 -0500 (EST) From: John Baldwin To: freebsd-stable@freebsd.org Date: Thu, 21 Jan 2010 08:00:02 -0500 User-Agent: KMail/1.12.1 (FreeBSD/7.2-CBSD-20091231; KDE/4.3.1; amd64; ; ) References: In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201001210800.02417.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (bigwig.baldwin.cx); Thu, 21 Jan 2010 08:12:55 -0500 (EST) X-Virus-Scanned: clamav-milter 0.95.1 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.6 required=4.2 tests=AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on bigwig.baldwin.cx Cc: Charles Sprickman Subject: Re: 32-bit jails on a 64-bit system? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jan 2010 13:12:56 -0000 On Thursday 21 January 2010 1:51:36 am Charles Sprickman wrote: > Howdy, > > I saw this little tidbit in the 8.0 Release Notes... > > ---- > The jail(8) subsystem has been updated. Changes include: > > Compatibility support which permits 32-bit jail binaries to be used on > 64-bit systems to manage jails has been added. > ---- > > I know prior to 8.0 with some fancy footwork you could do some interesting > things (for example, I have a jail running a bunch of 32-bit 4.11 stuff on > a 7.2 amd64 box), but it was not easy. The comment is a bit misleading, it just means you can use an i386 /usr/sbin/jail binary on an amd64 system (presumably the same is true for other jail-related programs like jls). It's probably not useful for the vast majority of folks. Perhaps with nested jails it could be useful as a 32-bit jail on a 64-bit host can create child jails w/o needing to copy the 64-bit jail binary from the host into the jail. There are still several binaries such as ps that need to be 64-bit, even in a 32-bit jail. -- John Baldwin From owner-freebsd-stable@FreeBSD.ORG Thu Jan 21 13:12: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 E1AB9106566C for ; Thu, 21 Jan 2010 13:12:57 +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 B638F8FC16 for ; Thu, 21 Jan 2010 13:12:57 +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 6ACEE46B5B; Thu, 21 Jan 2010 08:12:57 -0500 (EST) Received: from jhbbsd.localnet (smtp.hudson-trading.com [209.249.190.9]) by bigwig.baldwin.cx (Postfix) with ESMTPA id 5E0ED8A025; Thu, 21 Jan 2010 08:12:56 -0500 (EST) From: John Baldwin To: freebsd-stable@freebsd.org Date: Thu, 21 Jan 2010 08:01:48 -0500 User-Agent: KMail/1.12.1 (FreeBSD/7.2-CBSD-20091231; KDE/4.3.1; amd64; ; ) References: <4B58280C.50602@smeets.im> In-Reply-To: <4B58280C.50602@smeets.im> MIME-Version: 1.0 Message-Id: <201001210801.48390.jhb@freebsd.org> Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (bigwig.baldwin.cx); Thu, 21 Jan 2010 08:12:56 -0500 (EST) X-Virus-Scanned: clamav-milter 0.95.1 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.3 required=4.2 tests=AWL,BAYES_00,RAZOR2_CHECK autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on bigwig.baldwin.cx Cc: Florian Smeets Subject: Re: 7.2-STABLE page fault with kernel from 12.01.2010 / crashinfo available X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 21 Jan 2010 13:12:58 -0000 On Thursday 21 January 2010 5:10:20 am Florian Smeets wrote: > Hi, > > this firewall has been running happily with a kernel from August 8th > 2009 and has only been rebooted to upgrade world/kernel on Jan 12th > 2010, after only 7 days of uptime i got the page fault further down. > > There are quite a few services on this firewall it has 4 physical > (sis(4)) interfaces of which all are used, 3 for Ethernet and one for > PPPoE via mpd5, it uses a gif interface for IPv6 tunneling via IPv4, and > a few IPsec tunnels are also configured and heavily used. arpwatch is > beeing run on 2 of the ethernet interfaces so they are always in > promiscuous mode, as a packet filter pf with altq is used. > > The crashinfo file can be found here > http://webmail.smeets.im/~flo/crashinfo.txt > > Fatal trap 12: page fault while in kernel mode > fault virtual address = 0xc > fault code = supervisor read, page not present > instruction pointer = 0x20:0xc0572e48 > stack pointer = 0x28:0xc1f15b24 > frame pointer = 0x28:0xc1f15b40 > code segment = base 0x0, limit 0xfffff, type 0x1b > = DPL 0, pres 1, def32 1, gran 1 > processor eflags = interrupt enabled, resume, IOPL = 0 > current process = 21 (irq5: sis0) > trap number = 12 > panic: page fault > Uptime: 7d21h44m23s > Physical memory: 245 MB > Dumping 65 MB: 50 34 18 2 > > #0 doadump () at pcpu.h:196 > 196 pcpu.h: No such file or directory. > in pcpu.h > (kgdb) where > #0 doadump () at pcpu.h:196 > #1 0xc0525703 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:418 > #2 0xc052590e in panic (fmt=Variable "fmt" is not available. > ) at /usr/src/sys/kern/kern_shutdown.c:574 > #3 0xc06f110c in trap_fatal (frame=0xc1f15ae4, eva=12) at > /usr/src/sys/i386/i386/trap.c:950 > #4 0xc06f1390 in trap_pfault (frame=0xc1f15ae4, usermode=0, eva=12) at > /usr/src/sys/i386/i386/trap.c:863 > #5 0xc06f1d65 in trap (frame=0xc1f15ae4) at > /usr/src/sys/i386/i386/trap.c:541 > #6 0xc06d910b in calltrap () at /usr/src/sys/i386/i386/exception.s:166 > #7 0xc0572e48 in m_copydata (m=0x0, off=0, len=40, cp=0xc23cced8 > "\203??b??\237\f)h?M\220\224?\023?\205K(e??s?\"???k?oQ?~\223\020g\030") > at /usr/src/sys/kern/uipc_mbuf.c:815 > #8 0xc05f8b28 in ip_forward (m=0xc23dc900, srcrt=0) at > /usr/src/sys/netinet/ip_input.c:1307 > #9 0xc05fa30c in ip_input (m=0xc23dc900) at > /usr/src/sys/netinet/ip_input.c:609 > #10 0xc05c83d5 in netisr_dispatch (num=2, m=0xc23dc900) at > /usr/src/sys/net/netisr.c:185 > #11 0xc05bf581 in ether_demux (ifp=0xc20a4800, m=0xc23dc900) at > /usr/src/sys/net/if_ethersubr.c:834 > #12 0xc05bf973 in ether_input (ifp=0xc20a4800, m=0xc23dc900) at > /usr/src/sys/net/if_ethersubr.c:692 > #13 0xc04b8749 in sis_rxeof (sc=0xc2093800) at > /usr/src/sys/dev/sis/if_sis.c:1476 > #14 0xc04b8973 in sis_intr (arg=0xc2093800) at > /usr/src/sys/dev/sis/if_sis.c:1667 > #15 0xc050344b in ithread_loop (arg=0xc20ab410) at > /usr/src/sys/kern/kern_intr.c:1126 > #16 0xc04ffe36 in fork_exit (callout=0xc05032a0 , > arg=0xc20ab410, frame=0xc1f15d38) at /usr/src/sys/kern/kern_fork.c:811 > #17 0xc06d9180 in fork_trampoline () at > /usr/src/sys/i386/i386/exception.s:271 > (kgdb) list *0xc0572e48 > 0xc0572e48 is in m_copydata (libkern.h:61). > 56 static __inline int imax(int a, int b) { return (a > b ? a : b); } > 57 static __inline int imin(int a, int b) { return (a < b ? a : b); } > 58 static __inline long lmax(long a, long b) { return (a > b ? a : b); } > 59 static __inline long lmin(long a, long b) { return (a < b ? a : b); } > 60 static __inline u_int max(u_int a, u_int b) { return (a > b ? a : b); } > 61 static __inline u_int min(u_int a, u_int b) { return (a < b ? a : b); } > 62 static __inline quad_t qmax(quad_t a, quad_t b) { return (a > b ? a : > b); } > 63 static __inline quad_t qmin(quad_t a, quad_t b) { return (a < b ? a : > b); } > 64 static __inline u_long ulmax(u_long a, u_long b) { return (a > b ? a > : b); } > 65 static __inline u_long ulmin(u_long a, u_long b) { return (a < b ? a > : b); } > (kgdb) frame 7 > #7 0xc0572e48 in m_copydata (m=0x0, off=0, len=40, cp=0xc23cced8 > "\203??b??\237\f)h?M\220\224?\023?\205K(e??s?\"???k?oQ?~\223\020g\030") > at /usr/src/sys/kern/uipc_mbuf.c:815 > 815 count = min(m->m_len - off, len); > (kgdb) l > 810 off -= m->m_len; > 811 m = m->m_next; > 812 } > 813 while (len > 0) { > 814 KASSERT(m != NULL, ("m_copydata, length > size of mbuf chain")); I think you would have hit this assertion if INVARIANTS were enabled. Can you go up to frame 8 and do an 'l'? Maybe 'p *m' as well? -- John Baldwin From owner-freebsd-stable@FreeBSD.ORG Thu Jan 21 13:25: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 DF035106566B; Thu, 21 Jan 2010 13:25:26 +0000 (UTC) (envelope-from flo@smeets.im) Received: from mail.solomo.de (mail.solomo.de [85.214.124.163]) by mx1.freebsd.org (Postfix) with ESMTP id 7FE668FC0C; Thu, 21 Jan 2010 13:25:26 +0000 (UTC) Received: from mail.solomo.de (localhost [127.0.0.1]) by mail.solomo.de (Postfix) with ESMTP id 4FDD961C94; Thu, 21 Jan 2010 14:25:25 +0100 (CET) X-Virus-Scanned: amavisd-new at vistream.de Received: from mail.solomo.de ([127.0.0.1]) by mail.solomo.de (mail.solomo.de [127.0.0.1]) (amavisd-new, port 10024) with LMTP id EuYkhX4dC22e; Thu, 21 Jan 2010 14:25:23 +0100 (CET) Received: from nibbler.vistream.local (relay3.vistream.de [87.139.10.28]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mail.solomo.de (Postfix) with ESMTPSA id 0813D61C2E; Thu, 21 Jan 2010 14:25:23 +0100 (CET) Message-ID: <4B5855C2.6000002@smeets.im> Date: Thu, 21 Jan 2010 14:25:22 +0100 From: Florian Smeets User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2pre) Gecko/20100120 Lanikai/3.1b1pre MIME-Version: 1.0 To: John Baldwin References: <4B58280C.50602@smeets.im> <201001210801.48390.jhb@freebsd.org> In-Reply-To: <201001210801.48390.jhb@freebsd.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: freebsd-stable@freebsd.org Subject: Re: 7.2-STABLE page fault with kernel from 12.01.2010 / crashinfo available X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 21 Jan 2010 13:25:27 -0000 On 1/21/10 2:01 PM, John Baldwin wrote: > On Thursday 21 January 2010 5:10:20 am Florian Smeets wrote: >> (kgdb) where >> #0 doadump () at pcpu.h:196 >> #1 0xc0525703 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:418 >> #2 0xc052590e in panic (fmt=Variable "fmt" is not available. >> ) at /usr/src/sys/kern/kern_shutdown.c:574 >> #3 0xc06f110c in trap_fatal (frame=0xc1f15ae4, eva=12) at >> /usr/src/sys/i386/i386/trap.c:950 >> #4 0xc06f1390 in trap_pfault (frame=0xc1f15ae4, usermode=0, eva=12) at >> /usr/src/sys/i386/i386/trap.c:863 >> #5 0xc06f1d65 in trap (frame=0xc1f15ae4) at >> /usr/src/sys/i386/i386/trap.c:541 >> #6 0xc06d910b in calltrap () at /usr/src/sys/i386/i386/exception.s:166 >> #7 0xc0572e48 in m_copydata (m=0x0, off=0, len=40, cp=0xc23cced8 >> "\203??b??\237\f)h?M\220\224?\023?\205K(e??s?\"???k?oQ?~\223\020g\030") >> at /usr/src/sys/kern/uipc_mbuf.c:815 >> #8 0xc05f8b28 in ip_forward (m=0xc23dc900, srcrt=0) at >> /usr/src/sys/netinet/ip_input.c:1307 >> #9 0xc05fa30c in ip_input (m=0xc23dc900) at >> /usr/src/sys/netinet/ip_input.c:609 >> #10 0xc05c83d5 in netisr_dispatch (num=2, m=0xc23dc900) at >> /usr/src/sys/net/netisr.c:185 >> #11 0xc05bf581 in ether_demux (ifp=0xc20a4800, m=0xc23dc900) at >> /usr/src/sys/net/if_ethersubr.c:834 >> #12 0xc05bf973 in ether_input (ifp=0xc20a4800, m=0xc23dc900) at >> /usr/src/sys/net/if_ethersubr.c:692 >> #13 0xc04b8749 in sis_rxeof (sc=0xc2093800) at >> /usr/src/sys/dev/sis/if_sis.c:1476 >> #14 0xc04b8973 in sis_intr (arg=0xc2093800) at >> /usr/src/sys/dev/sis/if_sis.c:1667 >> #15 0xc050344b in ithread_loop (arg=0xc20ab410) at >> /usr/src/sys/kern/kern_intr.c:1126 >> #16 0xc04ffe36 in fork_exit (callout=0xc05032a0, >> arg=0xc20ab410, frame=0xc1f15d38) at /usr/src/sys/kern/kern_fork.c:811 >> #17 0xc06d9180 in fork_trampoline () at >> /usr/src/sys/i386/i386/exception.s:271 >> (kgdb) list *0xc0572e48 >> 0xc0572e48 is in m_copydata (libkern.h:61). >> 56 static __inline int imax(int a, int b) { return (a> b ? a : b); } >> 57 static __inline int imin(int a, int b) { return (a< b ? a : b); } >> 58 static __inline long lmax(long a, long b) { return (a> b ? a : b); } >> 59 static __inline long lmin(long a, long b) { return (a< b ? a : b); } >> 60 static __inline u_int max(u_int a, u_int b) { return (a> b ? a : b); } >> 61 static __inline u_int min(u_int a, u_int b) { return (a< b ? a : b); } >> 62 static __inline quad_t qmax(quad_t a, quad_t b) { return (a> b ? a : >> b); } >> 63 static __inline quad_t qmin(quad_t a, quad_t b) { return (a< b ? a : >> b); } >> 64 static __inline u_long ulmax(u_long a, u_long b) { return (a> b ? a >> : b); } >> 65 static __inline u_long ulmin(u_long a, u_long b) { return (a< b ? a >> : b); } >> (kgdb) frame 7 >> #7 0xc0572e48 in m_copydata (m=0x0, off=0, len=40, cp=0xc23cced8 >> "\203??b??\237\f)h?M\220\224?\023?\205K(e??s?\"???k?oQ?~\223\020g\030") >> at /usr/src/sys/kern/uipc_mbuf.c:815 >> 815 count = min(m->m_len - off, len); >> (kgdb) l >> 810 off -= m->m_len; >> 811 m = m->m_next; >> 812 } >> 813 while (len> 0) { >> 814 KASSERT(m != NULL, ("m_copydata, length> size of mbuf chain")); > > I think you would have hit this assertion if INVARIANTS were enabled. Can you > go up to frame 8 and do an 'l'? Maybe 'p *m' as well? > Sure, thanks for taking a look John! (kgdb) frame 8 #8 0xc05f8b28 in ip_forward (m=0xc23dc900, srcrt=0) at /usr/src/sys/netinet/ip_input.c:1307 1307 m_copydata(m, 0, mcopy->m_len, mtod(mcopy, caddr_t)); (kgdb) l 1302 mcopy = NULL; 1303 } 1304 if (mcopy != NULL) { 1305 mcopy->m_len = min(ip->ip_len, M_TRAILINGSPACE(mcopy)); 1306 mcopy->m_pkthdr.len = mcopy->m_len; 1307 m_copydata(m, 0, mcopy->m_len, mtod(mcopy, caddr_t)); 1308 } 1309 1310 #ifdef IPSTEALTH 1311 if (!ipstealth) { (kgdb) p *m $1 = {m_hdr = {mh_next = 0x0, mh_nextpkt = 0x0, mh_data = 0xc271e80e "E\020", mh_len = 164, mh_flags = 3, mh_type = 1, pad = "\000"}, M_dat = {MH = {MH_pkthdr = {rcvif = 0xc20a4800, header = 0x0, len = 164, csum_flags = 3072, csum_data = 65535, tso_segsz = 0, ether_vtag = 0, tags = {slh_first = 0xc35bc380}}, MH_dat = {MH_ext = {ext_buf = 0xc271e800 "", ext_free = 0, ext_args = 0x0, ext_size = 2048, ref_cnt = 0xc2703ab4, ext_type = 6}, MH_databuf = "\000?q?\000\000\000\000\000\000\000\000\000\b\000\000?:p?\006\000\000\000dL?\t<+?\202\200\020 O/\207\000\000\001\001\b\n-?b\230qms?\000\000\004\001?l?\000\000\001%r???\200\000????\034?Ot?\b?{sr\000\034org.jboss.mq.ConnectionToken?\b߼&?\237N\002\000\005I\000\004hashZ\000\asameJVML\000\bclientIDt\000\022Ljava/l\000\220\032Ae\207\000\002?36@\210d\021\000\001?\001B\000!E\000\001@bV\000\000@2\032$W\213\n\034"...}}, M_databuf = "\000H\n?\000\000\000\000?\000\000\000\000\f\000\000??\000\000\000\000\000\000\200?[?\000?q?\000\000\000\000\000\000\000\000\000\b\000\000?:p?\006\000\000\000dL?\t<+?\202\200\020 O/\207\000\000\001\001\b\n-?b\230qms?\000\000\004\001?l?\000\000\001%r???\200\000????\034?Ot?\b?{sr\000\034org.jboss.mq.ConnectionToken?\b߼&?\237N\002\000\005I\000\004hashZ\000\asameJVML\000\bclientIDt\000\022Ljava/l\000\220\032Ae\207\000\002?3"...}} Cheers, Florian From owner-freebsd-stable@FreeBSD.ORG Thu Jan 21 13:56: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 4285A106566B for ; Thu, 21 Jan 2010 13:56:14 +0000 (UTC) (envelope-from andrew.hotlab@hotmail.com) Received: from blu0-omc1-s25.blu0.hotmail.com (blu0-omc1-s25.blu0.hotmail.com [65.55.116.36]) by mx1.freebsd.org (Postfix) with ESMTP id 0EE0A8FC19 for ; Thu, 21 Jan 2010 13:56:13 +0000 (UTC) Received: from BLU138-W12 ([65.55.116.8]) by blu0-omc1-s25.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 21 Jan 2010 05:44:11 -0800 Message-ID: X-Originating-IP: [81.174.54.98] From: Andrew Hotlab To: <000.fbsd@quip.cz>, Date: Thu, 21 Jan 2010 13:44:11 +0000 Importance: Normal In-Reply-To: <4B581A74.5060000@quip.cz> References: , <4B581A74.5060000@quip.cz> Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 21 Jan 2010 13:44:11.0713 (UTC) FILETIME=[D0359310:01CA9A9F] Cc: freebsd-jail@freebsd.org, freebsd-stable@freebsd.org Subject: RE: 32-bit jails on a 64-bit system? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jan 2010 13:56:14 -0000 ---------------------------------------- > Date: Thu=2C 21 Jan 2010 10:12:20 +0100 > From: 000.fbsd@quip.cz > To: spork@bway.net > CC: freebsd-jail@FreeBSD.org=3B freebsd-stable@freebsd.org > Subject: Re: 32-bit jails on a 64-bit system? > >> The jail(8) subsystem has been updated. Changes include: >> >> Compatibility support which permits 32-bit jail binaries to be used on >> 64-bit systems to manage jails has been added. >> ---- >> >> I know prior to 8.0 with some fancy footwork you could do some >> interesting things (for example=2C I have a jail running a bunch of 32-b= it >> 4.11 stuff on a 7.2 amd64 box)=2C but it was not easy. >> >> Looking at the jail manpage and handbook entries=2C I'm not seeing >> anything that further explains the changes. I've been able to get some >> things working in a test setup=2C but not everything. Any pointers to wh= at >> exactly that blurb in the release notes actually means? Google is >> getting me nowhere. >> > > (freebsd-jail@ was added in to Cc:) > > I think it is nothing new to 8.0=2C it is the same as release note for 7.= 2. > > I didn't test it=2C but I think you can install (copy) i386 jail (or whol= e > system) in to amd64 host and just run it as any other jail. > It might be useful this thread about 32-bit jail on 64-bit host: http://lists.freebsd.org/pipermail/freebsd-i386/2009-January/007553.html Regards. Andrew =20 _________________________________________________________________ Windows Live Hotmail: Your friends can get your Facebook updates=2C right f= rom Hotmail=AE. http://www.microsoft.com/middleeast/windows/windowslive/see-it-in-action/so= cial-network-basics.aspx?ocid=3DPID23461::T:WLMTAGL:ON:WL:en-xm:SI_SB_4:092= 009= From owner-freebsd-stable@FreeBSD.ORG Thu Jan 21 14:53: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 B3599106566B for ; Thu, 21 Jan 2010 14:53:30 +0000 (UTC) (envelope-from wjw@digiware.nl) Received: from mail.digiware.nl (mail.ip6.digiware.nl [IPv6:2001:4cb8:1:106::2]) by mx1.freebsd.org (Postfix) with ESMTP id 527498FC0C for ; Thu, 21 Jan 2010 14:53:30 +0000 (UTC) Received: from localhost (localhost.digiware.nl [127.0.0.1]) by mail.digiware.nl (Postfix) with ESMTP id 6DF0B153433 for ; Thu, 21 Jan 2010 15:53:28 +0100 (CET) X-Virus-Scanned: amavisd-new at digiware.nl Received: from mail.digiware.nl ([127.0.0.1]) by localhost (rack1.digiware.nl [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OIcYkoENqn8C; Thu, 21 Jan 2010 15:53:26 +0100 (CET) Received: from [192.168.254.10] (unknown [192.168.254.10]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.digiware.nl (Postfix) with ESMTPSA id 59A3A15342F for ; Thu, 21 Jan 2010 15:53:26 +0100 (CET) Message-ID: <4B586A63.9080209@digiware.nl> Date: Thu, 21 Jan 2010 15:53:23 +0100 From: Willem Jan Withagen User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: FreeBSD Stable Users References: <4B572F4E.4010503@digiware.nl> In-Reply-To: <4B572F4E.4010503@digiware.nl> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: run_interrupt_driven_hooks: still waiting... for xpt_config X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 21 Jan 2010 14:53:30 -0000 Willem Jan Withagen wrote: > I'm trying to revive an old dual optern Tyan Tomcat S2875 board. Even > upgraded it to the most recent BIOS. But still no go. > Both with 8.0 and 7.2 RELEASE. > > I've also disabled P1394 and all USB in the BIOS, that did not work either. > Only thing that is "extra" in the box is a an Areca 1120 controller. Moved the bootable disk to an default SATA port on the MB, and removed the Areca controller. That gets ride of the problem, but it also creates a new problem since I'd like to use the controller to handle a bunch of backup-disks. Suggestions on how to get the Areca controller passed the xpt_config test are welcomed. --WjW From owner-freebsd-stable@FreeBSD.ORG Thu Jan 21 16:26: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 B10D01065679; Thu, 21 Jan 2010 16:26:51 +0000 (UTC) (envelope-from uqs@spoerlein.net) Received: from acme.spoerlein.net (acme.spoerlein.net [IPv6:2a01:198:206::1]) by mx1.freebsd.org (Postfix) with ESMTP id 3375F8FC16; Thu, 21 Jan 2010 16:26:51 +0000 (UTC) Received: from acme.spoerlein.net (localhost.spoerlein.net [IPv6:::1]) by acme.spoerlein.net (8.14.3/8.14.3) with ESMTP id o0LGQoSA041942 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 21 Jan 2010 17:26:50 +0100 (CET) (envelope-from uqs@spoerlein.net) Received: (from uqs@localhost) by acme.spoerlein.net (8.14.3/8.14.3/Submit) id o0LGQojb041941; Thu, 21 Jan 2010 17:26:50 +0100 (CET) (envelope-from uqs@spoerlein.net) Date: Thu, 21 Jan 2010 17:26:50 +0100 From: Ulrich =?utf-8?B?U3DDtnJsZWlu?= To: Marin Atanasov Message-ID: <20100121162649.GP96430@acme.spoerlein.net> Mail-Followup-To: Marin Atanasov , freebsd-hardware@freebsd.org, freebsd-stable@freebsd.org References: <717f7a3e1001120714m37aada69gfaa35f0f9b17f435@mail.gmail.com> <44678539@bb.ipt.ru> <717f7a3e1001142234y1de7ae15x6853e3ddcab4add9@mail.gmail.com> <717f7a3e1001192246o4dce4a82q57c05ff3f41b5feb@mail.gmail.com> <20100120074611.GA405@icarus.home.lan> <717f7a3e1001210137p7884adcbxc66a4f7fff928821@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <717f7a3e1001210137p7884adcbxc66a4f7fff928821@mail.gmail.com> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: freebsd-stable@freebsd.org, freebsd-hardware@freebsd.org Subject: Re: Multiple serial consoles via null modem cable X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 21 Jan 2010 16:26:51 -0000 On Thu, 21.01.2010 at 11:37:06 +0200, Marin Atanasov wrote: > Here's what I did: > > box1 COM1/ttyd0 -> box2 COM1/ttyd0 -> using null modem cable > box1 COM2/ttyd1 -> box3 COM1/ttyd0 -> using null modem cable > > On box1 I have this in /etc/ttys: > > ttyd0 "/usr/libexec/getty std.9600" vt100 on secure > ttyd1 "/usr/libexec/getty std.9600" vt100 on secure > > Now if I want to connect to box1 from box2 or box3 through the serial > connection it should work, right? > But I only can connect to box1 from box2, because box2's COM port is > connected to box1's COM1 port. Are there actually two gettys running on the serial ports? Did you do kill -1 1 after the changes to /etc/ttys? On box1, what do the following commands produce egrep "uart|sio" /var/run/dmesg.boot pgrep -fl getty Regards, Uli From owner-freebsd-stable@FreeBSD.ORG Thu Jan 21 16:50: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 51B231065679 for ; Thu, 21 Jan 2010 16:50:09 +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 0C8548FC13 for ; Thu, 21 Jan 2010 16:50:08 +0000 (UTC) Received: from list by lo.gmane.org with local (Exim 4.50) id 1NY0EP-0000wJ-Fb for freebsd-stable@freebsd.org; Thu, 21 Jan 2010 17:50:05 +0100 Received: from static-195-248-102-183.adsl.hotchilli.net ([195.248.102.183]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 21 Jan 2010 17:50:05 +0100 Received: from david000 by static-195-248-102-183.adsl.hotchilli.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 21 Jan 2010 17:50:05 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-stable@freebsd.org From: David Murray Date: Thu, 21 Jan 2010 16:36:12 +0000 Lines: 45 Message-ID: References: <659350866.20100120151602@mail.ru> <4B5703A3.6010507@cyb0rg.org> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: static-195-248-102-183.adsl.hotchilli.net User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.9.1.7) Gecko/20100111 Thunderbird/3.0.1 In-Reply-To: <4B5703A3.6010507@cyb0rg.org> Sender: news Subject: Re: IPSec NAT-T in transport 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: Thu, 21 Jan 2010 16:50:09 -0000 Chaps, On 10-01-20 Wed 1:04 pm, VANHULLEBUS Yvan wrote: > On Wed, Jan 20, 2010 at 03:16:02PM +0600, Rabidinov M.A. wrote: > >> Does FreeBSD 8.0 support IPSec NAT-T in transport mode? >> I want to create a L2TP/IPSec server. My VPN clients are NATed. >> L2TP server (MPD5.x) makes tunnel, so I need working IPSec NAT-T in >> transport mode. > > It may work..... or not.... > > The missing part is support of NAT-OA payloads, which are used to > update checksums when receiving packets. > > But afaik, most L2TP implementations computes checksums, so they will > be checked, and of course will be wrong.... On 2010-01-20 Wed 1:22 pm, Crest wrote: > Yes the NAT-T Patch has been integrated into FreeBSD 8.0. > > Just rebuild your kernel with this options: > device crypto # IPsec depends on this > options IPSEC > options IPSEC_DEBUG > options IPSEC_NAT_T I'm trying to do the same thing as the OP, so thanks for these replies. However, they seem to be at odds. Are we saying that the NAT-T patch is there, but is missing checksum re-calculation, so MPD's packets are going to be discarded? (FWIW, this seems to be what happens. All the negotiation to set up IPSEC SAs happens, but MPD's log never shows a single entry. I hadn't got as far as packet dumps when this thread popped up.) -- David Murray From owner-freebsd-stable@FreeBSD.ORG Thu Jan 21 17:41: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 6D89F1065672 for ; Thu, 21 Jan 2010 17:41:33 +0000 (UTC) (envelope-from boydjd@jbip.net) Received: from mail-bw0-f214.google.com (mail-bw0-f214.google.com [209.85.218.214]) by mx1.freebsd.org (Postfix) with ESMTP id 0C1868FC0C for ; Thu, 21 Jan 2010 17:41:31 +0000 (UTC) Received: by bwz6 with SMTP id 6so288885bwz.31 for ; Thu, 21 Jan 2010 09:41:31 -0800 (PST) MIME-Version: 1.0 Received: by 10.239.192.65 with SMTP id d1mr202879hbi.197.1264094238221; Thu, 21 Jan 2010 09:17:18 -0800 (PST) From: Joshua Boyd Date: Thu, 21 Jan 2010 12:16:58 -0500 Message-ID: <33c6b0bc1001210916u2131713do712e23ddaaa40cde@mail.gmail.com> To: freebsd-stable@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: install: amdsbwd.ko: No such file or directory X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 21 Jan 2010 17:41:33 -0000 make buildkernel KERNCONF=CUSTOM fails on latest 8-STABLE. Here's the diff between GENERIC and CUSTOM: $ diff GENERIC CUSTOM 323a324,343 > > # pf support > device mem > device pf > device pflog > device pfsync > > # altq support > options ALTQ > options ALTQ_CBQ > options ALTQ_RED > options ALTQ_RIO > options ALTQ_HFSC > options ALTQ_PRIQ > options ALTQ_NOPCC > > # other optimizations > device amdsbwd #Only added to see if this would help > options HZ=1000 > options DEVICE_POLLING buildkernel fails out with: install: amdsbwd.ko: No such file or directory Any help would be appreciated. cvsup was done last night. Let me know if any additional info is needed. -- Joshua Boyd JBipNet E-mail: boydjd@jbip.net http://www.jbip.net From owner-freebsd-stable@FreeBSD.ORG Thu Jan 21 17:52: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 51FAB1065679 for ; Thu, 21 Jan 2010 17:52:29 +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 98A498FC12 for ; Thu, 21 Jan 2010 17:52:28 +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 TAA13020; Thu, 21 Jan 2010 19:52:23 +0200 (EET) (envelope-from avg@icyb.net.ua) Message-ID: <4B589457.2060008@icyb.net.ua> Date: Thu, 21 Jan 2010 19:52:23 +0200 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.23 (X11/20091206) MIME-Version: 1.0 To: Joshua Boyd References: <33c6b0bc1001210916u2131713do712e23ddaaa40cde@mail.gmail.com> In-Reply-To: <33c6b0bc1001210916u2131713do712e23ddaaa40cde@mail.gmail.com> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org Subject: Re: install: amdsbwd.ko: No such file or directory X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 21 Jan 2010 17:52:29 -0000 on 21/01/2010 19:16 Joshua Boyd said the following: > make buildkernel KERNCONF=CUSTOM fails on latest 8-STABLE. > > Here's the diff between GENERIC and CUSTOM: > $ diff GENERIC CUSTOM > 323a324,343 >> # pf support >> device mem >> device pf >> device pflog >> device pfsync >> >> # altq support >> options ALTQ >> options ALTQ_CBQ >> options ALTQ_RED >> options ALTQ_RIO >> options ALTQ_HFSC >> options ALTQ_PRIQ >> options ALTQ_NOPCC >> >> # other optimizations >> device amdsbwd #Only added to see if this would help >> options HZ=1000 >> options DEVICE_POLLING > > buildkernel fails out with: > > install: amdsbwd.ko: No such file or directory > > Any help would be appreciated. cvsup was done last night. Let me know if any > additional info is needed. Hmm, I didn't think that buildkernel executes install.. Could you provide a little bit more context from the build? -- Andriy Gapon From owner-freebsd-stable@FreeBSD.ORG Thu Jan 21 17:54: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 AF10F10656BC for ; Thu, 21 Jan 2010 17:54:48 +0000 (UTC) (envelope-from boydjd@jbip.net) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.159]) by mx1.freebsd.org (Postfix) with ESMTP id 4F71C8FC0C for ; Thu, 21 Jan 2010 17:54:47 +0000 (UTC) Received: by fg-out-1718.google.com with SMTP id 19so141457fgg.13 for ; Thu, 21 Jan 2010 09:54:47 -0800 (PST) MIME-Version: 1.0 Received: by 10.239.177.211 with SMTP id w19mr186230hbf.162.1264096486878; Thu, 21 Jan 2010 09:54:46 -0800 (PST) In-Reply-To: <4B589457.2060008@icyb.net.ua> References: <33c6b0bc1001210916u2131713do712e23ddaaa40cde@mail.gmail.com> <4B589457.2060008@icyb.net.ua> From: Joshua Boyd Date: Thu, 21 Jan 2010 12:54:25 -0500 Message-ID: <33c6b0bc1001210954q206401f4n51d97af7f861e99c@mail.gmail.com> Cc: freebsd-stable@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Re: install: amdsbwd.ko: No such file or directory X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 21 Jan 2010 17:54:48 -0000 I'm sorry, it's installkernel that fails. I'll provide more details tonight when I get home from work. On Thu, Jan 21, 2010 at 12:52 PM, Andriy Gapon wrote: > on 21/01/2010 19:16 Joshua Boyd said the following: > > make buildkernel KERNCONF=CUSTOM fails on latest 8-STABLE. > > > > Here's the diff between GENERIC and CUSTOM: > > $ diff GENERIC CUSTOM > > 323a324,343 > >> # pf support > >> device mem > >> device pf > >> device pflog > >> device pfsync > >> > >> # altq support > >> options ALTQ > >> options ALTQ_CBQ > >> options ALTQ_RED > >> options ALTQ_RIO > >> options ALTQ_HFSC > >> options ALTQ_PRIQ > >> options ALTQ_NOPCC > >> > >> # other optimizations > >> device amdsbwd #Only added to see if this would help > >> options HZ=1000 > >> options DEVICE_POLLING > > > > buildkernel fails out with: > > > > install: amdsbwd.ko: No such file or directory > > > > Any help would be appreciated. cvsup was done last night. Let me know if > any > > additional info is needed. > > Hmm, I didn't think that buildkernel executes install.. > Could you provide a little bit more context from the build? > > -- > Andriy Gapon > -- Joshua Boyd JBipNet E-mail: boydjd@jbip.net Cell: (513) 375-0157 http://www.jbip.net From owner-freebsd-stable@FreeBSD.ORG Thu Jan 21 18:28: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 F41011065672 for ; Thu, 21 Jan 2010 18:28:32 +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 BC1FC8FC1A for ; Thu, 21 Jan 2010 18:28:32 +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 49E7D46B39; Thu, 21 Jan 2010 13:28:32 -0500 (EST) Received: from jhbbsd.localnet (smtp.hudson-trading.com [209.249.190.9]) by bigwig.baldwin.cx (Postfix) with ESMTPA id 67C628A026; Thu, 21 Jan 2010 13:28:31 -0500 (EST) From: John Baldwin To: Florian Smeets Date: Thu, 21 Jan 2010 12:58:40 -0500 User-Agent: KMail/1.12.1 (FreeBSD/7.2-CBSD-20091231; KDE/4.3.1; amd64; ; ) References: <4B58280C.50602@smeets.im> <201001210801.48390.jhb@freebsd.org> <4B5855C2.6000002@smeets.im> In-Reply-To: <4B5855C2.6000002@smeets.im> MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Message-Id: <201001211258.40316.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (bigwig.baldwin.cx); Thu, 21 Jan 2010 13:28:31 -0500 (EST) X-Virus-Scanned: clamav-milter 0.95.1 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.6 required=4.2 tests=AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on bigwig.baldwin.cx Cc: freebsd-stable@freebsd.org Subject: Re: 7.2-STABLE page fault with kernel from 12.01.2010 / crashinfo available X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 21 Jan 2010 18:28:33 -0000 On Thursday 21 January 2010 8:25:22 am Florian Smeets wrote: > On 1/21/10 2:01 PM, John Baldwin wrote: > > On Thursday 21 January 2010 5:10:20 am Florian Smeets wrote: > >> (kgdb) where > >> #0 doadump () at pcpu.h:196 > >> #1 0xc0525703 in boot (howto=3D260) at=20 /usr/src/sys/kern/kern_shutdown.c:418 > >> #2 0xc052590e in panic (fmt=3DVariable "fmt" is not available. > >> ) at /usr/src/sys/kern/kern_shutdown.c:574 > >> #3 0xc06f110c in trap_fatal (frame=3D0xc1f15ae4, eva=3D12) at > >> /usr/src/sys/i386/i386/trap.c:950 > >> #4 0xc06f1390 in trap_pfault (frame=3D0xc1f15ae4, usermode=3D0, eva= =3D12) at > >> /usr/src/sys/i386/i386/trap.c:863 > >> #5 0xc06f1d65 in trap (frame=3D0xc1f15ae4) at > >> /usr/src/sys/i386/i386/trap.c:541 > >> #6 0xc06d910b in calltrap () at /usr/src/sys/i386/i386/exception.s:166 > >> #7 0xc0572e48 in m_copydata (m=3D0x0, off=3D0, len=3D40, cp=3D0xc23cc= ed8 > >> "\203??b??\237\f)h?M\220\224?\023?\205K(e??s?\"???k?oQ?~\223\020g\030") > >> at /usr/src/sys/kern/uipc_mbuf.c:815 > >> #8 0xc05f8b28 in ip_forward (m=3D0xc23dc900, srcrt=3D0) at > >> /usr/src/sys/netinet/ip_input.c:1307 > >> #9 0xc05fa30c in ip_input (m=3D0xc23dc900) at > >> /usr/src/sys/netinet/ip_input.c:609 > >> #10 0xc05c83d5 in netisr_dispatch (num=3D2, m=3D0xc23dc900) at > >> /usr/src/sys/net/netisr.c:185 > >> #11 0xc05bf581 in ether_demux (ifp=3D0xc20a4800, m=3D0xc23dc900) at > >> /usr/src/sys/net/if_ethersubr.c:834 > >> #12 0xc05bf973 in ether_input (ifp=3D0xc20a4800, m=3D0xc23dc900) at > >> /usr/src/sys/net/if_ethersubr.c:692 > >> #13 0xc04b8749 in sis_rxeof (sc=3D0xc2093800) at > >> /usr/src/sys/dev/sis/if_sis.c:1476 > >> #14 0xc04b8973 in sis_intr (arg=3D0xc2093800) at > >> /usr/src/sys/dev/sis/if_sis.c:1667 > >> #15 0xc050344b in ithread_loop (arg=3D0xc20ab410) at > >> /usr/src/sys/kern/kern_intr.c:1126 > >> #16 0xc04ffe36 in fork_exit (callout=3D0xc05032a0, > >> arg=3D0xc20ab410, frame=3D0xc1f15d38) at /usr/src/sys/kern/kern_fork.c= :811 > >> #17 0xc06d9180 in fork_trampoline () at > >> /usr/src/sys/i386/i386/exception.s:271 > >> (kgdb) list *0xc0572e48 > >> 0xc0572e48 is in m_copydata (libkern.h:61). > >> 56 static __inline int imax(int a, int b) { return (a> b ? a : b); } > >> 57 static __inline int imin(int a, int b) { return (a< b ? a : b); } > >> 58 static __inline long lmax(long a, long b) { return (a> b ? a : b);= } > >> 59 static __inline long lmin(long a, long b) { return (a< b ? a : b);= } > >> 60 static __inline u_int max(u_int a, u_int b) { return (a> b ? a : b= );=20 } > >> 61 static __inline u_int min(u_int a, u_int b) { return (a< b ? a : b= );=20 } > >> 62 static __inline quad_t qmax(quad_t a, quad_t b) { return (a> b ? a= : > >> b); } > >> 63 static __inline quad_t qmin(quad_t a, quad_t b) { return (a< b ? a= : > >> b); } > >> 64 static __inline u_long ulmax(u_long a, u_long b) { return (a> b ? a > >> : b); } > >> 65 static __inline u_long ulmin(u_long a, u_long b) { return (a< b ? a > >> : b); } > >> (kgdb) frame 7 > >> #7 0xc0572e48 in m_copydata (m=3D0x0, off=3D0, len=3D40, cp=3D0xc23cc= ed8 > >> "\203??b??\237\f)h?M\220\224?\023?\205K(e??s?\"???k?oQ?~\223\020g\030") > >> at /usr/src/sys/kern/uipc_mbuf.c:815 > >> 815 count =3D min(m->m_len - off, len); > >> (kgdb) l > >> 810 off -=3D m->m_len; > >> 811 m =3D m->m_next; > >> 812 } > >> 813 while (len> 0) { > >> 814 KASSERT(m !=3D NULL, ("m_copydata, length> size of mbuf chain")= ); > > > > I think you would have hit this assertion if INVARIANTS were enabled. = Can=20 you > > go up to frame 8 and do an 'l'? Maybe 'p *m' as well? > > >=20 > Sure, thanks for taking a look John! >=20 > (kgdb) frame 8 > #8 0xc05f8b28 in ip_forward (m=3D0xc23dc900, srcrt=3D0) at=20 > /usr/src/sys/netinet/ip_input.c:1307 > 1307 m_copydata(m, 0, mcopy->m_len, mtod(mcopy, caddr_t)); > (kgdb) l > 1302 mcopy =3D NULL; > 1303 } > 1304 if (mcopy !=3D NULL) { > 1305 mcopy->m_len =3D min(ip->ip_len, M_TRAILINGSPACE(mcopy)); > 1306 mcopy->m_pkthdr.len =3D mcopy->m_len; > 1307 m_copydata(m, 0, mcopy->m_len, mtod(mcopy, caddr_t)); > 1308 } > 1309=09 > 1310 #ifdef IPSTEALTH > 1311 if (!ipstealth) { > (kgdb) p *m > $1 =3D {m_hdr =3D {mh_next =3D 0x0, mh_nextpkt =3D 0x0, mh_data =3D 0xc27= 1e80e=20 > "E\020", mh_len =3D 164, mh_flags =3D 3, mh_type =3D 1, pad =3D "\000"}, = M_dat =3D=20 > {MH =3D {MH_pkthdr =3D {rcvif =3D 0xc20a4800, header =3D 0x0, len =3D 164= ,=20 > csum_flags =3D 3072, > csum_data =3D 65535, tso_segsz =3D 0, ether_vtag =3D 0, tags =3D= =20 > {slh_first =3D 0xc35bc380}}, MH_dat =3D {MH_ext =3D {ext_buf =3D 0xc271e8= 00 "",=20 > ext_free =3D 0, ext_args =3D 0x0, ext_size =3D 2048, ref_cnt =3D 0xc2703a= b4,=20 > ext_type =3D 6}, > MH_databuf =3D=20 > "\000?q?\000\000\000\000\000\000\000\000\000\b\000\000?:p? \006\000\000\000dL?\t<+?\202\200\020=20 > O/\207\000\000\001\001\b\n-?b\230qms?\000\000\004\001?l?\000\000\001%r??? \200\000????\034?Ot?\b?{sr\000\034org.jboss.mq.ConnectionToken?\b=DF=BC&? \237N\002\000\005I\000\004hashZ\000\asameJVML\000\bclientIDt\000\022Ljava/l= \000\220\032Ae\207\000\002? 36@\210d\021\000\001?\001B\000!E\000\001@bV\000\000@2\032$W\213\n\034"...}}= ,=20 >=20 > M_databuf =3D=20 > "\000H\n?\000\000\000\000?\000\000\000\000\f\000\000?? \000\000\000\000\000\000\200?[?\000?q? \000\000\000\000\000\000\000\000\000\b\000\000?:p?\006\000\000\000dL?\t<+? \202\200\020=20 > O/\207\000\000\001\001\b\n-?b\230qms?\000\000\004\001?l?\000\000\001%r??? \200\000????\034?Ot?\b?{sr\000\034org.jboss.mq.ConnectionToken?\b=DF=BC&? \237N\002\000\005I\000\004hashZ\000\asameJVML\000\bclientIDt\000\022Ljava/l= \000\220\032Ae\207\000\002? 3"...}} Ok, can you do 'p *m_copy'? =2D-=20 John Baldwin From owner-freebsd-stable@FreeBSD.ORG Thu Jan 21 18:33: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 5212510656E4; Thu, 21 Jan 2010 18:33:40 +0000 (UTC) (envelope-from flo@smeets.im) Received: from mail.solomo.de (mail.solomo.de [85.214.124.163]) by mx1.freebsd.org (Postfix) with ESMTP id C3CBB8FC19; Thu, 21 Jan 2010 18:33:39 +0000 (UTC) Received: from mail.solomo.de (localhost [127.0.0.1]) by mail.solomo.de (Postfix) with ESMTP id 8AB486224E; Thu, 21 Jan 2010 19:33:38 +0100 (CET) X-Virus-Scanned: amavisd-new at vistream.de Received: from mail.solomo.de ([127.0.0.1]) by mail.solomo.de (mail.solomo.de [127.0.0.1]) (amavisd-new, port 10024) with LMTP id ArUKzOATBfxK; Thu, 21 Jan 2010 19:33:36 +0100 (CET) Received: from [192.168.0.100] (p509173EE.dip.t-dialin.net [80.145.115.238]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mail.solomo.de (Postfix) with ESMTPSA id E5BA6620A9; Thu, 21 Jan 2010 19:33:35 +0100 (CET) Message-ID: <4B589DFF.3030901@smeets.im> Date: Thu, 21 Jan 2010 19:33:35 +0100 From: Florian Smeets User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.3a1pre) Gecko/20100121 Shredder/3.2a1pre MIME-Version: 1.0 To: John Baldwin References: <4B58280C.50602@smeets.im> <201001210801.48390.jhb@freebsd.org> <4B5855C2.6000002@smeets.im> <201001211258.40316.jhb@freebsd.org> In-Reply-To: <201001211258.40316.jhb@freebsd.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: freebsd-stable@freebsd.org Subject: Re: 7.2-STABLE page fault with kernel from 12.01.2010 / crashinfo available X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 21 Jan 2010 18:33:40 -0000 On 1/21/10 6:58 PM, John Baldwin wrote: > On Thursday 21 January 2010 8:25:22 am Florian Smeets wrote: >> On 1/21/10 2:01 PM, John Baldwin wrote: >>> On Thursday 21 January 2010 5:10:20 am Florian Smeets wrote: >>>> (kgdb) where >>>> #0 doadump () at pcpu.h:196 >>>> #1 0xc0525703 in boot (howto=260) at > /usr/src/sys/kern/kern_shutdown.c:418 >>>> #2 0xc052590e in panic (fmt=Variable "fmt" is not available. >>>> ) at /usr/src/sys/kern/kern_shutdown.c:574 >>>> #3 0xc06f110c in trap_fatal (frame=0xc1f15ae4, eva=12) at >>>> /usr/src/sys/i386/i386/trap.c:950 >>>> #4 0xc06f1390 in trap_pfault (frame=0xc1f15ae4, usermode=0, eva=12) at >>>> /usr/src/sys/i386/i386/trap.c:863 >>>> #5 0xc06f1d65 in trap (frame=0xc1f15ae4) at >>>> /usr/src/sys/i386/i386/trap.c:541 >>>> #6 0xc06d910b in calltrap () at /usr/src/sys/i386/i386/exception.s:166 >>>> #7 0xc0572e48 in m_copydata (m=0x0, off=0, len=40, cp=0xc23cced8 >>>> "\203??b??\237\f)h?M\220\224?\023?\205K(e??s?\"???k?oQ?~\223\020g\030") >>>> at /usr/src/sys/kern/uipc_mbuf.c:815 >>>> #8 0xc05f8b28 in ip_forward (m=0xc23dc900, srcrt=0) at >>>> /usr/src/sys/netinet/ip_input.c:1307 >>>> #9 0xc05fa30c in ip_input (m=0xc23dc900) at >>>> /usr/src/sys/netinet/ip_input.c:609 >>>> #10 0xc05c83d5 in netisr_dispatch (num=2, m=0xc23dc900) at >>>> /usr/src/sys/net/netisr.c:185 >>>> #11 0xc05bf581 in ether_demux (ifp=0xc20a4800, m=0xc23dc900) at >>>> /usr/src/sys/net/if_ethersubr.c:834 >>>> #12 0xc05bf973 in ether_input (ifp=0xc20a4800, m=0xc23dc900) at >>>> /usr/src/sys/net/if_ethersubr.c:692 >>>> #13 0xc04b8749 in sis_rxeof (sc=0xc2093800) at >>>> /usr/src/sys/dev/sis/if_sis.c:1476 >>>> #14 0xc04b8973 in sis_intr (arg=0xc2093800) at >>>> /usr/src/sys/dev/sis/if_sis.c:1667 >>>> #15 0xc050344b in ithread_loop (arg=0xc20ab410) at >>>> /usr/src/sys/kern/kern_intr.c:1126 >>>> #16 0xc04ffe36 in fork_exit (callout=0xc05032a0, >>>> arg=0xc20ab410, frame=0xc1f15d38) at /usr/src/sys/kern/kern_fork.c:811 >>>> #17 0xc06d9180 in fork_trampoline () at >>>> /usr/src/sys/i386/i386/exception.s:271 >>>> (kgdb) list *0xc0572e48 >>>> 0xc0572e48 is in m_copydata (libkern.h:61). >>>> 56 static __inline int imax(int a, int b) { return (a> b ? a : b); } >>>> 57 static __inline int imin(int a, int b) { return (a< b ? a : b); } >>>> 58 static __inline long lmax(long a, long b) { return (a> b ? a : b); } >>>> 59 static __inline long lmin(long a, long b) { return (a< b ? a : b); } >>>> 60 static __inline u_int max(u_int a, u_int b) { return (a> b ? a : b); > } >>>> 61 static __inline u_int min(u_int a, u_int b) { return (a< b ? a : b); > } >>>> 62 static __inline quad_t qmax(quad_t a, quad_t b) { return (a> b ? a : >>>> b); } >>>> 63 static __inline quad_t qmin(quad_t a, quad_t b) { return (a< b ? a : >>>> b); } >>>> 64 static __inline u_long ulmax(u_long a, u_long b) { return (a> b ? a >>>> : b); } >>>> 65 static __inline u_long ulmin(u_long a, u_long b) { return (a< b ? a >>>> : b); } >>>> (kgdb) frame 7 >>>> #7 0xc0572e48 in m_copydata (m=0x0, off=0, len=40, cp=0xc23cced8 >>>> "\203??b??\237\f)h?M\220\224?\023?\205K(e??s?\"???k?oQ?~\223\020g\030") >>>> at /usr/src/sys/kern/uipc_mbuf.c:815 >>>> 815 count = min(m->m_len - off, len); >>>> (kgdb) l >>>> 810 off -= m->m_len; >>>> 811 m = m->m_next; >>>> 812 } >>>> 813 while (len> 0) { >>>> 814 KASSERT(m != NULL, ("m_copydata, length> size of mbuf chain")); >>> >>> I think you would have hit this assertion if INVARIANTS were enabled. Can > you >>> go up to frame 8 and do an 'l'? Maybe 'p *m' as well? >>> >> >> Sure, thanks for taking a look John! >> >> (kgdb) frame 8 >> #8 0xc05f8b28 in ip_forward (m=0xc23dc900, srcrt=0) at >> /usr/src/sys/netinet/ip_input.c:1307 >> 1307 m_copydata(m, 0, mcopy->m_len, mtod(mcopy, caddr_t)); >> (kgdb) l >> 1302 mcopy = NULL; >> 1303 } >> 1304 if (mcopy != NULL) { >> 1305 mcopy->m_len = min(ip->ip_len, M_TRAILINGSPACE(mcopy)); >> 1306 mcopy->m_pkthdr.len = mcopy->m_len; >> 1307 m_copydata(m, 0, mcopy->m_len, mtod(mcopy, caddr_t)); >> 1308 } >> 1309 >> 1310 #ifdef IPSTEALTH >> 1311 if (!ipstealth) { >> (kgdb) p *m >> $1 = {m_hdr = {mh_next = 0x0, mh_nextpkt = 0x0, mh_data = 0xc271e80e >> "E\020", mh_len = 164, mh_flags = 3, mh_type = 1, pad = "\000"}, M_dat = >> {MH = {MH_pkthdr = {rcvif = 0xc20a4800, header = 0x0, len = 164, >> csum_flags = 3072, >> csum_data = 65535, tso_segsz = 0, ether_vtag = 0, tags = >> {slh_first = 0xc35bc380}}, MH_dat = {MH_ext = {ext_buf = 0xc271e800 "", >> ext_free = 0, ext_args = 0x0, ext_size = 2048, ref_cnt = 0xc2703ab4, >> ext_type = 6}, >> MH_databuf = >> "\000?q?\000\000\000\000\000\000\000\000\000\b\000\000?:p? > \006\000\000\000dL?\t<+?\202\200\020 >> O/\207\000\000\001\001\b\n-?b\230qms?\000\000\004\001?l?\000\000\001%r??? > \200\000????\034?Ot?\b?{sr\000\034org.jboss.mq.ConnectionToken?\b߼&? > \237N\002\000\005I\000\004hashZ\000\asameJVML\000\bclientIDt\000\022Ljava/l\000\220\032Ae\207\000\002? > 36@\210d\021\000\001?\001B\000!E\000\001@bV\000\000@2\032$W\213\n\034"...}}, >> >> M_databuf = >> "\000H\n?\000\000\000\000?\000\000\000\000\f\000\000?? > \000\000\000\000\000\000\200?[?\000?q? > \000\000\000\000\000\000\000\000\000\b\000\000?:p?\006\000\000\000dL?\t<+? > \202\200\020 >> O/\207\000\000\001\001\b\n-?b\230qms?\000\000\004\001?l?\000\000\001%r??? > \200\000????\034?Ot?\b?{sr\000\034org.jboss.mq.ConnectionToken?\b߼&? > \237N\002\000\005I\000\004hashZ\000\asameJVML\000\bclientIDt\000\022Ljava/l\000\220\032Ae\207\000\002? > 3"...}} > > Ok, can you do 'p *m_copy'? > What ever you want :-) (kgdb) p *m_copy No symbol "m_copy" in current context. (kgdb) p *m_copydata $2 = {void (const struct mbuf *, int, int, caddr_t)} 0xc0572e10 (kgdb) p *mcopy $1 = {m_hdr = {mh_next = 0x0, mh_nextpkt = 0x0, mh_data = 0xc23cce34 "E\020", mh_len = 204, mh_flags = 2, mh_type = 1, pad = "\000"}, M_dat = {MH = {MH_pkthdr = {rcvif = 0xc20a4800, header = 0x0, len = 204, csum_flags = 3072, csum_data = 65535, tso_segsz = 0, ether_vtag = 0, tags = {slh_first = 0xc23c3e00}}, MH_dat = {MH_ext = {ext_buf = 0x84001045
, ext_free = 0x40f034, ext_args = 0x88210640, ext_size = 355576000, ref_cnt = 0x8631a8c0, ext_type = 365696512}, MH_databuf = "E\020\000\2044?@\000@\006!\210??1\025??1\206\000\026?\025?:N?\000e\224\214\200\030 \206?\017\000\000\001\001\b\n\017LM\027\036??\006Dʿfգ\001\030Qv\024s;Z??MC\f?\nx?&\201????8?\rr?<\r\222?h??\v^P\211???~]?y?R?'f\001&M?:\016i?\205S\030A\001'2?;aFp????@???\002?3?*6k\r?=]w?·\034??\210V(ré\203??b??\237\f)h?M\220\224?\023?\205K(e??s?\"???k?oQ?~"...}}, M_databuf = "\000H\n?\000\000\000\000?\000\000\000\000\f\000\000??\000\000\000\000\000\000\000> Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0C5941065695 for ; Thu, 21 Jan 2010 18:51:54 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: from mail-gx0-f214.google.com (mail-gx0-f214.google.com [209.85.217.214]) by mx1.freebsd.org (Postfix) with ESMTP id BA6B88FC17 for ; Thu, 21 Jan 2010 18:51:53 +0000 (UTC) Received: by gxk6 with SMTP id 6so305959gxk.13 for ; Thu, 21 Jan 2010 10:51:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type; bh=G55bUwK356QcXFu4JlSd+3M1ibiEqseLiFvBbncEqkY=; b=QteWTtxnwb/BUomNNi/bl6kcgr2OYsfO4MG2YbVYDcLM+JFNIf5ZunScyhMzsWZuFW UpnZqTAM0VzYOK9gfskUT1c+9Ov0JPS8fnANcWm/5FP9evvHEgyAYlxweFip+/KbdCNh v1Pe9LQzJFTAb7WFMI4Po6GohJr4SSzHRvxoM= 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=i4Fhq0Vu9OdigUNmTEuEq14ac4D7Id8bEkXCM3m4qdEMo/n+WF/dayu4xDtQen2dro VEtToors3yak+7Gw2nzGlsBqdYuKfRdEhP+S3xgqArCxuAP4V+E5LT6HeoDV/9i9kXkL AJqZ6s+USrAF+hsAEASIn49bIlokVhGivbe1Y= MIME-Version: 1.0 Sender: asmrookie@gmail.com Received: by 10.150.120.29 with SMTP id s29mr2653306ybc.65.1264099912899; Thu, 21 Jan 2010 10:51:52 -0800 (PST) In-Reply-To: <4B586A63.9080209@digiware.nl> References: <4B572F4E.4010503@digiware.nl> <4B586A63.9080209@digiware.nl> Date: Thu, 21 Jan 2010 19:51:52 +0100 X-Google-Sender-Auth: 79c9737ec8bf8f77 Message-ID: <3bbf2fe11001211051o2a6dcce0h26aca3c2d8b3a3bc@mail.gmail.com> From: Attilio Rao To: Willem Jan Withagen Content-Type: text/plain; charset=UTF-8 Cc: FreeBSD Stable Users Subject: Re: run_interrupt_driven_hooks: still waiting... for xpt_config X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 21 Jan 2010 18:51:54 -0000 2010/1/21 Willem Jan Withagen : > Willem Jan Withagen wrote: >> >> I'm trying to revive an old dual optern Tyan Tomcat S2875 board. Even >> upgraded it to the most recent BIOS. But still no go. >> Both with 8.0 and 7.2 RELEASE. >> >> I've also disabled P1394 and all USB in the BIOS, that did not work >> either. >> Only thing that is "extra" in the box is a an Areca 1120 controller. > > Moved the bootable disk to an default SATA port on the MB, and removed the > Areca controller. > That gets ride of the problem, but it also creates a new problem since I'd > like to use the controller to handle a bunch of backup-disks. > > Suggestions on how to get the Areca controller passed the xpt_config test > are welcomed. It may be linked to sbp(4) probabilly. Do you have it in your kernel? do you want to recompile it without if the answer is yes? It would be interesting to try it without ACPI and possibly see, in the hang case, on which IRQ (sharing with whatever other source) is. Attilio -- Peace can only be achieved by understanding - A. Einstein From owner-freebsd-stable@FreeBSD.ORG Thu Jan 21 19:05: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 8CE8B106568D for ; Thu, 21 Jan 2010 19:05:42 +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 34F378FC1A for ; Thu, 21 Jan 2010 19:05:42 +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 D916046B37; Thu, 21 Jan 2010 14:05:41 -0500 (EST) Received: from jhbbsd.localnet (smtp.hudson-trading.com [209.249.190.9]) by bigwig.baldwin.cx (Postfix) with ESMTPA id 0869E8A025; Thu, 21 Jan 2010 14:05:41 -0500 (EST) From: John Baldwin To: Florian Smeets Date: Thu, 21 Jan 2010 14:05:35 -0500 User-Agent: KMail/1.12.1 (FreeBSD/7.2-CBSD-20091231; KDE/4.3.1; amd64; ; ) References: <4B58280C.50602@smeets.im> <201001211258.40316.jhb@freebsd.org> <4B589DFF.3030901@smeets.im> In-Reply-To: <4B589DFF.3030901@smeets.im> MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Message-Id: <201001211405.35615.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (bigwig.baldwin.cx); Thu, 21 Jan 2010 14:05:41 -0500 (EST) X-Virus-Scanned: clamav-milter 0.95.1 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.6 required=4.2 tests=AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on bigwig.baldwin.cx Cc: freebsd-stable@freebsd.org Subject: Re: 7.2-STABLE page fault with kernel from 12.01.2010 / crashinfo available X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 21 Jan 2010 19:05:42 -0000 On Thursday 21 January 2010 1:33:35 pm Florian Smeets wrote: > On 1/21/10 6:58 PM, John Baldwin wrote: > > On Thursday 21 January 2010 8:25:22 am Florian Smeets wrote: > >> On 1/21/10 2:01 PM, John Baldwin wrote: > >>> On Thursday 21 January 2010 5:10:20 am Florian Smeets wrote: > >>>> (kgdb) where > >>>> #0 doadump () at pcpu.h:196 > >>>> #1 0xc0525703 in boot (howto=3D260) at > > /usr/src/sys/kern/kern_shutdown.c:418 > >>>> #2 0xc052590e in panic (fmt=3DVariable "fmt" is not available. > >>>> ) at /usr/src/sys/kern/kern_shutdown.c:574 > >>>> #3 0xc06f110c in trap_fatal (frame=3D0xc1f15ae4, eva=3D12) at > >>>> /usr/src/sys/i386/i386/trap.c:950 > >>>> #4 0xc06f1390 in trap_pfault (frame=3D0xc1f15ae4, usermode=3D0, eva= =3D12) at > >>>> /usr/src/sys/i386/i386/trap.c:863 > >>>> #5 0xc06f1d65 in trap (frame=3D0xc1f15ae4) at > >>>> /usr/src/sys/i386/i386/trap.c:541 > >>>> #6 0xc06d910b in calltrap () at /usr/src/sys/i386/i386/exception.s:= 166 > >>>> #7 0xc0572e48 in m_copydata (m=3D0x0, off=3D0, len=3D40, cp=3D0xc23= cced8 > >>>> "\203??b??\237\f)h?M\220\224?\023?\205K(e??s?\"???k?oQ?~\223\020g\03= 0") > >>>> at /usr/src/sys/kern/uipc_mbuf.c:815 > >>>> #8 0xc05f8b28 in ip_forward (m=3D0xc23dc900, srcrt=3D0) at > >>>> /usr/src/sys/netinet/ip_input.c:1307 > >>>> #9 0xc05fa30c in ip_input (m=3D0xc23dc900) at > >>>> /usr/src/sys/netinet/ip_input.c:609 > >>>> #10 0xc05c83d5 in netisr_dispatch (num=3D2, m=3D0xc23dc900) at > >>>> /usr/src/sys/net/netisr.c:185 > >>>> #11 0xc05bf581 in ether_demux (ifp=3D0xc20a4800, m=3D0xc23dc900) at > >>>> /usr/src/sys/net/if_ethersubr.c:834 > >>>> #12 0xc05bf973 in ether_input (ifp=3D0xc20a4800, m=3D0xc23dc900) at > >>>> /usr/src/sys/net/if_ethersubr.c:692 > >>>> #13 0xc04b8749 in sis_rxeof (sc=3D0xc2093800) at > >>>> /usr/src/sys/dev/sis/if_sis.c:1476 > >>>> #14 0xc04b8973 in sis_intr (arg=3D0xc2093800) at > >>>> /usr/src/sys/dev/sis/if_sis.c:1667 > >>>> #15 0xc050344b in ithread_loop (arg=3D0xc20ab410) at > >>>> /usr/src/sys/kern/kern_intr.c:1126 > >>>> #16 0xc04ffe36 in fork_exit (callout=3D0xc05032a0, > >>>> arg=3D0xc20ab410, frame=3D0xc1f15d38) at /usr/src/sys/kern/kern_fork= =2Ec:811 > >>>> #17 0xc06d9180 in fork_trampoline () at > >>>> /usr/src/sys/i386/i386/exception.s:271 > >>>> (kgdb) list *0xc0572e48 > >>>> 0xc0572e48 is in m_copydata (libkern.h:61). > >>>> 56 static __inline int imax(int a, int b) { return (a> b ? a : b);= } > >>>> 57 static __inline int imin(int a, int b) { return (a< b ? a : b);= } > >>>> 58 static __inline long lmax(long a, long b) { return (a> b ? a : = b);=20 } > >>>> 59 static __inline long lmin(long a, long b) { return (a< b ? a : = b);=20 } > >>>> 60 static __inline u_int max(u_int a, u_int b) { return (a> b ? a = :=20 b); > > } > >>>> 61 static __inline u_int min(u_int a, u_int b) { return (a< b ? a = :=20 b); > > } > >>>> 62 static __inline quad_t qmax(quad_t a, quad_t b) { return (a> b = ? a=20 : > >>>> b); } > >>>> 63 static __inline quad_t qmin(quad_t a, quad_t b) { return (a< b = ? a=20 : > >>>> b); } > >>>> 64 static __inline u_long ulmax(u_long a, u_long b) { return (a> b= ?=20 a > >>>> : b); } > >>>> 65 static __inline u_long ulmin(u_long a, u_long b) { return (a< b= ?=20 a > >>>> : b); } > >>>> (kgdb) frame 7 > >>>> #7 0xc0572e48 in m_copydata (m=3D0x0, off=3D0, len=3D40, cp=3D0xc23= cced8 > >>>> "\203??b??\237\f)h?M\220\224?\023?\205K(e??s?\"???k?oQ?~\223\020g\03= 0") > >>>> at /usr/src/sys/kern/uipc_mbuf.c:815 > >>>> 815 count =3D min(m->m_len - off, len); > >>>> (kgdb) l > >>>> 810 off -=3D m->m_len; > >>>> 811 m =3D m->m_next; > >>>> 812 } > >>>> 813 while (len> 0) { > >>>> 814 KASSERT(m !=3D NULL, ("m_copydata, length> size of mbuf chai= n")); > >>> > >>> I think you would have hit this assertion if INVARIANTS were enabled.= =20 Can > > you > >>> go up to frame 8 and do an 'l'? Maybe 'p *m' as well? > >>> > >> > >> Sure, thanks for taking a look John! > >> > >> (kgdb) frame 8 > >> #8 0xc05f8b28 in ip_forward (m=3D0xc23dc900, srcrt=3D0) at > >> /usr/src/sys/netinet/ip_input.c:1307 > >> 1307 m_copydata(m, 0, mcopy->m_len, mtod(mcopy, caddr_t)); > >> (kgdb) l > >> 1302 mcopy =3D NULL; > >> 1303 } > >> 1304 if (mcopy !=3D NULL) { > >> 1305 mcopy->m_len =3D min(ip->ip_len, M_TRAILINGSPACE(mcopy)); > >> 1306 mcopy->m_pkthdr.len =3D mcopy->m_len; > >> 1307 m_copydata(m, 0, mcopy->m_len, mtod(mcopy, caddr_t)); > >> 1308 } > >> 1309=09 > >> 1310 #ifdef IPSTEALTH > >> 1311 if (!ipstealth) { > >> (kgdb) p *m > >> $1 =3D {m_hdr =3D {mh_next =3D 0x0, mh_nextpkt =3D 0x0, mh_data =3D 0x= c271e80e > >> "E\020", mh_len =3D 164, mh_flags =3D 3, mh_type =3D 1, pad =3D "\000"= }, M_dat =3D > >> {MH =3D {MH_pkthdr =3D {rcvif =3D 0xc20a4800, header =3D 0x0, len =3D = 164, > >> csum_flags =3D 3072, > >> csum_data =3D 65535, tso_segsz =3D 0, ether_vtag =3D 0, tags= =3D > >> {slh_first =3D 0xc35bc380}}, MH_dat =3D {MH_ext =3D {ext_buf =3D 0xc27= 1e800 "", > >> ext_free =3D 0, ext_args =3D 0x0, ext_size =3D 2048, ref_cnt =3D 0xc27= 03ab4, > >> ext_type =3D 6}, > >> MH_databuf =3D > >> "\000?q?\000\000\000\000\000\000\000\000\000\b\000\000?:p? > > \006\000\000\000dL?\t<+?\202\200\020 > >> O/\207\000\000\001\001\b\n-?b\230qms?\000\000\004\001?l?\000\000\001%r= ??? > > \200\000????\034?Ot?\b?{sr\000\034org.jboss.mq.ConnectionToken?\b=DF=BC= &? > >=20 \237N\002\000\005I\000\004hashZ\000\asameJVML\000\bclientIDt\000\022Ljava/l= \000\220\032Ae\207\000\002? > > 36@\210d\021\000\001? \001B\000!E\000\001@bV\000\000@2\032$W\213\n\034"...}}, > >> > >> M_databuf =3D > >> "\000H\n?\000\000\000\000?\000\000\000\000\f\000\000?? > > \000\000\000\000\000\000\200?[?\000?q? > > \000\000\000\000\000\000\000\000\000\b\000\000?:p?\006\000\000\000dL?\t= <+? > > \202\200\020 > >> O/\207\000\000\001\001\b\n-?b\230qms?\000\000\004\001?l?\000\000\001%r= ??? > > \200\000????\034?Ot?\b?{sr\000\034org.jboss.mq.ConnectionToken?\b=DF=BC= &? > >=20 \237N\002\000\005I\000\004hashZ\000\asameJVML\000\bclientIDt\000\022Ljava/l= \000\220\032Ae\207\000\002? > > 3"...}} > > > > Ok, can you do 'p *m_copy'? > > >=20 > What ever you want :-) >=20 > (kgdb) p *m_copy > No symbol "m_copy" in current context. > (kgdb) p *m_copydata > $2 =3D {void (const struct mbuf *, int, int, caddr_t)} 0xc0572e10 > (kgdb) p *mcopy > $1 =3D {m_hdr =3D {mh_next =3D 0x0, mh_nextpkt =3D 0x0, mh_data =3D 0xc23= cce34=20 > "E\020", mh_len =3D 204, mh_flags =3D 2, mh_type =3D 1, pad =3D "\000"}, = M_dat =3D=20 > {MH =3D {MH_pkthdr =3D {rcvif =3D 0xc20a4800, header =3D 0x0, > len =3D 204, csum_flags =3D 3072, csum_data =3D 65535, tso_segsz= =3D 0,=20 > ether_vtag =3D 0, tags =3D {slh_first =3D 0xc23c3e00}}, MH_dat =3D {MH_ex= t =3D=20 > {ext_buf =3D 0x84001045
, Hmm, ok. Can you do 'p *ip'? mcopy->m_len (204) is larger than m->m_len=20 (164). That shouldn't be the case unless ip->ip_len is somehow larger than= m- >m_len. =2D-=20 John Baldwin From owner-freebsd-stable@FreeBSD.ORG Thu Jan 21 19: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 006A7106566C; Thu, 21 Jan 2010 19:09:40 +0000 (UTC) (envelope-from flo@smeets.im) Received: from mail.solomo.de (mail.solomo.de [85.214.124.163]) by mx1.freebsd.org (Postfix) with ESMTP id 723E08FC17; Thu, 21 Jan 2010 19:09:39 +0000 (UTC) Received: from mail.solomo.de (localhost [127.0.0.1]) by mail.solomo.de (Postfix) with ESMTP id 3AC5A61ED3; Thu, 21 Jan 2010 20:09:38 +0100 (CET) X-Virus-Scanned: amavisd-new at vistream.de Received: from mail.solomo.de ([127.0.0.1]) by mail.solomo.de (mail.solomo.de [127.0.0.1]) (amavisd-new, port 10024) with LMTP id yB7MLTlJQqyf; Thu, 21 Jan 2010 20:09:36 +0100 (CET) Received: from [192.168.0.100] (p509173EE.dip.t-dialin.net [80.145.115.238]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mail.solomo.de (Postfix) with ESMTPSA id BF6AC61C94; Thu, 21 Jan 2010 20:09:35 +0100 (CET) Message-ID: <4B58A66E.3040900@smeets.im> Date: Thu, 21 Jan 2010 20:09:34 +0100 From: Florian Smeets User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.3a1pre) Gecko/20100121 Shredder/3.2a1pre MIME-Version: 1.0 To: John Baldwin References: <4B58280C.50602@smeets.im> <201001211258.40316.jhb@freebsd.org> <4B589DFF.3030901@smeets.im> <201001211405.35615.jhb@freebsd.org> In-Reply-To: <201001211405.35615.jhb@freebsd.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: freebsd-stable@freebsd.org Subject: Re: 7.2-STABLE page fault with kernel from 12.01.2010 / crashinfo available X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 21 Jan 2010 19:09:40 -0000 On 1/21/10 8:05 PM, John Baldwin wrote: > On Thursday 21 January 2010 1:33:35 pm Florian Smeets wrote: >> On 1/21/10 6:58 PM, John Baldwin wrote: >>> On Thursday 21 January 2010 8:25:22 am Florian Smeets wrote: >>>> (kgdb) frame 8 >>>> #8 0xc05f8b28 in ip_forward (m=0xc23dc900, srcrt=0) at >>>> /usr/src/sys/netinet/ip_input.c:1307 >>>> 1307 m_copydata(m, 0, mcopy->m_len, mtod(mcopy, caddr_t)); >>>> (kgdb) l >>>> 1302 mcopy = NULL; >>>> 1303 } >>>> 1304 if (mcopy != NULL) { >>>> 1305 mcopy->m_len = min(ip->ip_len, M_TRAILINGSPACE(mcopy)); >>>> 1306 mcopy->m_pkthdr.len = mcopy->m_len; >>>> 1307 m_copydata(m, 0, mcopy->m_len, mtod(mcopy, caddr_t)); >>>> 1308 } >>>> 1309 >>>> 1310 #ifdef IPSTEALTH >>>> 1311 if (!ipstealth) { >>>> (kgdb) p *m >>>> $1 = {m_hdr = {mh_next = 0x0, mh_nextpkt = 0x0, mh_data = 0xc271e80e >>>> "E\020", mh_len = 164, mh_flags = 3, mh_type = 1, pad = "\000"}, M_dat = >>>> {MH = {MH_pkthdr = {rcvif = 0xc20a4800, header = 0x0, len = 164, >>>> csum_flags = 3072, >>>> csum_data = 65535, tso_segsz = 0, ether_vtag = 0, tags = >>>> {slh_first = 0xc35bc380}}, MH_dat = {MH_ext = {ext_buf = 0xc271e800 "", >>>> ext_free = 0, ext_args = 0x0, ext_size = 2048, ref_cnt = 0xc2703ab4, >>>> ext_type = 6}, >>>> MH_databuf = >>>> "\000?q?\000\000\000\000\000\000\000\000\000\b\000\000?:p? >>> \006\000\000\000dL?\t<+?\202\200\020 >>>> O/\207\000\000\001\001\b\n-?b\230qms?\000\000\004\001?l?\000\000\001%r??? >>> \200\000????\034?Ot?\b?{sr\000\034org.jboss.mq.ConnectionToken?\b߼&? >>> > \237N\002\000\005I\000\004hashZ\000\asameJVML\000\bclientIDt\000\022Ljava/l\000\220\032Ae\207\000\002? >>> 36@\210d\021\000\001? > \001B\000!E\000\001@bV\000\000@2\032$W\213\n\034"...}}, >>>> >>>> M_databuf = >>>> "\000H\n?\000\000\000\000?\000\000\000\000\f\000\000?? >>> \000\000\000\000\000\000\200?[?\000?q? >>> \000\000\000\000\000\000\000\000\000\b\000\000?:p?\006\000\000\000dL?\t<+? >>> \202\200\020 >>>> O/\207\000\000\001\001\b\n-?b\230qms?\000\000\004\001?l?\000\000\001%r??? >>> \200\000????\034?Ot?\b?{sr\000\034org.jboss.mq.ConnectionToken?\b߼&? >>> > \237N\002\000\005I\000\004hashZ\000\asameJVML\000\bclientIDt\000\022Ljava/l\000\220\032Ae\207\000\002? >>> 3"...}} >>> >>> Ok, can you do 'p *m_copy'? >>> >> >> What ever you want :-) >> >> (kgdb) p *m_copy >> No symbol "m_copy" in current context. >> (kgdb) p *m_copydata >> $2 = {void (const struct mbuf *, int, int, caddr_t)} 0xc0572e10 >> (kgdb) p *mcopy >> $1 = {m_hdr = {mh_next = 0x0, mh_nextpkt = 0x0, mh_data = 0xc23cce34 >> "E\020", mh_len = 204, mh_flags = 2, mh_type = 1, pad = "\000"}, M_dat = >> {MH = {MH_pkthdr = {rcvif = 0xc20a4800, header = 0x0, >> len = 204, csum_flags = 3072, csum_data = 65535, tso_segsz = 0, >> ether_vtag = 0, tags = {slh_first = 0xc23c3e00}}, MH_dat = {MH_ext = >> {ext_buf = 0x84001045
, > > Hmm, ok. Can you do 'p *ip'? mcopy->m_len (204) is larger than m->m_len > (164). That shouldn't be the case unless ip->ip_len is somehow larger than m- >> m_len. > (kgdb) p *ip $3 = {ip_hl = 5, ip_v = 4, ip_tos = 16 '\020', ip_len = 33792, ip_id = 61492, ip_off = 64, ip_ttl = 64 '@', ip_p = 6 '\006', ip_sum = 34849, ip_src = {s_addr = 355576000}, ip_dst = { s_addr = 2251401408}} From owner-freebsd-stable@FreeBSD.ORG Thu Jan 21 19:26: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 63859106568B; Thu, 21 Jan 2010 19:26:46 +0000 (UTC) (envelope-from bsam@ipt.ru) Received: from services.ipt.ru (services.ipt.ru [194.62.233.110]) by mx1.freebsd.org (Postfix) with ESMTP id 1E9B58FC16; Thu, 21 Jan 2010 19:26:45 +0000 (UTC) Received: from [85.173.16.175] (helo=izar) by services.ipt.ru with esmtpa (Exim 4.54 (FreeBSD)) id 1NY2g0-0001aK-Rj; Thu, 21 Jan 2010 22:26:44 +0300 From: Boris Samorodov To: Alexander Motin References: <4B55D9D4.1000008@FreeBSD.org> <4B57064F.9060704@restart.be> Date: Thu, 21 Jan 2010 22:26:38 +0300 In-Reply-To: <4B57064F.9060704@restart.be> (Henri Hennebert's message of "Wed, 20 Jan 2010 14:34:07 +0100") Message-ID: <30311009@ipt.ru> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: FreeBSD-Current , FreeBSD Stable Subject: Re: Pack of CAM improvements X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 21 Jan 2010 19:26:46 -0000 On Wed, 20 Jan 2010 14:34:07 +0100 Henri Hennebert wrote: > On 01/19/2010 17:12, Alexander Motin wrote: > > Hi. > > > > I've made a patch, that should solve set of problems of CAM ATA and CAM Thanks! > > generally. I would like to ask for testing and feedback. > > > > What patch does: > > - It unifies bus reset/probe sequence. Whenever bus attached at boot or > > later, CAM will automatically reset and scan it. It allows to remove > > duplicate code from many drivers. > > - Any bus, attached before CAM completed it's boot-time initialization, > > will equally join to the process, delaying boot if needed. > > - New kern.cam.boot_delay loader tunable should help controllers that > > are still unable to register their buses in time (such as slow USB/ > > PCCard/ CardBus devices). > With kern.cam.boot_delay=15000 (I suppose that it was in ms) I can now > boot from my sim card reader. So do I with kern.cam.boot_delay=6000 for my EEEPC-1000: ----- % uname -a FreeBSD izar 9.0-CURRENT FreeBSD 9.0-CURRENT #3 r202734M: Thu Jan 21 18:13:10 MSK 2010 bsam@izar:/obj/usr/src/sys/EEEBB i386 ----- > > - To allow synchronization between different CAM levels, concept of > > requests priorities was extended. Priorities now split between several > > "run levels". Device can be freezed at specified level, allowing higher > > priority requests to pass. For example, no payload requests allowed, > > until PMP driver enable port. ATA XPT negotiate transfer parameters, > > periph driver configure caching and so on. > > - Frozen requests are no more counted by request allocation scheduler. > > It fixes deadlocks, when frozen low priority payload requests occupying > > slots, required by higher levels to manage theit execution. > > - Two last changes were holding proper ATA reinitialization and error > > recovery implementation. Now it is done: SATA controllers and Port > > Multipliers now implement automatic hot-plug and should correctly > > recover from timeouts and bus resets. > > > > Patch can be found here: > > http://people.freebsd.org/~mav/cam-ata.20100119.patch > > > > Feedback as always welcome. -- WBR, Boris Samorodov (bsam) Research Engineer, http://www.ipt.ru Telephone & Internet SP FreeBSD Committer, http://www.FreeBSD.org The Power To Serve From owner-freebsd-stable@FreeBSD.ORG Thu Jan 21 20:15: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 29492106566B; Thu, 21 Jan 2010 20:15:38 +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 EDE718FC1C; Thu, 21 Jan 2010 20:15:37 +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 8C28146B35; Thu, 21 Jan 2010 15:15:37 -0500 (EST) Received: from jhbbsd.localnet (smtp.hudson-trading.com [209.249.190.9]) by bigwig.baldwin.cx (Postfix) with ESMTPA id 9E5638A026; Thu, 21 Jan 2010 15:15:36 -0500 (EST) From: John Baldwin To: Florian Smeets Date: Thu, 21 Jan 2010 15:15:32 -0500 User-Agent: KMail/1.12.1 (FreeBSD/7.2-CBSD-20091231; KDE/4.3.1; amd64; ; ) References: <4B58280C.50602@smeets.im> <201001211405.35615.jhb@freebsd.org> <4B58A66E.3040900@smeets.im> In-Reply-To: <4B58A66E.3040900@smeets.im> MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Message-Id: <201001211515.32562.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (bigwig.baldwin.cx); Thu, 21 Jan 2010 15:15:36 -0500 (EST) X-Virus-Scanned: clamav-milter 0.95.1 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.6 required=4.2 tests=AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on bigwig.baldwin.cx Cc: Luigi Rizzo , freebsd-stable@freebsd.org Subject: Re: 7.2-STABLE page fault with kernel from 12.01.2010 / crashinfo available X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 21 Jan 2010 20:15:38 -0000 On Thursday 21 January 2010 2:09:34 pm Florian Smeets wrote: > On 1/21/10 8:05 PM, John Baldwin wrote: > > On Thursday 21 January 2010 1:33:35 pm Florian Smeets wrote: > >> On 1/21/10 6:58 PM, John Baldwin wrote: > >>> On Thursday 21 January 2010 8:25:22 am Florian Smeets wrote: > >>>> (kgdb) frame 8 > >>>> #8 0xc05f8b28 in ip_forward (m=3D0xc23dc900, srcrt=3D0) at > >>>> /usr/src/sys/netinet/ip_input.c:1307 > >>>> 1307 m_copydata(m, 0, mcopy->m_len, mtod(mcopy, caddr_t)); > >>>> (kgdb) l > >>>> 1302 mcopy =3D NULL; > >>>> 1303 } > >>>> 1304 if (mcopy !=3D NULL) { > >>>> 1305 mcopy->m_len =3D min(ip->ip_len, M_TRAILINGSPACE(mcopy)); > >>>> 1306 mcopy->m_pkthdr.len =3D mcopy->m_len; > >>>> 1307 m_copydata(m, 0, mcopy->m_len, mtod(mcopy, caddr_t)); > >>>> 1308 } > >>>> 1309=09 > >>>> 1310 #ifdef IPSTEALTH > >>>> 1311 if (!ipstealth) { > >>>> (kgdb) p *m > >>>> $1 =3D {m_hdr =3D {mh_next =3D 0x0, mh_nextpkt =3D 0x0, mh_data =3D = 0xc271e80e > >>>> "E\020", mh_len =3D 164, mh_flags =3D 3, mh_type =3D 1, pad =3D "\00= 0"}, M_dat=20 =3D > >>>> {MH =3D {MH_pkthdr =3D {rcvif =3D 0xc20a4800, header =3D 0x0, len = =3D 164, > >>>> csum_flags =3D 3072, > >>>> csum_data =3D 65535, tso_segsz =3D 0, ether_vtag =3D 0, t= ags =3D > >>>> {slh_first =3D 0xc35bc380}}, MH_dat =3D {MH_ext =3D {ext_buf =3D 0xc= 271e800 "", > >>>> ext_free =3D 0, ext_args =3D 0x0, ext_size =3D 2048, ref_cnt =3D 0xc= 2703ab4, > >>>> ext_type =3D 6}, > >>>> MH_databuf =3D > >>>> "\000?q?\000\000\000\000\000\000\000\000\000\b\000\000?:p? > >>> \006\000\000\000dL?\t<+?\202\200\020 > >>>> O/\207\000\000\001\001\b\n-?b\230qms?\000\000\004\001?l? \000\000\001%r??? > >>> \200\000????\034?Ot?\b?{sr\000\034org.jboss.mq.ConnectionToken?\b=DF= =BC&? > >>> > >=20 \237N\002\000\005I\000\004hashZ\000\asameJVML\000\bclientIDt\000\022Ljava/l= \000\220\032Ae\207\000\002? > >>> 36@\210d\021\000\001? > > \001B\000!E\000\001@bV\000\000@2\032$W\213\n\034"...}}, > >>>> > >>>> M_databuf =3D > >>>> "\000H\n?\000\000\000\000?\000\000\000\000\f\000\000?? > >>> \000\000\000\000\000\000\200?[?\000?q? > >>> \000\000\000\000\000\000\000\000\000\b\000\000?:p?\006\000\000\000dL? \t<+? > >>> \202\200\020 > >>>> O/\207\000\000\001\001\b\n-?b\230qms?\000\000\004\001?l? \000\000\001%r??? > >>> \200\000????\034?Ot?\b?{sr\000\034org.jboss.mq.ConnectionToken?\b=DF= =BC&? > >>> > >=20 \237N\002\000\005I\000\004hashZ\000\asameJVML\000\bclientIDt\000\022Ljava/l= \000\220\032Ae\207\000\002? > >>> 3"...}} > >>> > >>> Ok, can you do 'p *m_copy'? > >>> > >> > >> What ever you want :-) > >> > >> (kgdb) p *m_copy > >> No symbol "m_copy" in current context. > >> (kgdb) p *m_copydata > >> $2 =3D {void (const struct mbuf *, int, int, caddr_t)}=20 0xc0572e10 > >> (kgdb) p *mcopy > >> $1 =3D {m_hdr =3D {mh_next =3D 0x0, mh_nextpkt =3D 0x0, mh_data =3D 0x= c23cce34 > >> "E\020", mh_len =3D 204, mh_flags =3D 2, mh_type =3D 1, pad =3D "\000"= }, M_dat =3D > >> {MH =3D {MH_pkthdr =3D {rcvif =3D 0xc20a4800, header =3D 0x0, > >> len =3D 204, csum_flags =3D 3072, csum_data =3D 65535, tso_s= egsz =3D 0, > >> ether_vtag =3D 0, tags =3D {slh_first =3D 0xc23c3e00}}, MH_dat =3D {MH= _ext =3D > >> {ext_buf =3D 0x84001045
, > > > > Hmm, ok. Can you do 'p *ip'? mcopy->m_len (204) is larger than m->m_l= en > > (164). That shouldn't be the case unless ip->ip_len is somehow larger= =20 than m- > >> m_len. > > >=20 > (kgdb) p *ip > $3 =3D {ip_hl =3D 5, ip_v =3D 4, ip_tos =3D 16 '\020', ip_len =3D 33792, = ip_id =3D=20 > 61492, ip_off =3D 64, ip_ttl =3D 64 '@', ip_p =3D 6 '\006', ip_sum =3D 34= 849,=20 > ip_src =3D {s_addr =3D 355576000}, ip_dst =3D { > s_addr =3D 2251401408}} Looks like ip_len is in network byte order instead of host byte order and t= hat=20 is causing the problem. 33792 =3D=3D 0x8400. Swapping that gives 0x84 =3D= =3D 132=20 which would be a reasonable length. Are you using any firewall rules that= =20 would rewrite packets? I wonder if you are having a packet rewritten and t= he=20 new IP header is written in network byte order, but we swap the IP header l= en=20 field to host byte order earlier in ip_input(). Luigi Rizzo may have some= =20 insight into this. =2D-=20 John Baldwin From owner-freebsd-stable@FreeBSD.ORG Thu Jan 21 20:44: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 E4AEE106568D; Thu, 21 Jan 2010 20:44:37 +0000 (UTC) (envelope-from wjw@digiware.nl) Received: from mail.digiware.nl (mail.ip6.digiware.nl [IPv6:2001:4cb8:1:106::2]) by mx1.freebsd.org (Postfix) with ESMTP id 804E78FC18; Thu, 21 Jan 2010 20:44:37 +0000 (UTC) Received: from localhost (localhost.digiware.nl [127.0.0.1]) by mail.digiware.nl (Postfix) with ESMTP id D4B2F153433; Thu, 21 Jan 2010 21:44:35 +0100 (CET) X-Virus-Scanned: amavisd-new at digiware.nl Received: from mail.digiware.nl ([127.0.0.1]) by localhost (rack1.digiware.nl [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EPz0XqWq95Fs; Thu, 21 Jan 2010 21:44:33 +0100 (CET) Received: from [192.168.10.212] (unknown [192.168.10.212]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.digiware.nl (Postfix) with ESMTPSA id 7F87815342F; Thu, 21 Jan 2010 21:44:33 +0100 (CET) Message-ID: <4B58BCB0.4030205@digiware.nl> Date: Thu, 21 Jan 2010 21:44:32 +0100 From: Willem Jan Withagen User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Attilio Rao References: <4B572F4E.4010503@digiware.nl> <4B586A63.9080209@digiware.nl> <3bbf2fe11001211051o2a6dcce0h26aca3c2d8b3a3bc@mail.gmail.com> In-Reply-To: <3bbf2fe11001211051o2a6dcce0h26aca3c2d8b3a3bc@mail.gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: FreeBSD Stable Users Subject: Re: run_interrupt_driven_hooks: still waiting... for xpt_config X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 21 Jan 2010 20:44:38 -0000 Attilio Rao wrote: > 2010/1/21 Willem Jan Withagen : >> Willem Jan Withagen wrote: >>> I'm trying to revive an old dual optern Tyan Tomcat S2875 board. Even >>> upgraded it to the most recent BIOS. But still no go. >>> Both with 8.0 and 7.2 RELEASE. >>> >>> I've also disabled P1394 and all USB in the BIOS, that did not work >>> either. >>> Only thing that is "extra" in the box is a an Areca 1120 controller. >> Moved the bootable disk to an default SATA port on the MB, and removed the >> Areca controller. >> That gets ride of the problem, but it also creates a new problem since I'd >> like to use the controller to handle a bunch of backup-disks. >> >> Suggestions on how to get the Areca controller passed the xpt_config test >> are welcomed. > > It may be linked to sbp(4) probabilly. Do you have it in your kernel? > do you want to recompile it without if the answer is yes? > It would be interesting to try it without ACPI and possibly see, in > the hang case, on which IRQ (sharing with whatever other source) is. cd /usr/src/sys/i386/conf > grep sbp * GENERIC:#device sbp # SCSI over FireWire (Requires scbus and da) > But even a custom build kernel only, keeps hanging on the xpt_config. Haven't tried without ACPI, but will do so within a moment. And I'll be willing to compile any type of kernel and or patches that you care to suggest. The system is at the moment an idle brick that is going to run a 16 disk zfs system for backups. But until I fix this Areca problem, that isn't going to happen. And the previous backup-server is still up and running. So no pressure there. So did some reboots.... Disabeling ACPI makes the board not complete the BIOS bootcycle. It completes the ARECA BIOS, reports intr15. And freezes where normally you would get the BIOS summary of what is in the system, after which the BIOS boots from a device.... But this suggestion also made be select another PCI slot to try, an that slot made it boot..... Interrupt-wise it also got assigned a different interrupt. In the non-booting case it was intr19 on pci3 which intr was shared with em0. In the booting case it was intr18 on pci18 which was shared with an InterSil 3114 controller. So this sounds like motherboard BIOS does not play nice with setting up the devices??? Thanx for getting me this far and giving the much needed pointer. --WjW From owner-freebsd-stable@FreeBSD.ORG Thu Jan 21 22:04:25 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 D675E106566B; Thu, 21 Jan 2010 22:04:25 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost2.sentex.ca (smarthost2.sentex.ca [205.211.164.50]) by mx1.freebsd.org (Postfix) with ESMTP id 87E558FC1D; Thu, 21 Jan 2010 22:04:25 +0000 (UTC) Received: from smtp1.sentex.ca (smtp1.sentex.ca [199.212.134.4]) by smarthost2.sentex.ca (8.14.3/8.14.3) with ESMTP id o0LM4NRE094187; Thu, 21 Jan 2010 17:04:23 -0500 (EST) (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.3/8.14.3) with ESMTP id o0LM4NCm054383; Thu, 21 Jan 2010 17:04:23 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: by freebsd-stable.sentex.ca (Postfix, from userid 666) id E67481B5078; Thu, 21 Jan 2010 17:04:22 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20100121220422.E67481B5078@freebsd-stable.sentex.ca> Date: Thu, 21 Jan 2010 17:04:22 -0500 (EST) X-Virus-Scanned: clamav-milter 0.95.1 at smtp1.sentex.ca X-Virus-Status: Clean X-Scanned-By: MIMEDefang 2.64 on 205.211.164.50 Cc: Subject: [releng_7 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: Thu, 21 Jan 2010 22:04:25 -0000 TB --- 2010-01-21 20:08:12 - tinderbox 2.6 running on freebsd-stable.sentex.ca TB --- 2010-01-21 20:08:12 - starting RELENG_7 tinderbox run for amd64/amd64 TB --- 2010-01-21 20:08:12 - cleaning the object tree TB --- 2010-01-21 20:08:41 - cvsupping the source tree TB --- 2010-01-21 20:08:41 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/RELENG_7/amd64/amd64/supfile TB --- 2010-01-21 20:08:54 - building world TB --- 2010-01-21 20:08:54 - MAKEOBJDIRPREFIX=/obj TB --- 2010-01-21 20:08:54 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-01-21 20:08:54 - TARGET=amd64 TB --- 2010-01-21 20:08:54 - TARGET_ARCH=amd64 TB --- 2010-01-21 20:08:54 - TZ=UTC TB --- 2010-01-21 20:08:54 - __MAKE_CONF=/dev/null TB --- 2010-01-21 20:08:54 - cd /src TB --- 2010-01-21 20:08:54 - /usr/bin/make -B buildworld >>> World build started on Thu Jan 21 20:08:55 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 Thu Jan 21 21:39:33 UTC 2010 TB --- 2010-01-21 21:39:33 - generating LINT kernel config TB --- 2010-01-21 21:39:33 - cd /src/sys/amd64/conf TB --- 2010-01-21 21:39:33 - /usr/bin/make -B LINT TB --- 2010-01-21 21:39:33 - building LINT kernel TB --- 2010-01-21 21:39:33 - MAKEOBJDIRPREFIX=/obj TB --- 2010-01-21 21:39:33 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-01-21 21:39:33 - TARGET=amd64 TB --- 2010-01-21 21:39:33 - TARGET_ARCH=amd64 TB --- 2010-01-21 21:39:33 - TZ=UTC TB --- 2010-01-21 21:39:33 - __MAKE_CONF=/dev/null TB --- 2010-01-21 21:39:33 - cd /src TB --- 2010-01-21 21:39:33 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Thu Jan 21 21:39:33 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 >>> stage 3.2: building everything [...] cc -O2 -fno-strict-aliasing -pipe -DFREEBSD_NAMECACHE -DBUILDING_ZFS -D_KERNEL -DKLD_MODULE -std=c99 -nostdinc -I/src/sys/modules/zfs/../../cddl/compat/opensolaris -I/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/zmod -I/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common -I/src/sys/modules/zfs/../.. -I/src/sys/modules/zfs/../../cddl/contrib/opensolaris/common/zfs -I/src/sys/modules/zfs/../../cddl/contrib/opensolaris/common -I/src/sys/modules/zfs/../../../include -DHAVE_KERNEL_OPTION_HEADERS -include /obj/amd64/src/sys/LINT/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -fno-omit-frame-pointer -I/obj/amd64/src/sys/LINT -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -Wall -Wredundant-decls -Wnes ted-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wno-unknown-pragmas -Wno-missing-prototypes -Wno-undef -Wno-strict-prototypes -Wno-cast-qual -Wno-parentheses -Wno-redundant-decls -Wno-missing-braces -Wno-uninitialized -Wno-unused -Wno-inline -Wno-switch -Wno-pointer-arith -c /src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_byteswap.c cc -O2 -fno-strict-aliasing -pipe -DFREEBSD_NAMECACHE -DBUILDING_ZFS -D_KERNEL -DKLD_MODULE -std=c99 -nostdinc -I/src/sys/modules/zfs/../../cddl/compat/opensolaris -I/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/zmod -I/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common -I/src/sys/modules/zfs/../.. -I/src/sys/modules/zfs/../../cddl/contrib/opensolaris/common/zfs -I/src/sys/modules/zfs/../../cddl/contrib/opensolaris/common -I/src/sys/modules/zfs/../../../include -DHAVE_KERNEL_OPTION_HEADERS -include /obj/amd64/src/sys/LINT/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -fno-omit-frame-pointer -I/obj/amd64/src/sys/LINT -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -Wall -Wredundant-decls -Wnes ted-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wno-unknown-pragmas -Wno-missing-prototypes -Wno-undef -Wno-strict-prototypes -Wno-cast-qual -Wno-parentheses -Wno-redundant-decls -Wno-missing-braces -Wno-uninitialized -Wno-unused -Wno-inline -Wno-switch -Wno-pointer-arith -c /src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_fm.c cc -O2 -fno-strict-aliasing -pipe -DFREEBSD_NAMECACHE -DBUILDING_ZFS -D_KERNEL -DKLD_MODULE -std=c99 -nostdinc -I/src/sys/modules/zfs/../../cddl/compat/opensolaris -I/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/zmod -I/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common -I/src/sys/modules/zfs/../.. -I/src/sys/modules/zfs/../../cddl/contrib/opensolaris/common/zfs -I/src/sys/modules/zfs/../../cddl/contrib/opensolaris/common -I/src/sys/modules/zfs/../../../include -DHAVE_KERNEL_OPTION_HEADERS -include /obj/amd64/src/sys/LINT/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -fno-omit-frame-pointer -I/obj/amd64/src/sys/LINT -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -Wall -Wredundant-decls -Wnes ted-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wno-unknown-pragmas -Wno-missing-prototypes -Wno-undef -Wno-strict-prototypes -Wno-cast-qual -Wno-parentheses -Wno-redundant-decls -Wno-missing-braces -Wno-uninitialized -Wno-unused -Wno-inline -Wno-switch -Wno-pointer-arith -c /src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_fuid.c cc -O2 -fno-strict-aliasing -pipe -DFREEBSD_NAMECACHE -DBUILDING_ZFS -D_KERNEL -DKLD_MODULE -std=c99 -nostdinc -I/src/sys/modules/zfs/../../cddl/compat/opensolaris -I/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/zmod -I/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common -I/src/sys/modules/zfs/../.. -I/src/sys/modules/zfs/../../cddl/contrib/opensolaris/common/zfs -I/src/sys/modules/zfs/../../cddl/contrib/opensolaris/common -I/src/sys/modules/zfs/../../../include -DHAVE_KERNEL_OPTION_HEADERS -include /obj/amd64/src/sys/LINT/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -fno-omit-frame-pointer -I/obj/amd64/src/sys/LINT -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -Wall -Wredundant-decls -Wnes ted-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wno-unknown-pragmas -Wno-missing-prototypes -Wno-undef -Wno-strict-prototypes -Wno-cast-qual -Wno-parentheses -Wno-redundant-decls -Wno-missing-braces -Wno-uninitialized -Wno-unused -Wno-inline -Wno-switch -Wno-pointer-arith -c /src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_znode.c /src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_znode.c: In function 'zfs_create_fs': /src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_znode.c:1523: error: 'vp' undeclared (first use in this function) /src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_znode.c:1523: error: (Each undeclared identifier is reported only once /src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_znode.c:1523: error: for each function it appears in.) *** Error code 1 Stop in /src/sys/modules/zfs. *** Error code 1 Stop in /src/sys/modules. *** Error code 1 Stop in /obj/amd64/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2010-01-21 22:04:22 - WARNING: /usr/bin/make returned exit code 1 TB --- 2010-01-21 22:04:22 - ERROR: failed to build lint kernel TB --- 2010-01-21 22:04:22 - 5879.07 user 599.84 system 6969.99 real http://tinderbox.freebsd.org/tinderbox-releng_7-RELENG_7-amd64-amd64.full From owner-freebsd-stable@FreeBSD.ORG Thu Jan 21 22:44:46 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 9CAE0106566B; Thu, 21 Jan 2010 22:44:46 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.freebsd.org (Postfix) with ESMTP id 65B488FC13; Thu, 21 Jan 2010 22:44:45 +0000 (UTC) Received: from smtp2.sentex.ca (smtp2c.sentex.ca [64.7.153.30]) by smarthost1.sentex.ca (8.14.3/8.14.3) with ESMTP id o0LMii7a054375; Thu, 21 Jan 2010 17:44:44 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: from freebsd-stable.sentex.ca (freebsd-stable.sentex.ca [64.7.128.103]) by smtp2.sentex.ca (8.14.3/8.14.3) with ESMTP id o0LMih4f011531; Thu, 21 Jan 2010 17:44:43 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: by freebsd-stable.sentex.ca (Postfix, from userid 666) id AAD851B5078; Thu, 21 Jan 2010 17:44:43 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20100121224443.AAD851B5078@freebsd-stable.sentex.ca> Date: Thu, 21 Jan 2010 17:44:43 -0500 (EST) X-Virus-Scanned: clamav-milter 0.95.1 at smtp2.sentex.ca X-Virus-Status: Clean X-Scanned-By: MIMEDefang 2.64 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: Thu, 21 Jan 2010 22:44:46 -0000 TB --- 2010-01-21 21:11:38 - tinderbox 2.6 running on freebsd-stable.sentex.ca TB --- 2010-01-21 21:11:38 - starting RELENG_7 tinderbox run for i386/i386 TB --- 2010-01-21 21:11:38 - cleaning the object tree TB --- 2010-01-21 21:12:00 - cvsupping the source tree TB --- 2010-01-21 21:12:00 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/RELENG_7/i386/i386/supfile TB --- 2010-01-21 21:12:15 - building world TB --- 2010-01-21 21:12:15 - MAKEOBJDIRPREFIX=/obj TB --- 2010-01-21 21:12:15 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-01-21 21:12:15 - TARGET=i386 TB --- 2010-01-21 21:12:15 - TARGET_ARCH=i386 TB --- 2010-01-21 21:12:15 - TZ=UTC TB --- 2010-01-21 21:12:15 - __MAKE_CONF=/dev/null TB --- 2010-01-21 21:12:15 - cd /src TB --- 2010-01-21 21:12:15 - /usr/bin/make -B buildworld >>> World build started on Thu Jan 21 21:12:17 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 Thu Jan 21 22:16:25 UTC 2010 TB --- 2010-01-21 22:16:25 - generating LINT kernel config TB --- 2010-01-21 22:16:25 - cd /src/sys/i386/conf TB --- 2010-01-21 22:16:25 - /usr/bin/make -B LINT TB --- 2010-01-21 22:16:25 - building LINT kernel TB --- 2010-01-21 22:16:25 - MAKEOBJDIRPREFIX=/obj TB --- 2010-01-21 22:16:25 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-01-21 22:16:25 - TARGET=i386 TB --- 2010-01-21 22:16:25 - TARGET_ARCH=i386 TB --- 2010-01-21 22:16:25 - TZ=UTC TB --- 2010-01-21 22:16:25 - __MAKE_CONF=/dev/null TB --- 2010-01-21 22:16:25 - cd /src TB --- 2010-01-21 22:16:25 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Thu Jan 21 22:16:25 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 >>> stage 3.2: building everything [...] cc -O2 -fno-strict-aliasing -pipe -DFREEBSD_NAMECACHE -DBUILDING_ZFS -D_KERNEL -DKLD_MODULE -std=c99 -nostdinc -I/src/sys/modules/zfs/../../cddl/compat/opensolaris -I/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/zmod -I/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common -I/src/sys/modules/zfs/../.. -I/src/sys/modules/zfs/../../cddl/contrib/opensolaris/common/zfs -I/src/sys/modules/zfs/../../cddl/contrib/opensolaris/common -I/src/sys/modules/zfs/../../../include -DHAVE_KERNEL_OPTION_HEADERS -include /obj/src/sys/LINT/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -I/obj/src/sys/LINT -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointe r-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wno-unknown-pragmas -Wno-missing-prototypes -Wno-undef -Wno-strict-prototypes -Wno-cast-qual -Wno-parentheses -Wno-redundant-decls -Wno-missing-braces -Wno-uninitialized -Wno-unused -Wno-inline -Wno-switch -Wno-pointer-arith -c /src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_byteswap.c cc -O2 -fno-strict-aliasing -pipe -DFREEBSD_NAMECACHE -DBUILDING_ZFS -D_KERNEL -DKLD_MODULE -std=c99 -nostdinc -I/src/sys/modules/zfs/../../cddl/compat/opensolaris -I/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/zmod -I/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common -I/src/sys/modules/zfs/../.. -I/src/sys/modules/zfs/../../cddl/contrib/opensolaris/common/zfs -I/src/sys/modules/zfs/../../cddl/contrib/opensolaris/common -I/src/sys/modules/zfs/../../../include -DHAVE_KERNEL_OPTION_HEADERS -include /obj/src/sys/LINT/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -I/obj/src/sys/LINT -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointe r-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wno-unknown-pragmas -Wno-missing-prototypes -Wno-undef -Wno-strict-prototypes -Wno-cast-qual -Wno-parentheses -Wno-redundant-decls -Wno-missing-braces -Wno-uninitialized -Wno-unused -Wno-inline -Wno-switch -Wno-pointer-arith -c /src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_fm.c cc -O2 -fno-strict-aliasing -pipe -DFREEBSD_NAMECACHE -DBUILDING_ZFS -D_KERNEL -DKLD_MODULE -std=c99 -nostdinc -I/src/sys/modules/zfs/../../cddl/compat/opensolaris -I/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/zmod -I/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common -I/src/sys/modules/zfs/../.. -I/src/sys/modules/zfs/../../cddl/contrib/opensolaris/common/zfs -I/src/sys/modules/zfs/../../cddl/contrib/opensolaris/common -I/src/sys/modules/zfs/../../../include -DHAVE_KERNEL_OPTION_HEADERS -include /obj/src/sys/LINT/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -I/obj/src/sys/LINT -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointe r-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wno-unknown-pragmas -Wno-missing-prototypes -Wno-undef -Wno-strict-prototypes -Wno-cast-qual -Wno-parentheses -Wno-redundant-decls -Wno-missing-braces -Wno-uninitialized -Wno-unused -Wno-inline -Wno-switch -Wno-pointer-arith -c /src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_fuid.c cc -O2 -fno-strict-aliasing -pipe -DFREEBSD_NAMECACHE -DBUILDING_ZFS -D_KERNEL -DKLD_MODULE -std=c99 -nostdinc -I/src/sys/modules/zfs/../../cddl/compat/opensolaris -I/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/zmod -I/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common -I/src/sys/modules/zfs/../.. -I/src/sys/modules/zfs/../../cddl/contrib/opensolaris/common/zfs -I/src/sys/modules/zfs/../../cddl/contrib/opensolaris/common -I/src/sys/modules/zfs/../../../include -DHAVE_KERNEL_OPTION_HEADERS -include /obj/src/sys/LINT/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -I/obj/src/sys/LINT -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointe r-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wno-unknown-pragmas -Wno-missing-prototypes -Wno-undef -Wno-strict-prototypes -Wno-cast-qual -Wno-parentheses -Wno-redundant-decls -Wno-missing-braces -Wno-uninitialized -Wno-unused -Wno-inline -Wno-switch -Wno-pointer-arith -c /src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_znode.c /src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_znode.c: In function 'zfs_create_fs': /src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_znode.c:1523: error: 'vp' undeclared (first use in this function) /src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_znode.c:1523: error: (Each undeclared identifier is reported only once /src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_znode.c:1523: error: for each function it appears in.) *** Error code 1 Stop in /src/sys/modules/zfs. *** Error code 1 Stop in /src/sys/modules. *** Error code 1 Stop in /obj/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2010-01-21 22:44:43 - WARNING: /usr/bin/make returned exit code 1 TB --- 2010-01-21 22:44:43 - ERROR: failed to build lint kernel TB --- 2010-01-21 22:44:43 - 4754.66 user 443.45 system 5584.68 real http://tinderbox.freebsd.org/tinderbox-releng_7-RELENG_7-i386-i386.full From owner-freebsd-stable@FreeBSD.ORG Fri Jan 22 01:23: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 AA5B41065672 for ; Fri, 22 Jan 2010 01:23:20 +0000 (UTC) (envelope-from dan@langille.org) Received: from nyi.unixathome.org (nyi.unixathome.org [64.147.113.42]) by mx1.freebsd.org (Postfix) with ESMTP id 839458FC16 for ; Fri, 22 Jan 2010 01:23:19 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by nyi.unixathome.org (Postfix) with ESMTP id 01DEE5099F; Fri, 22 Jan 2010 01:23:19 +0000 (GMT) X-Virus-Scanned: amavisd-new at unixathome.org Received: from nyi.unixathome.org ([127.0.0.1]) by localhost (nyi.unixathome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aGapP4BdoysY; Fri, 22 Jan 2010 01:23:18 +0000 (GMT) Received: from smtp-auth.unixathome.org (smtp-auth.unixathome.org [10.4.7.7]) (Authenticated sender: hidden) by nyi.unixathome.org (Postfix) with ESMTPSA id 05ACE50823 ; Fri, 22 Jan 2010 01:23:17 +0000 (GMT) Message-ID: <4B58FE0B.3010001@langille.org> Date: Thu, 21 Jan 2010 20:23:23 -0500 From: Dan Langille User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: FreeBSD Stable Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Dan Langille Subject: device.hints isn't setting what I want X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 22 Jan 2010 01:23:20 -0000 Folks, [please CC me on replies] First, see also my post: do I want ch0 or pass1? I have an external tape library and an external tape drive. They are not always powered up. My goal: always get the same devices regardless of whether or not the tape library is powered on at boot. After booting, with the tape library powered on, I have these devices: # camcontrol devlist at scbus0 target 5 lun 0 (sa0,pass0) at scbus1 target 0 lun 0 (ch0,pass1) at scbus1 target 5 lun 0 (sa1,pass2) at scbus2 target 0 lun 0 (cd0,pass3) at scbus5 target 0 lun 0 (da0,pass4) In /boot/devices, I have added these entries: hint.scbus.1.at="ahc0" hint.scbus.0.at="ahc1" hint.scbus.2.at="acd0" hint.scbus.5.at="umass0" The first two lines ensure I always get the QUANTUM drive at sa0, and the DEC at sa1. That part works. The second two lines aren't doing as expected. If the external tape library is not powered up, I get: # camcontrol devlist at scbus0 target 5 lun 0 (sa0,pass0) at scbus3 target 0 lun 0 (cd0,pass1) at scbus7 target 0 lun 0 (da0,pass2) Then, after powering up, and doing a rescan all, I get: # camcontrol devlist at scbus0 target 5 lun 0 (sa0,pass0) at scbus1 target 0 lun 0 (pass3,ch0) at scbus1 target 5 lun 0 (pass4,sa1) at scbus3 target 0 lun 0 (cd0,pass1) at scbus7 target 0 lun 0 (da0,pass2) So... I could keep the unit powered on all the time, but that's really not what I want to do. Clues please? Full dmesg output at http://www.langille.org/tmp/dmesg.boot From owner-freebsd-stable@FreeBSD.ORG Fri Jan 22 01:23:39 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 1D82F10656C7 for ; Fri, 22 Jan 2010 01:23:39 +0000 (UTC) (envelope-from dan@langille.org) Received: from nyi.unixathome.org (nyi.unixathome.org [64.147.113.42]) by mx1.freebsd.org (Postfix) with ESMTP id EC3198FC20 for ; Fri, 22 Jan 2010 01:23:38 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by nyi.unixathome.org (Postfix) with ESMTP id 799475099F; Fri, 22 Jan 2010 01:23:38 +0000 (GMT) X-Virus-Scanned: amavisd-new at unixathome.org Received: from nyi.unixathome.org ([127.0.0.1]) by localhost (nyi.unixathome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0GB5PArj+5p2; Fri, 22 Jan 2010 01:23:37 +0000 (GMT) Received: from smtp-auth.unixathome.org (smtp-auth.unixathome.org [10.4.7.7]) (Authenticated sender: hidden) by nyi.unixathome.org (Postfix) with ESMTPSA id A90D8509A5 ; Fri, 22 Jan 2010 01:23:37 +0000 (GMT) Message-ID: <4B58FE1F.5020402@langille.org> Date: Thu, 21 Jan 2010 20:23:43 -0500 From: Dan Langille User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: FreeBSD Stable Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Dan Langille Subject: do I want ch0 or pass1? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 22 Jan 2010 01:23:39 -0000 Please CC me on replies. I'm running into issues with hard-coding some devices (see recent post titled 'device.hints isn't setting what I want'). Associated with this issue is confusion over whether I want to use ch0 or pass1. I have these devices: at scbus1 target 0 lun 0 (ch0,pass1) at scbus1 target 5 lun 0 (sa1,pass2) My understanding: chio(1) will with ch0, whereas mtx(1) will work with pass1. Is this correct? More information/elaboration will help I'm sure. Why do I ask? I can get the tape changer and tape drive hardwired to ch0 and sa1 respectively. I cannot [yet] do the same with pass1. Thanks folks. From owner-freebsd-stable@FreeBSD.ORG Fri Jan 22 03:57: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 59831106566B; Fri, 22 Jan 2010 03:57:24 +0000 (UTC) (envelope-from dan.naumov@gmail.com) Received: from mail-yw0-f194.google.com (mail-yw0-f194.google.com [209.85.211.194]) by mx1.freebsd.org (Postfix) with ESMTP id 068FF8FC14; Fri, 22 Jan 2010 03:57:23 +0000 (UTC) Received: by ywh32 with SMTP id 32so676973ywh.14 for ; Thu, 21 Jan 2010 19:57:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type; bh=IbSzMq+ZGDcROzUbveKlhcUwAxsGGTFw5WScPJr5UYo=; b=BhLht2RpBEnwCqK1QS09Kn2++5e4jUmodYUhTTViDZXN9mwTHuNFBmaW7ExawRpXyM hRXNPsmR6dKJ43OuvbLWefzhX0scRa+lLzV710eJZOC8t4Y63IJRo5i0d7k9UsiPuLGo Q/GN5Zv40L05n1PjIGjzURjzColERBXJVlp7I= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=nwM+BEBO1NLvFG0tGLU4BYTn1Dzn2aEnIg9ytXPgLOORsRd8UHf6nPPpky2AS5iqZ+ u0c17INow/erG8OkIZLpAmkWr+Z8M51B0jCt34DFXFIvxGVRyGPlNiCc20cuhu/nVoqb D3YuuzHmfeqe1lC3DQl9bHhIYUp5o4t11Yr28= MIME-Version: 1.0 Received: by 10.101.34.8 with SMTP id m8mr3119683anj.211.1264132643379; Thu, 21 Jan 2010 19:57:23 -0800 (PST) Date: Fri, 22 Jan 2010 05:57:23 +0200 Message-ID: From: Dan Naumov To: freebsd-questions@freebsd.org, FreeBSD-STABLE Mailing List Content-Type: text/plain; charset=ISO-8859-1 Cc: Subject: Loader, MBR and the boot process X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 22 Jan 2010 03:57:24 -0000 I recently found a nifty "FreeBSD ZFS root installation script" and been reworking it a bit to suit my needs better, including changing it from GPT to MBR partitioning. However, I was stumped, even though I had done everything right (or so I thought), the system would get stuck at Loader and refuse to go anywhere. After trying over a dozen different things, it downed on me to change the partition order inside the slice, I had 1) swap 2) freebsd-zfs and for the test, I got rid of swap altogether and gave the entire slice to the freebsd-zfs partition. Suddenly, my problem went away and the system booted just fine. So it seems that Loader requires that the partition containing the files vital to the boot is the first partition on the slice and that "swap first, then the rest" doesn't work. The thing is, I am absolutely positive that in the past, I've had sysinstall created installs using MBR partitioning and that I had swap as my first partition inside the slice and that it all worked dandy. Has this changed at some point? Oh, and for the curious the installation script is here: http://jago.pp.fi/zfsmbrv1-works.sh - Sincerely, Dan Naumov From owner-freebsd-stable@FreeBSD.ORG Fri Jan 22 04:17: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 603F7106568D for ; Fri, 22 Jan 2010 04:17:07 +0000 (UTC) (envelope-from boydjd@jbip.net) Received: from mail-fx0-f227.google.com (mail-fx0-f227.google.com [209.85.220.227]) by mx1.freebsd.org (Postfix) with ESMTP id DF1078FC18 for ; Fri, 22 Jan 2010 04:17:06 +0000 (UTC) Received: by fxm27 with SMTP id 27so30960fxm.3 for ; Thu, 21 Jan 2010 20:17:05 -0800 (PST) MIME-Version: 1.0 Received: by 10.239.188.145 with SMTP id p17mr274446hbh.175.1264133825136; Thu, 21 Jan 2010 20:17:05 -0800 (PST) In-Reply-To: <33c6b0bc1001210954q206401f4n51d97af7f861e99c@mail.gmail.com> References: <33c6b0bc1001210916u2131713do712e23ddaaa40cde@mail.gmail.com> <4B589457.2060008@icyb.net.ua> <33c6b0bc1001210954q206401f4n51d97af7f861e99c@mail.gmail.com> From: Joshua Boyd Date: Thu, 21 Jan 2010 23:16:45 -0500 Message-ID: <33c6b0bc1001212016r68aaf62cl8d3a88c4abce0c15@mail.gmail.com> Cc: freebsd-stable@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Re: install: amdsbwd.ko: No such file or directory X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 22 Jan 2010 04:17:07 -0000 Well, I have good news and bad news. I was able to get the kernel installed, reboot, and do a mergemaster -p. When I went to do installworld, it failed on me. I tried to do buildworld again, and get this: ------------ cc -O2 -pipe -DNEED_SOLARIS_BOOLEAN -I/usr/src/cddl/usr.bin/ctfconvert/../../../sys/cddl/compat/opensolaris -I/usr/src/cddl/usr.bin/ctfconvert/../../../cddl/compat/opensolaris/include -I/usr/src/cddl/usr.bin/ctfconvert/../../../cddl/contrib/opensolaris -I/usr/src/cddl/usr.bin/ctfconvert/../../../sys/cddl/contrib/opensolaris -I/usr/src/cddl/usr.bin/ctfconvert/../../../cddl/contrib/opensolaris/head -I/usr/src/cddl/usr.bin/ctfconvert/../../../cddl/contrib/opensolaris/tools/ctf/common -I/usr/src/cddl/usr.bin/ctfconvert/../../../cddl/contrib/opensolaris/tools/ctf/cvt -I/usr/src/cddl/usr.bin/ctfconvert/../../../sys/cddl/contrib/opensolaris/uts/common -DNEED_SOLARIS_BOOLEAN -g -Wno-unknown-pragmas -I/usr/obj/usr/src/tmp/legacy/usr/include -static -L/usr/obj/usr/src/tmp/legacy/usr/lib -o ctfconvert alist.o ctf.o ctfconvert.o dwarf.o fixup_tdescs.o hash.o iidesc.o input.o list.o memory.o merge.o output.o st_parse.o stabs.o stack.o strtab.o symbol.o tdata.o traverse.o util.o -lctf -ldwarf -lelf -lz -lthr -legacy /usr/lib/libthr.a(thr_syscalls.o)(.text+0x87a): In function `___pselect': : undefined reference to `__pselect' *** Error code 1 Stop in /usr/src/cddl/usr.bin/ctfconvert. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. ------------ I tried to re cvsup, make cleanworld && make cleandir, and moved my make.conf and src.conf out of the way. Build dies at the same place. Googling found this other fellow with the same problem, but no solution: http://forums.freebsd.org/showthread.php?p=63531 Any help would be appreciated. Thanks. On Thu, Jan 21, 2010 at 12:54 PM, Joshua Boyd wrote: > I'm sorry, it's installkernel that fails. > > I'll provide more details tonight when I get home from work. > > On Thu, Jan 21, 2010 at 12:52 PM, Andriy Gapon wrote: > >> on 21/01/2010 19:16 Joshua Boyd said the following: >> > make buildkernel KERNCONF=CUSTOM fails on latest 8-STABLE. >> > >> > Here's the diff between GENERIC and CUSTOM: >> > $ diff GENERIC CUSTOM >> > 323a324,343 >> >> # pf support >> >> device mem >> >> device pf >> >> device pflog >> >> device pfsync >> >> >> >> # altq support >> >> options ALTQ >> >> options ALTQ_CBQ >> >> options ALTQ_RED >> >> options ALTQ_RIO >> >> options ALTQ_HFSC >> >> options ALTQ_PRIQ >> >> options ALTQ_NOPCC >> >> >> >> # other optimizations >> >> device amdsbwd #Only added to see if this would help >> >> options HZ=1000 >> >> options DEVICE_POLLING >> > >> > buildkernel fails out with: >> > >> > install: amdsbwd.ko: No such file or directory >> > >> > Any help would be appreciated. cvsup was done last night. Let me know if >> any >> > additional info is needed. >> >> Hmm, I didn't think that buildkernel executes install.. >> Could you provide a little bit more context from the build? >> >> -- >> Andriy Gapon >> > > > > -- > Joshua Boyd > JBipNet > > E-mail: boydjd@jbip.net > > http://www.jbip.net > -- Joshua Boyd JBipNet E-mail: boydjd@jbip.net http://www.jbip.net From owner-freebsd-stable@FreeBSD.ORG Fri Jan 22 04:42: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 B5DE5106566B for ; Fri, 22 Jan 2010 04:42:33 +0000 (UTC) (envelope-from fwd@gothschlampen.com) Received: from vs.gothschlampen.com (vs.gothschlampen.com [85.93.11.85]) by mx1.freebsd.org (Postfix) with ESMTP id 7BF5B8FC14 for ; Fri, 22 Jan 2010 04:42:33 +0000 (UTC) Received: by vs.gothschlampen.com (Postfix, from userid 667) id A85E01D33B0; Fri, 22 Jan 2010 05:12:37 +0100 (CET) Date: Fri, 22 Jan 2010 05:12:37 +0100 From: "Thomas K." To: Dan Naumov Message-ID: <20100122041237.GA22312@gothschlampen.com> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.13 (2006-08-11) Cc: FreeBSD-STABLE Mailing List , freebsd-questions@freebsd.org Subject: Re: Loader, MBR and the boot process X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 22 Jan 2010 04:42:33 -0000 On Fri, Jan 22, 2010 at 05:57:23AM +0200, Dan Naumov wrote: Hi, > I recently found a nifty "FreeBSD ZFS root installation script" and > been reworking it a bit to suit my needs better, including changing it > from GPT to MBR partitioning. However, I was stumped, even though I > had done everything right (or so I thought), the system would get > stuck at Loader and refuse to go anywhere. After trying over a dozen probably this line is the cause: dd if=/mnt2/boot/zfsboot of=/dev/"${TARGETDISK}"s1a skip=1 seek=1024 Unless by "swap first" you meant the on-disk location, and not the partition letter. If swap is partition "a", you're writing the loader into swapspace. Regards, Thomas From owner-freebsd-stable@FreeBSD.ORG Fri Jan 22 04:49: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 47A7B106566B; Fri, 22 Jan 2010 04:49:40 +0000 (UTC) (envelope-from dan.naumov@gmail.com) Received: from mail-gx0-f214.google.com (mail-gx0-f214.google.com [209.85.217.214]) by mx1.freebsd.org (Postfix) with ESMTP id E52D68FC1A; Fri, 22 Jan 2010 04:49:39 +0000 (UTC) Received: by gxk6 with SMTP id 6so770609gxk.13 for ; Thu, 21 Jan 2010 20:49:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=+C20RlyeKWN9L9zforGnj2NIKCtrfi5b9oXjzXlykRk=; b=AjQuVEjejnEgRhyyyUX3OtfUWBFG2IbO38CtBafmuPYzQHxznY14uOqxnMfjs13tuc 5A9HZob5xMKB5gJO00eFZzMGJ2AxL4e2FwSsAUrSbUgCtcxFIwLRrgbpD4X3/4VuDG8h QFBCOO5fu33cGSX8QxECy9xR2ujP+b+drwbRA= 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=MBme+mMvKHgQEGb/8ARcjD3km+0xcoQy+TtLDHteghMYPzx14BCdDmAjzVJ7w+jFh/ il4kaN55CgM58MmLD0bXlhN3mWWsKcUBd836nk45BGOzgqNVQjIB4IjufRlEBdE8B9pc aIjys+MztlU690lD9EjF/LnkACQoUgv0T6e34= MIME-Version: 1.0 Received: by 10.101.6.22 with SMTP id j22mr3159040ani.224.1264135778989; Thu, 21 Jan 2010 20:49:38 -0800 (PST) In-Reply-To: <20100122041237.GA22312@gothschlampen.com> References: <20100122041237.GA22312@gothschlampen.com> Date: Fri, 22 Jan 2010 06:49:38 +0200 Message-ID: From: Dan Naumov To: "Thomas K." Content-Type: text/plain; charset=ISO-8859-1 Cc: FreeBSD-STABLE Mailing List , freebsd-questions@freebsd.org Subject: Re: Loader, MBR and the boot process X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 22 Jan 2010 04:49:40 -0000 On Fri, Jan 22, 2010 at 6:12 AM, Thomas K. wrote: > On Fri, Jan 22, 2010 at 05:57:23AM +0200, Dan Naumov wrote: > > Hi, > >> I recently found a nifty "FreeBSD ZFS root installation script" and >> been reworking it a bit to suit my needs better, including changing it >> from GPT to MBR partitioning. However, I was stumped, even though I >> had done everything right (or so I thought), the system would get >> stuck at Loader and refuse to go anywhere. After trying over a dozen > > probably this line is the cause: > > dd if=/mnt2/boot/zfsboot of=/dev/"${TARGETDISK}"s1a skip=1 seek=1024 > > Unless by "swap first" you meant the on-disk location, and not the > partition letter. If swap is partition "a", you're writing the loader > into swapspace. > > > Regards, > Thomas At first you made me feel silly, but then I decided to double-check, I uncommented the swap line in the partitioning part again, ensured I was writing the bootloader to "${TARGETDISK}"s1b and ran the script. Same problem, hangs at loader. Again, if I comment out the swap, giving the entire slice to ZFS and then write the bootloader to "${TARGETDISK}"s1a, run the script, everything works. - Sincerely, Dan Naumov From owner-freebsd-stable@FreeBSD.ORG Fri Jan 22 05:02: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 EA06A106566B; Fri, 22 Jan 2010 05:02:54 +0000 (UTC) (envelope-from dan.naumov@gmail.com) Received: from mail-yx0-f171.google.com (mail-yx0-f171.google.com [209.85.210.171]) by mx1.freebsd.org (Postfix) with ESMTP id 923C58FC17; Fri, 22 Jan 2010 05:02:54 +0000 (UTC) Received: by yxe1 with SMTP id 1so677206yxe.3 for ; Thu, 21 Jan 2010 21:02:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=A2GhY+Mbos8pkVtiDeoMQCNYdQE2+Fu1KhfPkWs1/YQ=; b=I3lH1VyVFy5QD8ZE1o5xBjmPYCkmieKL2Pc5gDx5g1CZuy3D7P8f9cldyIv2SnAY8r oi/lJH+TfYoX5AyVjQKhwj6K0DN5aQoB6PhpBVJDBwbt8fyYdkkVPNL34rIXymglSLbw yDL35E6PEao9hu+zynKtDioeluoAxoaWzM/Ec= 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=XnK2ZB3gPfI0Kpd/T7KbZ94dUN51KNuaR85agk4xMXfGmo+Xo251/OTpD55+ibGVJx Dsn4+wqJlNwokRdevR4GodzI/1VkUVkDKzYUL21O4kikILfzsejPYIIon5QMqdlGsNuA pwAFUXzTilZl5RM/HjQwgfhTHOS5RlczwTYQ8= MIME-Version: 1.0 Received: by 10.101.10.24 with SMTP id n24mr3278061ani.78.1264136573668; Thu, 21 Jan 2010 21:02:53 -0800 (PST) In-Reply-To: References: <20100122041237.GA22312@gothschlampen.com> Date: Fri, 22 Jan 2010 07:02:53 +0200 Message-ID: From: Dan Naumov To: "Thomas K." Content-Type: text/plain; charset=ISO-8859-1 Cc: FreeBSD-STABLE Mailing List , freebsd-questions@freebsd.org Subject: Re: Loader, MBR and the boot process X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 22 Jan 2010 05:02:55 -0000 On Fri, Jan 22, 2010 at 6:49 AM, Dan Naumov wrote: > On Fri, Jan 22, 2010 at 6:12 AM, Thomas K. wrote: >> On Fri, Jan 22, 2010 at 05:57:23AM +0200, Dan Naumov wrote: >> >> Hi, >> >>> I recently found a nifty "FreeBSD ZFS root installation script" and >>> been reworking it a bit to suit my needs better, including changing it >>> from GPT to MBR partitioning. However, I was stumped, even though I >>> had done everything right (or so I thought), the system would get >>> stuck at Loader and refuse to go anywhere. After trying over a dozen >> >> probably this line is the cause: >> >> dd if=/mnt2/boot/zfsboot of=/dev/"${TARGETDISK}"s1a skip=1 seek=1024 >> >> Unless by "swap first" you meant the on-disk location, and not the >> partition letter. If swap is partition "a", you're writing the loader >> into swapspace. >> >> >> Regards, >> Thomas > > At first you made me feel silly, but then I decided to double-check, I > uncommented the swap line in the partitioning part again, ensured I > was writing the bootloader to "${TARGETDISK}"s1b and ran the script. > Same problem, hangs at loader. Again, if I comment out the swap, > giving the entire slice to ZFS and then write the bootloader to > "${TARGETDISK}"s1a, run the script, everything works. I have also just tested creating 2 slices, like this: gpart create -s mbr "${TARGETDISK}" gpart add -s 3G -t freebsd "${TARGETDISK}" gpart create -s BSD "${TARGETDISK}"s1 gpart add -t freebsd-swap "${TARGETDISK}"s1 gpart add -t freebsd "${TARGETDISK}" gpart create -s BSD "${TARGETDISK}"s2 gpart add -t freebsd-zfs "${TARGETDISK}"s2 gpart set -a active -i 2 "${TARGETDISK}" gpart bootcode -b /mnt2/boot/boot0 "${TARGETDISK}" and later: dd if=/mnt2/boot/zfsboot of=/dev/"${TARGETDISK}"s2 count=1 dd if=/mnt2/boot/zfsboot of=/dev/"${TARGETDISK}"s2a skip=1 seek=1024 Putting the swap into it's own slice and then putting FreeBSD into it's own slice worked fine. So why the hell can't they both coexist in 1 slice if the swap comes first? - Dan Naumov From owner-freebsd-stable@FreeBSD.ORG Fri Jan 22 06:36: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 209721065676; Fri, 22 Jan 2010 06:36:53 +0000 (UTC) (envelope-from dnaeon@gmail.com) Received: from mail-ew0-f211.google.com (mail-ew0-f211.google.com [209.85.219.211]) by mx1.freebsd.org (Postfix) with ESMTP id 7A8AE8FC13; Fri, 22 Jan 2010 06:36:51 +0000 (UTC) Received: by ewy3 with SMTP id 3so948990ewy.33 for ; Thu, 21 Jan 2010 22:36:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type; bh=Xn4lfjswCA1iWbd69Hqih7OWN6LC6yL3xllY3SacPHo=; b=i/EC8vfaIbLXjUtp5K8JsTsmAN1X3FMbfpV/JFje9OpN8thN0bonJYJHH6G5kWhb/z an8xY2SoRXmSBvJ/IEm1lQZviNhH56wc5ZPB3cBxnoJ259ezCKzBiieblNtdmTxESCBL OUQCv4qcVVcm31EPQaKMvT1+TzSBQwbAyBNz4= 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=T4wveQJb30WuT99uVG1uG8f0mNStO6RFOhu+zSqJcb9r4Qdfhwm2uPFTxGvCOanNRX LiEoMS6a8DdWb9gc6JqUUK2CThX5CK6n5B7i7AJd8f+u458Tg8fi/iGU5EE/ioVbo+3o iwNiCOAD9KGJuBZZQZX6mrRyDbpOhErl+fdyo= MIME-Version: 1.0 Received: by 10.216.91.6 with SMTP id g6mr921101wef.212.1264142211124; Thu, 21 Jan 2010 22:36:51 -0800 (PST) In-Reply-To: <20100121162649.GP96430@acme.spoerlein.net> References: <717f7a3e1001120714m37aada69gfaa35f0f9b17f435@mail.gmail.com> <44678539@bb.ipt.ru> <717f7a3e1001142234y1de7ae15x6853e3ddcab4add9@mail.gmail.com> <717f7a3e1001192246o4dce4a82q57c05ff3f41b5feb@mail.gmail.com> <20100120074611.GA405@icarus.home.lan> <717f7a3e1001210137p7884adcbxc66a4f7fff928821@mail.gmail.com> <20100121162649.GP96430@acme.spoerlein.net> Date: Fri, 22 Jan 2010 08:36:51 +0200 Message-ID: <717f7a3e1001212236x78c12d1ue22283338e3e179c@mail.gmail.com> From: Marin Atanasov To: Marin Atanasov , freebsd-hardware@freebsd.org, freebsd-stable@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Subject: Re: Multiple serial consoles via null modem cable X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 22 Jan 2010 06:36:53 -0000 On Thu, Jan 21, 2010 at 6:26 PM, Ulrich Sp=F6rlein wrot= e: > On Thu, 21.01.2010 at 11:37:06 +0200, Marin Atanasov wrote: > > Here's what I did: > > > > box1 COM1/ttyd0 -> box2 COM1/ttyd0 -> using null modem cable > > box1 COM2/ttyd1 -> box3 COM1/ttyd0 -> using null modem cable > > > > On box1 I have this in /etc/ttys: > > > > ttyd0 "/usr/libexec/getty std.9600" vt100 on secure > > ttyd1 "/usr/libexec/getty std.9600" vt100 on secure > > > > Now if I want to connect to box1 from box2 or box3 through the serial > > connection it should work, right? > > But I only can connect to box1 from box2, because box2's COM port is > > connected to box1's COM1 port. > > Are there actually two gettys running on the serial ports? Did you do > kill -1 1 after the changes to /etc/ttys? > > On box1, what do the following commands produce > > egrep "uart|sio" /var/run/dmesg.boot > pgrep -fl getty > > Regards, > Uli > Hi, This is the output from the requested commands: box1# egrep 'uart|sio' /var/run/dmesg.boot usb0: USB revision 1.0 sio0: <16550A-compatible COM port> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 sio0: type 16550A sio1: <16550A-compatible COM port> port 0x2f8-0x2ff irq 3 on acpi0 sio1: type 16550A box1# pgrep -fl getty 3066 /usr/libexec/getty std.9600 ttyd1 3065 /usr/libexec/getty std.9600 ttyd0 534 /usr/libexec/getty Pc ttyv7 533 /usr/libexec/getty Pc ttyv6 532 /usr/libexec/getty Pc ttyv5 531 /usr/libexec/getty Pc ttyv4 530 /usr/libexec/getty Pc ttyv3 529 /usr/libexec/getty Pc ttyv2 528 /usr/libexec/getty Pc ttyv1 527 /usr/libexec/getty Pc ttyv0 Regards, Marin --=20 Marin Atanasov Nikolov dnaeon AT gmail DOT com daemon AT unix-heaven DOT org From owner-freebsd-stable@FreeBSD.ORG Fri Jan 22 08:02: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 ECB43106566B for ; Fri, 22 Jan 2010 08:02:31 +0000 (UTC) (envelope-from njm@njm.me.uk) Received: from smtp004.apm-internet.net (smtp004.apm-internet.net [85.119.248.54]) by mx1.freebsd.org (Postfix) with SMTP id 77CF18FC0C for ; Fri, 22 Jan 2010 08:02:30 +0000 (UTC) Received: (qmail 41025 invoked from network); 22 Jan 2010 08:02:29 -0000 Received: from unknown (HELO oberon.njm.me.uk) (86.129.211.242) by smtp004.apm-internet.net with SMTP; 22 Jan 2010 08:02:29 -0000 Received: from titania.njm.me.uk (titania.njm.me.uk [192.168.144.130]) by oberon.njm.me.uk (8.14.3/8.14.3) with ESMTP id o0M82TL2084197; Fri, 22 Jan 2010 08:02:29 GMT (envelope-from njm@njm.me.uk) Received: from titania.njm.me.uk (localhost [127.0.0.1]) by titania.njm.me.uk (8.14.3/8.14.3) with ESMTP id o0M82S69015969; Fri, 22 Jan 2010 08:02:28 GMT (envelope-from njm@njm.me.uk) Received: (from njm@localhost) by titania.njm.me.uk (8.14.3/8.14.3/Submit) id o0M82N2e015968; Fri, 22 Jan 2010 08:02:23 GMT (envelope-from njm@njm.me.uk) Date: Fri, 22 Jan 2010 08:02:23 +0000 From: "N.J. Mann" To: Marin Atanasov Message-ID: <20100122080223.GA6681@titania.njm.me.uk> Mail-Followup-To: Marin Atanasov , Jeremy Chadwick , freebsd-hardware@freebsd.org, freebsd-stable@freebsd.org, Ronald Klop References: <717f7a3e1001120714m37aada69gfaa35f0f9b17f435@mail.gmail.com> <44678539@bb.ipt.ru> <717f7a3e1001142234y1de7ae15x6853e3ddcab4add9@mail.gmail.com> <717f7a3e1001192246o4dce4a82q57c05ff3f41b5feb@mail.gmail.com> <20100120074611.GA405@icarus.home.lan> <717f7a3e1001210137p7884adcbxc66a4f7fff928821@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <717f7a3e1001210137p7884adcbxc66a4f7fff928821@mail.gmail.com> X-Operating-System: FreeBSD 7.2-STABLE User-Agent: mutt-NJM (2009-12-30) Cc: Ronald Klop , freebsd-stable@freebsd.org, Jeremy Chadwick , freebsd-hardware@freebsd.org Subject: Re: Multiple serial consoles via null modem cable X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 22 Jan 2010 08:02:32 -0000 In message <717f7a3e1001210137p7884adcbxc66a4f7fff928821@mail.gmail.com>, Marin Atanasov (dnaeon@gmail.com) wrote: > Hello Jeremy, > > Now I'm a little confused :) > > I've made some tests with my machines and a couple of null modem cables, and > here's what I've got. > > On Wed, Jan 20, 2010 at 9:46 AM, Jeremy Chadwick > wrote: > > > On Wed, Jan 20, 2010 at 08:46:48AM +0200, Marin Atanasov wrote: > > > Hello, > > > > > > Using `cu' only works with COM1 for me. > > > > > > Currently I have two serial ports on the system, and only the first is > > able > > > to make the connection - the serial consoles are enabled in /etc/tty, but > > as > > > I said only COM1 is able to make the connection. > > > > I'm a little confused by this statement, so I'll add some clarify: > > > > /etc/ttys is for configuring a machine to tie getty (think login prompt) > > to a device (in this case, a serial port). Meaning: the device on the > > other end of the serial cable will start seeing "login:" and so on > > assuming you attach to the serial port there. > > > > For example: > > > > box1 COM1/ttyu0 is wired to box2 COM3/ttyu2 using a null modem cable. > > box1 COM2/ttyu1 is wired to box2 COM4/ttyu3 using a null modem cable. > > > > On box1, you'd have something like this in /etc/ttys: > > > > ttyu0 "/usr/libexec/getty std.9600" vt100 on secure > > ttyu1 "/usr/libexec/getty std.9600" vt100 on secure > > > > Here's what I did: > > box1 COM1/ttyd0 -> box2 COM1/ttyd0 -> using null modem cable > box1 COM2/ttyd1 -> box3 COM1/ttyd0 -> using null modem cable > > On box1 I have this in /etc/ttys: > > ttyd0 "/usr/libexec/getty std.9600" vt100 on secure > ttyd1 "/usr/libexec/getty std.9600" vt100 on secure > > Now if I want to connect to box1 from box2 or box3 through the serial > connection it should work, right? > But I only can connect to box1 from box2, because box2's COM port is > connected to box1's COM1 port. > > >From box2 I can get a login prompt > box2# cu -l /dev/cuad0 -s 9600 > Connected > > login: > ) > (host.domain) (ttyd0) > > login: ~ > [EOT] > > But if I try to connect to box1 from box3 - no success there. > box3# cu -l /dev/cuad0 -s 9600 > Connected > ~ > [EOT] You need to reduce the number of unknowns, e.g. where is the problem: box1, box3 or in between. So, swap the cables on box1 so that you now have box1:COM1 -> box3:COM1 and box1:COM2 -> box2:COM1. Now repeat the tests above and post your results. Cheers, Nick. -- From owner-freebsd-stable@FreeBSD.ORG Fri Jan 22 08:08: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 1530E106566B; Fri, 22 Jan 2010 08:08:51 +0000 (UTC) (envelope-from flo@smeets.im) Received: from mail.solomo.de (mail.solomo.de [85.214.124.163]) by mx1.freebsd.org (Postfix) with ESMTP id A43298FC0C; Fri, 22 Jan 2010 08:08:50 +0000 (UTC) Received: from mail.solomo.de (localhost [127.0.0.1]) by mail.solomo.de (Postfix) with ESMTP id 654C861ED3; Fri, 22 Jan 2010 09:08:49 +0100 (CET) X-Virus-Scanned: amavisd-new at vistream.de Received: from mail.solomo.de ([127.0.0.1]) by mail.solomo.de (mail.solomo.de [127.0.0.1]) (amavisd-new, port 10024) with LMTP id e6WkBHxMqCLA; Fri, 22 Jan 2010 09:08:47 +0100 (CET) Received: from nibbler.vistream.local (relay3.vistream.de [87.139.10.28]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mail.solomo.de (Postfix) with ESMTPSA id 07AF261C94; Fri, 22 Jan 2010 09:08:47 +0100 (CET) Message-ID: <4B595D0D.3060904@smeets.im> Date: Fri, 22 Jan 2010 09:08:45 +0100 From: Florian Smeets User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.3a1pre) Gecko/20100121 Shredder/3.2a1pre MIME-Version: 1.0 To: John Baldwin References: <4B58280C.50602@smeets.im> <201001211405.35615.jhb@freebsd.org> <4B58A66E.3040900@smeets.im> <201001211515.32562.jhb@freebsd.org> In-Reply-To: <201001211515.32562.jhb@freebsd.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: Luigi Rizzo , freebsd-stable@freebsd.org Subject: Re: 7.2-STABLE page fault with kernel from 12.01.2010 / crashinfo available X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 22 Jan 2010 08:08:51 -0000 On 1/21/10 9:15 PM, John Baldwin wrote: > On Thursday 21 January 2010 2:09:34 pm Florian Smeets wrote: >> On 1/21/10 8:05 PM, John Baldwin wrote: >>> On Thursday 21 January 2010 1:33:35 pm Florian Smeets wrote: >>>> On 1/21/10 6:58 PM, John Baldwin wrote: >>>>> On Thursday 21 January 2010 8:25:22 am Florian Smeets wrote: >>>>>> (kgdb) frame 8 >>>>>> #8 0xc05f8b28 in ip_forward (m=0xc23dc900, srcrt=0) at >>>>>> /usr/src/sys/netinet/ip_input.c:1307 >>>>>> 1307 m_copydata(m, 0, mcopy->m_len, mtod(mcopy, caddr_t)); >>>>>> (kgdb) l >>>>>> 1302 mcopy = NULL; >>>>>> 1303 } >>>>>> 1304 if (mcopy != NULL) { >>>>>> 1305 mcopy->m_len = min(ip->ip_len, M_TRAILINGSPACE(mcopy)); >>>>>> 1306 mcopy->m_pkthdr.len = mcopy->m_len; >>>>>> 1307 m_copydata(m, 0, mcopy->m_len, mtod(mcopy, caddr_t)); >>>>>> 1308 } >>>>>> 1309 >>>>>> 1310 #ifdef IPSTEALTH >>>>>> 1311 if (!ipstealth) { >>>>>> (kgdb) p *m >>>>>> $1 = {m_hdr = {mh_next = 0x0, mh_nextpkt = 0x0, mh_data = 0xc271e80e >>>>>> "E\020", mh_len = 164, mh_flags = 3, mh_type = 1, pad = "\000"}, M_dat > = >>>>>> {MH = {MH_pkthdr = {rcvif = 0xc20a4800, header = 0x0, len = 164, >>>>>> csum_flags = 3072, >>>>>> csum_data = 65535, tso_segsz = 0, ether_vtag = 0, tags = >>>>>> {slh_first = 0xc35bc380}}, MH_dat = {MH_ext = {ext_buf = 0xc271e800 "", >>>>>> ext_free = 0, ext_args = 0x0, ext_size = 2048, ref_cnt = 0xc2703ab4, >>>>>> ext_type = 6}, >>>>>> MH_databuf = >>>>>> "\000?q?\000\000\000\000\000\000\000\000\000\b\000\000?:p? >>>>> \006\000\000\000dL?\t<+?\202\200\020 >>>>>> O/\207\000\000\001\001\b\n-?b\230qms?\000\000\004\001?l? > \000\000\001%r??? >>>>> \200\000????\034?Ot?\b?{sr\000\034org.jboss.mq.ConnectionToken?\b߼&? >>>>> >>> > \237N\002\000\005I\000\004hashZ\000\asameJVML\000\bclientIDt\000\022Ljava/l\000\220\032Ae\207\000\002? >>>>> 36@\210d\021\000\001? >>> \001B\000!E\000\001@bV\000\000@2\032$W\213\n\034"...}}, >>>>>> >>>>>> M_databuf = >>>>>> "\000H\n?\000\000\000\000?\000\000\000\000\f\000\000?? >>>>> \000\000\000\000\000\000\200?[?\000?q? >>>>> \000\000\000\000\000\000\000\000\000\b\000\000?:p?\006\000\000\000dL? > \t<+? >>>>> \202\200\020 >>>>>> O/\207\000\000\001\001\b\n-?b\230qms?\000\000\004\001?l? > \000\000\001%r??? >>>>> \200\000????\034?Ot?\b?{sr\000\034org.jboss.mq.ConnectionToken?\b߼&? >>>>> >>> > \237N\002\000\005I\000\004hashZ\000\asameJVML\000\bclientIDt\000\022Ljava/l\000\220\032Ae\207\000\002? >>>>> 3"...}} >>>>> >>>>> Ok, can you do 'p *m_copy'? >>>>> >>>> >>>> What ever you want :-) >>>> >>>> (kgdb) p *m_copy >>>> No symbol "m_copy" in current context. >>>> (kgdb) p *m_copydata >>>> $2 = {void (const struct mbuf *, int, int, caddr_t)} > 0xc0572e10 >>>> (kgdb) p *mcopy >>>> $1 = {m_hdr = {mh_next = 0x0, mh_nextpkt = 0x0, mh_data = 0xc23cce34 >>>> "E\020", mh_len = 204, mh_flags = 2, mh_type = 1, pad = "\000"}, M_dat = >>>> {MH = {MH_pkthdr = {rcvif = 0xc20a4800, header = 0x0, >>>> len = 204, csum_flags = 3072, csum_data = 65535, tso_segsz = 0, >>>> ether_vtag = 0, tags = {slh_first = 0xc23c3e00}}, MH_dat = {MH_ext = >>>> {ext_buf = 0x84001045
, >>> >>> Hmm, ok. Can you do 'p *ip'? mcopy->m_len (204) is larger than m->m_len >>> (164). That shouldn't be the case unless ip->ip_len is somehow larger > than m- >>>> m_len. >>> >> >> (kgdb) p *ip >> $3 = {ip_hl = 5, ip_v = 4, ip_tos = 16 '\020', ip_len = 33792, ip_id = >> 61492, ip_off = 64, ip_ttl = 64 '@', ip_p = 6 '\006', ip_sum = 34849, >> ip_src = {s_addr = 355576000}, ip_dst = { >> s_addr = 2251401408}} > > Looks like ip_len is in network byte order instead of host byte order and that > is causing the problem. 33792 == 0x8400. Swapping that gives 0x84 == 132 > which would be a reasonable length. Are you using any firewall rules that > would rewrite packets? I wonder if you are having a packet rewritten and the > new IP header is written in network byte order, but we swap the IP header len > field to host byte order earlier in ip_input(). Luigi Rizzo may have some > insight into this. > Well, when looking at MH_databuf i see Jboss MQ traffic that would mean that this traffic was coming from or going to an IPsec tunnel, i could say for sure when i would have a clue how to get an IP address from something like ip_src = {s_addr = 355576000}. If it really is IPsec traffic then there are no rewrite rules only 10 pf pass rules on the enc0 interface and a "scrub in all" rule. Perhaps it matters that i have these set: net.enc.out.ipsec_bpf_mask=0x00000001 net.enc.out.ipsec_filter_mask=0x00000001 net.enc.in.ipsec_bpf_mask=0x00000002 net.enc.in.ipsec_filter_mask=0x00000002 so that i can filter the "encapsulated" traffic. Thanks, Florian From owner-freebsd-stable@FreeBSD.ORG Fri Jan 22 09:01: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 9F9A5106566B for ; Fri, 22 Jan 2010 09:01:26 +0000 (UTC) (envelope-from byshenknet@byshenk.net) Received: from core.byshenk.net (core.byshenk.net [62.58.73.230]) by mx1.freebsd.org (Postfix) with ESMTP id 1EBA78FC16 for ; Fri, 22 Jan 2010 09:01:25 +0000 (UTC) Received: from core.byshenk.net (localhost [127.0.0.1]) by core.byshenk.net (8.14.3/8.14.3) with ESMTP id o0M912G3025464; Fri, 22 Jan 2010 10:01:02 +0100 (CET) (envelope-from byshenknet@core.byshenk.net) Received: (from byshenknet@localhost) by core.byshenk.net (8.14.3/8.14.3/Submit) id o0M9122P025463; Fri, 22 Jan 2010 10:01:02 +0100 (CET) (envelope-from byshenknet) Date: Fri, 22 Jan 2010 10:01:02 +0100 From: Greg Byshenk To: Dan Langille Message-ID: <20100122090102.GF2910@core.byshenk.net> References: <4B58FE0B.3010001@langille.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4B58FE0B.3010001@langille.org> User-Agent: Mutt/1.4.2.3i X-Spam-Status: No, score=1.9 required=5.0 tests=ALL_TRUSTED, FH_DATE_PAST_20XX autolearn=no version=3.2.5 X-Spam-Level: * X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on core.byshenk.net Cc: FreeBSD Stable Subject: Re: device.hints isn't setting what I want X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 22 Jan 2010 09:01:26 -0000 On Thu, Jan 21, 2010 at 08:23:23PM -0500, Dan Langille wrote: > First, see also my post: do I want ch0 or pass1? > > I have an external tape library and an external tape drive. They are > not always powered up. My goal: always get the same devices regardless > of whether or not the tape library is powered on at boot. > > After booting, with the tape library powered on, I have these devices: > > # camcontrol devlist > at scbus0 target 5 lun 0 (sa0,pass0) > at scbus1 target 0 lun 0 (ch0,pass1) > at scbus1 target 5 lun 0 (sa1,pass2) > at scbus2 target 0 lun 0 (cd0,pass3) > at scbus5 target 0 lun 0 (da0,pass4) > > In /boot/devices, I have added these entries: > > hint.scbus.1.at="ahc0" > hint.scbus.0.at="ahc1" > hint.scbus.2.at="acd0" > hint.scbus.5.at="umass0" I think that this is wrong. I had a similar issue (multiple tape drives and changer devices that needed to stay at the same ids). Your device.hints entries should look something like this: hint.sa.0.at="scbus0" hint.sa.0.target="5" hint.sa.0.unit="0" hint.sa.1.at="scbus0" hint.sa.1.target="3" hint.sa.1.unit="0" hint.sa.2.at="scbus0" hint.sa.2.target="1" hint.sa.2.unit="0" hint.ch.0.at="scbus0" hint.ch.0.target="4" hint.ch.0.unit="0" hint.ch.1.at="scbus0" hint.ch.1.target="2" hint.ch.1.unit="0" hint.ch.2.at="scbus0" hint.ch.2.target="0" hint.ch.2.unit="0" Which I use to get this: # camcontrol devlist at scbus0 target 0 lun 0 (pass0,ch2) at scbus0 target 1 lun 0 (sa2,pass1) at scbus0 target 2 lun 0 (pass2,ch1) at scbus0 target 3 lun 0 (sa1,pass3) # (Currently the first changer is not powered up.) So I think that what you want is something like: hint.sa.0.at="scbus0" hint.sa.0.target="5" hint.sa.0.unit="0" hint.sa.1.at="scbus1" hint.sa.1.target="5" hint.sa.1.unit="0" hint.ch.0.at="scbus1" hint.ch.0.target="0" hint.ch.0.unit="0" [...] -- greg byshenk - gbyshenk@byshenk.net - Leiden, NL From owner-freebsd-stable@FreeBSD.ORG Fri Jan 22 09:09: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 D928B10656A4 for ; Fri, 22 Jan 2010 09:09:24 +0000 (UTC) (envelope-from byshenknet@byshenk.net) Received: from core.byshenk.net (core.byshenk.net [62.58.73.230]) by mx1.freebsd.org (Postfix) with ESMTP id 574A68FC13 for ; Fri, 22 Jan 2010 09:09:23 +0000 (UTC) Received: from core.byshenk.net (localhost [127.0.0.1]) by core.byshenk.net (8.14.3/8.14.3) with ESMTP id o0M990da025624; Fri, 22 Jan 2010 10:09:00 +0100 (CET) (envelope-from byshenknet@core.byshenk.net) Received: (from byshenknet@localhost) by core.byshenk.net (8.14.3/8.14.3/Submit) id o0M990Mp025623; Fri, 22 Jan 2010 10:09:00 +0100 (CET) (envelope-from byshenknet) Date: Fri, 22 Jan 2010 10:09:00 +0100 From: Greg Byshenk To: Dan Langille Message-ID: <20100122090900.GG2910@core.byshenk.net> References: <4B58FE0B.3010001@langille.org> <20100122090102.GF2910@core.byshenk.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100122090102.GF2910@core.byshenk.net> User-Agent: Mutt/1.4.2.3i X-Spam-Status: No, score=1.9 required=5.0 tests=ALL_TRUSTED, FH_DATE_PAST_20XX autolearn=no version=3.2.5 X-Spam-Level: * X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on core.byshenk.net Cc: FreeBSD Stable Subject: Re: device.hints isn't setting what I want X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 22 Jan 2010 09:09:25 -0000 On Fri, Jan 22, 2010 at 10:01:02AM +0100, Greg Byshenk wrote: > On Thu, Jan 21, 2010 at 08:23:23PM -0500, Dan Langille wrote: > > First, see also my post: do I want ch0 or pass1? > > > > I have an external tape library and an external tape drive. They are > > not always powered up. My goal: always get the same devices regardless > > of whether or not the tape library is powered on at boot. > > > > After booting, with the tape library powered on, I have these devices: > > > > # camcontrol devlist > > at scbus0 target 5 lun 0 (sa0,pass0) > > at scbus1 target 0 lun 0 (ch0,pass1) > > at scbus1 target 5 lun 0 (sa1,pass2) > > at scbus2 target 0 lun 0 (cd0,pass3) > > at scbus5 target 0 lun 0 (da0,pass4) > > > > In /boot/devices, I have added these entries: > > > > hint.scbus.1.at="ahc0" > > hint.scbus.0.at="ahc1" > > hint.scbus.2.at="acd0" > > hint.scbus.5.at="umass0" > > I think that this is wrong. > > I had a similar issue (multiple tape drives and changer devices that > needed to stay at the same ids). > > Your device.hints entries should look something like this: > > hint.sa.0.at="scbus0" > hint.sa.0.target="5" > hint.sa.0.unit="0" > hint.sa.1.at="scbus0" > hint.sa.1.target="3" > hint.sa.1.unit="0" > hint.sa.2.at="scbus0" > hint.sa.2.target="1" > hint.sa.2.unit="0" > hint.ch.0.at="scbus0" > hint.ch.0.target="4" > hint.ch.0.unit="0" > hint.ch.1.at="scbus0" > hint.ch.1.target="2" > hint.ch.1.unit="0" > hint.ch.2.at="scbus0" > hint.ch.2.target="0" > hint.ch.2.unit="0" > > Which I use to get this: > > # camcontrol devlist > at scbus0 target 0 lun 0 (pass0,ch2) > at scbus0 target 1 lun 0 (sa2,pass1) > at scbus0 target 2 lun 0 (pass2,ch1) > at scbus0 target 3 lun 0 (sa1,pass3) > # > > (Currently the first changer is not powered up.) > > > So I think that what you want is something like: > > hint.sa.0.at="scbus0" > hint.sa.0.target="5" > hint.sa.0.unit="0" > hint.sa.1.at="scbus1" > hint.sa.1.target="5" > hint.sa.1.unit="0" > hint.ch.0.at="scbus1" > hint.ch.0.target="0" > hint.ch.0.unit="0" > [...] Just saw your second message. I don't know if you can wire down 'pass?' the same way, but if you can, I would assume that you need to set it the same way as the 'sa?' and other devices. That is, if you want: > > at scbus0 target 5 lun 0 (sa0,pass0) Then the device.hints entry would look like: hint.pass.0.at="scbus0" hint.pass.0.target="5" hint.pass.0.unit="0" (If you can do that.) -greg -- greg byshenk - gbyshenk@byshenk.net - Leiden, NL From owner-freebsd-stable@FreeBSD.ORG Fri Jan 22 09:11:31 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 60B88106568F for ; Fri, 22 Jan 2010 09:11:31 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta14.westchester.pa.mail.comcast.net (qmta14.westchester.pa.mail.comcast.net [76.96.59.212]) by mx1.freebsd.org (Postfix) with ESMTP id E4EC18FC0C for ; Fri, 22 Jan 2010 09:11:29 +0000 (UTC) Received: from omta23.westchester.pa.mail.comcast.net ([76.96.62.74]) by qmta14.westchester.pa.mail.comcast.net with comcast id YZB91d0011c6gX85EZBWGS; Fri, 22 Jan 2010 09:11:30 +0000 Received: from koitsu.dyndns.org ([98.248.46.159]) by omta23.westchester.pa.mail.comcast.net with comcast id YZBt1d0013S48mS3jZBtfF; Fri, 22 Jan 2010 09:11:53 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id E23CA1E3033; Fri, 22 Jan 2010 01:11:27 -0800 (PST) Date: Fri, 22 Jan 2010 01:11:27 -0800 From: Jeremy Chadwick To: freebsd-stable@freebsd.org Message-ID: <20100122091127.GA64593@icarus.home.lan> References: <717f7a3e1001120714m37aada69gfaa35f0f9b17f435@mail.gmail.com> <44678539@bb.ipt.ru> <717f7a3e1001142234y1de7ae15x6853e3ddcab4add9@mail.gmail.com> <717f7a3e1001192246o4dce4a82q57c05ff3f41b5feb@mail.gmail.com> <20100120074611.GA405@icarus.home.lan> <717f7a3e1001210137p7884adcbxc66a4f7fff928821@mail.gmail.com> <20100121162649.GP96430@acme.spoerlein.net> <717f7a3e1001212236x78c12d1ue22283338e3e179c@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <717f7a3e1001212236x78c12d1ue22283338e3e179c@mail.gmail.com> User-Agent: Mutt/1.5.20 (2009-06-14) Subject: Re: Multiple serial consoles via null modem cable X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 22 Jan 2010 09:11:31 -0000 On Fri, Jan 22, 2010 at 08:36:51AM +0200, Marin Atanasov wrote: > On Thu, Jan 21, 2010 at 6:26 PM, Ulrich Sprlein wrote: > > > On Thu, 21.01.2010 at 11:37:06 +0200, Marin Atanasov wrote: > > > Here's what I did: > > > > > > box1 COM1/ttyd0 -> box2 COM1/ttyd0 -> using null modem cable > > > box1 COM2/ttyd1 -> box3 COM1/ttyd0 -> using null modem cable > > > > > > On box1 I have this in /etc/ttys: > > > > > > ttyd0 "/usr/libexec/getty std.9600" vt100 on secure > > > ttyd1 "/usr/libexec/getty std.9600" vt100 on secure > > > > > > Now if I want to connect to box1 from box2 or box3 through the serial > > > connection it should work, right? > > > But I only can connect to box1 from box2, because box2's COM port is > > > connected to box1's COM1 port. > > > > Are there actually two gettys running on the serial ports? Did you do > > kill -1 1 after the changes to /etc/ttys? > > > > On box1, what do the following commands produce > > > > egrep "uart|sio" /var/run/dmesg.boot > > pgrep -fl getty > > > > Regards, > > Uli > > > Hi, > > This is the output from the requested commands: > > box1# egrep 'uart|sio' /var/run/dmesg.boot > usb0: USB revision 1.0 > sio0: <16550A-compatible COM port> port 0x3f8-0x3ff irq 4 flags 0x10 on > acpi0 > sio0: type 16550A > sio1: <16550A-compatible COM port> port 0x2f8-0x2ff irq 3 on acpi0 > sio1: type 16550A > > box1# pgrep -fl getty > 3066 /usr/libexec/getty std.9600 ttyd1 > 3065 /usr/libexec/getty std.9600 ttyd0 > 534 /usr/libexec/getty Pc ttyv7 > 533 /usr/libexec/getty Pc ttyv6 > 532 /usr/libexec/getty Pc ttyv5 > 531 /usr/libexec/getty Pc ttyv4 > 530 /usr/libexec/getty Pc ttyv3 > 529 /usr/libexec/getty Pc ttyv2 > 528 /usr/libexec/getty Pc ttyv1 > 527 /usr/libexec/getty Pc ttyv0 Can you run the same commands on box2 please? -- | 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 Jan 22 09:31: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 9F04C1065672 for ; Fri, 22 Jan 2010 09:31:26 +0000 (UTC) (envelope-from freebsd@southportcomputers.co.uk) Received: from ted.southportcomputers.co.uk (ted.southportcomputers.co.uk [92.48.124.28]) by mx1.freebsd.org (Postfix) with ESMTP id 636028FC20 for ; Fri, 22 Jan 2010 09:31:26 +0000 (UTC) Received: from office.southportcomputers.co.uk ([78.105.116.12] helo=[192.168.1.68]) by ted.southportcomputers.co.uk with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NYFJb-000Iqe-Ni for freebsd-stable@freebsd.org; Fri, 22 Jan 2010 08:56:27 +0000 Message-ID: <4B596838.9020609@southportcomputers.co.uk> Date: Fri, 22 Jan 2010 08:56:24 +0000 From: Colin User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: freebsd-stable@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ted.southportcomputers.co.uk X-AntiAbuse: Original Domain - freebsd.org X-AntiAbuse: Originator/Caller UID/GID - [26 6] / [26 6] X-AntiAbuse: Sender Address Domain - southportcomputers.co.uk X-Source: X-Source-Args: X-Source-Dir: Subject: make buildkernel failing on zfs X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 22 Jan 2010 09:31:26 -0000 Hi Folks, I'm having a problem since I upgraded from 7.0 to the latest stable over Christmas with quotas and exim not rebuilding. I'm told that exim requires NIS and WITHOUT_NIS=yes was defined in /usr/src.conf My /usr/src.conf for that build is as follows though I've removed it for a test build: WITHOUT_ATM=yes WITHOUT_BLUETOOTH=yes WITHOUT_GAMES=yes WITHOUT_I4B=yes WITHOUT_IPX=yes WITHOUT_NCP=yes WITHOUT_NIS=yes WITHOUT_SENDMAIL=yes WITHOUT_INET6=yes WITHOUT_PROFILE=yes I've been building with the following command (this worked with the sources I used at Christmas, but I updated yesterday and now it won't): cd /usr/src && make buildworld | tee /root/build && make kernel-toolchain | tee /root/build2 && make -DALWAYS_CHECK_MAKE buildkernel KERNCONF=TED | tee /root/build3 It goes for a while and then the buildkernel fails with this: cc -O2 -fno-strict-aliasing -pipe -DFREEBSD_NAMECACHE -DBUILDING_ZFS -D_KERNEL -DKLD_MODULE -std=c99 -nostdinc -I/usr/src/sys/modules/zfs/../../cddl/compat/opensolaris -I/usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/commo n/fs/zfs -I/usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/zmod -I/usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common -I/usr/src/sys/modules/zfs/../.. -I/usr/src/sys/modules/zfs/../../cddl/contrib/openso laris/common/zfs -I/usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/common -I/usr/src/sys/modules/zfs/../../../include -DHAVE_KERNEL_OPTION_HEADERS -include /usr/obj/usr/src/sys/TED/opt_global.h -I. -I@ -I@/contrib/altq -finline-l imit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -g -I/usr/obj/usr/src/sys/TED -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding - Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wno-unknown-pragmas -Wno-missing-prototypes -Wno-undef -Wno-strict-pro totypes -Wno-cast-qual -Wno-parentheses -Wno-redundant-decls -Wno-missing-braces -Wno-uninitialized -Wno-unused -Wno-inline -Wno-switch -Wno-pointer-arith -c /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_z node.c *** Error code 1 Stop in /usr/src/sys/modules/zfs. *** Error code 1 Stop in /usr/src/sys/modules. *** Error code 1 Stop in /usr/obj/usr/src/sys/TED. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. It is a custom kernel and the conf file is here: http://www.pastebin.org/80156 First build I used the old conf file and that failed then I compared the generic and the custom before attempting this rebuild and copied in a couple of new lines (options P1003_1B_SEMAPHORES and device vlan) but they've nothing to do with it from what I can tell. I don't even need zfs seen as this is a ufs machine but I do need some of the other options in the kernel hence using custom. I am currently running another csup and will try building a generic kernel to see if that works but I can't really install a generic. Anyone got any pointers? Cheers, Colin. From owner-freebsd-stable@FreeBSD.ORG Fri Jan 22 09:40: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 E62AA1065670 for ; Fri, 22 Jan 2010 09:40:18 +0000 (UTC) (envelope-from christer.solskogen@gmail.com) Received: from mail-ew0-f211.google.com (mail-ew0-f211.google.com [209.85.219.211]) by mx1.freebsd.org (Postfix) with ESMTP id 7C9848FC08 for ; Fri, 22 Jan 2010 09:40:18 +0000 (UTC) Received: by ewy3 with SMTP id 3so1095074ewy.33 for ; Fri, 22 Jan 2010 01:40:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=mHgC/Ot0Mh37fwyWcq3RpFF+qj/CsSd8HW8lUiKcxEE=; b=XK6zFVEvRnipVigtUv1BPL9tFKKnc07mufcGY4+v71f984Unqf0y7xFEHvwe7JOR8l 1ehOdywZCuXOmid80KRwDfl+ws9H/KoLFrffxaJwjy8ZjitPsi4naxpY6pUDmk7AQeDq 9GYqWEHcs0fnD5wOJoBwotsDfq0BlFqyEFBcs= 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=BbS/vTsJZjfAda0kC5RKZ+ryLeoRMl64TFQIFYuUeSTUoFBAh0MzAQTP5MxEhYFoK4 ChWBkYhfwgN8qflNtPnFyKzJAsMC31UGWgqLYM/Bn3VUXc2mGX9bcZ63qLJrrVoQ2PCY 0mRNw/VGLJuLuLNk1vSjhXQroc++jYxO6o5ks= MIME-Version: 1.0 Received: by 10.213.1.18 with SMTP id 18mr2021915ebd.17.1264153217295; Fri, 22 Jan 2010 01:40:17 -0800 (PST) In-Reply-To: <4B596838.9020609@southportcomputers.co.uk> References: <4B596838.9020609@southportcomputers.co.uk> Date: Fri, 22 Jan 2010 10:40:17 +0100 Message-ID: From: Christer Solskogen To: Colin Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-stable@freebsd.org Subject: Re: make buildkernel failing on zfs X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 22 Jan 2010 09:40:19 -0000 On Fri, Jan 22, 2010 at 9:56 AM, Colin wrote: > Anyone got any pointers? Could you post your /etc/make.conf? That said, I recon you build your kernel in a rather wierd way. Delete /usr/obj/* and run "make cleandir && make cleandir" in /usr/src. Then build your world and kernel like this "make buildworld buildkernel KERNCONF=TED". If that goes as well, run "make installkernel KERNCONF=TED", reboot, "make installworld", run mergemaster and reboot again. -- chs From owner-freebsd-stable@FreeBSD.ORG Fri Jan 22 09:45: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 A733E106566B for ; Fri, 22 Jan 2010 09:45:48 +0000 (UTC) (envelope-from njm@njm.me.uk) Received: from smtp004.apm-internet.net (smtp004.apm-internet.net [85.119.248.54]) by mx1.freebsd.org (Postfix) with SMTP id 193BA8FC23 for ; Fri, 22 Jan 2010 09:45:47 +0000 (UTC) Received: (qmail 94989 invoked from network); 22 Jan 2010 09:45:47 -0000 Received: from unknown (HELO oberon.njm.me.uk) (86.129.211.242) by smtp004.apm-internet.net with SMTP; 22 Jan 2010 09:45:47 -0000 Received: from titania.njm.me.uk (titania.njm.me.uk [192.168.144.130]) by oberon.njm.me.uk (8.14.3/8.14.3) with ESMTP id o0M9jkkU005498; Fri, 22 Jan 2010 09:45:46 GMT (envelope-from njm@njm.me.uk) Received: from titania.njm.me.uk (localhost [127.0.0.1]) by titania.njm.me.uk (8.14.3/8.14.3) with ESMTP id o0M9jkEb019216; Fri, 22 Jan 2010 09:45:46 GMT (envelope-from njm@njm.me.uk) Received: (from njm@localhost) by titania.njm.me.uk (8.14.3/8.14.3/Submit) id o0M9jkoV019215; Fri, 22 Jan 2010 09:45:46 GMT (envelope-from njm@njm.me.uk) Date: Fri, 22 Jan 2010 09:45:46 +0000 From: "N.J. Mann" To: Colin Message-ID: <20100122094546.GB6681@titania.njm.me.uk> Mail-Followup-To: Colin , freebsd-stable@freebsd.org References: <4B596838.9020609@southportcomputers.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4B596838.9020609@southportcomputers.co.uk> X-Operating-System: FreeBSD 7.2-STABLE User-Agent: mutt-NJM (2009-12-30) Cc: freebsd-stable@freebsd.org Subject: Re: make buildkernel failing on zfs X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 22 Jan 2010 09:45:48 -0000 In message <4B596838.9020609@southportcomputers.co.uk>, Colin (freebsd@southportcomputers.co.uk) wrote: > [snip] > It goes for a while and then the buildkernel fails with this: > > cc -O2 -fno-strict-aliasing -pipe -DFREEBSD_NAMECACHE -DBUILDING_ZFS > -D_KERNEL -DKLD_MODULE -std=c99 -nostdinc > -I/usr/src/sys/modules/zfs/../../cddl/compat/opensolaris > -I/usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/commo > n/fs/zfs > -I/usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/zmod > -I/usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common > -I/usr/src/sys/modules/zfs/../.. > -I/usr/src/sys/modules/zfs/../../cddl/contrib/openso > laris/common/zfs > -I/usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/common > -I/usr/src/sys/modules/zfs/../../../include -DHAVE_KERNEL_OPTION_HEADERS > -include /usr/obj/usr/src/sys/TED/opt_global.h -I. -I@ -I@/contrib/altq > -finline-l > imit=8000 --param inline-unit-growth=100 --param > large-function-growth=1000 -fno-common -g -I/usr/obj/usr/src/sys/TED > -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx > -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding - > Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes > -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef > -Wno-pointer-sign -fformat-extensions -Wno-unknown-pragmas > -Wno-missing-prototypes -Wno-undef -Wno-strict-pro > totypes -Wno-cast-qual -Wno-parentheses -Wno-redundant-decls > -Wno-missing-braces -Wno-uninitialized -Wno-unused -Wno-inline > -Wno-switch -Wno-pointer-arith -c > /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_z > node.c > *** Error code 1 I think this was a temporary problem that has already been fixed. Try updating to the latest version and see if that builds okay. Cheers, Nick. -- From owner-freebsd-stable@FreeBSD.ORG Fri Jan 22 09:46: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 CB4B01065696 for ; Fri, 22 Jan 2010 09:46:10 +0000 (UTC) (envelope-from freebsd@southportcomputers.co.uk) Received: from ted.southportcomputers.co.uk (ted.southportcomputers.co.uk [92.48.124.28]) by mx1.freebsd.org (Postfix) with ESMTP id 8CF478FC28 for ; Fri, 22 Jan 2010 09:46:10 +0000 (UTC) Received: from 87-194-181-232.bethere.co.uk ([87.194.181.232] helo=[192.168.1.27]) by ted.southportcomputers.co.uk with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NYG5f-000E0v-Rv for freebsd-stable@freebsd.org; Fri, 22 Jan 2010 09:46:08 +0000 Message-ID: <4B5973DE.4050008@southportcomputers.co.uk> Date: Fri, 22 Jan 2010 09:46:06 +0000 From: Colin User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: freebsd-stable@freebsd.org References: <4B596838.9020609@southportcomputers.co.uk> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ted.southportcomputers.co.uk X-AntiAbuse: Original Domain - freebsd.org X-AntiAbuse: Originator/Caller UID/GID - [26 6] / [26 6] X-AntiAbuse: Sender Address Domain - southportcomputers.co.uk X-Source: X-Source-Args: X-Source-Dir: Subject: Re: make buildkernel failing on zfs X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 22 Jan 2010 09:46:10 -0000 Christer Solskogen wrote: > On Fri, Jan 22, 2010 at 9:56 AM, Colin wrote: > > >> Anyone got any pointers? >> > > Could you post your /etc/make.conf? > That said, I recon you build your kernel in a rather wierd way. Delete > /usr/obj/* and run "make cleandir && make cleandir" in /usr/src. Then > build your world and kernel like this "make buildworld buildkernel > KERNCONF=TED". If that goes as well, run "make installkernel > KERNCONF=TED", reboot, "make installworld", run mergemaster and reboot > again. > > > Thanks for the reply. I have deleted /usr/obj in between builds (forgot to mention that) but didn't do make cleandir. I think the first way that I did the build when I started was similar to what you suggested but I was having problems with installworld so after various reading and suggestions dropped back to that format which I read was a more paranoid way of doing it. make.conf as below: SUP= /usr/local/bin/cvsup SUPFLAGS= -g -L 2 SUPHOST= cvsup.FreeBSD.org SUPFILE= /root/standard-supfile PORTSSUPFILE= /root/ports-supfile #*REMOVE* OPENSSL_OVERWRITE_BASE=NO # added by use.perl 2009-06-14 11:10:18 #PERL_VERSION=5.8.9 #BATCH=YES #CRYPT_DES=0 #WITHOUT_ALT_CONFIG_PREFIX=YES #CFLAGS= -O -pipe NO_FORTRAN= true NO_OBJC= true NO_X= true NO_GAMES= true NO_PROFILE= true BATCH=YES WITHOUT_X11=YES SKIP_DNS_CHECK=YES CRYPT_DES=0 WITH_PORT_REPLACES_BASE_BIND8=YES WITH_PORT_REPLACES_BASE_BIND9=YES WITHOUT_ALT_CONFIG_PREFIX=YES WITH_OPENSSL_PORT=YES X11BASE=${LOCALBASE} From owner-freebsd-stable@FreeBSD.ORG Fri Jan 22 09:51: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 EE0C9106566C for ; Fri, 22 Jan 2010 09:51:14 +0000 (UTC) (envelope-from freebsd@southportcomputers.co.uk) Received: from ted.southportcomputers.co.uk (ted.southportcomputers.co.uk [92.48.124.28]) by mx1.freebsd.org (Postfix) with ESMTP id AFC3C8FC1A for ; Fri, 22 Jan 2010 09:51:14 +0000 (UTC) Received: from 87-194-181-232.bethere.co.uk ([87.194.181.232] helo=[192.168.1.27]) by ted.southportcomputers.co.uk with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NYGAa-000G29-3p; Fri, 22 Jan 2010 09:51:12 +0000 Message-ID: <4B59750E.6020506@southportcomputers.co.uk> Date: Fri, 22 Jan 2010 09:51:10 +0000 From: Colin User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Colin , freebsd-stable@freebsd.org References: <4B596838.9020609@southportcomputers.co.uk> <20100122094546.GB6681@titania.njm.me.uk> In-Reply-To: <20100122094546.GB6681@titania.njm.me.uk> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ted.southportcomputers.co.uk X-AntiAbuse: Original Domain - freebsd.org X-AntiAbuse: Originator/Caller UID/GID - [26 6] / [26 6] X-AntiAbuse: Sender Address Domain - southportcomputers.co.uk X-Source: X-Source-Args: X-Source-Dir: Cc: Subject: Re: make buildkernel failing on zfs X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 22 Jan 2010 09:51:15 -0000 N.J. Mann wrote: > In message <4B596838.9020609@southportcomputers.co.uk>, > Colin (freebsd@southportcomputers.co.uk) wrote: > > [snip] > >> It goes for a while and then the buildkernel fails with this: >> >> cc -O2 -fno-strict-aliasing -pipe -DFREEBSD_NAMECACHE -DBUILDING_ZFS >> -D_KERNEL -DKLD_MODULE -std=c99 -nostdinc >> -I/usr/src/sys/modules/zfs/../../cddl/compat/opensolaris >> -I/usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/commo >> n/fs/zfs >> -I/usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/zmod >> -I/usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common >> -I/usr/src/sys/modules/zfs/../.. >> -I/usr/src/sys/modules/zfs/../../cddl/contrib/openso >> laris/common/zfs >> -I/usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/common >> -I/usr/src/sys/modules/zfs/../../../include -DHAVE_KERNEL_OPTION_HEADERS >> -include /usr/obj/usr/src/sys/TED/opt_global.h -I. -I@ -I@/contrib/altq >> -finline-l >> imit=8000 --param inline-unit-growth=100 --param >> large-function-growth=1000 -fno-common -g -I/usr/obj/usr/src/sys/TED >> -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx >> -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding - >> Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes >> -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef >> -Wno-pointer-sign -fformat-extensions -Wno-unknown-pragmas >> -Wno-missing-prototypes -Wno-undef -Wno-strict-pro >> totypes -Wno-cast-qual -Wno-parentheses -Wno-redundant-decls >> -Wno-missing-braces -Wno-uninitialized -Wno-unused -Wno-inline >> -Wno-switch -Wno-pointer-arith -c >> /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_z >> node.c >> *** Error code 1 >> > > I think this was a temporary problem that has already been fixed. Try > updating to the latest version and see if that builds okay. > > > Cheers, > Nick. > Ahh if that is the case then the build I currently have running should work seen as I ran a csup less than an hour ago. Fingers crossed! Regards, Colin. From owner-freebsd-stable@FreeBSD.ORG Fri Jan 22 10:23: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 7DA7610656D0; Fri, 22 Jan 2010 10:23:57 +0000 (UTC) (envelope-from h.schmalzbauer@omnilan.de) Received: from host.omnilan.net (host.omnilan.net [62.245.232.135]) by mx1.freebsd.org (Postfix) with ESMTP id DD5AE8FC08; Fri, 22 Jan 2010 10:23:56 +0000 (UTC) Received: from titan.flintsbach.schmalzbauer.de (titan.flintsbach.schmalzbauer.de [172.21.1.150]) (authenticated bits=0) by host.omnilan.net (8.13.8/8.13.8) with ESMTP id o0MANtYW085682 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 22 Jan 2010 11:23:55 +0100 (CET) (envelope-from h.schmalzbauer@omnilan.de) Message-ID: <4B597CBB.5040900@omnilan.de> Date: Fri, 22 Jan 2010 11:23:55 +0100 From: Harald Schmalzbauer Organization: OmniLAN User-Agent: Thunderbird 2.0.0.23 (X11/20090906) MIME-Version: 1.0 To: Alexander Motin References: <4B55D9D4.1000008@FreeBSD.org> In-Reply-To: <4B55D9D4.1000008@FreeBSD.org> X-Enigmail-Version: 0.95.6 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig1C16E17E03DE133328835B8F" Cc: FreeBSD-Current , FreeBSD Stable Subject: Re: Pack of CAM improvements X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 22 Jan 2010 10:23:57 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig1C16E17E03DE133328835B8F Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable Alexander Motin schrieb am 19.01.2010 17:12 (localtime): =2E.. > Patch can be found here: > http://people.freebsd.org/~mav/cam-ata.20100119.patch >=20 > Feedback as always welcome. Again, thanks a lot for your ongoing great work! The patch doesn't cleanly apply with vpo, but I don't use vpo so I=20 didn't care. Otherwise I couldn't find any problems. The system detects reinserted SATA drives on ICH9 fine. This was tested on a zfs backup server which went to the backbone=20 yesterday, so I can't physically remove any devices any more for testing.= =2E. But I had some questions about zfs raidz states. I think that isn't a=20 matter of atacam but if I removed one disk, zpool status still showed me = the ada3 device "online". After reinserting (and proper detection/initialisazion with cam, ada3=20 was present again) and zpool clean, it set the devicea as UNAVAIL sinve=20 I/O errors. I coudn't get the device into the pool again, no matter what I tried. Only rebooting the machine helped. Then I could clean and scrub. What are the needed steps to provide a reinsterted hard disk to geom?=20 With the latest patches I don't need to issue any reset/rescan comman,=20 right? So it's a zfs problem, right? My mistake in understanding? Thanks, -Harry --------------enig1C16E17E03DE133328835B8F 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.13 (FreeBSD) iEYEARECAAYFAktZfLsACgkQLDqVQ9VXb8h6ywCgleNs3+7wtinOt4D+b+XKJtQs I5EAoJ2VkP8NmHzUxEl4AOHN4Q+TcoTq =82Q7 -----END PGP SIGNATURE----- --------------enig1C16E17E03DE133328835B8F-- From owner-freebsd-stable@FreeBSD.ORG Fri Jan 22 10: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 EE119106566C for ; Fri, 22 Jan 2010 10:50:55 +0000 (UTC) (envelope-from mail25@bzerk.org) Received: from ei.bzerk.org (tunnel490.ipv6.xs4all.nl [IPv6:2001:888:10:1ea::2]) by mx1.freebsd.org (Postfix) with ESMTP id 7CF2C8FC17 for ; Fri, 22 Jan 2010 10:50:55 +0000 (UTC) Received: from ei.bzerk.org (BOFH@localhost [127.0.0.1]) by ei.bzerk.org (8.14.2/8.14.2) with ESMTP id o0MAnpMp046818; Fri, 22 Jan 2010 11:49:51 +0100 (CET) (envelope-from mail25@bzerk.org) Received: (from bulk@localhost) by ei.bzerk.org (8.14.3/8.14.2/Submit) id o0MAnot7046817; Fri, 22 Jan 2010 11:49:50 +0100 (CET) (envelope-from mail25@bzerk.org) Date: Fri, 22 Jan 2010 11:49:50 +0100 From: Ruben de Groot To: Christer Solskogen Message-ID: <20100122104950.GA46742@ei.bzerk.org> Mail-Followup-To: Ruben de Groot , Christer Solskogen , Colin , freebsd-stable@freebsd.org References: <4B596838.9020609@southportcomputers.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i X-Spam-Status: No, score=-4.3 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on ei.bzerk.org X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.0.1 (ei.bzerk.org [127.0.0.1]); Fri, 22 Jan 2010 11:50:53 +0100 (CET) Cc: freebsd-stable@freebsd.org, Colin Subject: Re: make buildkernel failing on zfs X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 22 Jan 2010 10:50:56 -0000 On Fri, Jan 22, 2010 at 10:40:17AM +0100, Christer Solskogen typed: > On Fri, Jan 22, 2010 at 9:56 AM, Colin wrote: > > > Anyone got any pointers? > > Could you post your /etc/make.conf? > That said, I recon you build your kernel in a rather wierd way. Delete > /usr/obj/* and run "make cleandir && make cleandir" in /usr/src. Then Bit redundant ;) cleandir only effects /usr/obj, which you just blew away. Ruben From owner-freebsd-stable@FreeBSD.ORG Fri Jan 22 11:17: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 B3C421065670 for ; Fri, 22 Jan 2010 11:17:10 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta14.westchester.pa.mail.comcast.net (qmta14.westchester.pa.mail.comcast.net [76.96.59.212]) by mx1.freebsd.org (Postfix) with ESMTP id 5D1EC8FC08 for ; Fri, 22 Jan 2010 11:17:09 +0000 (UTC) Received: from omta05.westchester.pa.mail.comcast.net ([76.96.62.43]) by qmta14.westchester.pa.mail.comcast.net with comcast id YasH1d0080vyq2s5EbHAoG; Fri, 22 Jan 2010 11:17:10 +0000 Received: from koitsu.dyndns.org ([98.248.46.159]) by omta05.westchester.pa.mail.comcast.net with comcast id YbH91d0023S48mS3RbH9eW; Fri, 22 Jan 2010 11:17:10 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 1DB711E3033; Fri, 22 Jan 2010 03:17:08 -0800 (PST) Date: Fri, 22 Jan 2010 03:17:08 -0800 From: Jeremy Chadwick To: freebsd-stable@freebsd.org Message-ID: <20100122111708.GA67643@icarus.home.lan> References: <4B596838.9020609@southportcomputers.co.uk> <20100122094546.GB6681@titania.njm.me.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100122094546.GB6681@titania.njm.me.uk> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: Colin Subject: Re: make buildkernel failing on zfs X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 22 Jan 2010 11:17:10 -0000 On Fri, Jan 22, 2010 at 09:45:46AM +0000, N.J. Mann wrote: > In message <4B596838.9020609@southportcomputers.co.uk>, > Colin (freebsd@southportcomputers.co.uk) wrote: > > > [snip] > > It goes for a while and then the buildkernel fails with this: > > > > cc -O2 -fno-strict-aliasing -pipe -DFREEBSD_NAMECACHE -DBUILDING_ZFS > > -D_KERNEL -DKLD_MODULE -std=c99 -nostdinc > > -I/usr/src/sys/modules/zfs/../../cddl/compat/opensolaris > > -I/usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/commo > > n/fs/zfs > > -I/usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/zmod > > -I/usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common > > -I/usr/src/sys/modules/zfs/../.. > > -I/usr/src/sys/modules/zfs/../../cddl/contrib/openso > > laris/common/zfs > > -I/usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/common > > -I/usr/src/sys/modules/zfs/../../../include -DHAVE_KERNEL_OPTION_HEADERS > > -include /usr/obj/usr/src/sys/TED/opt_global.h -I. -I@ -I@/contrib/altq > > -finline-l > > imit=8000 --param inline-unit-growth=100 --param > > large-function-growth=1000 -fno-common -g -I/usr/obj/usr/src/sys/TED > > -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx > > -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding - > > Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes > > -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef > > -Wno-pointer-sign -fformat-extensions -Wno-unknown-pragmas > > -Wno-missing-prototypes -Wno-undef -Wno-strict-pro > > totypes -Wno-cast-qual -Wno-parentheses -Wno-redundant-decls > > -Wno-missing-braces -Wno-uninitialized -Wno-unused -Wno-inline > > -Wno-switch -Wno-pointer-arith -c > > /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_z > > node.c > > *** Error code 1 > > I think this was a temporary problem that has already been fixed. Try > updating to the latest version and see if that builds okay. The FreeBSD tinderbox build system noticed this problem as well, dying in the same piece of code. It's not you. 738 01/21 17:04 FreeBSD Tinderbox (9.0K) [releng_7 tinderbox] failure on amd64/amd64 739 01/21 17:44 FreeBSD Tinderbox (8.7K) [releng_7 tinderbox] failure on i386/i386 Normally I'd shake my finger at the committer for committing code to stable branches without testing, but I hold the committer (jhb) in very high regards and he has a very established history of not breaking things + doing excellent work. Mistakes happen, we're all human. :-) -- | 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 Jan 22 11:43: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 5FCBA1065676 for ; Fri, 22 Jan 2010 11:43:55 +0000 (UTC) (envelope-from marck@rinet.ru) Received: from woozle.rinet.ru (woozle.rinet.ru [195.54.192.68]) by mx1.freebsd.org (Postfix) with ESMTP id D7C858FC17 for ; Fri, 22 Jan 2010 11:43:54 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by woozle.rinet.ru (8.14.3/8.14.3) with ESMTP id o0MBhogC033315; Fri, 22 Jan 2010 14:43:50 +0300 (MSK) (envelope-from marck@rinet.ru) Date: Fri, 22 Jan 2010 14:43:50 +0300 (MSK) From: Dmitry Morozovsky To: Ruben de Groot In-Reply-To: <20100122104950.GA46742@ei.bzerk.org> Message-ID: References: <4B596838.9020609@southportcomputers.co.uk> <20100122104950.GA46742@ei.bzerk.org> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) X-NCC-RegID: ru.rinet X-OpenPGP-Key-ID: 6B691B03 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.3 (woozle.rinet.ru [0.0.0.0]); Fri, 22 Jan 2010 14:43:50 +0300 (MSK) Cc: Christer Solskogen , freebsd-stable@freebsd.org, Colin Subject: Re: make buildkernel failing on zfs X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 22 Jan 2010 11:43:55 -0000 On Fri, 22 Jan 2010, Ruben de Groot wrote: RdG> > Could you post your /etc/make.conf? RdG> > That said, I recon you build your kernel in a rather wierd way. Delete RdG> > /usr/obj/* and run "make cleandir && make cleandir" in /usr/src. Then RdG> RdG> Bit redundant ;) RdG> cleandir only effects /usr/obj, which you just blew away. Not exactly: without objdir, cleandir removes built objects from source directory (where they may accidentally reside if one type 'make all' without 'make obj' previously) -- Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] [ FreeBSD committer: marck@FreeBSD.org ] ------------------------------------------------------------------------ *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- marck@rinet.ru *** ------------------------------------------------------------------------ From owner-freebsd-stable@FreeBSD.ORG Fri Jan 22 11:44: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 ACF2910656A6 for ; Fri, 22 Jan 2010 11:44:56 +0000 (UTC) (envelope-from alexander@leidinger.net) Received: from mail.ebusiness-leidinger.de (mail.ebusiness-leidinger.de [217.11.53.44]) by mx1.freebsd.org (Postfix) with ESMTP id 36CBD8FC20 for ; Fri, 22 Jan 2010 11:44:56 +0000 (UTC) Received: from outgoing.leidinger.net (pD954F1B8.dip.t-dialin.net [217.84.241.184]) by mail.ebusiness-leidinger.de (Postfix) with ESMTPSA id B2A8884425B; Fri, 22 Jan 2010 12:44:39 +0100 (CET) Received: from webmail.leidinger.net (webmail.leidinger.net [192.168.1.102]) by outgoing.leidinger.net (Postfix) with ESMTP id 2D2467EE75; Thu, 21 Jan 2010 03:32:22 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=Leidinger.net; s=outgoing-alex; t=1264041142; bh=xJTljPu0kpgaGROK69sGr2HU5gvbQ6ZxriQntnG0V0A=; h=Message-ID:Date:From:To:Cc:Subject:References:In-Reply-To: MIME-Version:Content-Type:Content-Transfer-Encoding; b=z9lqYUATaGwm6gYMVK4ry7zo/GGK6xhfhkaqAMuGd4jsflRFcce77KfFbSSkPj3Kz Sj8o98QafHZvRecXUX8tygs6882nV7A/PladxrYE068+zsvsZsVENIrysnZpua3hQy dJeQ8hTIJN6pOCNDnsNwIgyzy3tjLGugGJN8fZfT6dH8kDcIRExRqwgXIUBHRP7Gmf KWxFjTTLGWSfBMM0AggXPqWR8pfdLVVCk2jJcf5n7HV9jfpP9YTX1CB9DGNByYkfpF Z+ZL4a55sf0jDp34xNqatGL4GBp9jsZidO5JvIvHbAfJvASOGhYi4SYI2a3y8s1Etp Q8PVviDMhwPEQ== Received: (from www@localhost) by webmail.leidinger.net (8.14.3/8.13.8/Submit) id o0KAlUGw061051; Wed, 20 Jan 2010 11:47:30 +0100 (CET) (envelope-from Alexander@Leidinger.net) Received: from pslux.cec.eu.int (pslux.cec.eu.int [158.169.9.14]) by webmail.leidinger.net (Horde Framework) with HTTP; Wed, 20 Jan 2010 11:47:30 +0100 Message-ID: <20100120114730.916917ef0eu668n4@webmail.leidinger.net> Date: Wed, 20 Jan 2010 11:47:30 +0100 From: Alexander Leidinger To: Jeremy Chadwick References: <7346c5c61001030842r7dc76199y51e4c1c90a3eea6e@mail.gmail.com> <7346c5c61001091706m45a3a2a5k3ca8bb0c4bec5ea8@mail.gmail.com> <7346c5c61001171521w1ca4738w98e8fcca24643cda@mail.gmail.com> <201001180829.48126.npapke@acm.org> <7346c5c61001190840k31466754i32b2ae833390b79b@mail.gmail.com> <20100119170101.GA80917@icarus.home.lan> In-Reply-To: <20100119170101.GA80917@icarus.home.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: Dynamic Internet Messaging Program (DIMP) H3 (1.1.4) X-EBL-MailScanner-Information: Please contact the ISP for more information X-EBL-MailScanner-ID: B2A8884425B.65725 X-EBL-MailScanner: Found to be clean X-EBL-MailScanner-SpamCheck: not spam, spamhaus-ZEN, SpamAssassin (not cached, score=-1.44, required 6, autolearn=disabled, ALL_TRUSTED -1.44, DKIM_SIGNED 0.00, DKIM_VERIFIED -0.00) X-EBL-MailScanner-From: alexander@leidinger.net X-EBL-MailScanner-Watermark: 1264765483.82864@0Ktajn9IaGqLN1pEkwB5Ww X-EBL-Spam-Status: No Cc: freebsd-stable@FreeBSD.org Subject: Re: ZFS performance degradation over time X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 22 Jan 2010 11:44:56 -0000 Quoting Jeremy Chadwick (from Tue, 19 Jan 2010 09:01:01 -0800): > On Tue, Jan 19, 2010 at 11:40:50AM -0500, Garrett Moore wrote: >> I've been watching my memory usage and I have no idea what is consuming >> memory as 'Active'. >> >> Last night I had around 6500MB 'Active' again, 1500MB Wired, no inact, ~30MB >> buf, no free, and ~100MB swap used. My performance copying ZFS->ZFS was >> again slow (<1MB/s). I tried killing rTorrent and no significant amount of >> memory was reclaimed - maybe 100MB. `ps aux` showed no processes using any >> significant amount of memory, and I was definitely nowhere near 6500MB >> usage. >> >> I tried running the perl oneliner again to hog a bunch of memory, and almost >> all of the Active memory was IMMEDIATELY marked as Free, and my performance >> was excellent again. >> >> I'm not sure what in userland could be causing the issue. The only things >> I've installed are rTorrent, lighttpd, samba, smartmontools, vim, bash, >> Python, Perl, and SABNZBd. There is nothing that *should* be consuming any >> serious amount of memory. > > I've two recommendations: > > 1) Have you considered "upgrading" to RELENG_8 (e.g. 8.0-STABLE) instead > of sticking with 8.0-RELEASE? There's been a recent MFC to RELENG_8 > which pertain to ARC drainage. I'm referring to the commit labelled > revision 1.22.2.2 (RELENG_8): > > http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/arc.c This patch can be merged stand-alone if necessary, no need to go to RELENG_8 if there are reservations. > 2) Have you tried using vfs.zfs.arc_max in loader.conf to limit the ARC > size? I'd recommend picking something like 1GB as a cap (your machine Or even less... to be determined by experimenting. > has 8GB total at present, if I remember right). I believe long ago > someone said this isn't an explicit hard limit on the maximum size of > the ARC, but I believe this was during the RELENG_7 days and the ARC > "stuff" on FreeBSD has changed since then. I wish the tunables were > better documented, or at least explained in detail (hello Wiki!). The commit you refer to above is just doing this: limiting the arc more to the arc_max than it was the case before. This patch is in 7-stable too (in case someone is interested). Bye, Alexander. -- Johnson's First Law: When any mechanical contrivance fails, it will do so at the most inconvenient possible time. http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 From owner-freebsd-stable@FreeBSD.ORG Fri Jan 22 13:19:39 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 DD29D1065670 for ; Fri, 22 Jan 2010 13:19:39 +0000 (UTC) (envelope-from vanhu@zeninc.net) Received: from smtp.zeninc.net (smtp.zeninc.net [80.67.176.25]) by mx1.freebsd.org (Postfix) with ESMTP id 96C648FC22 for ; Fri, 22 Jan 2010 13:19:39 +0000 (UTC) Received: from astro.zen.inc (astro.zen.inc [192.168.1.239]) by smtp.zeninc.net (smtpd) with ESMTP id 7D7432798BC; Fri, 22 Jan 2010 14:19:37 +0100 (CET) Received: by astro.zen.inc (Postfix, from userid 1000) id 7E0ED17047; Fri, 22 Jan 2010 14:19:37 +0100 (CET) Date: Fri, 22 Jan 2010 14:19:37 +0100 From: VANHULLEBUS Yvan To: David Murray Message-ID: <20100122131937.GA50007@zeninc.net> References: <659350866.20100120151602@mail.ru> <4B5703A3.6010507@cyb0rg.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: All mail clients suck. This one just sucks less. Cc: freebsd-stable@freebsd.org Subject: Re: IPSec NAT-T in transport 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, 22 Jan 2010 13:19:39 -0000 Hi. On Thu, Jan 21, 2010 at 04:36:12PM +0000, David Murray wrote: [...] > On 2010-01-20 Wed 1:22 pm, Crest wrote: > > >Yes the NAT-T Patch has been integrated into FreeBSD 8.0. > > > >Just rebuild your kernel with this options: > >device crypto # IPsec depends on this > >options IPSEC > >options IPSEC_DEBUG > >options IPSEC_NAT_T > > I'm trying to do the same thing as the OP, so thanks for these replies. > > However, they seem to be at odds. Are we saying that the NAT-T patch is > there, but is missing checksum re-calculation, so MPD's packets are > going to be discarded? Yes, see my other mail in this thread. > (FWIW, this seems to be what happens. All the negotiation to set up > IPSEC SAs happens, but MPD's log never shows a single entry. I hadn't > got as far as packet dumps when this thread popped up.) And if you have a look at system stats, you'll see lots of UDP packets dropped because of invalid checksums.... Yvan. From owner-freebsd-stable@FreeBSD.ORG Fri Jan 22 14:32: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 2A59F1065670; Fri, 22 Jan 2010 14:32:06 +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 DF6178FC12; Fri, 22 Jan 2010 14:32:05 +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 8FBF846B53; Fri, 22 Jan 2010 09:32:05 -0500 (EST) Received: from jhbbsd.localnet (smtp.hudson-trading.com [209.249.190.9]) by bigwig.baldwin.cx (Postfix) with ESMTPA id A558C8A026; Fri, 22 Jan 2010 09:32:04 -0500 (EST) From: John Baldwin To: Florian Smeets Date: Fri, 22 Jan 2010 09:20:13 -0500 User-Agent: KMail/1.12.1 (FreeBSD/7.2-CBSD-20091231; KDE/4.3.1; amd64; ; ) References: <4B58280C.50602@smeets.im> <201001211515.32562.jhb@freebsd.org> <4B595D0D.3060904@smeets.im> In-Reply-To: <4B595D0D.3060904@smeets.im> MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Message-Id: <201001220920.13458.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (bigwig.baldwin.cx); Fri, 22 Jan 2010 09:32:04 -0500 (EST) X-Virus-Scanned: clamav-milter 0.95.1 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.6 required=4.2 tests=AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on bigwig.baldwin.cx Cc: Luigi Rizzo , Bjoern Zeeb , freebsd-stable@freebsd.org, mlaier@freebsd.org Subject: Re: 7.2-STABLE page fault with kernel from 12.01.2010 / crashinfo available X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 22 Jan 2010 14:32:06 -0000 On Friday 22 January 2010 3:08:45 am Florian Smeets wrote: > On 1/21/10 9:15 PM, John Baldwin wrote: > > On Thursday 21 January 2010 2:09:34 pm Florian Smeets wrote: > >> On 1/21/10 8:05 PM, John Baldwin wrote: > >>> On Thursday 21 January 2010 1:33:35 pm Florian Smeets wrote: > >>>> On 1/21/10 6:58 PM, John Baldwin wrote: > >>>>> On Thursday 21 January 2010 8:25:22 am Florian Smeets wrote: > >>>>>> (kgdb) frame 8 > >>>>>> #8 0xc05f8b28 in ip_forward (m=3D0xc23dc900, srcrt=3D0) at > >>>>>> /usr/src/sys/netinet/ip_input.c:1307 > >>>>>> 1307 m_copydata(m, 0, mcopy->m_len, mtod(mcopy, caddr_t)); > >>>>>> (kgdb) l > >>>>>> 1302 mcopy =3D NULL; > >>>>>> 1303 } > >>>>>> 1304 if (mcopy !=3D NULL) { > >>>>>> 1305 mcopy->m_len =3D min(ip->ip_len, M_TRAILINGSPACE(mcopy)); > >>>>>> 1306 mcopy->m_pkthdr.len =3D mcopy->m_len; > >>>>>> 1307 m_copydata(m, 0, mcopy->m_len, mtod(mcopy, caddr_t)); > >>>>>> 1308 } > >>>>>> 1309=09 > >>>>>> 1310 #ifdef IPSTEALTH > >>>>>> 1311 if (!ipstealth) { > >>>>>> (kgdb) p *m > >>>>>> $1 =3D {m_hdr =3D {mh_next =3D 0x0, mh_nextpkt =3D 0x0, mh_data = =3D 0xc271e80e > >>>>>> "E\020", mh_len =3D 164, mh_flags =3D 3, mh_type =3D 1, pad =3D "\= 000"}, M_dat > > =3D > >>>>>> {MH =3D {MH_pkthdr =3D {rcvif =3D 0xc20a4800, header =3D 0x0, len = =3D 164, > >>>>>> csum_flags =3D 3072, > >>>>>> csum_data =3D 65535, tso_segsz =3D 0, ether_vtag =3D 0= , tags =3D > >>>>>> {slh_first =3D 0xc35bc380}}, MH_dat =3D {MH_ext =3D {ext_buf =3D 0= xc271e800 "", > >>>>>> ext_free =3D 0, ext_args =3D 0x0, ext_size =3D 2048, ref_cnt =3D 0= xc2703ab4, > >>>>>> ext_type =3D 6}, > >>>>>> MH_databuf =3D > >>>>>> "\000?q?\000\000\000\000\000\000\000\000\000\b\000\000?:p? > >>>>> \006\000\000\000dL?\t<+?\202\200\020 > >>>>>> O/\207\000\000\001\001\b\n-?b\230qms?\000\000\004\001?l? > > \000\000\001%r??? > >>>>> \200\000????\034?Ot?\b?{sr\000\034org.jboss.mq.ConnectionToken?\b= =DF=BC&? > >>>>> > >>> > > \237N\002\000\005I\000\004hashZ\000\asameJVML\000\bclientIDt\000\022Lja= va/l\000\220\032Ae\207\000\002? > >>>>> 36@\210d\021\000\001? > >>> \001B\000!E\000\001@bV\000\000@2\032$W\213\n\034"...}}, > >>>>>> > >>>>>> M_databuf =3D > >>>>>> "\000H\n?\000\000\000\000?\000\000\000\000\f\000\000?? > >>>>> \000\000\000\000\000\000\200?[?\000?q? > >>>>> \000\000\000\000\000\000\000\000\000\b\000\000?:p?\006\000\000\000d= L? > > \t<+? > >>>>> \202\200\020 > >>>>>> O/\207\000\000\001\001\b\n-?b\230qms?\000\000\004\001?l? > > \000\000\001%r??? > >>>>> \200\000????\034?Ot?\b?{sr\000\034org.jboss.mq.ConnectionToken?\b= =DF=BC&? > >>>>> > >>> > > \237N\002\000\005I\000\004hashZ\000\asameJVML\000\bclientIDt\000\022Lja= va/l\000\220\032Ae\207\000\002? > >>>>> 3"...}} > >>>>> > >>>>> Ok, can you do 'p *m_copy'? > >>>>> > >>>> > >>>> What ever you want :-) > >>>> > >>>> (kgdb) p *m_copy > >>>> No symbol "m_copy" in current context. > >>>> (kgdb) p *m_copydata > >>>> $2 =3D {void (const struct mbuf *, int, int, caddr_t)} > > 0xc0572e10 > >>>> (kgdb) p *mcopy > >>>> $1 =3D {m_hdr =3D {mh_next =3D 0x0, mh_nextpkt =3D 0x0, mh_data =3D = 0xc23cce34 > >>>> "E\020", mh_len =3D 204, mh_flags =3D 2, mh_type =3D 1, pad =3D "\00= 0"}, M_dat =3D > >>>> {MH =3D {MH_pkthdr =3D {rcvif =3D 0xc20a4800, header =3D 0x0, > >>>> len =3D 204, csum_flags =3D 3072, csum_data =3D 65535, ts= o_segsz =3D 0, > >>>> ether_vtag =3D 0, tags =3D {slh_first =3D 0xc23c3e00}}, MH_dat =3D {= MH_ext =3D > >>>> {ext_buf =3D 0x84001045
, > >>> > >>> Hmm, ok. Can you do 'p *ip'? mcopy->m_len (204) is larger than m->m= _len > >>> (164). That shouldn't be the case unless ip->ip_len is somehow larger > > than m- > >>>> m_len. > >>> > >> > >> (kgdb) p *ip > >> $3 =3D {ip_hl =3D 5, ip_v =3D 4, ip_tos =3D 16 '\020', ip_len =3D 3379= 2, ip_id =3D > >> 61492, ip_off =3D 64, ip_ttl =3D 64 '@', ip_p =3D 6 '\006', ip_sum =3D= 34849, > >> ip_src =3D {s_addr =3D 355576000}, ip_dst =3D { > >> s_addr =3D 2251401408}} > > > > Looks like ip_len is in network byte order instead of host byte order a= nd that > > is causing the problem. 33792 =3D=3D 0x8400. Swapping that gives 0x84= =3D=3D 132 > > which would be a reasonable length. Are you using any firewall rules t= hat > > would rewrite packets? I wonder if you are having a packet rewritten a= nd the > > new IP header is written in network byte order, but we swap the IP head= er len > > field to host byte order earlier in ip_input(). Luigi Rizzo may have s= ome > > insight into this. > > >=20 > Well, when looking at MH_databuf i see Jboss MQ traffic that would mean=20 > that this traffic was coming from or going to an IPsec tunnel, i could=20 > say for sure when i would have a clue how to get an IP address from=20 > something like ip_src =3D {s_addr =3D 355576000}. Something like this should show you the IP: (gdb) set $i =3D 355576000 (gdb) printf "%d.%d.%d.%d\n", $i >> 24, $i >> 16 & 0xff, $i >> 8 & 0xff, $i= & 0xff 21.49.168.192 In this case I probably printed it backwards, so it is probably 192.168.49.21. > If it really is IPsec traffic then there are no rewrite rules only 10 pf= =20 > pass rules on the enc0 interface and a "scrub in all" rule. >=20 > Perhaps it matters that i have these set: >=20 > net.enc.out.ipsec_bpf_mask=3D0x00000001 > net.enc.out.ipsec_filter_mask=3D0x00000001 > net.enc.in.ipsec_bpf_mask=3D0x00000002 > net.enc.in.ipsec_filter_mask=3D0x00000002 >=20 > so that i can filter the "encapsulated" traffic. I have no idea, I've cc'd mlaier@ (pf) and bz@ (ipsec) to see if they have any ideas. =2D-=20 John Baldwin From owner-freebsd-stable@FreeBSD.ORG Fri Jan 22 15:29: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 965D81065672 for ; Fri, 22 Jan 2010 15:29:50 +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 52F428FC0C for ; Fri, 22 Jan 2010 15:29:50 +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 D855A46B3B; Fri, 22 Jan 2010 10:29:49 -0500 (EST) Received: from jhbbsd.localnet (smtp.hudson-trading.com [209.249.190.9]) by bigwig.baldwin.cx (Postfix) with ESMTPA id 1A2938A025; Fri, 22 Jan 2010 10:29:49 -0500 (EST) From: John Baldwin To: freebsd-stable@freebsd.org Date: Fri, 22 Jan 2010 10:29:43 -0500 User-Agent: KMail/1.12.1 (FreeBSD/7.2-CBSD-20091231; KDE/4.3.1; amd64; ; ) References: <4B596838.9020609@southportcomputers.co.uk> <20100122094546.GB6681@titania.njm.me.uk> <20100122111708.GA67643@icarus.home.lan> In-Reply-To: <20100122111708.GA67643@icarus.home.lan> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201001221029.43926.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (bigwig.baldwin.cx); Fri, 22 Jan 2010 10:29:49 -0500 (EST) X-Virus-Scanned: clamav-milter 0.95.1 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.6 required=4.2 tests=AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on bigwig.baldwin.cx Cc: Colin , Jeremy Chadwick Subject: Re: make buildkernel failing on zfs X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 22 Jan 2010 15:29:50 -0000 On Friday 22 January 2010 6:17:08 am Jeremy Chadwick wrote: > On Fri, Jan 22, 2010 at 09:45:46AM +0000, N.J. Mann wrote: > > In message <4B596838.9020609@southportcomputers.co.uk>, > > Colin (freebsd@southportcomputers.co.uk) wrote: > > > > > [snip] > > > It goes for a while and then the buildkernel fails with this: > > > > > > cc -O2 -fno-strict-aliasing -pipe -DFREEBSD_NAMECACHE -DBUILDING_ZFS > > > -D_KERNEL -DKLD_MODULE -std=c99 -nostdinc > > > -I/usr/src/sys/modules/zfs/../../cddl/compat/opensolaris > > > -I/usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/commo > > > n/fs/zfs > > > -I/usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/zmod > > > -I/usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common > > > -I/usr/src/sys/modules/zfs/../.. > > > -I/usr/src/sys/modules/zfs/../../cddl/contrib/openso > > > laris/common/zfs > > > -I/usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/common > > > -I/usr/src/sys/modules/zfs/../../../include -DHAVE_KERNEL_OPTION_HEADERS > > > -include /usr/obj/usr/src/sys/TED/opt_global.h -I. -I@ -I@/contrib/altq > > > -finline-l > > > imit=8000 --param inline-unit-growth=100 --param > > > large-function-growth=1000 -fno-common -g -I/usr/obj/usr/src/sys/TED > > > -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx > > > -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding - > > > Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes > > > -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef > > > -Wno-pointer-sign -fformat-extensions -Wno-unknown-pragmas > > > -Wno-missing-prototypes -Wno-undef -Wno-strict-pro > > > totypes -Wno-cast-qual -Wno-parentheses -Wno-redundant-decls > > > -Wno-missing-braces -Wno-uninitialized -Wno-unused -Wno-inline > > > -Wno-switch -Wno-pointer-arith -c > > > /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_z > > > node.c > > > *** Error code 1 > > > > I think this was a temporary problem that has already been fixed. Try > > updating to the latest version and see if that builds okay. > > The FreeBSD tinderbox build system noticed this problem as well, dying > in the same piece of code. It's not you. > > 738 01/21 17:04 FreeBSD Tinderbox (9.0K) [releng_7 tinderbox] failure on amd64/amd64 > 739 01/21 17:44 FreeBSD Tinderbox (8.7K) [releng_7 tinderbox] failure on i386/i386 > > Normally I'd shake my finger at the committer for committing code to > stable branches without testing, but I hold the committer (jhb) in very > high regards and he has a very established history of not breaking > things + doing excellent work. Mistakes happen, we're all human. :-) Kind words aside, in this case the testing wasn't quite adequate. While I did run-test it under UFS, I only built a GENERIC kernel w/o modules which is how I missed ZFS. Given that the patch touched ZFS I really should have built the module. -- John Baldwin From owner-freebsd-stable@FreeBSD.ORG Fri Jan 22 16:00: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 81C1910656F4; Fri, 22 Jan 2010 16:00:27 +0000 (UTC) (envelope-from to.my.trociny@gmail.com) Received: from mail-bw0-f213.google.com (mail-bw0-f213.google.com [209.85.218.213]) by mx1.freebsd.org (Postfix) with ESMTP id AD9BF8FC0C; Fri, 22 Jan 2010 16:00:26 +0000 (UTC) Received: by bwz5 with SMTP id 5so1223792bwz.3 for ; Fri, 22 Jan 2010 08:00:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:to:subject:references :organization:from:date:in-reply-to:message-id:user-agent :mime-version:content-type:content-transfer-encoding; bh=lR54PkQR1F2FsB9R46HknPl0T/g9NX1AZEceUOxri2w=; b=XoaJ0km04Yw873HEo+DH1UEOAtkQsZD/R/5cw79O/D1hlP3IajIYwIHJWMBGeDTtlo 1xoSwdUM4Oakzsn1kJulNdFrNWCisF9VzCKu/UtUBC9mVoOm65OY/qhTaDi2KEJkMDDu ewMXxBUxhP/DVIWQugFCF3pCq63Kd79icyc6U= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=to:subject:references:organization:from:date:in-reply-to:message-id :user-agent:mime-version:content-type:content-transfer-encoding; b=SCfXG+141KYQ4AFIvg2W9BWFKMqJDuvaoAZkxyi314oDPNn0/NpJM4YmgeitzSY36J j6H/s0VtcsnaYDwZIp/xtlynIF2eJeSl25VmbnZ55SR4E/5eHvB6/5Dx/0h8JTrh0ouZ 7JwCf1PWgKfvWKx0mj29T1Dfe+CSKd8GA2c50= Received: by 10.204.144.86 with SMTP id y22mr1757061bku.43.1264176025495; Fri, 22 Jan 2010 08:00:25 -0800 (PST) Received: from localhost (ms.singlescrowd.net [80.85.90.67]) by mx.google.com with ESMTPS id 15sm1029159bwz.4.2010.01.22.08.00.22 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 22 Jan 2010 08:00:23 -0800 (PST) To: freebsd-fs@FreeBSD.org, freebsd-stable@FreeBSD.org References: <86ocl272mb.fsf@kopusha.onet> <86tyuqnz9x.fsf@zhuzha.ua1> <86zl4awmon.fsf@zhuzha.ua1> <86vdeywmha.fsf@zhuzha.ua1> Organization: TOA Ukraine From: Mikolaj Golub Date: Fri, 22 Jan 2010 18:00:21 +0200 In-Reply-To: <86vdeywmha.fsf@zhuzha.ua1> (Mikolaj Golub's message of "Tue\, 19 Jan 2010 10\:02\:57 +0200") Message-ID: <86vdeuuo2y.fsf@zhuzha.ua1> User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 8bit Cc: Subject: Re: FreeBSD NFS client/Linux NFS server issue X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 22 Jan 2010 16:00:27 -0000 On Tue, 19 Jan 2010 10:02:57 +0200 Mikolaj Golub wrote: > So, on some of our freebsd7.1 nfs clients (and it looks like we have had > similar case with 6.3), which have several nfs mounts to the same CentOS 5.3 > NFS server (mount options: rw,-3,-T,-s,-i,-r=32768,-w=32768,-o=noinet6), at > some moment the access to one of the NFS mount gets stuck, while the access to > the other mounts works ok. > > In all cases we have been observed so far the first gotten stuck process was > php script (or two) that was (were) writing to logs file (appending). In > tcpdump we see that every write to the file causes the sequence of the > following rpc: ACCESS - READ - WRITE - COMMIT. And at some moment this stops > after READ rpc call and successful reply. > > After this in tcpdump successful readdir/access/lookup/fstat calls are > observed from our other utilities, which just check the presence of some files > and they work ok (df also works). The php process at this state is in bo_wwait > invalidating buffer cache [1]. > > If at this time we try accessing the share with mc then it hangs acquiring the > vn_lock held by php process [2] and after this any operations with this NFS > share hang (df hangs too). > > If instead some other process is started that writes to some other file on > this share (append) then the first process "unfreezes" too (starting from > WRITE rpc, so there is no any retransmits). So it looks for me that the problem here is that eventually problem nfsmount ends up in this state: (kgdb) p *nmp $1 = {nm_mtx = {lock_object = {lo_name = 0xc0b808ee "NFSmount lock", lo_type = 0xc0b808ee "NFSmount lock", lo_flags = 16973824, lo_witness_data = {lod_list = { stqe_next = 0x0}, lod_witness = 0x0}}, mtx_lock = 4, mtx_recurse = 0}, nm_flag = 35399, nm_state = 1310720, nm_mountp = 0xc6b472cc, nm_numgrps = 16, nm_fh = "\001\000\000\000\000\223\000\000\001@\003\n", '\0' , nm_fhsize = 12, nm_rpcclnt = {rc_flag = 0, rc_wsize = 0, rc_rsize = 0, rc_name = 0x0, rc_so = 0x0, rc_sotype = 0, rc_soproto = 0, rc_soflags = 0, rc_timeo = 0, rc_retry = 0, rc_srtt = {0, 0, 0, 0}, rc_sdrtt = {0, 0, 0, 0}, rc_sent = 0, rc_cwnd = 0, rc_timeouts = 0, rc_deadthresh = 0, rc_authtype = 0, rc_auth = 0x0, rc_prog = 0x0, rc_proctlen = 0, rc_proct = 0x0}, nm_so = 0xc6e81d00, nm_sotype = 1, nm_soproto = 0, nm_soflags = 44, nm_nam = 0xc6948640, nm_timeo = 6000, nm_retry = 2, nm_srtt = {15, 15, 31, 52}, nm_sdrtt = {3, 3, 15, 15}, nm_sent = 0, nm_cwnd = 4096, nm_timeouts = 0, nm_deadthresh = 9, nm_rsize = 32768, nm_wsize = 32768, nm_readdirsize = 4096, nm_readahead = 1, nm_wcommitsize = 1177026, nm_acdirmin = 30, nm_acdirmax = 60, nm_acregmin = 3, nm_acregmax = 60, nm_verf = "JW\000\004o", nm_bufq = {tqh_first = 0xda82dc70, tqh_last = 0xda8058e0}, nm_bufqlen = 2, nm_bufqwant = 0, nm_bufqiods = 1, nm_maxfilesize = 1099511627775, nm_rpcops = 0xc0c2b5bc, nm_tprintf_initial_delay = 12, nm_tprintf_delay = 30, nm_nfstcpstate = { rpcresid = 0, flags = 1, sock_send_inprog = 0}, nm_hostname = "172.30.10.92\000/var/www/app31", '\0' , nm_clientid = 0, nm_fsid = { val = {0, 0}}, nm_lease_time = 0, nm_last_renewal = 0} We have nonempty nm_bufq, nm_bufqiods = 1, but actually there is no nfsiod thread run for this mount, which is wrong -- nm_bufq will not be emptied until some other process starts writing to the nfsmount and starts nfsiod thread for this mount. Reviewing the code how it could happen I see the following path. Could someone confirm or disprove me? in nfs_bio.c:nfs_asyncio() we have: 1363 mtx_lock(&nfs_iod_mtx); ... 1374 /* 1375 * Find a free iod to process this request. 1376 */ 1377 for (iod = 0; iod < nfs_numasync; iod++) 1378 if (nfs_iodwant[iod]) { 1379 gotiod = TRUE; 1380 break; 1381 } 1382 1383 /* 1384 * Try to create one if none are free. 1385 */ 1386 if (!gotiod) { 1387 iod = nfs_nfsiodnew(); 1388 if (iod != -1) 1389 gotiod = TRUE; 1390 } Let's consider situation when new nfsiod is created. nfs_nfsiod.c:nfs_nfsiodnew() before creating nfssvc_iod thread unlocks nfs_iod_mtx: 179 mtx_unlock(&nfs_iod_mtx); 180 error = kthread_create(nfssvc_iod, nfs_asyncdaemon + i, NULL, RFHIGHPID, 181 0, "nfsiod %d", newiod); 182 mtx_lock(&nfs_iod_mtx); And nfs_nfsiod.c:nfssvc_iod() do the followin: 226 mtx_lock(&nfs_iod_mtx); ... 238 nfs_iodwant[myiod] = curthread->td_proc; 239 nfs_iodmount[myiod] = NULL; ... 244 error = msleep(&nfs_iodwant[myiod], &nfs_iod_mtx, PWAIT | PCATCH, 245 "-", timo); Let's at this moment another nfs_asyncio() request for another nfsmount has happened and this thread has locked nfs_iod_mtx. Then this thread will found nfs_iodwant[iod] in "for" loop and will use it. When the first thread actually has returned from nfs_nfsiodnew() it will insert buffer to nmp->nm_bufq but nfsiod will process other nmp. It looks like the fix for this situation would be to check nfs_iodwant[iod] after nfs_nfsiodnew(): --- nfs_bio.c.orig 2010-01-22 15:38:02.000000000 +0000 +++ nfs_bio.c 2010-01-22 15:39:58.000000000 +0000 @@ -1385,7 +1385,7 @@ again: */ if (!gotiod) { iod = nfs_nfsiodnew(); - if (iod != -1) + if ((iod != -1) && (nfs_iodwant[iod] == NULL)) gotiod = TRUE; } Described here scenario could be our case. We have 7 nfs mounts on the problem host. And by cront at the same time one or two scripts for every mount were started. So we had something like this in top (cron tasks started at 23:02): last pid: 64884; load averages: 0.28, 0.34, 0.24 up 0+22:15:41 23:02:04 300 processes: 6 running, 259 sleeping, 1 stopped, 17 zombie, 17 waiting CPU: 10.2% user, 0.0% nice, 7.6% system, 1.0% interrupt, 81.2% idle Mem: 174M Active, 2470M Inact, 221M Wired, 136M Cache, 112M Buf, 251M Free Swap: 8192M Total, 8192M Free 64793 app12 -1 0 23352K 11980K nfsreq 0 0:00 1.07% php 64789 app16 -1 0 21304K 11084K nfsreq 0 0:00 0.98% php 64784 app16 -1 0 19256K 9696K nfsreq 2 0:00 0.88% php 64768 app20 -1 0 19256K 9300K nfsreq 0 0:00 0.78% php 64759 app20 -1 0 18232K 8888K nfsreq 1 0:00 0.78% php 64722 app31 -1 0 20280K 9956K nfsreq 0 0:00 0.68% php 64781 app18 -1 0 19256K 9412K nfsreq 3 0:00 0.68% php 64778 app26 -1 0 18232K 8840K nfsreq 1 0:00 0.68% php 64800 app8 -1 0 18232K 8664K nfsreq 3 0:00 0.68% php 64728 app31 -1 0 18232K 8752K nfsreq 0 0:00 0.59% php 64795 app18 -1 0 18232K 8676K nfsreq 1 0:00 0.59% php 64777 app22 -1 0 18232K 8984K nfsreq 0 0:00 0.49% php 2342 app31 -4 0 22236K 7780K nfs 1 0:13 0.00% icoms_agent_cox215 58920 root 8 - 0K 8K - 2 0:08 0.00% nfsiod 0 2334 app31 -4 0 18908K 6356K nfs 1 0:05 0.00% icoms_agent_cox001 64297 root 8 - 0K 8K - 2 0:00 0.00% nfsiod 1 64298 root 8 - 0K 8K - 3 0:00 0.00% nfsiod 2 64303 root 8 - 0K 8K - 1 0:00 0.00% nfsiod 3 64874 root 8 - 0K 8K - 0 0:00 0.00% nfsiod 12 64870 root 8 - 0K 8K - 3 0:00 0.00% nfsiod 9 64866 root 8 - 0K 8K - 0 0:00 0.00% nfsiod 4 64873 root 8 - 0K 8K - 3 0:00 0.00% nfsiod 11 64867 root 8 - 0K 8K - 0 0:00 0.00% nfsiod 5 64869 root 8 - 0K 8K - 1 0:00 0.00% nfsiod 8 64872 root 8 - 0K 8K - 0 0:00 0.00% nfsiod 10 64868 root 8 - 0K 8K - 3 0:00 0.00% nfsiod 7 64871 root 8 - 0K 8K - 0 0:00 0.00% nfsiod 6 last pid: 64967; load averages: 0.42, 0.37, 0.25 up 0+22:15:46 23:02:09 295 processes: 7 running, 251 sleeping, 1 stopped, 19 zombie, 17 waiting CPU: 69.1% user, 0.0% nice, 8.3% system, 1.5% interrupt, 21.1% idle Mem: 376M Active, 2488M Inact, 226M Wired, 124M Cache, 106M Buf, 37M Free Swap: 8192M Total, 8192M Free 64793 app12 99 0 86840K 59968K CPU3 3 0:02 16.55% php 64768 app20 -1 0 57144K 38424K nfsreq 1 0:02 15.19% php 64722 app31 99 0 61240K 41228K CPU0 0 0:02 15.19% php 64781 app18 -1 0 54072K 35612K nfsreq 2 0:02 13.67% php 64789 app16 -1 0 48952K 31660K nfsreq 3 0:01 10.60% php 64777 app22 -1 0 43832K 27876K nfsreq 0 0:01 9.86% php 64784 app16 -1 0 45880K 29648K nfsreq 0 0:01 9.77% php 64759 app20 -7 0 36664K 22792K bo_wwa 0 0:01 8.25% php 64800 app8 -7 0 24376K 13596K bo_wwa 1 0:01 2.39% php 64795 app18 -7 0 23352K 12788K bo_wwa 3 0:00 1.37% php 58920 root -1 - 0K 8K nfsreq 2 0:08 0.00% nfsiod 0 64303 root 8 - 0K 8K - 0 0:00 0.00% nfsiod 3 64866 root 8 - 0K 8K - 0 0:00 0.00% nfsiod 4 64297 root -1 - 0K 8K nfsreq 2 0:00 0.00% nfsiod 1 64298 root -1 - 0K 8K nfsreq 3 0:00 0.00% nfsiod 2 64873 root 8 - 0K 8K - 1 0:00 0.00% nfsiod 11 64868 root 8 - 0K 8K - 0 0:00 0.00% nfsiod 7 64867 root 8 - 0K 8K - 0 0:00 0.00% nfsiod 5 64871 root 8 - 0K 8K - 0 0:00 0.00% nfsiod 6 64947 root 8 - 0K 8K - 0 0:00 0.00% nfsiod 14 64950 root 8 - 0K 8K - 0 0:00 0.00% nfsiod 17 64870 root 8 - 0K 8K - 0 0:00 0.00% nfsiod 9 64869 root 8 - 0K 8K - 0 0:00 0.00% nfsiod 8 64949 root 8 - 0K 8K - 3 0:00 0.00% nfsiod 16 64874 root 8 - 0K 8K - 1 0:00 0.00% nfsiod 12 64872 root 8 - 0K 8K - 0 0:00 0.00% nfsiod 10 64952 root 8 - 0K 8K - 0 0:00 0.00% nfsiod 19 64948 root 8 - 0K 8K - 0 0:00 0.00% nfsiod 15 64951 root 8 - 0K 8K - 3 0:00 0.00% nfsiod 18 64946 root 8 - 0K 8K - 0 0:00 0.00% nfsiod 13 last pid: 64968; load averages: 0.54, 0.39, 0.26 up 0+22:15:51 23:02:14 289 processes: 7 running, 243 sleeping, 1 stopped, 21 zombie, 17 waiting CPU: 28.7% user, 0.0% nice, 8.8% system, 1.1% interrupt, 61.4% idle Mem: 404M Active, 2503M Inact, 224M Wired, 83M Cache, 107M Buf, 37M Free Swap: 8192M Total, 8192M Free 64793 app12 -1 0 148M 106M nfsreq 1 0:07 41.55% php 64722 app31 -7 0 61240K 41232K bo_wwa 1 0:03 14.26% php 64768 app20 -7 0 57144K 38424K bo_wwa 3 0:03 13.67% php 64781 app18 -7 0 54072K 35612K bo_wwa 0 0:02 11.18% php 64789 app16 -7 0 48952K 31660K bo_wwa 0 0:02 7.96% php 64784 app16 -7 0 45880K 29648K bo_wwa 0 0:02 7.76% php 64777 app22 -7 0 43832K 27876K bo_wwa 0 0:01 6.40% php 64759 app20 -7 0 36664K 22792K bo_wwa 0 0:01 4.79% php 58920 root -1 - 0K 8K nfsreq 2 0:08 0.00% nfsiod 0 64867 root 8 - 0K 8K - 1 0:00 0.00% nfsiod 5 64873 root 8 - 0K 8K - 0 0:00 0.00% nfsiod 11 64303 root -1 - 0K 8K nfsreq 0 0:00 0.00% nfsiod 3 64866 root -1 - 0K 8K nfsreq 1 0:00 0.00% nfsiod 4 64297 root -1 - 0K 8K nfsreq 0 0:00 0.00% nfsiod 1 64298 root -1 - 0K 8K nfsreq 3 0:00 0.00% nfsiod 2 64871 root 8 - 0K 8K - 1 0:00 0.00% nfsiod 6 64868 root 8 - 0K 8K - 1 0:00 0.00% nfsiod 7 64869 root 8 - 0K 8K - 0 0:00 0.00% nfsiod 8 64947 root 8 - 0K 8K - 1 0:00 0.00% nfsiod 14 64872 root 8 - 0K 8K - 2 0:00 0.00% nfsiod 10 64874 root 8 - 0K 8K - 1 0:00 0.00% nfsiod 12 64870 root 8 - 0K 8K - 2 0:00 0.00% nfsiod 9 64949 root 8 - 0K 8K - 2 0:00 0.00% nfsiod 16 64950 root 8 - 0K 8K - 1 0:00 0.00% nfsiod 17 64948 root 8 - 0K 8K - 1 0:00 0.00% nfsiod 15 64951 root 8 - 0K 8K - 3 0:00 0.00% nfsiod 18 64946 root 8 - 0K 8K - 2 0:00 0.00% nfsiod 13 64952 root 8 - 0K 8K - 1 0:00 0.00% nfsiod 19 last pid: 64969; load averages: 0.50, 0.39, 0.25 up 0+22:15:56 23:02:19 269 processes: 6 running, 219 sleeping, 1 stopped, 26 zombie, 17 waiting CPU: 11.9% user, 0.0% nice, 5.8% system, 0.8% interrupt, 81.5% idle Mem: 264M Active, 2504M Inact, 232M Wired, 83M Cache, 112M Buf, 169M Free Swap: 8192M Total, 8192M Free 64793 app12 -1 0 148M 106M nfsreq 3 0:08 33.69% php 64789 app16 -7 0 48952K 31660K bo_wwa 0 0:02 4.98% php 64784 app16 -7 0 45880K 29648K bo_wwa 0 0:02 4.88% php 58920 root 8 - 0K 8K - 1 0:08 0.20% nfsiod 0 64867 root 8 - 0K 8K - 2 0:00 0.10% nfsiod 5 64303 root 8 - 0K 8K - 3 0:00 0.00% nfsiod 3 64297 root 8 - 0K 8K - 3 0:00 0.00% nfsiod 1 64873 root 8 - 0K 8K - 0 0:00 0.00% nfsiod 11 64866 root 8 - 0K 8K - 3 0:00 0.00% nfsiod 4 64871 root 8 - 0K 8K - 2 0:00 0.00% nfsiod 6 64298 root 8 - 0K 8K - 0 0:00 0.00% nfsiod 2 64868 root 8 - 0K 8K - 0 0:00 0.00% nfsiod 7 64869 root 8 - 0K 8K - 0 0:00 0.00% nfsiod 8 64947 root 8 - 0K 8K - 1 0:00 0.00% nfsiod 14 64872 root 8 - 0K 8K - 2 0:00 0.00% nfsiod 10 64874 root 8 - 0K 8K - 1 0:00 0.00% nfsiod 12 64870 root 8 - 0K 8K - 2 0:00 0.00% nfsiod 9 64949 root 8 - 0K 8K - 2 0:00 0.00% nfsiod 16 64950 root 8 - 0K 8K - 1 0:00 0.00% nfsiod 17 64948 root 8 - 0K 8K - 1 0:00 0.00% nfsiod 15 64951 root 8 - 0K 8K - 3 0:00 0.00% nfsiod 18 64946 root 8 - 0K 8K - 2 0:00 0.00% nfsiod 13 64952 root 8 - 0K 8K - 1 0:00 0.00% nfsiod 19 last pid: 64970; load averages: 0.46, 0.38, 0.25 up 0+22:16:02 23:02:25 263 processes: 5 running, 212 sleeping, 1 stopped, 28 zombie, 17 waiting CPU: 8.7% user, 0.0% nice, 3.1% system, 0.3% interrupt, 87.9% idle Mem: 160M Active, 2502M Inact, 232M Wired, 83M Cache, 112M Buf, 274M Free Swap: 8192M Total, 8192M Free 64789 app16 -7 0 48952K 31660K bo_wwa 0 0:02 3.27% php 64784 app16 -7 0 45880K 29648K bo_wwa 0 0:02 3.17% php 58920 root 8 - 0K 8K - 1 0:08 0.00% nfsiod 0 64867 root 8 - 0K 8K - 2 0:00 0.00% nfsiod 5 64303 root 8 - 0K 8K - 3 0:00 0.00% nfsiod 3 64297 root 8 - 0K 8K - 3 0:00 0.00% nfsiod 1 64873 root 8 - 0K 8K - 0 0:00 0.00% nfsiod 11 64866 root 8 - 0K 8K - 3 0:00 0.00% nfsiod 4 64871 root 8 - 0K 8K - 2 0:00 0.00% nfsiod 6 64298 root 8 - 0K 8K - 0 0:00 0.00% nfsiod 2 64868 root 8 - 0K 8K - 0 0:00 0.00% nfsiod 7 64869 root 8 - 0K 8K - 0 0:00 0.00% nfsiod 8 64947 root 8 - 0K 8K - 1 0:00 0.00% nfsiod 14 64872 root 8 - 0K 8K - 2 0:00 0.00% nfsiod 10 64874 root 8 - 0K 8K - 1 0:00 0.00% nfsiod 12 64870 root 8 - 0K 8K - 2 0:00 0.00% nfsiod 9 64949 root 8 - 0K 8K - 2 0:00 0.00% nfsiod 16 64950 root 8 - 0K 8K - 1 0:00 0.00% nfsiod 17 64948 root 8 - 0K 8K - 1 0:00 0.00% nfsiod 15 64951 root 8 - 0K 8K - 3 0:00 0.00% nfsiod 18 64946 root 8 - 0K 8K - 2 0:00 0.00% nfsiod 13 64952 root 8 - 0K 8K - 1 0:00 0.00% nfsiod 19 And this two php processes were hanged until 23:05 another process started that write to another file on this nfs mount. -- Mikolaj Golub From owner-freebsd-stable@FreeBSD.ORG Fri Jan 22 16:10:25 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 D1AFB10656D6; Fri, 22 Jan 2010 16:10:25 +0000 (UTC) (envelope-from dnaeon@gmail.com) Received: from mail-ew0-f226.google.com (mail-ew0-f226.google.com [209.85.219.226]) by mx1.freebsd.org (Postfix) with ESMTP id 129DA8FC15; Fri, 22 Jan 2010 16:10:24 +0000 (UTC) Received: by ewy26 with SMTP id 26so333134ewy.3 for ; Fri, 22 Jan 2010 08:10:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type; bh=eL41dN0L5PLt0KdWho/DEzHD6PeOg8dEwFYx/RP4k2g=; b=ozEAzEfNPjkIq3eJKHKL3oBKJRpQ4rGFqFsVpreqt4+xxSdIsHMlQ3kJ6ORFqAdus1 RYZpobm9wxzAulTryoHxFf8biFR9YbB0mvAelbMJjAWi9gMYuo0P38l9y/izZCM3YVRd cDjvq/tCq1IBJBnoMy6skW6KfesKgfs+INTB0= 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=XZXvAciriQf/ARSDOt50JtrZAB52CgJbUJhU1MWrtkoXDayFUWdn0ArdxLm4pDvfQN zPYcyJXlRRzjAYNKjFm0b1F3Y2F3WNBDqnjDGVMxTo/SUJ/XmRQ+GhlYFLsn56h59RbM MjkHtTugCdIlgFfsZ6UPPBTYNfS3jPS6CJyGw= MIME-Version: 1.0 Received: by 10.216.91.81 with SMTP id g59mr1221978wef.128.1264176623743; Fri, 22 Jan 2010 08:10:23 -0800 (PST) In-Reply-To: <20100122080223.GA6681@titania.njm.me.uk> References: <717f7a3e1001120714m37aada69gfaa35f0f9b17f435@mail.gmail.com> <44678539@bb.ipt.ru> <717f7a3e1001142234y1de7ae15x6853e3ddcab4add9@mail.gmail.com> <717f7a3e1001192246o4dce4a82q57c05ff3f41b5feb@mail.gmail.com> <20100120074611.GA405@icarus.home.lan> <717f7a3e1001210137p7884adcbxc66a4f7fff928821@mail.gmail.com> <20100122080223.GA6681@titania.njm.me.uk> Date: Fri, 22 Jan 2010 18:10:23 +0200 Message-ID: <717f7a3e1001220810s11b241b7ve9a9172c51ea531b@mail.gmail.com> From: Marin Atanasov To: Marin Atanasov , Jeremy Chadwick , freebsd-hardware@freebsd.org, freebsd-stable@freebsd.org, Ronald Klop Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Subject: Re: Multiple serial consoles via null modem cable X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 22 Jan 2010 16:10:25 -0000 On Fri, Jan 22, 2010 at 10:02 AM, N.J. Mann wrote: > In message <717f7a3e1001210137p7884adcbxc66a4f7fff928821@mail.gmail.com>, > Marin Atanasov (dnaeon@gmail.com) wrote: > > Hello Jeremy, > > > > Now I'm a little confused :) > > > > I've made some tests with my machines and a couple of null modem cables, > and > > here's what I've got. > > > > On Wed, Jan 20, 2010 at 9:46 AM, Jeremy Chadwick > > wrote: > > > > > On Wed, Jan 20, 2010 at 08:46:48AM +0200, Marin Atanasov wrote: > > > > Hello, > > > > > > > > Using `cu' only works with COM1 for me. > > > > > > > > Currently I have two serial ports on the system, and only the first > is > > > able > > > > to make the connection - the serial consoles are enabled in /etc/tty, > but > > > as > > > > I said only COM1 is able to make the connection. > > > > > > I'm a little confused by this statement, so I'll add some clarify: > > > > > > /etc/ttys is for configuring a machine to tie getty (think login > prompt) > > > to a device (in this case, a serial port). Meaning: the device on the > > > other end of the serial cable will start seeing "login:" and so on > > > assuming you attach to the serial port there. > > > > > > For example: > > > > > > box1 COM1/ttyu0 is wired to box2 COM3/ttyu2 using a null modem cable. > > > box1 COM2/ttyu1 is wired to box2 COM4/ttyu3 using a null modem cable. > > > > > > On box1, you'd have something like this in /etc/ttys: > > > > > > ttyu0 "/usr/libexec/getty std.9600" vt100 on secure > > > ttyu1 "/usr/libexec/getty std.9600" vt100 on secure > > > > > > > Here's what I did: > > > > box1 COM1/ttyd0 -> box2 COM1/ttyd0 -> using null modem cable > > box1 COM2/ttyd1 -> box3 COM1/ttyd0 -> using null modem cable > > > > On box1 I have this in /etc/ttys: > > > > ttyd0 "/usr/libexec/getty std.9600" vt100 on secure > > ttyd1 "/usr/libexec/getty std.9600" vt100 on secure > > > > Now if I want to connect to box1 from box2 or box3 through the serial > > connection it should work, right? > > But I only can connect to box1 from box2, because box2's COM port is > > connected to box1's COM1 port. > > > > >From box2 I can get a login prompt > > box2# cu -l /dev/cuad0 -s 9600 > > Connected > > > > login: > > ) > > (host.domain) (ttyd0) > > > > login: ~ > > [EOT] > > > > But if I try to connect to box1 from box3 - no success there. > > box3# cu -l /dev/cuad0 -s 9600 > > Connected > > ~ > > [EOT] > > You need to reduce the number of unknowns, e.g. where is the problem: > box1, box3 or in between. So, swap the cables on box1 so that you now > have box1:COM1 -> box3:COM1 and box1:COM2 -> box2:COM1. Now repeat the > tests above and post your results. > > > Cheers, > Nick. > -- > > Seems I've found the issue, that I'm having - a broken null modem cable :( The last time I was using that cable it was working fine. And now that I connected a second one to the machine, it seemed that only the one connected to COM1 was actually working, and I was left with the impression from the documentation that only COM1 is able to do a serial console connection. I'm very sorry to bother you like that. I'll continue setting up the servers once I get a new null modem cable. Thanks and regards, Marin -- Marin Atanasov Nikolov dnaeon AT gmail DOT com daemon AT unix-heaven DOT org From owner-freebsd-stable@FreeBSD.ORG Fri Jan 22 16:21: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 B6404106566B for ; Fri, 22 Jan 2010 16:21:57 +0000 (UTC) (envelope-from prvs=0638d2851d=ob@gruft.de) Received: from main.mx.e-gitt.net (service.rules.org [IPv6:2001:1560:2342::2]) by mx1.freebsd.org (Postfix) with ESMTP id 3EA328FC1F for ; Fri, 22 Jan 2010 16:21:57 +0000 (UTC) Received: from ob by main.mx.e-gitt.net with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NYMGi-000OOn-Ea for freebsd-stable@FreeBSD.org; Fri, 22 Jan 2010 17:21:56 +0100 Date: Fri, 22 Jan 2010 17:21:56 +0100 From: Oliver Brandmueller To: freebsd-stable@FreeBSD.org Message-ID: <20100122162155.GG3917@e-Gitt.NET> Mail-Followup-To: freebsd-stable@FreeBSD.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.20 (2009-06-14) Sender: Oliver Brandmueller Cc: Subject: 8.0-RELEASE -> -STABLE and size of / X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 22 Jan 2010 16:21:57 -0000 Hi, I just noticed somthing: I setup an 8.0-RELEASE amd64 box, / is default 512M. First step after setup was to csup to RELENG_8 and buildkernel and buildworld (no custom kernel, no make.conf). Instaling the new kernel failed, since /boot/kernel/ is already well over 230 MBytes in size. moving that to kernel.old and writing a new one with about the same size fails due to no space left on device. This is not a question; I do know how to get around this and how to configure custom kernels so they are a fragment of that size afterwards. However, I think this is a clear POLA violation. So, either GENERIC with less debugging information (symbols and stuff), which makes debugging harder or setting a higher default for / would be options, if not anyone else has better ideas. - Oliver -- | Oliver Brandmueller http://sysadm.in/ ob@sysadm.in | | Ich bin das Internet. Sowahr ich Gott helfe. | From owner-freebsd-stable@FreeBSD.ORG Fri Jan 22 16:27: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 1E6DA1065679 for ; Fri, 22 Jan 2010 16:27:54 +0000 (UTC) (envelope-from mh@kernel32.de) Received: from crivens.kernel32.de (crivens.asm68k.org [81.169.171.191]) by mx1.freebsd.org (Postfix) with ESMTP id D30EB8FC16 for ; Fri, 22 Jan 2010 16:27:53 +0000 (UTC) Received: from www.terrorteam.de (localhost [127.0.0.1]) by crivens.kernel32.de (Postfix) with ESMTP id 44C86B0391; Fri, 22 Jan 2010 17:27:52 +0100 (CET) MIME-Version: 1.0 Date: Fri, 22 Jan 2010 17:27:52 +0100 From: Marian Hettwer To: Oliver Brandmueller In-Reply-To: <20100122162155.GG3917@e-Gitt.NET> References: <20100122162155.GG3917@e-Gitt.NET> Message-ID: X-Sender: mh@kernel32.de User-Agent: RoundCube Webmail/0.1-rc2 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit Cc: freebsd-stable@FreeBSD.org Subject: Re: 8.0-RELEASE -> -STABLE and size of / X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 22 Jan 2010 16:27:54 -0000 Hi All, On Fri, 22 Jan 2010 17:21:56 +0100, Oliver Brandmueller wrote: > Hi, > > I just noticed somthing: I setup an 8.0-RELEASE amd64 box, / is default > 512M. First step after setup was to csup to RELENG_8 and buildkernel and > buildworld (no custom kernel, no make.conf). > > Instaling the new kernel failed, since /boot/kernel/ is already well > over 230 MBytes in size. moving that to kernel.old and writing a new one > with about the same size fails due to no space left on device. > > This is not a question; I do know how to get around this and how to > configure custom kernels so they are a fragment of that size afterwards. > However, I think this is a clear POLA violation. So, either GENERIC with > less debugging information (symbols and stuff), which makes debugging > harder or setting a higher default for / would be options, if not anyone > else has better ideas. > +1 vote for making / bigger. At least a size where a make installkernel runs through. I like FreeBSD because it honors POLA. And as Oliver stated, this is a clear POLA violation. Cheers, Marian From owner-freebsd-stable@FreeBSD.ORG Fri Jan 22 16:46: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 D3E1D106566B for ; Fri, 22 Jan 2010 16:46:05 +0000 (UTC) (envelope-from torfinn.ingolfsen@broadpark.no) Received: from bgo1smout1.broadpark.no (bgo1smout1.broadpark.no [217.13.4.94]) by mx1.freebsd.org (Postfix) with ESMTP id 925658FC15 for ; Fri, 22 Jan 2010 16:46:05 +0000 (UTC) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=US-ASCII Received: from bgo1sminn1.broadpark.no ([217.13.4.93]) by bgo1smout1.broadpark.no (Sun Java(tm) System Messaging Server 6.3-3.01 (built Jul 12 2007; 32bit)) with ESMTP id <0KWN00KWIQKPRM10@bgo1smout1.broadpark.no> for freebsd-stable@freebsd.org; Fri, 22 Jan 2010 17:46:01 +0100 (CET) Received: from kg-v2.kg4.no ([80.203.92.186]) by bgo1sminn1.broadpark.no (Sun Java(tm) System Messaging Server 6.3-3.01 (built Jul 12 2007; 32bit)) with SMTP id <0KWN000U6QKPF3G0@bgo1sminn1.broadpark.no> for freebsd-stable@freebsd.org; Fri, 22 Jan 2010 17:46:01 +0100 (CET) Date: Fri, 22 Jan 2010 17:46:01 +0100 From: Torfinn Ingolfsen To: freebsd-stable@freebsd.org Message-id: <20100122174601.e76f8b01.torfinn.ingolfsen@broadpark.no> In-reply-to: <20100122162155.GG3917@e-Gitt.NET> References: <20100122162155.GG3917@e-Gitt.NET> X-Mailer: Sylpheed 2.7.1 (GTK+ 2.18.6; amd64-portbld-freebsd8.0) X-Face: "t9w2,-X@O^I`jVW\sonI3.,36KBLZE*AL[y9lL[PyFD*r_S:dIL9c[8Y>V42R0"!"yb_zN,f#%.[PYYNq; m"_0v; ~rUM2Yy!zmkh)3&U|u!=T(zyv,MHJv"nDH>OJ`t(@mil461d_B'Uo|'nMwlKe0Mv=kvV?Nh@>Hb<3s_z2jYgZhPb@?Wi^x1a~Hplz1.zH Subject: Re: 8.0-RELEASE -> -STABLE and size of / X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 22 Jan 2010 16:46:05 -0000 On Fri, 22 Jan 2010 17:21:56 +0100 Oliver Brandmueller wrote: > Instaling the new kernel failed, since /boot/kernel/ is already well > over 230 MBytes in size. moving that to kernel.old and writing a new one > with about the same size fails due to no space left on device. > > This is not a question; I do know how to get around this and how to > configure custom kernels so they are a fragment of that size afterwards. It would also be nice if we knew how to configure the whole "make world" procedure[1] to make a new kernel and modules without symbols. The FAQ doesn't seem to have that answer either. References: 1) http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/makeworld.html -- Regards, Torfinn Ingolfsen From owner-freebsd-stable@FreeBSD.ORG Fri Jan 22 16:48: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 54F5C1065698; Fri, 22 Jan 2010 16:48:34 +0000 (UTC) (envelope-from fjwcash@gmail.com) Received: from mail-iw0-f198.google.com (mail-iw0-f198.google.com [209.85.223.198]) by mx1.freebsd.org (Postfix) with ESMTP id 0D1618FC27; Fri, 22 Jan 2010 16:48:33 +0000 (UTC) Received: by iwn36 with SMTP id 36so1149347iwn.3 for ; Fri, 22 Jan 2010 08:48:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type; bh=DK58rBGwTxxNOLhQXY2UxQg82Y0UH6VIeDKsv7w29Cs=; b=LKiXIx8QGAChQH66QP8W6PMRfygAGj3HsgQAXKQlKwlZMUTQ0CpQaPP3utnkP250/f E+aokt2ZWtEExcIuln5mSNnJYAaaeD8Fsgfa79ZohOQmWFnfyHcjVR2zhCWvcGAT7I1O PZtlF2CFT5phNyBQdC9csAJLPcUvPxZZHqGqc= 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=lqF4L6GECoFxJ73xO8F89QoTV6Af3zQSVses2bc+MTKFEToem0OX8yk3X8lGZZ16jZ aDUhBZMBBN0oHljwuQ+X20IijT2tpHMHAFdL8az0jnh57kOagOiJuQbLYJIiXYT3pvXM UO+w+Jic0LBVHnJy4iTr4BYNTrT3idyPFOAk4= MIME-Version: 1.0 Received: by 10.231.149.16 with SMTP id r16mr1987199ibv.93.1264178913588; Fri, 22 Jan 2010 08:48:33 -0800 (PST) In-Reply-To: <4B597CBB.5040900@omnilan.de> References: <4B55D9D4.1000008@FreeBSD.org> <4B597CBB.5040900@omnilan.de> Date: Fri, 22 Jan 2010 08:48:33 -0800 Message-ID: From: Freddie Cash To: FreeBSD-Current , FreeBSD Stable Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Subject: Re: Pack of CAM improvements X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 22 Jan 2010 16:48:34 -0000 On Fri, Jan 22, 2010 at 2:23 AM, Harald Schmalzbauer < h.schmalzbauer@omnilan.de> wrote: > Alexander Motin schrieb am 19.01.2010 17:12 (localtime): > ... > > Patch can be found here: >> http://people.freebsd.org/~mav/cam-ata.20100119.patch >> >> Feedback as always welcome. >> > > Again, thanks a lot for your ongoing great work! > The patch doesn't cleanly apply with vpo, but I don't use vpo so I didn't > care. > Otherwise I couldn't find any problems. > The system detects reinserted SATA drives on ICH9 fine. > > This was tested on a zfs backup server which went to the backbone > yesterday, so I can't physically remove any devices any more for testing... > > But I had some questions about zfs raidz states. I think that isn't a > matter of atacam but if I removed one disk, zpool status still showed me the > ada3 device "online". > After reinserting (and proper detection/initialisazion with cam, ada3 was > present again) and zpool clean, it set the devicea as UNAVAIL sinve I/O > errors. > I coudn't get the device into the pool again, no matter what I tried. > Only rebooting the machine helped. Then I could clean and scrub. > > What are the needed steps to provide a reinsterted hard disk to geom? With > the latest patches I don't need to issue any reset/rescan comman, right? > So it's a zfs problem, right? My mistake in understanding? > > In my testing of pulling drives at random (using a 3Ware 9550SXU or 9650SE controller), you have to "zpool offline " while the drive is unplugged, before you can re-insert the same disk or a different disk. Without doing that step, it's very hard to re-insert the same disk, or replace it with a new one, without rebooting. Took me a couple of reboots and drive replacements before I figured that one out. :) -- Freddie Cash fjwcash@gmail.com From owner-freebsd-stable@FreeBSD.ORG Fri Jan 22 16:57: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 B5215106566B for ; Fri, 22 Jan 2010 16:57:45 +0000 (UTC) (envelope-from fjwcash@gmail.com) Received: from mail-iw0-f198.google.com (mail-iw0-f198.google.com [209.85.223.198]) by mx1.freebsd.org (Postfix) with ESMTP id 797618FC17 for ; Fri, 22 Jan 2010 16:57:45 +0000 (UTC) Received: by iwn36 with SMTP id 36so1156829iwn.3 for ; Fri, 22 Jan 2010 08:57:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type; bh=UVdQWHCCCvqXRZtxOP8PgwVTb+y8jco35u6q2HEa+5A=; b=N2P62g0UlYb0oUTFvVBfMjhXZJjPQQMWyyYj+XWJ3P9/BTYCGq8gejWcNlTl46iw1E fYZpe/mVsf1vFWeEDBkFeHIySeakqo9Ulo7wb7YJ+tqts0Ntwy7+TNtbifZcYx4tpvRF 4p5dnljHfpCqaUcTL8A45a8NqeVto4pRgCLRU= 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=q7ObIT+f8fs3Z7vrhSkTfo63E9JsQuAyxFkRraSVOoXxyZ2Dxdp2hP7K8UkqvU4EGs ZuFTV7N9BrYs36KmEQ6DOVr9Dmx1k398Paye5yThL1OOX5kGOE9rQeO/g1WNx3bzsC8S wqM+NsFJPoQIVcERPkli9uqC8E44LE3+SeDhg= MIME-Version: 1.0 Received: by 10.231.153.69 with SMTP id j5mr5195677ibw.33.1264179464829; Fri, 22 Jan 2010 08:57:44 -0800 (PST) In-Reply-To: <20100122090900.GG2910@core.byshenk.net> References: <4B58FE0B.3010001@langille.org> <20100122090102.GF2910@core.byshenk.net> <20100122090900.GG2910@core.byshenk.net> Date: Fri, 22 Jan 2010 08:57:44 -0800 Message-ID: From: Freddie Cash To: FreeBSD Stable Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Re: device.hints isn't setting what I want X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 22 Jan 2010 16:57:45 -0000 Just as a side note: does mergemaster or installworld handle the installation of /boot/device.hints? If it's mergemaster, then everything is fine, it'll detect your changes. If it's installworld, you'll lose your changes at the next update. Either way, I find it nicer/simpler to use /boot/loader.conf for this, as nothing in the build/update process touches it, and it keeps all boot/kernel options in one file. And, it overrides any settings in device.hints. -- Freddie Cash fjwcash@gmail.com From owner-freebsd-stable@FreeBSD.ORG Fri Jan 22 17:07: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 99A80106568B for ; Fri, 22 Jan 2010 17:07:19 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta05.westchester.pa.mail.comcast.net (qmta05.westchester.pa.mail.comcast.net [76.96.62.48]) by mx1.freebsd.org (Postfix) with ESMTP id 43F6F8FC25 for ; Fri, 22 Jan 2010 17:07:18 +0000 (UTC) Received: from omta15.westchester.pa.mail.comcast.net ([76.96.62.87]) by qmta05.westchester.pa.mail.comcast.net with comcast id YbXT1d00G1swQuc55h6tHg; Fri, 22 Jan 2010 17:06:53 +0000 Received: from koitsu.dyndns.org ([98.248.46.159]) by omta15.westchester.pa.mail.comcast.net with comcast id Yh7n1d0023S48mS3bh7n5K; Fri, 22 Jan 2010 17:07:48 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 9B7441E3033; Fri, 22 Jan 2010 09:07:16 -0800 (PST) Date: Fri, 22 Jan 2010 09:07:16 -0800 From: Jeremy Chadwick To: freebsd-stable@freebsd.org Message-ID: <20100122170716.GA75020@icarus.home.lan> References: <20100122162155.GG3917@e-Gitt.NET> 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) Subject: Re: 8.0-RELEASE -> -STABLE and size of / X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 22 Jan 2010 17:07:19 -0000 On Fri, Jan 22, 2010 at 05:27:52PM +0100, Marian Hettwer wrote: > Hi All, > > On Fri, 22 Jan 2010 17:21:56 +0100, Oliver Brandmueller > wrote: > > Hi, > > > > I just noticed somthing: I setup an 8.0-RELEASE amd64 box, / is default > > 512M. First step after setup was to csup to RELENG_8 and buildkernel and > > buildworld (no custom kernel, no make.conf). > > > > Instaling the new kernel failed, since /boot/kernel/ is already well > > over 230 MBytes in size. moving that to kernel.old and writing a new one > > with about the same size fails due to no space left on device. > > > > This is not a question; I do know how to get around this and how to > > configure custom kernels so they are a fragment of that size afterwards. > > However, I think this is a clear POLA violation. So, either GENERIC with > > less debugging information (symbols and stuff), which makes debugging > > harder or setting a higher default for / would be options, if not anyone > > else has better ideas. > > > +1 vote for making / bigger. > At least a size where a make installkernel runs through. > > I like FreeBSD because it honors POLA. > And as Oliver stated, this is a clear POLA violation. I'd like to see the default root filesystem size default to 1GB. For most folks this works well. If people are paranoid, 2GB should be more than sufficient. While I'm here, I figure I'd share how I end up partitioning most of the server systems I maintain. I use this general "formula" when building a new system, unless it's a 4-disk box (see bottom of mail): ad4s1a = / = UFS2 = 1GB ad4s1b = swap = (2*RAM) or (2*MaxRAMPossible) ad4s1d = /var = UFS2+SU = 16GB (mandatory: must be >= 2*RAM) ad4s1e = /tmp = UFS2+SU = (2*RAM) ad4s1f = /usr = UFS2+SU = 16GB There's lots of leftover space on the disk of course -- for either ad4s1g or ad4s2. For 1-disk boxes, I add ad8s1g = /home = UFS2+SU = , or sometimes name it /storage (depends on the role of the box). For 2-disk boxes, I almost always go with disks that are identical in size, use the above formula, and add ZFS mirroring as so: ad4s2 = ZFS mirror pool = ad6 = ZFS mirror pool = Then /home or /storage are ZFS filesystems in that pool. Folks will say "but that means you're losing/wasting gigs of space on ad6, since the mirror size is based on the smallest pool member!" Yep, but I consider the trade off easily worth it. Given the size of disks today (500GB to 2TB), I really don't stress about it: Wasted space for 4GB RAM systems: 1 + 2*4 + 16 + 2*4 + 16 = 49GB Wasted space for 8GB RAM systems: 1 + 2*8 + 16 + 2*8 + 16 = 65GB If the machine is 4-disk, I use a slightly modified formula: ad4s1a = / = UFS2 = 1GB ad4s1b = swap = (2*RAM) or (2*MaxRAMPossible) ad4s1d = /var = UFS2+SU = 16GB (mandatory: must be >= 2*RAM) ad4s1e = /tmp = UFS2+SU = (2*RAM) ad4s1f = /usr = UFS2+SU = 16GB ad4s1g = /spare = UFS2+SU = ad6 = ZFS raidz1 pool = ad8 = ZFS raidz1 pool = ad10 = ZFS raidz1 pool = The ad4s1g part might seem silly, but I've found it useful. If a filesystem like /var goes awry (usually if bad blocks exist on the disk where that filesystem lies), you can temporarily work around it by rsync'ing as much data over to /spare, then remount /spare as /var to avoid use of the sectors involved in ad4s1d. I've had to do this on two separate occasions. There are network backups for all the boxes, so I don't OCD about it all too much. :-) -- | 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 Jan 22 17:15: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 B20201065697 for ; Fri, 22 Jan 2010 17:15:50 +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 6AC918FC2C for ; Fri, 22 Jan 2010 17:15:50 +0000 (UTC) Received: from list by lo.gmane.org with local (Exim 4.50) id 1NYN6m-0004RD-Nc for freebsd-stable@freebsd.org; Fri, 22 Jan 2010 18:15:44 +0100 Received: from static-195-248-102-183.adsl.hotchilli.net ([195.248.102.183]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 22 Jan 2010 18:15:44 +0100 Received: from david000 by static-195-248-102-183.adsl.hotchilli.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 22 Jan 2010 18:15:44 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-stable@freebsd.org From: David Murray Date: Fri, 22 Jan 2010 17:15:21 +0000 Lines: 35 Message-ID: <4B59DD29.6020607@davidmurray.name> References: <659350866.20100120151602@mail.ru> <4B5703A3.6010507@cyb0rg.org> <20100122131937.GA50007@zeninc.net> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: static-195-248-102-183.adsl.hotchilli.net User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.9.1.7) Gecko/20100111 Thunderbird/3.0.1 In-Reply-To: <20100122131937.GA50007@zeninc.net> Sender: news Subject: Re: IPSec NAT-T in transport 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, 22 Jan 2010 17:15:50 -0000 Hi Yvan, On 10-01-22 Fri 1:19 pm, VANHULLEBUS Yvan wrote: > On Thu, Jan 21, 2010 at 04:36:12PM +0000, David Murray wrote: > >> On 2010-01-20 Wed 1:22 pm, Crest wrote: >> >>> Yes the NAT-T Patch has been integrated into FreeBSD 8.0. >> >> Are we saying that the NAT-T patch is there, but is missing checksum >> re-calculation, so MPD's packets are going to be discarded? > > Yes, see my other mail in this thread. > > >> (FWIW, this seems to be what happens. All the negotiation to set up >> IPSEC SAs happens, but MPD's log never shows a single entry. I hadn't >> got as far as packet dumps when this thread popped up.) > > And if you have a look at system stats, you'll see lots of UDP packets > dropped because of invalid checksums.... Thanks for taking the time to reply. Actually, I find that each attempt to connect causes netstat -s -p udp to show a few UDP packets arriving and being dropped due to no socket, rather than bad checksums, so maybe I've got some other sort of problem with my mpd config, which I'll look into. -- David Murray From owner-freebsd-stable@FreeBSD.ORG Fri Jan 22 17:17: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 B324A106576C for ; Fri, 22 Jan 2010 17:17:55 +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 EA3DE8FC1A for ; Fri, 22 Jan 2010 17:17:53 +0000 (UTC) Received: from omta05.emeryville.ca.mail.comcast.net ([76.96.30.43]) by qmta04.emeryville.ca.mail.comcast.net with comcast id Ydbq1d00E0vp7WLA4hHuYz; Fri, 22 Jan 2010 17:17:54 +0000 Received: from koitsu.dyndns.org ([98.248.46.159]) by omta05.emeryville.ca.mail.comcast.net with comcast id YhHt1d00F3S48mS8RhHtFZ; Fri, 22 Jan 2010 17:17:54 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 696531E3033; Fri, 22 Jan 2010 09:17:52 -0800 (PST) Date: Fri, 22 Jan 2010 09:17:52 -0800 From: Jeremy Chadwick To: freebsd-stable@freebsd.org Message-ID: <20100122171752.GB75020@icarus.home.lan> References: <4B55D9D4.1000008@FreeBSD.org> <4B597CBB.5040900@omnilan.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4B597CBB.5040900@omnilan.de> User-Agent: Mutt/1.5.20 (2009-06-14) Subject: Re: Pack of CAM improvements X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 22 Jan 2010 17:17:55 -0000 On Fri, Jan 22, 2010 at 11:23:55AM +0100, Harald Schmalzbauer wrote: > But I had some questions about zfs raidz states. I think that isn't > a matter of atacam but if I removed one disk, zpool status still > showed me the ada3 device "online". > After reinserting (and proper detection/initialisazion with cam, > ada3 was present again) and zpool clean, it set the devicea as > UNAVAIL sinve I/O errors. > I coudn't get the device into the pool again, no matter what I tried. > Only rebooting the machine helped. Then I could clean and scrub. > > What are the needed steps to provide a reinsterted hard disk to > geom? With the latest patches I don't need to issue any reset/rescan > comman, right? > So it's a zfs problem, right? My mistake in understanding? I can't speak with regards to the new ATA-via-CAM stuff, but with the classic AHCI (meaning ataahci(4)), the procedure I've used reliably for quite some time on Intel ICHx controllers is this: For SATA disks that are purely UFS/UFS2: - Single-user mode might be required here; it varies - Terminate any processes which rely on filesystems on that disk - umount /filesystem - atacontrol detach ataX (where X = channel associated with disk) - Physically remove bad disk - Physically insert new disk - Wait 15 seconds for stuff to settle - atacontrol attach ataX (where X = previous channel detached) - sade / sysinstall / gpart / whatever you like - Restore data... :-) For SATA disks part of a ZFS mirror or raidz[123] pool: - zpool offline - atacontrol detach ataX (where X = channel associated with disk) - Physically remove bad disk - Physically insert new disk - Wait 15 seconds for stuff to settle - atacontrol attach ataX (where X = previous channel detached) - zpool replace - zpool online -- | 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 Jan 22 17:18: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 3824710656A5 for ; Fri, 22 Jan 2010 17:18:23 +0000 (UTC) (envelope-from max@love2party.net) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.187]) by mx1.freebsd.org (Postfix) with ESMTP id B928A8FC16 for ; Fri, 22 Jan 2010 17:18:22 +0000 (UTC) Received: from vampire.homelinux.org (dslb-088-066-045-145.pools.arcor-ip.net [88.66.45.145]) by mrelayeu.kundenserver.de (node=mreu0) with ESMTP (Nemesis) id 0Mefpk-1NA4xh1vEO-00OgaM; Fri, 22 Jan 2010 18:18:21 +0100 Received: (qmail 89242 invoked from network); 22 Jan 2010 17:18:21 -0000 Received: from f8x64.laiers.local (192.168.4.188) by ns1.laiers.local with SMTP; 22 Jan 2010 17:18:21 -0000 From: Max Laier Organization: FreeBSD To: John Baldwin Date: Fri, 22 Jan 2010 18:18:20 +0100 User-Agent: KMail/1.12.4 (FreeBSD/8.0-RELEASE-p2; KDE/4.3.4; amd64; ; ) References: <4B58280C.50602@smeets.im> <4B595D0D.3060904@smeets.im> <201001220920.13458.jhb@freebsd.org> In-Reply-To: <201001220920.13458.jhb@freebsd.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <201001221818.20409.max@love2party.net> X-Provags-ID: V01U2FsdGVkX1/XNn0n0w+4rHPJIWLxYZ1rpcuJ+c2Mno1tx4O CdpZ6sIFknOk022Rka8HimEcPhsQDvkisADO/Ha/iv2XImD2gL JhuOk0J6+XagVsHJAKd4Q== Cc: Bjoern Zeeb , Luigi Rizzo , Florian Smeets , freebsd-stable@freebsd.org Subject: Re: 7.2-STABLE page fault with kernel from 12.01.2010 / crashinfo available X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 22 Jan 2010 17:18:23 -0000 On Friday 22 January 2010 15:20:13 John Baldwin wrote: > On Friday 22 January 2010 3:08:45 am Florian Smeets wrote: ... > > If it really is IPsec traffic then there are no rewrite rules only 10 pf > > pass rules on the enc0 interface and a "scrub in all" rule. > > > > Perhaps it matters that i have these set: > > > > net.enc.out.ipsec_bpf_mask=0x00000001 > > net.enc.out.ipsec_filter_mask=0x00000001 > > net.enc.in.ipsec_bpf_mask=0x00000002 > > net.enc.in.ipsec_filter_mask=0x00000002 > > > > so that i can filter the "encapsulated" traffic. > > I have no idea, I've cc'd mlaier@ (pf) and bz@ (ipsec) to see if they have > any ideas. pf could be the culprit if it were present in the trace, but I don't see any sign of it: On Thursday 21 January 2010 11:10:20 Florian Smeets wrote: > #7 0xc0572e48 in m_copydata (m=0x0, off=0, len=40, cp=0xc23cced8 > "\203??b??\237\f)h?M\220\224?\023?\205K(e??s?\"???k?oQ?~\223\020g\030") > at /usr/src/sys/kern/uipc_mbuf.c:815 > #8 0xc05f8b28 in ip_forward (m=0xc23dc900, srcrt=0) at > /usr/src/sys/netinet/ip_input.c:1307 > #9 0xc05fa30c in ip_input (m=0xc23dc900) at > /usr/src/sys/netinet/ip_input.c:609 > #10 0xc05c83d5 in netisr_dispatch (num=2, m=0xc23dc900) at > /usr/src/sys/net/netisr.c:185 > #11 0xc05bf581 in ether_demux (ifp=0xc20a4800, m=0xc23dc900) at > /usr/src/sys/net/if_ethersubr.c:834 > #12 0xc05bf973 in ether_input (ifp=0xc20a4800, m=0xc23dc900) at > /usr/src/sys/net/if_ethersubr.c:692 > #13 0xc04b8749 in sis_rxeof (sc=0xc2093800) at > /usr/src/sys/dev/sis/if_sis.c:1476 > #14 0xc04b8973 in sis_intr (arg=0xc2093800) at > /usr/src/sys/dev/sis/if_sis.c:1667 > #15 0xc050344b in ithread_loop (arg=0xc20ab410) at > /usr/src/sys/kern/kern_intr.c:1126 > #16 0xc04ffe36 in fork_exit (callout=0xc05032a0 , > arg=0xc20ab410, frame=0xc1f15d38) at /usr/src/sys/kern/kern_fork.c:811 > #17 0xc06d9180 in fork_trampoline () at > /usr/src/sys/i386/i386/exception.s:271 pf does change the byte order in the pfil hook, but changes it back on return to the stack either when returning from the hook or when calling back into the stack. There have been some issues where we missed returns to the stack that would result in this situation, but since pf is not in the trace, this is clearly not the case here. It might indeed be related to enc(4). I remember there have been some issues in IPSEC where it failed to properly copy a packet before modifying it. Maybe this is what is happening. Details escape me at the moment. Can you also make sure that your if_enc.c has revision 174978: http://svn.freebsd.org/viewvc/base/release/7.2.0/sys/net/if_enc.c?view=diff&r1=174977&r2=174978 Regards, -- Max From owner-freebsd-stable@FreeBSD.ORG Fri Jan 22 17:21: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 6651A106566C for ; Fri, 22 Jan 2010 17:21:27 +0000 (UTC) (envelope-from dan@dan.emsphone.com) Received: from email1.allantgroup.com (email1.emsphone.com [199.67.51.115]) by mx1.freebsd.org (Postfix) with ESMTP id 1DB0B8FC08 for ; Fri, 22 Jan 2010 17:21:26 +0000 (UTC) Received: from dan.emsphone.com (dan.emsphone.com [199.67.51.101]) by email1.allantgroup.com (8.14.0/8.14.0) with ESMTP id o0MHLPvY049462 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 22 Jan 2010 11:21:26 -0600 (CST) (envelope-from dan@dan.emsphone.com) Received: from dan.emsphone.com (smmsp@localhost [127.0.0.1]) by dan.emsphone.com (8.14.4/8.14.3) with ESMTP id o0MHLOL5090765 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 22 Jan 2010 11:21:25 -0600 (CST) (envelope-from dan@dan.emsphone.com) Received: (from dan@localhost) by dan.emsphone.com (8.14.4/8.14.3/Submit) id o0MHLOWK090763; Fri, 22 Jan 2010 11:21:24 -0600 (CST) (envelope-from dan) Date: Fri, 22 Jan 2010 11:21:24 -0600 From: Dan Nelson To: Dan Langille Message-ID: <20100122172124.GF50360@dan.emsphone.com> References: <4B58FE1F.5020402@langille.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4B58FE1F.5020402@langille.org> X-OS: FreeBSD 7.2-STABLE User-Agent: Mutt/1.5.20 (2009-06-14) X-Virus-Scanned: clamav-milter 0.95.3 at email1.allantgroup.com X-Virus-Status: Clean X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0.2 (email1.allantgroup.com [199.67.51.78]); Fri, 22 Jan 2010 11:21:26 -0600 (CST) X-Scanned-By: MIMEDefang 2.45 Cc: FreeBSD Stable Subject: Re: do I want ch0 or pass1? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 22 Jan 2010 17:21:27 -0000 In the last episode (Jan 21), Dan Langille said: > Please CC me on replies. > > I'm running into issues with hard-coding some devices (see recent post > titled 'device.hints isn't setting what I want'). > > Associated with this issue is confusion over whether I want to use ch0 > or pass1. I have these devices: > > at scbus1 target 0 lun 0 (ch0,pass1) > at scbus1 target 5 lun 0 (sa1,pass2) > > My understanding: chio(1) will with ch0, whereas mtx(1) will work with > pass1. Is this correct? More information/elaboration will help I'm sure. > > Why do I ask? I can get the tape changer and tape drive hardwired to ch0 > and sa1 respectively. I cannot [yet] do the same with pass1. You can try wiring them down the same way you wire down regular devices, but if they're created sequentially in probe order, that won't work. Ideally, mtx should use cam_open_spec_device() which, when given a device name, will automatically open the matching pass device. -- Dan Nelson dnelson@allantgroup.com From owner-freebsd-stable@FreeBSD.ORG Fri Jan 22 17:49: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 9CEE21065672; Fri, 22 Jan 2010 17:49:49 +0000 (UTC) (envelope-from dan.naumov@gmail.com) Received: from mail-yx0-f171.google.com (mail-yx0-f171.google.com [209.85.210.171]) by mx1.freebsd.org (Postfix) with ESMTP id 4B6F08FC1A; Fri, 22 Jan 2010 17:49:48 +0000 (UTC) Received: by yxe1 with SMTP id 1so1160300yxe.3 for ; Fri, 22 Jan 2010 09:49:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type; bh=cXshbdZTZMZ0nUSzAPUqMBBcK+gyfjE/cbi9yTrIrvk=; b=TYrmIrOFwdPVT9u8T8/jBea2hEg9hqKUR2K7R7q2eq65xYDW3nbtGNRe7MLAEU3PZj bWN9XheqMYZBfkL/Muy1kG0OvEDXnEbmp2OsDtzi2qqO49PZ3XMlPd3DfdJzxwFsS5nk tCyydDaE4M1wQKqJ3VmKI2gjXuSpqlFBuQ2Xo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=ceOOY4Ulxh4R8JA6go5BJQUwcYq1M/b+HKNirXrb++i+X0wXqZHwJj4qChDODzMb4X YoQH71tUT0TcND1JcnFdWQSzCe+Ho6/CPlEwjfYn4L9cJVPby8gHmXMQXucGxX3dEd0g OkiaW44R+6ypzpClynnyTVF81Y1ii/sSNpdCQ= MIME-Version: 1.0 Received: by 10.101.12.6 with SMTP id p6mr4215154ani.248.1264182586100; Fri, 22 Jan 2010 09:49:46 -0800 (PST) Date: Fri, 22 Jan 2010 19:49:46 +0200 Message-ID: From: Dan Naumov To: FreeBSD-STABLE Mailing List , freebsd-hackers@freebsd.org, freebsd-questions@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Cc: Subject: posting coding bounties, appropriate money amounts? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 22 Jan 2010 17:49:49 -0000 Hello I am curious about posting some coding bounties, my current interest revolves around improving the ZVOL functionality in FreeBSD: fixing the known ZVOL SWAP reliability/stability problems as well as making ZVOLs work as a dumpon device (as is already the case in OpenSolaris) for crash dumps. I am a private individual and not some huge Fortune 100 and while I am not exactly rich, I am willing to put some of my personal money towards this. I am curious though, what would be the best way to approach this: directly approaching committer(s) with the know-how-and-why of the areas involved or through the FreeBSD Foundation? And how would one go about calculating the appropriate amount of money for such a thing? Thanks. - Sincerely, Dan Naumov From owner-freebsd-stable@FreeBSD.ORG Fri Jan 22 18:01: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 B2F3F106566C for ; Fri, 22 Jan 2010 18:01:10 +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 400C28FC33 for ; Fri, 22 Jan 2010 18:01:10 +0000 (UTC) Received: from list by lo.gmane.org with local (Exim 4.50) id 1NYNog-0000lA-3k for freebsd-stable@freebsd.org; Fri, 22 Jan 2010 19:01:06 +0100 Received: from static-195-248-102-183.adsl.hotchilli.net ([195.248.102.183]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 22 Jan 2010 19:01:06 +0100 Received: from david000 by static-195-248-102-183.adsl.hotchilli.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 22 Jan 2010 19:01:06 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-stable@freebsd.org From: David Murray Date: Fri, 22 Jan 2010 18:00:45 +0000 Lines: 45 Message-ID: <4B59E7CD.10604@davidmurray.name> References: <659350866.20100120151602@mail.ru> <4B5703A3.6010507@cyb0rg.org> <20100122131937.GA50007@zeninc.net> <4B59DD29.6020607@davidmurray.name> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: static-195-248-102-183.adsl.hotchilli.net User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.9.1.7) Gecko/20100111 Thunderbird/3.0.1 In-Reply-To: <4B59DD29.6020607@davidmurray.name> Sender: news Subject: Re: IPSec NAT-T in transport 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, 22 Jan 2010 18:01:10 -0000 Hi Yvan, On 10-01-22 Fri 5:15 pm, David Murray wrote: > On 10-01-22 Fri 1:19 pm, VANHULLEBUS Yvan wrote: > >> On Thu, Jan 21, 2010 at 04:36:12PM +0000, David Murray wrote: >> >>> On 2010-01-20 Wed 1:22 pm, Crest wrote: >>> >>>> Yes the NAT-T Patch has been integrated into FreeBSD 8.0. >>> >>> Are we saying that the NAT-T patch is there, but is missing checksum >>> re-calculation, so MPD's packets are going to be discarded? >> >> Yes, see my other mail in this thread. >> >> >>> (FWIW, this seems to be what happens. All the negotiation to set up >>> IPSEC SAs happens, but MPD's log never shows a single entry. I >>> hadn't got as far as packet dumps when this thread popped up.) >> >> And if you have a look at system stats, you'll see lots of UDP >> packets dropped because of invalid checksums.... > > Actually, I find that each attempt to connect causes netstat -s -p udp > to show a few UDP packets arriving and being dropped due to no socket, > rather than bad checksums, so maybe I've got some other sort of > problem with my mpd config, which I'll look into. Ah, yes, I'd forgotten that my external IP address had changed since I last tried this, so I needed to restart racoon and ipsec. So now, like you say, I see UDP packets dropped due to bad checksums. I'll have a look at the NAT-T RFQs just in case support for NAT-OA payloads is something I could help with, but I suspect it'll need an in-depth knowledge of the IP stack. Thanks! -- David Murray From owner-freebsd-stable@FreeBSD.ORG Fri Jan 22 18:28: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 1EC62106568B for ; Fri, 22 Jan 2010 18:28:37 +0000 (UTC) (envelope-from korvus@comcast.net) Received: from mx04.pub.collaborativefusion.com (mx04.pub.collaborativefusion.com [206.210.72.84]) by mx1.freebsd.org (Postfix) with ESMTP id C92B28FC16 for ; Fri, 22 Jan 2010 18:28:36 +0000 (UTC) Received: from reflector.ws.pitbpa0.priv.collaborativefusion.com ([206.210.89.202]) by mx04.pub.collaborativefusion.com (StrongMail Enterprise 4.1.1.4(4.1.1.4-47689)); Fri, 22 Jan 2010 13:54:51 -0500 X-VirtualServerGroup: Default X-MailingID: 00000::00000::00000::00000::::24 X-SMHeaderMap: mid="X-MailingID" X-Destination-ID: freebsd-stable@freebsd.org X-SMFBL: ZnJlZWJzZC1zdGFibGVAZnJlZWJzZC5vcmc= Message-ID: <4B59EE52.8050400@comcast.net> Date: Fri, 22 Jan 2010 13:28:34 -0500 From: Steve Polyack User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.1.5) Gecko/20100114 Thunderbird/3.0 MIME-Version: 1.0 To: Freddie Cash References: <4B55D9D4.1000008@FreeBSD.org> <4B597CBB.5040900@omnilan.de> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: FreeBSD-Current , FreeBSD Stable Subject: Re: Pack of CAM improvements X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 22 Jan 2010 18:28:37 -0000 On 01/22/10 11:48, Freddie Cash wrote: > On Fri, Jan 22, 2010 at 2:23 AM, Harald Schmalzbauer< > h.schmalzbauer@omnilan.de> wrote: > > >> Alexander Motin schrieb am 19.01.2010 17:12 (localtime): >> ... >> >> Patch can be found here: >> >>> http://people.freebsd.org/~mav/cam-ata.20100119.patch >>> >>> Feedback as always welcome. >>> >>> >> Again, thanks a lot for your ongoing great work! >> The patch doesn't cleanly apply with vpo, but I don't use vpo so I didn't >> care. >> Otherwise I couldn't find any problems. >> The system detects reinserted SATA drives on ICH9 fine. >> >> This was tested on a zfs backup server which went to the backbone >> yesterday, so I can't physically remove any devices any more for testing... >> >> But I had some questions about zfs raidz states. I think that isn't a >> matter of atacam but if I removed one disk, zpool status still showed me the >> ada3 device "online". >> After reinserting (and proper detection/initialisazion with cam, ada3 was >> present again) and zpool clean, it set the devicea as UNAVAIL sinve I/O >> errors. >> I coudn't get the device into the pool again, no matter what I tried. >> Only rebooting the machine helped. Then I could clean and scrub. >> >> What are the needed steps to provide a reinsterted hard disk to geom? With >> the latest patches I don't need to issue any reset/rescan comman, right? >> So it's a zfs problem, right? My mistake in understanding? >> >> In my testing of pulling drives at random (using a 3Ware 9550SXU or 9650SE >> > controller), you have to "zpool offline " while the drive is > unplugged, before you can re-insert the same disk or a different disk. > Without doing that step, it's very hard to re-insert the same disk, or > replace it with a new one, without rebooting. > > Took me a couple of reboots and drive replacements before I figured that one > out. :) > > I think you can do it without the 'zpool offline ' command; I may be wrong, but I believe you can use 'zpool replace' to accomplish what you're trying to do. i.e. if you have a bad drive ada3, and take it out, then replace it with a new disk, you can issue a 'zpool replace /dev/ada3 /dev/ada3' (yes, the same device is specified twice). ZFS should recognize that its a different disk and/or that it is lacking ZFS metadata and begin to resilver the pool onto the new device. If you watch 'zfs status' in the process you'll see something like: raidz1 DEGRADED 0 0 0 label/ada4 ONLINE 0 0 0 12.4M resilvered label/ada5 ONLINE 0 0 0 12.4M resilvered label/ada6 ONLINE 0 0 0 12.3M resilvered replacing DEGRADED 0 0 0 label/ada3/old UNAVAIL 0 595 0 cannot open label/ada3 ONLINE 0 0 0 9.74G resilvered Try it out and let me know if it works for you. From owner-freebsd-stable@FreeBSD.ORG Fri Jan 22 18:29: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 66456106568B for ; Fri, 22 Jan 2010 18:29:16 +0000 (UTC) (envelope-from traveling08@cox.net) Received: from fed1rmmtao107.cox.net (fed1rmmtao107.cox.net [68.230.241.39]) by mx1.freebsd.org (Postfix) with ESMTP id 176418FC17 for ; Fri, 22 Jan 2010 18:29:15 +0000 (UTC) Received: from fed1rmimpo02.cox.net ([70.169.32.72]) by fed1rmmtao107.cox.net (InterMail vM.8.00.01.00 201-2244-105-20090324) with ESMTP id <20100122182916.XACQ20722.fed1rmmtao107.cox.net@fed1rmimpo02.cox.net>; Fri, 22 Jan 2010 13:29:16 -0500 Received: from vaio ([72.220.91.251]) by fed1rmimpo02.cox.net with bizsmtp id YiVF1d00C5RPd3404iVFVh; Fri, 22 Jan 2010 13:29:15 -0500 X-VR-Score: -200.00 X-Authority-Analysis: v=1.1 cv=zS9SgV63hfBKgCfMNmcWTXDxxMKGbBeTgNVRdCpsi3s= c=1 sm=1 a=aQKPT3jRvjwCBEVvbLbxkw==:17 a=MBIA0dz7AAAA:8 a=6I5d2MoRAAAA:8 a=7Cpl6D5JuiCJhHn9iYQA:9 a=Av03RmF8woO2n40fOeEA:7 a=8jyc3JAzRcv8tUlRnOgGXMWmI9EA:4 a=so-IRZCK-goA:10 a=9ZX6gfnTnSoA:10 a=aQKPT3jRvjwCBEVvbLbxkw==:117 X-CM-Score: 0.00 Date: Fri, 22 Jan 2010 10:29:10 -0800 From: Robert To: Dan Langille Message-ID: <20100122102910.4f683f74@vaio> In-Reply-To: <4B58FE1F.5020402@langille.org> References: <4B58FE1F.5020402@langille.org> X-Mailer: Claws Mail 3.7.3 (GTK+ 2.18.6; i386-portbld-freebsd8.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: FreeBSD Stable Subject: Re: do I want ch0 or pass1? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 22 Jan 2010 18:29:16 -0000 On Thu, 21 Jan 2010 20:23:43 -0500 Dan Langille wrote: > Please CC me on replies. > > I'm running into issues with hard-coding some devices (see recent post > titled 'device.hints isn't setting what I want'). > > Associated with this issue is confusion over whether I want to use ch0 > or pass1. I have these devices: > > at scbus1 target 0 lun 0 > (ch0,pass1) at scbus1 target 5 lun > 0 (sa1,pass2) > > My understanding: chio(1) will with ch0, whereas mtx(1) will work with > pass1. Is this correct? More information/elaboration will help I'm > sure. > > Why do I ask? I can get the tape changer and tape drive hardwired to > ch0 and sa1 respectively. I cannot [yet] do the same with pass1. > > Thanks folks. Hi Dan You might take a look at this thread. It looks like what you want to do. http://lists.freebsd.org/pipermail/freebsd-questions/2007-April/146738.html HTH Robert From owner-freebsd-stable@FreeBSD.ORG Fri Jan 22 18:34: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 0A0C51065670; Fri, 22 Jan 2010 18:34:34 +0000 (UTC) (envelope-from fjwcash@gmail.com) Received: from mail-iw0-f177.google.com (mail-iw0-f177.google.com [209.85.223.177]) by mx1.freebsd.org (Postfix) with ESMTP id B4DC68FC1A; Fri, 22 Jan 2010 18:34:33 +0000 (UTC) Received: by iwn7 with SMTP id 7so1197277iwn.7 for ; Fri, 22 Jan 2010 10:34:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type; bh=4yu3IosZGCCIgPv3rz0snaGgWWkc5VLfzSxNfuW1/5k=; b=QySIfm0zmq0tbjSUrchnCGWMoUI2EymH6lcgxp8H9HRVIFgNBvMHGBDl647JseJMoj kWcEIKup+glZ4QGKbak8nuDlVw8L/OBvvsoJNcM8o7/0m8WHwy3BO33VI8Dr09j2p42X irWPvKB/BSPi+VPjY7Z+GJVrIYZwjUCJGHBNY= 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=A5tGzjCBQkkJhbAOiwYgAfcsEtXjEDUMYo/fqqdU0m7ls1HOiYz3W+sCNk3cWmJi1s yhdb7za4zH/I7SpDcmaKiYW1kYOE4M1BpM+yGmtJMrIVKOwGKXlvYwt9+rTO0IzYqGsQ Jas9IVWZDn7cbEnwhox3WiuRVZJsZAvtpntzs= MIME-Version: 1.0 Received: by 10.231.170.14 with SMTP id b14mr5392347ibz.26.1264185271378; Fri, 22 Jan 2010 10:34:31 -0800 (PST) In-Reply-To: <4B59EE52.8050400@comcast.net> References: <4B55D9D4.1000008@FreeBSD.org> <4B597CBB.5040900@omnilan.de> <4B59EE52.8050400@comcast.net> Date: Fri, 22 Jan 2010 10:34:31 -0800 Message-ID: From: Freddie Cash To: FreeBSD-Current , FreeBSD Stable Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Subject: Re: Pack of CAM improvements X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 22 Jan 2010 18:34:34 -0000 On Fri, Jan 22, 2010 at 10:28 AM, Steve Polyack wrote: > On 01/22/10 11:48, Freddie Cash wrote: > >> In my testing of pulling drives at random (using a 3Ware 9550SXU or 9650SE >>> >>> >> controller), you have to "zpool offline " while the drive >> is >> unplugged, before you can re-insert the same disk or a different disk. >> Without doing that step, it's very hard to re-insert the same disk, or >> replace it with a new one, without rebooting. >> >> Took me a couple of reboots and drive replacements before I figured that >> one >> out. :) >> >> > I think you can do it without the 'zpool offline ' command; > I may be wrong, but I believe you can use 'zpool replace' to accomplish > what you're trying to do. i.e. if you have a bad drive ada3, and take it > out, then replace it with a new disk, you can issue a 'zpool replace > /dev/ada3 /dev/ada3' (yes, the same device is specified twice). ZFS should > recognize that its a different disk and/or that it is lacking ZFS metadata > and begin to resilver the pool onto the new device. If you watch 'zfs > status' in the process you'll see something like: > > Yes, that does work ... but it's not nearly as reliable as doing the offline first. If you do things in the right order, drives can be replaced and resilvering started within minutes (our process takes a little less than 5 minutes, but the bulk of that is removing the dead drive from the caddy, and adding the new drive to the caddy). Do things in the wrong order, and it can take 15 minutes or more, and may require rebooting the system (as our manager discovered trying to replace a drive while I was away). :) Just because there are shortcuts available ... doesn't mean you should always take them. :D -- Freddie Cash fjwcash@gmail.com From owner-freebsd-stable@FreeBSD.ORG Fri Jan 22 18:49: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 DE009106568F; Fri, 22 Jan 2010 18:49:21 +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 9901C8FC18; Fri, 22 Jan 2010 18:49:21 +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 2BE6B46B23; Fri, 22 Jan 2010 13:49:21 -0500 (EST) Received: from jhbbsd.localnet (smtp.hudson-trading.com [209.249.190.9]) by bigwig.baldwin.cx (Postfix) with ESMTPA id 267BE8A026; Fri, 22 Jan 2010 13:49:20 -0500 (EST) From: John Baldwin To: Max Laier Date: Fri, 22 Jan 2010 13:49:19 -0500 User-Agent: KMail/1.12.1 (FreeBSD/7.2-CBSD-20091231; KDE/4.3.1; amd64; ; ) References: <4B58280C.50602@smeets.im> <201001220920.13458.jhb@freebsd.org> <201001221818.20409.max@love2party.net> In-Reply-To: <201001221818.20409.max@love2party.net> MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <201001221349.19810.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (bigwig.baldwin.cx); Fri, 22 Jan 2010 13:49:20 -0500 (EST) X-Virus-Scanned: clamav-milter 0.95.1 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.6 required=4.2 tests=AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on bigwig.baldwin.cx Cc: Bjoern Zeeb , Luigi Rizzo , Florian Smeets , freebsd-stable@freebsd.org Subject: Re: 7.2-STABLE page fault with kernel from 12.01.2010 / crashinfo available X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 22 Jan 2010 18:49:22 -0000 On Friday 22 January 2010 12:18:20 pm Max Laier wrote: > On Friday 22 January 2010 15:20:13 John Baldwin wrote: > > On Friday 22 January 2010 3:08:45 am Florian Smeets wrote: > ... > > > If it really is IPsec traffic then there are no rewrite rules only 10 pf > > > pass rules on the enc0 interface and a "scrub in all" rule. > > > > > > Perhaps it matters that i have these set: > > > > > > net.enc.out.ipsec_bpf_mask=0x00000001 > > > net.enc.out.ipsec_filter_mask=0x00000001 > > > net.enc.in.ipsec_bpf_mask=0x00000002 > > > net.enc.in.ipsec_filter_mask=0x00000002 > > > > > > so that i can filter the "encapsulated" traffic. > > > > I have no idea, I've cc'd mlaier@ (pf) and bz@ (ipsec) to see if they have > > any ideas. > > pf could be the culprit if it were present in the trace, but I don't see any > sign of it: > > On Thursday 21 January 2010 11:10:20 Florian Smeets wrote: > > #7 0xc0572e48 in m_copydata (m=0x0, off=0, len=40, cp=0xc23cced8 > > "\203??b??\237\f)h?M\220\224?\023?\205K(e??s?\"???k?oQ?~\223\020g\030") > > at /usr/src/sys/kern/uipc_mbuf.c:815 > > #8 0xc05f8b28 in ip_forward (m=0xc23dc900, srcrt=0) at > > /usr/src/sys/netinet/ip_input.c:1307 > > #9 0xc05fa30c in ip_input (m=0xc23dc900) at > > /usr/src/sys/netinet/ip_input.c:609 > > #10 0xc05c83d5 in netisr_dispatch (num=2, m=0xc23dc900) at > > /usr/src/sys/net/netisr.c:185 > > #11 0xc05bf581 in ether_demux (ifp=0xc20a4800, m=0xc23dc900) at > > /usr/src/sys/net/if_ethersubr.c:834 > > #12 0xc05bf973 in ether_input (ifp=0xc20a4800, m=0xc23dc900) at > > /usr/src/sys/net/if_ethersubr.c:692 > > #13 0xc04b8749 in sis_rxeof (sc=0xc2093800) at > > /usr/src/sys/dev/sis/if_sis.c:1476 > > #14 0xc04b8973 in sis_intr (arg=0xc2093800) at > > /usr/src/sys/dev/sis/if_sis.c:1667 > > #15 0xc050344b in ithread_loop (arg=0xc20ab410) at > > /usr/src/sys/kern/kern_intr.c:1126 > > #16 0xc04ffe36 in fork_exit (callout=0xc05032a0 , > > arg=0xc20ab410, frame=0xc1f15d38) at /usr/src/sys/kern/kern_fork.c:811 > > #17 0xc06d9180 in fork_trampoline () at > > /usr/src/sys/i386/i386/exception.s:271 > > pf does change the byte order in the pfil hook, but changes it back on return > to the stack either when returning from the hook or when calling back into the > stack. There have been some issues where we missed returns to the stack that > would result in this situation, but since pf is not in the trace, this is > clearly not the case here. That isn't necessarily the case. ip_input() invokes the PFIL hooks which then return after possibly modifying the packet. The (possibly modified) packet is then passed to ip_forward() from ip_input(). If the PFIL hook modified the packet and returned ip_len in network byte order then it would cause this breakage without showing up in the stack trace. -- John Baldwin From owner-freebsd-stable@FreeBSD.ORG Fri Jan 22 19:27: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 D75D91065679; Fri, 22 Jan 2010 19:27:16 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from esa-annu.mail.uoguelph.ca (esa-annu.mail.uoguelph.ca [131.104.91.36]) by mx1.freebsd.org (Postfix) with ESMTP id 705A38FC1D; Fri, 22 Jan 2010 19:27:16 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAA+LWUuDaFvJ/2dsb2JhbADZL4IzggkE X-IronPort-AV: E=Sophos;i="4.49,325,1262581200"; d="scan'208";a="62589991" Received: from ganges.cs.uoguelph.ca ([131.104.91.201]) by esa-annu-pri.mail.uoguelph.ca with ESMTP; 22 Jan 2010 14:27:14 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by ganges.cs.uoguelph.ca (Postfix) with ESMTP id A1DD8FB808E; Fri, 22 Jan 2010 14:27:14 -0500 (EST) X-Virus-Scanned: amavisd-new at ganges.cs.uoguelph.ca Received: from ganges.cs.uoguelph.ca ([127.0.0.1]) by localhost (ganges.cs.uoguelph.ca [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZntHnpHgZ2wX; Fri, 22 Jan 2010 14:27:13 -0500 (EST) Received: from muncher.cs.uoguelph.ca (muncher.cs.uoguelph.ca [131.104.91.102]) by ganges.cs.uoguelph.ca (Postfix) with ESMTP id 5C806FB8063; Fri, 22 Jan 2010 14:27:13 -0500 (EST) Received: from localhost (rmacklem@localhost) by muncher.cs.uoguelph.ca (8.11.7p3+Sun/8.11.6) with ESMTP id o0MJbmD06729; Fri, 22 Jan 2010 14:37:48 -0500 (EST) X-Authentication-Warning: muncher.cs.uoguelph.ca: rmacklem owned process doing -bs Date: Fri, 22 Jan 2010 14:37:48 -0500 (EST) From: Rick Macklem X-X-Sender: rmacklem@muncher.cs.uoguelph.ca To: Mikolaj Golub In-Reply-To: <86vdeuuo2y.fsf@zhuzha.ua1> Message-ID: References: <86ocl272mb.fsf@kopusha.onet> <86tyuqnz9x.fsf@zhuzha.ua1> <86zl4awmon.fsf@zhuzha.ua1> <86vdeywmha.fsf@zhuzha.ua1> <86vdeuuo2y.fsf@zhuzha.ua1> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-fs@FreeBSD.org, freebsd-stable@FreeBSD.org Subject: Re: FreeBSD NFS client/Linux NFS server issue X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 22 Jan 2010 19:27:16 -0000 On Fri, 22 Jan 2010, Mikolaj Golub wrote: > > We have nonempty nm_bufq, nm_bufqiods = 1, but actually there is no nfsiod > thread run for this mount, which is wrong -- nm_bufq will not be emptied until > some other process starts writing to the nfsmount and starts nfsiod thread for > this mount. > > Reviewing the code how it could happen I see the following path. Could someone > confirm or disprove me? > > in nfs_bio.c:nfs_asyncio() we have: > > 1363 mtx_lock(&nfs_iod_mtx); > ... > 1374 /* > 1375 * Find a free iod to process this request. > 1376 */ > 1377 for (iod = 0; iod < nfs_numasync; iod++) > 1378 if (nfs_iodwant[iod]) { > 1379 gotiod = TRUE; > 1380 break; > 1381 } > 1382 > 1383 /* > 1384 * Try to create one if none are free. > 1385 */ > 1386 if (!gotiod) { > 1387 iod = nfs_nfsiodnew(); > 1388 if (iod != -1) > 1389 gotiod = TRUE; > 1390 } > > Let's consider situation when new nfsiod is created. > > nfs_nfsiod.c:nfs_nfsiodnew() before creating nfssvc_iod thread unlocks nfs_iod_mtx: > > 179 mtx_unlock(&nfs_iod_mtx); > 180 error = kthread_create(nfssvc_iod, nfs_asyncdaemon + i, NULL, RFHIGHPID, > 181 0, "nfsiod %d", newiod); > 182 mtx_lock(&nfs_iod_mtx); > > > And nfs_nfsiod.c:nfssvc_iod() do the followin: > > 226 mtx_lock(&nfs_iod_mtx); > ... > 238 nfs_iodwant[myiod] = curthread->td_proc; > 239 nfs_iodmount[myiod] = NULL; > ... > 244 error = msleep(&nfs_iodwant[myiod], &nfs_iod_mtx, PWAIT | PCATCH, > 245 "-", timo); > > Let's at this moment another nfs_asyncio() request for another nfsmount has > happened and this thread has locked nfs_iod_mtx. Then this thread will found > nfs_iodwant[iod] in "for" loop and will use it. When the first thread actually > has returned from nfs_nfsiodnew() it will insert buffer to nmp->nm_bufq but > nfsiod will process other nmp. > Ok, good catch, I think you've found the problem (or at least a race that might have caused it). > It looks like the fix for this situation would be to check nfs_iodwant[iod] > after nfs_nfsiodnew(): > > --- nfs_bio.c.orig 2010-01-22 15:38:02.000000000 +0000 > +++ nfs_bio.c 2010-01-22 15:39:58.000000000 +0000 > @@ -1385,7 +1385,7 @@ again: > */ > if (!gotiod) { > iod = nfs_nfsiodnew(); > - if (iod != -1) > + if ((iod != -1) && (nfs_iodwant[iod] == NULL)) > gotiod = TRUE; > } > Unfortunately, I don't think the above fixes the problem. If another thread that called nfs_asyncio() has "stolen" the this "iod", it will have set nfs_iodwant[iod] == NULL (set non-NULL at #238) and it will remain NULL until the other thread is done with it. If you instead make it: if (iod != -1 && nfs_iodwant[iod] != NULL) gotiod = TRUE; then I think it fixes your scenario above, but will break for the case where the mtx_lock(&nfs_iod_mtx) call in nfs_nfsnewiod() (#182) wins out over the one near the beginning of nfssvc_iod() (#226), since in that case, nfs_iodwant[iod] will still be NULL because it hasn't yet been set by nfssvc_iod() (#238). There should probably be some sort of 3 way handshake between the code in nfs_asyncio() after calling nfs_nfsnewiod() and the code near the beginning of nfssvc_iod(), but I think the following somewhat cheesy fix might do the trick: if (!gotiod) { iod = nfs_nfsiodnew(); if (iod != -1) { if (nfs_iodwant[iod] == NULL) { /* * Either another thread has acquired this * iod or I acquired the nfs_iod_mtx mutex * before the new iod thread did in * nfssvc_iod(). To be safe, go back and * try again after allowing another thread * to acquire the nfs_iod_mtx mutex. */ mtx_unlock(&nfs_iod_mtx); /* * So long as mtx_lock() implements some * sort of fairness, nfssvc_iod() should * get nfs_iod_mtx here and set * nfs_iodwant[iod] != NULL for the case * where the iod has not been "stolen" by * another thread for a different mount * point. */ mtx_lock(&nfs_iod_mtx); goto again; } gotiod = TRUE; } } Does anyone else have a better solution? (Mikolaj, could you by any chance test this? You can test yours, but I think it breaks.) rick From owner-freebsd-stable@FreeBSD.ORG Fri Jan 22 19:55: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 4DDEF10656A8 for ; Fri, 22 Jan 2010 19:55:48 +0000 (UTC) (envelope-from max@love2party.net) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.171]) by mx1.freebsd.org (Postfix) with ESMTP id EB24D8FC25 for ; Fri, 22 Jan 2010 19:55:47 +0000 (UTC) Received: from vampire.homelinux.org (dslb-088-066-045-145.pools.arcor-ip.net [88.66.45.145]) by mrelayeu.kundenserver.de (node=mreu1) with ESMTP (Nemesis) id 0MXCaX-1NMiIB1tRN-00WKGx; Fri, 22 Jan 2010 20:55:46 +0100 Received: (qmail 91371 invoked from network); 22 Jan 2010 19:55:46 -0000 Received: from f8x64.laiers.local (192.168.4.188) by mx.laiers.local with SMTP; 22 Jan 2010 19:55:46 -0000 From: Max Laier Organization: FreeBSD To: John Baldwin Date: Fri, 22 Jan 2010 20:55:45 +0100 User-Agent: KMail/1.12.4 (FreeBSD/8.0-RELEASE-p2; KDE/4.3.4; amd64; ; ) References: <4B58280C.50602@smeets.im> <201001221818.20409.max@love2party.net> <201001221349.19810.jhb@freebsd.org> In-Reply-To: <201001221349.19810.jhb@freebsd.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <201001222055.45980.max@love2party.net> X-Provags-ID: V01U2FsdGVkX1/Iwmy3qcgcq0ldKb3nriEo3vXNyYhYOyMPFYD Wf6eWbh/w32KItgPRqR2u+RWzV0SAT80Ya+jA3OzdNui4uQYvb 8uGdrsGt/YIzrRCGOLTtw== Cc: Bjoern Zeeb , Luigi Rizzo , Florian Smeets , freebsd-stable@freebsd.org Subject: Re: 7.2-STABLE page fault with kernel from 12.01.2010 / crashinfo available X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 22 Jan 2010 19:55:48 -0000 On Friday 22 January 2010 19:49:19 John Baldwin wrote: > On Friday 22 January 2010 12:18:20 pm Max Laier wrote: > > On Friday 22 January 2010 15:20:13 John Baldwin wrote: > > > On Friday 22 January 2010 3:08:45 am Florian Smeets wrote: > > > > ... > > > > > > If it really is IPsec traffic then there are no rewrite rules only 10 > > > > pf pass rules on the enc0 interface and a "scrub in all" rule. > > > > > > > > Perhaps it matters that i have these set: > > > > > > > > net.enc.out.ipsec_bpf_mask=0x00000001 > > > > net.enc.out.ipsec_filter_mask=0x00000001 > > > > net.enc.in.ipsec_bpf_mask=0x00000002 > > > > net.enc.in.ipsec_filter_mask=0x00000002 > > > > > > > > so that i can filter the "encapsulated" traffic. > > > > > > I have no idea, I've cc'd mlaier@ (pf) and bz@ (ipsec) to see if they > > > have any ideas. > > > > pf could be the culprit if it were present in the trace, but I don't see > > any sign of it: > > > > On Thursday 21 January 2010 11:10:20 Florian Smeets wrote: > > > #7 0xc0572e48 in m_copydata (m=0x0, off=0, len=40, cp=0xc23cced8 > > > "\203??b??\237\f)h?M\220\224?\023?\205K(e??s?\"???k?oQ?~\223\020g\030") > > > at /usr/src/sys/kern/uipc_mbuf.c:815 > > > #8 0xc05f8b28 in ip_forward (m=0xc23dc900, srcrt=0) at > > > /usr/src/sys/netinet/ip_input.c:1307 > > > #9 0xc05fa30c in ip_input (m=0xc23dc900) at > > > /usr/src/sys/netinet/ip_input.c:609 > > > #10 0xc05c83d5 in netisr_dispatch (num=2, m=0xc23dc900) at > > > /usr/src/sys/net/netisr.c:185 > > > #11 0xc05bf581 in ether_demux (ifp=0xc20a4800, m=0xc23dc900) at > > > /usr/src/sys/net/if_ethersubr.c:834 > > > #12 0xc05bf973 in ether_input (ifp=0xc20a4800, m=0xc23dc900) at > > > /usr/src/sys/net/if_ethersubr.c:692 > > > #13 0xc04b8749 in sis_rxeof (sc=0xc2093800) at > > > /usr/src/sys/dev/sis/if_sis.c:1476 > > > #14 0xc04b8973 in sis_intr (arg=0xc2093800) at > > > /usr/src/sys/dev/sis/if_sis.c:1667 > > > #15 0xc050344b in ithread_loop (arg=0xc20ab410) at > > > /usr/src/sys/kern/kern_intr.c:1126 > > > #16 0xc04ffe36 in fork_exit (callout=0xc05032a0 , > > > arg=0xc20ab410, frame=0xc1f15d38) at /usr/src/sys/kern/kern_fork.c:811 > > > #17 0xc06d9180 in fork_trampoline () at > > > /usr/src/sys/i386/i386/exception.s:271 > > > > pf does change the byte order in the pfil hook, but changes it back on > > return to the stack either when returning from the hook or when calling > > back into the stack. There have been some issues where we missed returns > > to the stack that would result in this situation, but since pf is not in > > the trace, this is clearly not the case here. > > That isn't necessarily the case. ip_input() invokes the PFIL hooks which > then return after possibly modifying the packet. The (possibly modified) > packet is then passed to ip_forward() from ip_input(). If the PFIL hook > modified the packet and returned ip_len in network byte order then it would > cause this breakage without showing up in the stack trace. What I meant to say was: if we return from the pfil hook we either report error (and/or consume the mbuf) or switch back to network byte order: http://fxr.watson.org/fxr/source/contrib/pf/net/pf_ioctl.c?v=FREEBSD72#L3655 While I can't completely rule out that there is a double flip happening in some obscure path through pf, I very much doubt this is what is going on (or there would be more reports and it would happen straight away, not only after passing some data). A quick search through the sources also didn't turn up any red flags. All byte order operations inside pf are either temporary or performed on a properly copied packet that is send back through the stack (icmp error, tcp packet, ...). Depending on how easily this can be reproduced, my money is on modifying a shared mbuf (possibly inside enc(4)). Regards, -- Max From owner-freebsd-stable@FreeBSD.ORG Fri Jan 22 20:37: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 1C5651065670; Fri, 22 Jan 2010 20:37:54 +0000 (UTC) (envelope-from to.my.trociny@gmail.com) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.152]) by mx1.freebsd.org (Postfix) with ESMTP id 7658D8FC0C; Fri, 22 Jan 2010 20:37:53 +0000 (UTC) Received: by fg-out-1718.google.com with SMTP id 16so146326fgg.13 for ; Fri, 22 Jan 2010 12:37:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:to:cc:subject:references :organization:from:date:in-reply-to:message-id:user-agent :mime-version:content-type; bh=9bup00Tj3jlLs7R1jBd1+fha+HAjNnLMHba4LLKaQOo=; b=c71xc628ay2UbQsnNl1saJQal006lIYguiU71hIgIjqtaYa7iYALBLCCXAxmkZDWGr 8saI09bPD0MR16Axxgd06Guk5G5MyrfmpWJeqhbZWrJqiPo6GJR+Xh0fLMGiZ2kQmuTt W6O6hZDlwvz4QmQOvBhu6a1+8fwsBtp2pQjP8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=to:cc:subject:references:organization:from:date:in-reply-to :message-id:user-agent:mime-version:content-type; b=H7YV26eeHmGdectzYBZ1m8wsrNbOEY1XyvpFuWPn2YApDKTAahYEwukuWU8oDdlp1q JlMte3n8cYHp1OIufDfvtKODgm4MCcfQxt6UCLUqQWqADifiBA4jpalb9FWdSoq6DAMV YNzY2d0iGzEgA2aGVviUc3RFgzvr2KFIV92kE= Received: by 10.103.50.15 with SMTP id c15mr1840004muk.35.1264192672286; Fri, 22 Jan 2010 12:37:52 -0800 (PST) Received: from localhost ([95.69.162.7]) by mx.google.com with ESMTPS id e10sm10542198muf.26.2010.01.22.12.37.50 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 22 Jan 2010 12:37:51 -0800 (PST) To: Rick Macklem References: <86ocl272mb.fsf@kopusha.onet> <86tyuqnz9x.fsf@zhuzha.ua1> <86zl4awmon.fsf@zhuzha.ua1> <86vdeywmha.fsf@zhuzha.ua1> <86vdeuuo2y.fsf@zhuzha.ua1> Organization: TOA Ukraine From: Mikolaj Golub Date: Fri, 22 Jan 2010 22:37:49 +0200 In-Reply-To: (Rick Macklem's message of "Fri\, 22 Jan 2010 14\:37\:48 -0500 \(EST\)") Message-ID: <86my05x4de.fsf@kopusha.onet> User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: freebsd-fs@FreeBSD.org, freebsd-stable@FreeBSD.org Subject: Re: FreeBSD NFS client/Linux NFS server issue X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 22 Jan 2010 20:37:54 -0000 On Fri, 22 Jan 2010 14:37:48 -0500 (EST) Rick Macklem wrote: >> --- nfs_bio.c.orig 2010-01-22 15:38:02.000000000 +0000 >> +++ nfs_bio.c 2010-01-22 15:39:58.000000000 +0000 >> @@ -1385,7 +1385,7 @@ again: >> */ >> if (!gotiod) { >> iod = nfs_nfsiodnew(); >> - if (iod != -1) >> + if ((iod != -1) && (nfs_iodwant[iod] == NULL)) >> gotiod = TRUE; >> } >> > > Unfortunately, I don't think the above fixes the problem. > If another thread that called nfs_asyncio() has "stolen" the this "iod", > it will have set nfs_iodwant[iod] == NULL (set non-NULL at #238) > and it will remain NULL until the other thread is done with it. I see. I have missed this. Thanks. > > There should probably be some sort of 3 way handshake between > the code in nfs_asyncio() after calling nfs_nfsnewiod() and the > code near the beginning of nfssvc_iod(), but I think the following > somewhat cheesy fix might do the trick: > > if (!gotiod) { > iod = nfs_nfsiodnew(); > if (iod != -1) { > if (nfs_iodwant[iod] == NULL) { > /* > * Either another thread has acquired this > * iod or I acquired the nfs_iod_mtx mutex > * before the new iod thread did in > * nfssvc_iod(). To be safe, go back and > * try again after allowing another thread > * to acquire the nfs_iod_mtx mutex. > */ > mtx_unlock(&nfs_iod_mtx); > /* > * So long as mtx_lock() implements some > * sort of fairness, nfssvc_iod() should > * get nfs_iod_mtx here and set > * nfs_iodwant[iod] != NULL for the case > * where the iod has not been "stolen" by > * another thread for a different mount > * point. > */ > mtx_lock(&nfs_iod_mtx); > goto again; > } > gotiod = TRUE; > } > } > > Does anyone else have a better solution? > (Mikolaj, could you by any chance test this? You can test yours, but I > think it breaks.) Unfortunately we observed this only on our production servers. A week ago we made some changes in configuration as workaround -- reconfigure cron no to run scripts simultaneously, set the scripts in cron that just periodically write a line to the file on nfs share (to "unlock" it if it is locked). We have not been observed problems since then and we would not like to experiment in production. If I manage to produce good test case in test environment I will be able to test the patch but I am not sure... -- Mikolaj Golub From owner-freebsd-stable@FreeBSD.ORG Fri Jan 22 20:56: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 19C33106566C for ; Fri, 22 Jan 2010 20:56:45 +0000 (UTC) (envelope-from freebsd@insightbb.com) Received: from mxsf12.insightbb.com (mxsf12.insightbb.com [74.128.0.94]) by mx1.freebsd.org (Postfix) with ESMTP id D7BB88FC12 for ; Fri, 22 Jan 2010 20:56:44 +0000 (UTC) X-IronPort-AV: E=Sophos;i="4.49,326,1262581200"; d="scan'208";a="21310110" Received: from unknown (HELO asav03.insightbb.com) ([172.31.249.123]) by mxsf12.insightbb.com with ESMTP; 22 Jan 2010 15:56:43 -0500 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArsEACegWUvQLicL/2dsb2JhbACBRdcYhDwE X-IronPort-AV: E=Sophos;i="4.49,326,1262581200"; d="scan'208";a="121663441" Received: from 208-46-39-11.dia.static.qwest.net (HELO laptop2.stevenfriedrich.org) ([208.46.39.11]) by asavout03.insightbb.com with ESMTP; 22 Jan 2010 15:56:43 -0500 From: Steven Friedrich To: freebsd-stable@freebsd.org Date: Fri, 22 Jan 2010 15:56:31 -0500 User-Agent: KMail/1.12.4 (FreeBSD/8.0-STABLE; KDE/4.3.4; i386; ; ) References: <20100122162155.GG3917@e-Gitt.NET> <20100122174601.e76f8b01.torfinn.ingolfsen@broadpark.no> In-Reply-To: <20100122174601.e76f8b01.torfinn.ingolfsen@broadpark.no> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201001221556.31278.freebsd@insightbb.com> Cc: Torfinn Ingolfsen Subject: Re: 8.0-RELEASE -> -STABLE and size of / X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 22 Jan 2010 20:56:45 -0000 On Friday 22 January 2010 11:46:01 am Torfinn Ingolfsen wrote: > On Fri, 22 Jan 2010 17:21:56 +0100 > > Oliver Brandmueller wrote: > > Instaling the new kernel failed, since /boot/kernel/ is already well > > over 230 MBytes in size. moving that to kernel.old and writing a new one > > with about the same size fails due to no space left on device. > > > > This is not a question; I do know how to get around this and how to > > configure custom kernels so they are a fragment of that size afterwards. > > It would also be nice if we knew how to configure the > whole "make world" procedure[1] to make a new kernel and modules without > symbols. The FAQ doesn't seem to have that answer either. > > > References: > 1) http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/makeworld.html > in your /etc/make.conf, do you have a line like: makeoptions DEBUG=-g if so, comment it out. From owner-freebsd-stable@FreeBSD.ORG Fri Jan 22 21:18: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 39020106568B; Fri, 22 Jan 2010 21:18:14 +0000 (UTC) (envelope-from olivier@gid0.org) Received: from mail-bw0-f213.google.com (mail-bw0-f213.google.com [209.85.218.213]) by mx1.freebsd.org (Postfix) with ESMTP id 786C88FC1F; Fri, 22 Jan 2010 21:18:13 +0000 (UTC) Received: by bwz5 with SMTP id 5so1494797bwz.3 for ; Fri, 22 Jan 2010 13:18:12 -0800 (PST) MIME-Version: 1.0 Received: by 10.204.16.194 with SMTP id p2mr1952836bka.32.1264195092177; Fri, 22 Jan 2010 13:18:12 -0800 (PST) In-Reply-To: <4B597CBB.5040900@omnilan.de> References: <4B55D9D4.1000008@FreeBSD.org> <4B597CBB.5040900@omnilan.de> Date: Fri, 22 Jan 2010 22:18:11 +0100 Message-ID: <367b2c981001221318q6a59913av14cceca4a2dab132@mail.gmail.com> From: Olivier Smedts To: Harald Schmalzbauer Content-Type: text/plain; charset=ISO-8859-1 Cc: Alexander Motin , FreeBSD-Current , FreeBSD Stable Subject: Re: Pack of CAM improvements X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 22 Jan 2010 21:18:14 -0000 2010/1/22 Harald Schmalzbauer : > Alexander Motin schrieb am 19.01.2010 17:12 (localtime): > ... >> >> Patch can be found here: >> http://people.freebsd.org/~mav/cam-ata.20100119.patch >> >> Feedback as always welcome. > > Again, thanks a lot for your ongoing great work! > The patch doesn't cleanly apply with vpo, but I don't use vpo so I didn't > care. Since r202799 it applies cleanly to 8-STABLE. > Otherwise I couldn't find any problems. > The system detects reinserted SATA drives on ICH9 fine. > > This was tested on a zfs backup server which went to the backbone yesterday, > so I can't physically remove any devices any more for testing... > > But I had some questions about zfs raidz states. I think that isn't a matter > of atacam but if I removed one disk, zpool status still showed me the ada3 > device "online". > After reinserting (and proper detection/initialisazion with cam, ada3 was > present again) and zpool clean, it set the devicea as UNAVAIL sinve I/O > errors. > I coudn't get the device into the pool again, no matter what I tried. > Only rebooting the machine helped. Then I could clean and scrub. > > What are the needed steps to provide a reinsterted hard disk to geom? With > the latest patches I don't need to issue any reset/rescan comman, right? > So it's a zfs problem, right? My mistake in understanding? > > Thanks, > > -Harry > > -- Olivier Smedts _ ASCII ribbon campaign ( ) e-mail: olivier@gid0.org - against HTML email & vCards X www: http://www.gid0.org - against proprietary attachments / \ "Il y a seulement 10 sortes de gens dans le monde : ceux qui comprennent le binaire, et ceux qui ne le comprennent pas." From owner-freebsd-stable@FreeBSD.ORG Fri Jan 22 21:21: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 D05D0106566B for ; Fri, 22 Jan 2010 21:21:41 +0000 (UTC) (envelope-from nicolas@i.0x5.de) Received: from n.0x5.de (n.0x5.de [217.197.85.144]) by mx1.freebsd.org (Postfix) with ESMTP id 5DA5F8FC1B for ; Fri, 22 Jan 2010 21:21:41 +0000 (UTC) Received: by pc5.i.0x5.de (Postfix, from userid 1003) id 9F8738FC8E; Fri, 22 Jan 2010 22:05:49 +0100 (CET) Date: Fri, 22 Jan 2010 22:05:49 +0100 From: Nicolas Rachinsky To: freebsd-stable@freebsd.org Message-ID: <20100122210549.GA5038@mid.pc5.i.0x5.de> Mail-Followup-To: freebsd-stable@freebsd.org References: <717f7a3e1001120714m37aada69gfaa35f0f9b17f435@mail.gmail.com> <44678539@bb.ipt.ru> <717f7a3e1001142234y1de7ae15x6853e3ddcab4add9@mail.gmail.com> <717f7a3e1001192246o4dce4a82q57c05ff3f41b5feb@mail.gmail.com> <20100120074611.GA405@icarus.home.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100120074611.GA405@icarus.home.lan> X-Powered-by: FreeBSD X-Homepage: http://www.rachinsky.de X-PGP-Keyid: 887BAE72 X-PGP-Fingerprint: 039E 9433 115F BC5F F88D 4524 5092 45C4 887B AE72 X-PGP-Keys: http://www.rachinsky.de/nicolas/gpg/nicolas_rachinsky.asc User-Agent: Mutt/1.5.20 (2009-06-14) Subject: Re: Multiple serial consoles via null modem cable X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 22 Jan 2010 21:21:41 -0000 * Jeremy Chadwick [2010-01-19 23:46 -0800]: > You cannot do something like where box1 COM1 is wired to box2 COM1, and > depending on what box you're on doing the "cu -l ttyu0" from, get a > login prompt on the other. It doesn't work like that. :-) Isn't the reason for different dial-in and dial-out devices that this should work? Or does that only work with modem? http://www.freebsd.org/doc/en_US.ISO8859-1/books/faq/serial.html#ACCESS-SERIAL-PORTS Nicolas -- http://www.rachinsky.de/nicolas From owner-freebsd-stable@FreeBSD.ORG Fri Jan 22 21:31: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 EEF771065676 for ; Fri, 22 Jan 2010 21:31:52 +0000 (UTC) (envelope-from mloftis@wgops.com) Received: from juggler.wgops.com (juggler.wgops.com [204.11.247.41]) by mx1.freebsd.org (Postfix) with ESMTP id C6AF58FC08 for ; Fri, 22 Jan 2010 21:31:52 +0000 (UTC) Received: by juggler.wgops.com (Postfix, from userid 65534) id 081DDA8110; Fri, 22 Jan 2010 14:31:51 -0700 (MST) X-Spam-ASN: X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on juggler.wgops.com X-Spam-Level: X-Spam-Status: No, score=-1.4 required=5.0 tests=ALL_TRUSTED autolearn=failed version=3.2.5 Received: from [192.168.1.44] (host-72-174-39-176.msl-mt.client.bresnan.net [72.174.39.176]) by juggler.wgops.com (Postfix) with ESMTPSA id DE337A810E for ; Fri, 22 Jan 2010 14:31:49 -0700 (MST) Date: Fri, 22 Jan 2010 14:31:55 -0700 From: Michael Loftis To: freebsd-stable@freebsd.org Message-ID: <7A1BFA601D973DD9D73B2952@[192.168.1.44]> In-Reply-To: <20100122210549.GA5038@mid.pc5.i.0x5.de> References: <717f7a3e1001120714m37aada69gfaa35f0f9b17f435@mail.gmail.com> <44678539@bb.ipt.ru> <717f7a3e1001142234y1de7ae15x6853e3ddcab4add9@mail.gmail.com> <717f7a3e1001192246o4dce4a82q57c05ff3f41b5feb@mail.gmail.com> <20100120074611.GA405@icarus.home.lan> <20100122210549.GA5038@mid.pc5.i.0x5.de> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Virus-Scanned: clamav-milter 0.95.3 at juggler X-Virus-Status: Clean Subject: Re: Multiple serial consoles via null modem cable X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 22 Jan 2010 21:31:53 -0000 --On Friday, January 22, 2010 10:05 PM +0100 Nicolas Rachinsky wrote: > * Jeremy Chadwick [2010-01-19 23:46 -0800]: >> You cannot do something like where box1 COM1 is wired to box2 COM1, and >> depending on what box you're on doing the "cu -l ttyu0" from, get a >> login prompt on the other. It doesn't work like that. :-) > > Isn't the reason for different dial-in and dial-out devices that this > should work? Or does that only work with modem? You can't with two directly connected machines. When the two are physically wired together, and getty is configured (via ttys) to fire up on the port it takes over the port. If you connect two machines via a null modem cable, both with getty on the same port, the getty's will be chatting with each other. The locking mechanism will "break" the chat loop when you try to use the dialout device on one end or the other but you may have to wait some time before the other end restarts getty (because it previously would have been dieing very rapidly due to login failures) A NULL modem connection is ALWAYS active. A regular modem, is NOT. It has a state of 'inactive' or 'waiting for ring' if you will. The correct way to do what you want is as others have suggested, two serial null modem cables, and two com ports on each machine. From owner-freebsd-stable@FreeBSD.ORG Fri Jan 22 21:54: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 379B5106566B; Fri, 22 Jan 2010 21:54:00 +0000 (UTC) (envelope-from flo@smeets.im) Received: from mail.solomo.de (mail.solomo.de [85.214.124.163]) by mx1.freebsd.org (Postfix) with ESMTP id DA0188FC14; Fri, 22 Jan 2010 21:53:59 +0000 (UTC) Received: from mail.solomo.de (localhost [127.0.0.1]) by mail.solomo.de (Postfix) with ESMTP id 9AF2D61ED3; Fri, 22 Jan 2010 22:53:58 +0100 (CET) X-Virus-Scanned: amavisd-new at vistream.de Received: from mail.solomo.de ([127.0.0.1]) by mail.solomo.de (mail.solomo.de [127.0.0.1]) (amavisd-new, port 10024) with LMTP id BAIAvX11p94L; Fri, 22 Jan 2010 22:53:56 +0100 (CET) Received: from [192.168.0.100] (p50912FB1.dip.t-dialin.net [80.145.47.177]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mail.solomo.de (Postfix) with ESMTPSA id E37E661C94; Fri, 22 Jan 2010 22:53:55 +0100 (CET) Message-ID: <4B5A1E72.2020809@smeets.im> Date: Fri, 22 Jan 2010 22:53:54 +0100 From: Florian Smeets User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.3a1pre) Gecko/20100121 Shredder/3.2a1pre MIME-Version: 1.0 To: Max Laier References: <4B58280C.50602@smeets.im> <4B595D0D.3060904@smeets.im> <201001220920.13458.jhb@freebsd.org> <201001221818.20409.max@love2party.net> In-Reply-To: <201001221818.20409.max@love2party.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: Luigi Rizzo , Bjoern Zeeb , freebsd-stable@freebsd.org, John Baldwin Subject: Re: 7.2-STABLE page fault with kernel from 12.01.2010 / crashinfo available X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 22 Jan 2010 21:54:00 -0000 On 1/22/10 6:18 PM, Max Laier wrote: > pf does change the byte order in the pfil hook, but changes it back on return > to the stack either when returning from the hook or when calling back into the > stack. There have been some issues where we missed returns to the stack that > would result in this situation, but since pf is not in the trace, this is > clearly not the case here. > > It might indeed be related to enc(4). I remember there have been some issues > in IPSEC where it failed to properly copy a packet before modifying it. Maybe > this is what is happening. Details escape me at the moment. > > Can you also make sure that your if_enc.c has revision 174978: > http://svn.freebsd.org/viewvc/base/release/7.2.0/sys/net/if_enc.c?view=diff&r1=174977&r2=174978 Yes i have the latest if_enc.c available on stable/7 cvs 1.6.2.3, svn r183630 World and kernel were compiled from sources csuped on 12.01.2010. Thanks, Florian From owner-freebsd-stable@FreeBSD.ORG Fri Jan 22 22:02: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 A77C01065672; Fri, 22 Jan 2010 22:02:36 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from esa-annu.mail.uoguelph.ca (esa-annu.mail.uoguelph.ca [131.104.91.36]) by mx1.freebsd.org (Postfix) with ESMTP id 3BE198FC19; Fri, 22 Jan 2010 22:02:35 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAHWvWUuDaFvI/2dsb2JhbADYfIQ8BA X-IronPort-AV: E=Sophos;i="4.49,326,1262581200"; d="scan'208";a="62614338" Received: from darling.cs.uoguelph.ca ([131.104.91.200]) by esa-annu-pri.mail.uoguelph.ca with ESMTP; 22 Jan 2010 17:02:35 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by darling.cs.uoguelph.ca (Postfix) with ESMTP id 565B394016A; Fri, 22 Jan 2010 17:02:35 -0500 (EST) X-Virus-Scanned: amavisd-new at darling.cs.uoguelph.ca Received: from darling.cs.uoguelph.ca ([127.0.0.1]) by localhost (darling.cs.uoguelph.ca [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BqvrPt5TaKse; Fri, 22 Jan 2010 17:02:33 -0500 (EST) Received: from muncher.cs.uoguelph.ca (muncher.cs.uoguelph.ca [131.104.91.102]) by darling.cs.uoguelph.ca (Postfix) with ESMTP id DC38F940062; Fri, 22 Jan 2010 17:02:33 -0500 (EST) Received: from localhost (rmacklem@localhost) by muncher.cs.uoguelph.ca (8.11.7p3+Sun/8.11.6) with ESMTP id o0MMD9o07073; Fri, 22 Jan 2010 17:13:09 -0500 (EST) X-Authentication-Warning: muncher.cs.uoguelph.ca: rmacklem owned process doing -bs Date: Fri, 22 Jan 2010 17:13:09 -0500 (EST) From: Rick Macklem X-X-Sender: rmacklem@muncher.cs.uoguelph.ca To: Mikolaj Golub In-Reply-To: Message-ID: References: <86ocl272mb.fsf@kopusha.onet> <86tyuqnz9x.fsf@zhuzha.ua1> <86zl4awmon.fsf@zhuzha.ua1> <86vdeywmha.fsf@zhuzha.ua1> <86vdeuuo2y.fsf@zhuzha.ua1> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-fs@FreeBSD.org, freebsd-stable@FreeBSD.org Subject: Re: FreeBSD NFS client/Linux NFS server issue X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 22 Jan 2010 22:02:36 -0000 On Fri, 22 Jan 2010, Rick Macklem wrote: > > There should probably be some sort of 3 way handshake between > the code in nfs_asyncio() after calling nfs_nfsnewiod() and the > code near the beginning of nfssvc_iod(), but I think the following > somewhat cheesy fix might do the trick: > [stuff deleted] I know it's a little weird to reply to my own posting, but I think this might be a reasonable patch (I have only tested it for a few minutes at this point). I basically redefined nfs_iodwant[] as a tri-state variable (although it was a struct proc *, it was only tested NULL/non-NULL). 0 - was NULL 1 - was non-NULL -1 - just created by nfs_asyncio() and will be used by it I'll keep testing it, but hopefully someone else can test and/or review it... rick ps: Mikolaj, I'm a sysadmin so I understand the problems with production systems, but if you do get a chance to test it somehow, that would be great. pss: This is against -current, but hopefully stable/7 can be patched about the same. --- patch for nfsiod race against -current --- --- nfsclient/nfs.h.sav 2010-01-22 16:21:53.000000000 -0500 +++ nfsclient/nfs.h 2010-01-22 16:22:04.000000000 -0500 @@ -252,7 +252,7 @@ int nfs_commit(struct vnode *vp, u_quad_t offset, int cnt, struct ucred *cred, struct thread *td); int nfs_readdirrpc(struct vnode *, struct uio *, struct ucred *); -int nfs_nfsiodnew(void); +int nfs_nfsiodnew(int); int nfs_asyncio(struct nfsmount *, struct buf *, struct ucred *, struct thread *); int nfs_doio(struct vnode *, struct buf *, struct ucred *, struct thread *); void nfs_doio_directwrite (struct buf *); --- nfsclient/nfsnode.h.sav 2010-01-22 14:56:34.000000000 -0500 +++ nfsclient/nfsnode.h 2010-01-22 14:56:52.000000000 -0500 @@ -180,7 +180,7 @@ * Queue head for nfsiod's */ extern TAILQ_HEAD(nfs_bufq, buf) nfs_bufq; -extern struct proc *nfs_iodwant[NFS_MAXASYNCDAEMON]; +extern int nfs_iodwant[NFS_MAXASYNCDAEMON]; extern struct nfsmount *nfs_iodmount[NFS_MAXASYNCDAEMON]; #if defined(_KERNEL) --- nfsclient/nfs_bio.c.sav 2010-01-22 14:57:28.000000000 -0500 +++ nfsclient/nfs_bio.c 2010-01-22 16:17:24.000000000 -0500 @@ -1377,7 +1377,7 @@ * Find a free iod to process this request. */ for (iod = 0; iod < nfs_numasync; iod++) - if (nfs_iodwant[iod]) { + if (nfs_iodwant[iod] > 0) { gotiod = TRUE; break; } @@ -1386,7 +1386,7 @@ * Try to create one if none are free. */ if (!gotiod) { - iod = nfs_nfsiodnew(); + iod = nfs_nfsiodnew(1); if (iod != -1) gotiod = TRUE; } @@ -1398,7 +1398,7 @@ */ NFS_DPF(ASYNCIO, ("nfs_asyncio: waking iod %d for mount %p\n", iod, nmp)); - nfs_iodwant[iod] = NULL; + nfs_iodwant[iod] = 0; nfs_iodmount[iod] = nmp; nmp->nm_bufqiods++; wakeup(&nfs_iodwant[iod]); --- nfsclient/nfs_nfsiod.c.sav 2010-01-22 14:57:28.000000000 -0500 +++ nfsclient/nfs_nfsiod.c 2010-01-22 16:32:31.000000000 -0500 @@ -113,7 +113,7 @@ * than the new minimum, create some more. */ for (i = nfs_iodmin - nfs_numasync; i > 0; i--) - nfs_nfsiodnew(); + nfs_nfsiodnew(0); out: mtx_unlock(&nfs_iod_mtx); return (0); @@ -147,7 +147,7 @@ */ iod = nfs_numasync - 1; for (i = 0; i < nfs_numasync - nfs_iodmax; i++) { - if (nfs_iodwant[iod]) + if (nfs_iodwant[iod] > 0) wakeup(&nfs_iodwant[iod]); iod--; } @@ -160,7 +160,7 @@ "Max number of nfsiod kthreads"); int -nfs_nfsiodnew(void) +nfs_nfsiodnew(int set_iodwant) { int error, i; int newiod; @@ -176,12 +176,17 @@ } if (newiod == -1) return (-1); + if (set_iodwant > 0) + nfs_iodwant[i] = -1; mtx_unlock(&nfs_iod_mtx); error = kproc_create(nfssvc_iod, nfs_asyncdaemon + i, NULL, RFHIGHPID, 0, "nfsiod %d", newiod); mtx_lock(&nfs_iod_mtx); - if (error) + if (error) { + if (set_iodwant > 0) + nfs_iodwant[i] = 0; return (-1); + } nfs_numasync++; return (newiod); } @@ -199,7 +204,7 @@ nfs_iodmin = NFS_MAXASYNCDAEMON; for (i = 0; i < nfs_iodmin; i++) { - error = nfs_nfsiodnew(); + error = nfs_nfsiodnew(0); if (error == -1) panic("nfsiod_setup: nfs_nfsiodnew failed"); } @@ -236,7 +241,8 @@ goto finish; if (nmp) nmp->nm_bufqiods--; - nfs_iodwant[myiod] = curthread->td_proc; + if (nfs_iodwant[myiod] == 0) + nfs_iodwant[myiod] = 1; nfs_iodmount[myiod] = NULL; /* * Always keep at least nfs_iodmin kthreads. @@ -303,7 +309,7 @@ nfs_asyncdaemon[myiod] = 0; if (nmp) nmp->nm_bufqiods--; - nfs_iodwant[myiod] = NULL; + nfs_iodwant[myiod] = 0; nfs_iodmount[myiod] = NULL; /* Someone may be waiting for the last nfsiod to terminate. */ if (--nfs_numasync == 0) --- nfsclient/nfs_subs.c.sav 2010-01-22 14:57:28.000000000 -0500 +++ nfsclient/nfs_subs.c 2010-01-22 16:35:10.000000000 -0500 @@ -347,7 +347,7 @@ nfs_ticks = 1; /* Ensure async daemons disabled */ for (i = 0; i < NFS_MAXASYNCDAEMON; i++) { - nfs_iodwant[i] = NULL; + nfs_iodwant[i] = 0; nfs_iodmount[i] = NULL; } nfs_nhinit(); /* Init the nfsnode table */ @@ -375,7 +375,7 @@ mtx_lock(&nfs_iod_mtx); nfs_iodmax = 0; for (i = 0; i < nfs_numasync; i++) - if (nfs_iodwant[i]) + if (nfs_iodwant[i] > 0) wakeup(&nfs_iodwant[i]); /* The last nfsiod to exit will wake us up when nfs_numasync hits 0 */ while (nfs_numasync) --- nfsclient/nfs_vnops.c.sav 2010-01-22 14:57:28.000000000 -0500 +++ nfsclient/nfs_vnops.c 2010-01-22 15:01:38.000000000 -0500 @@ -212,7 +212,7 @@ * Global variables */ struct mtx nfs_iod_mtx; -struct proc *nfs_iodwant[NFS_MAXASYNCDAEMON]; +int nfs_iodwant[NFS_MAXASYNCDAEMON]; struct nfsmount *nfs_iodmount[NFS_MAXASYNCDAEMON]; int nfs_numasync = 0; vop_advlock_t *nfs_advlock_p = nfs_dolock; From owner-freebsd-stable@FreeBSD.ORG Fri Jan 22 22:27: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 6308B1065670 for ; Fri, 22 Jan 2010 22:27:04 +0000 (UTC) (envelope-from to.my.trociny@gmail.com) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.152]) by mx1.freebsd.org (Postfix) with ESMTP id E7E4C8FC38 for ; Fri, 22 Jan 2010 22:27:03 +0000 (UTC) Received: by fg-out-1718.google.com with SMTP id 16so182530fgg.13 for ; Fri, 22 Jan 2010 14:27:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:to:cc:subject:references :organization:from:date:in-reply-to:message-id:user-agent :mime-version:content-type; bh=CGjUSDwBfdpnNGy+4zoFB2gO0gUZ+u3fnMTs49019dI=; b=l4q4yN2nD+v/gocYNSpOe7CeTC4Dq8x/nOILZtsWA6vPSjeLBVJ3Xbiky+zGlbuVnd +L3T8twkXPfti/R7ZY/7IuHSjQCA/eVK0EdZI9qo3WYf9ZGxD0CeeJ3bohpdsit882Zi 6frfyUcbQbDIQ7mxDj6QQydCuHtL/BTbHs7ls= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=to:cc:subject:references:organization:from:date:in-reply-to :message-id:user-agent:mime-version:content-type; b=QRmb8XUm+CHQ7KxDXADZWM5TgA38DtI0IgUvUUq4mSpPlmdnlAf8f1fr9QT8rTjisV AEvShZRbzGOrS5ZY9JZvroFdenL+t4BtW4Ns1+0Tar0oCQJuDzgx0/8w/keu6iOLURWt cgLqfh+/3Bu0HV91/qlEx/ZdA3jap9RYscbGA= Received: by 10.103.76.37 with SMTP id d37mr1862154mul.105.1264199221010; Fri, 22 Jan 2010 14:27:01 -0800 (PST) Received: from localhost ([95.69.162.7]) by mx.google.com with ESMTPS id e10sm10858688muf.26.2010.01.22.14.27.00 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 22 Jan 2010 14:27:00 -0800 (PST) To: Harald Schmalzbauer References: <4B56AB6F.9010303@omnilan.de> Organization: TOA Ukraine From: Mikolaj Golub Date: Sat, 23 Jan 2010 00:26:58 +0200 In-Reply-To: <4B56AB6F.9010303@omnilan.de> (Harald Schmalzbauer's message of "Wed\, 20 Jan 2010 08\:06\:23 +0100") Message-ID: <86eilhwzbh.fsf@kopusha.onet> User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: freebsd-stable@freebsd.org Subject: Re: top Segmentation faulting on 8.0p2 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, 22 Jan 2010 22:27:04 -0000 On Wed, 20 Jan 2010 08:06:23 +0100 Harald Schmalzbauer wrote: > Dear all, > > I have no idea why top crashes with segmentation fault on my amd64 > machine running FreeBSD 8.0-RELEASE-p2. > If someone wants to have a loot at the core dump: > http://www.schmalzbauer.de/downloads/top.core core file is useless without binary and libraries. So it is better to run gdb on your host, produce backtrace and post here: gdb /usr/bin/top top.core bt And sure a backtrace from the top built with -g would be much better. cd /usr/src/usr.bin/top CFLAGS=-g make -- Mikolaj Golub From owner-freebsd-stable@FreeBSD.ORG Fri Jan 22 23:15: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 4CD24106566B for ; Fri, 22 Jan 2010 23:15:30 +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 067FB8FC14 for ; Fri, 22 Jan 2010 23:15:29 +0000 (UTC) Received: from list by lo.gmane.org with local (Exim 4.50) id 1NYSic-0007C8-4d for freebsd-stable@freebsd.org; Sat, 23 Jan 2010 00:15:10 +0100 Received: from 93-138-99-190.adsl.net.t-com.hr ([93.138.99.190]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 23 Jan 2010 00:15:09 +0100 Received: from ivoras by 93-138-99-190.adsl.net.t-com.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 23 Jan 2010 00:15:09 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-stable@freebsd.org From: Ivan Voras Date: Sat, 23 Jan 2010 00:06:25 +0100 Lines: 22 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: 93-138-99-190.adsl.net.t-com.hr User-Agent: Thunderbird 2.0.0.21 (X11/20090612) In-Reply-To: Sender: news Cc: freebsd-hackers@freebsd.org, freebsd-questions@freebsd.org Subject: Re: posting coding bounties, appropriate money amounts? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 22 Jan 2010 23:15:30 -0000 Dan Naumov wrote: > Hello > > I am curious about posting some coding bounties, my current interest > revolves around improving the ZVOL functionality in FreeBSD: fixing > the known ZVOL SWAP reliability/stability problems as well as making > ZVOLs work as a dumpon device (as is already the case in OpenSolaris) > for crash dumps. I am a private individual and not some huge Fortune > 100 and while I am not exactly rich, I am willing to put some of my > personal money towards this. I am curious though, what would be the > best way to approach this: directly approaching committer(s) with the > know-how-and-why of the areas involved or through the FreeBSD > Foundation? And how would one go about calculating the appropriate > amount of money for such a thing? Hi, This idea (bounties) appear approximately every 6 months and it appears there is no better way than contacting the developers directly. AFAIK all attempts to conglomerate such an effort have failed. One important conclusion is that it cannot go through the Foundation since they cannot accept targeted donations. From owner-freebsd-stable@FreeBSD.ORG Fri Jan 22 23:32: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 76BCF106566C for ; Fri, 22 Jan 2010 23:32:03 +0000 (UTC) (envelope-from prvs=0638d2851d=ob@gruft.de) Received: from main.mx.e-gitt.net (service.rules.org [IPv6:2001:1560:2342::2]) by mx1.freebsd.org (Postfix) with ESMTP id 0333F8FC17 for ; Fri, 22 Jan 2010 23:32:03 +0000 (UTC) Received: from ob by main.mx.e-gitt.net with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NYSyw-0004oI-97 for freebsd-stable@freebsd.org; Sat, 23 Jan 2010 00:32:02 +0100 Date: Sat, 23 Jan 2010 00:32:02 +0100 From: Oliver Brandmueller To: freebsd-stable@freebsd.org Message-ID: <20100122233201.GI3917@e-Gitt.NET> Mail-Followup-To: freebsd-stable@freebsd.org References: <20100122162155.GG3917@e-Gitt.NET> <20100122174601.e76f8b01.torfinn.ingolfsen@broadpark.no> <201001221556.31278.freebsd@insightbb.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201001221556.31278.freebsd@insightbb.com> User-Agent: Mutt/1.5.20 (2009-06-14) Sender: Oliver Brandmueller Subject: Re: 8.0-RELEASE -> -STABLE and size of / X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 22 Jan 2010 23:32:03 -0000 Hi, On Fri, Jan 22, 2010 at 03:56:31PM -0500, Steven Friedrich wrote: > in your /etc/make.conf, do you have a line like: > makeoptions DEBUG=-g > if so, comment it out. The GENEREIC kernel by default has the following config: makeoptions DEBUG=-g # Build kernel with gdb(1) debug symbols You don't need anything special in your make.conf In fact having the debug symbols is useful in many cases. So raising the default size for the / partition might be the better option (OK, doesn't help for already installed systems of course). - Oliver -- | Oliver Brandmueller http://sysadm.in/ ob@sysadm.in | | Ich bin das Internet. Sowahr ich Gott helfe. | From owner-freebsd-stable@FreeBSD.ORG Fri Jan 22 23:52: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 B5398106566B for ; Fri, 22 Jan 2010 23:52:48 +0000 (UTC) (envelope-from freebsd-stable@track.pupworks.com) Received: from pupworks.com (cl-252.chi-02.us.sixxs.net [IPv6:2001:4978:f:fb::2]) by mx1.freebsd.org (Postfix) with ESMTP id 833268FC12 for ; Fri, 22 Jan 2010 23:52:48 +0000 (UTC) Received: from [IPv6:2001:4978:168::225:ff:fe4e:60d1] (unknown [IPv6:2001:4978:168:0:225:ff:fe4e:60d1]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by pupworks.com (Postfix) with ESMTPSA id 64FF41E63CF1 for ; Fri, 22 Jan 2010 23:52:47 +0000 (UTC) From: Nat Howard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Fri, 22 Jan 2010 18:52:47 -0500 Message-Id: To: freebsd-stable@freebsd.org Mime-Version: 1.0 (Apple Message framework v1077) X-Mailer: Apple Mail (2.1077) Subject: IPSec NAT-T in transport 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, 22 Jan 2010 23:52:48 -0000 I'm very interested in this problem -- I want to run an L2TP server = myself. Is anyone actually working on this? I might be able to chip = in a few bucks... But I'm not seeing bad checksums. Here's my setup: L2tp server A<---------------->B Freebsd NAT box C = <-----------internal network----------->D my mac Where should I be seeing the bad checksums? A, B, C, or D? Looking only at B, I don't see any bad udp checksums, but I'm seeing a = bunch of these (IP numbers changed to bracketed names): 23:49:48.004107 IP (tos 0x0, ttl 64, id 52328, offset 0, flags [none], = proto ICMP (1), length 56) [NAT Box] > [External Server] ICMP [NAT Box] = udp port 58660 unreachable, length 36 IP (tos 0x20, ttl 59, id 36320, offset 0, flags [none], proto = UDP (17), length 143) [External Server].1701 > [NAT Box].58660: [|l2tp] From owner-freebsd-stable@FreeBSD.ORG Sat Jan 23 00:05: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 948A61065679; Sat, 23 Jan 2010 00:05:18 +0000 (UTC) (envelope-from mattjeet@gmail.com) Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by mx1.freebsd.org (Postfix) with ESMTP id 559208FC13; Sat, 23 Jan 2010 00:05:18 +0000 (UTC) Received: by pwi15 with SMTP id 15so1223946pwi.3 for ; Fri, 22 Jan 2010 16:05:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:reply-to:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type; bh=Ac3+p2e1Yd2SwWueZbPmWpim4uv5eetnfcarYxribXo=; b=XJMqVNadz3jtoXAd/Akacl1q1DCDC6jDI6GLtNUhEBRr1TpNYThD+wkPolyHflTbMU RYe9ut62fNXz+UbSJUfPddJkSHYKEd2aYuyqMBzZiKkWbtfnjEOE5XJBFt7E2CS5yNci tbqBfSk0n7fcnJxDDrOMiFD3i5tyhs3q2Th+0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:reply-to:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; b=vL5ULOW3kpK44/VHPRf2pKFuuGYgKyS966HIq8DHhVTIcVVpeoJgBAU1aif7F91c3v ab6VrbFjMuX5zZcXZomj2Ep0bmQ32KBszQhX/A5pRoNMi6fqw9ZEhHKndmZ6JsVIL3S2 f4yoM69Hk7wiYA3p7rVeXmZiyzul5wN34fcVk= MIME-Version: 1.0 Sender: mattjeet@gmail.com Received: by 10.142.1.20 with SMTP id 20mr2460947wfa.73.1264203320891; Fri, 22 Jan 2010 15:35:20 -0800 (PST) In-Reply-To: References: Date: Fri, 22 Jan 2010 15:35:20 -0800 X-Google-Sender-Auth: f0816e0fa82657ee Message-ID: <9740caf1001221535l1fcb45f0pa189c84517640314@mail.gmail.com> From: Matt Olander To: Ivan Voras Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-hackers@freebsd.org, freebsd-stable@freebsd.org, freebsd-questions@freebsd.org Subject: Re: posting coding bounties, appropriate money amounts? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: matt@ixsystems.com List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Jan 2010 00:05:18 -0000 On Fri, Jan 22, 2010 at 3:06 PM, Ivan Voras wrote: > Dan Naumov wrote: >> >> Hello >> >> I am curious about posting some coding bounties, my current interest >> revolves around improving the ZVOL functionality in FreeBSD: fixing >> the known ZVOL SWAP reliability/stability problems as well as making >> ZVOLs work as a dumpon device (as is already the case in OpenSolaris) >> for crash dumps. I am a private individual and not some huge Fortune >> 100 and while I am not exactly rich, I am willing to put some of my >> personal money towards this. I am curious though, what would be the >> best way to approach this: directly approaching committer(s) with the >> know-how-and-why of the areas involved or through the FreeBSD >> Foundation? And how would one go about calculating the appropriate >> amount of money for such a thing? > > Hi, > > This idea (bounties) appear approximately every 6 months and it appears > there is no better way than contacting the developers directly. AFAIK all > attempts to conglomerate such an effort have failed. One important > conclusion is that it cannot go through the Foundation since they cannot > accept targeted donations. Awhile back, we built a simple app for posting bounties, getting devs and sponsors on board, posting the committed code in a browser viewable format, and then handle final payout upon completion. iXsystems is more than willing to handle financial details and I would gladly be the first to sponsor this project on the site. http://www.sponsorbsd.org We would need a team leader *cough* Ivan *cough* that could make sure developing contributors are actually involved so that the final payoff can be shared accordingly. It's a cakephp app and I'm sure it needs a bit more polish but we could do it on the fly and it shouldn't be to hard :) Any cakephp or php devs interested in helping testing and launch, let me know. I just haven't had much time to spend on launching it although I still think it's a great idea. If somebody would like to spearhead this effort, that would be great. For companies wishing to sponsor non-community code, it also has the option of hiding the community committed code. best, -matt From owner-freebsd-stable@FreeBSD.ORG Sat Jan 23 00:40: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 271861065672 for ; Sat, 23 Jan 2010 00:40:06 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta06.westchester.pa.mail.comcast.net (qmta06.westchester.pa.mail.comcast.net [76.96.62.56]) by mx1.freebsd.org (Postfix) with ESMTP id C5E6F8FC12 for ; Sat, 23 Jan 2010 00:40:05 +0000 (UTC) Received: from omta12.westchester.pa.mail.comcast.net ([76.96.62.44]) by qmta06.westchester.pa.mail.comcast.net with comcast id YePa1d00E0xGWP856og6XV; Sat, 23 Jan 2010 00:40:06 +0000 Received: from koitsu.dyndns.org ([98.248.46.159]) by omta12.westchester.pa.mail.comcast.net with comcast id Yog51d0043S48mS3Yog5PT; Sat, 23 Jan 2010 00:40:06 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id E70A71E3033; Fri, 22 Jan 2010 16:40:03 -0800 (PST) Date: Fri, 22 Jan 2010 16:40:03 -0800 From: Jeremy Chadwick To: freebsd-stable@freebsd.org Message-ID: <20100123004003.GA97111@icarus.home.lan> 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) Subject: Re: posting coding bounties, appropriate money amounts? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 23 Jan 2010 00:40:06 -0000 On Fri, Jan 22, 2010 at 07:49:46PM +0200, Dan Naumov wrote: > I am curious about posting some coding bounties, my current interest > revolves around improving the ZVOL functionality in FreeBSD: fixing > the known ZVOL SWAP reliability/stability problems as well as making > ZVOLs work as a dumpon device (as is already the case in OpenSolaris) > for crash dumps. I am a private individual and not some huge Fortune > 100 and while I am not exactly rich, I am willing to put some of my > personal money towards this. I am curious though, what would be the > best way to approach this: directly approaching committer(s) with the > know-how-and-why of the areas involved or through the FreeBSD > Foundation? And how would one go about calculating the appropriate > amount of money for such a thing? For what it's worth: count me in here, and not just with regards to zvol. I'd be more than happy to donate money to a pool (pun intended) to get some of the ZFS-centric issues looked at / focused on, and possibly fixed. I'd be willing to put up a thousand USD or possibly more depending on what sort of work was being considered. I suppose a better choice would be for someone here to make a list of issues which the community feels need attention, and put the pooled donations to whatever things had highest priority -- or, if that isn't plausible, then to what interested developers wanted to work on. -- | 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 Sat Jan 23 01:02: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 1607A106566C for ; Sat, 23 Jan 2010 01:02:14 +0000 (UTC) (envelope-from h.schmalzbauer@omnilan.de) Received: from host.omnilan.net (host.omnilan.net [62.245.232.135]) by mx1.freebsd.org (Postfix) with ESMTP id 8A65A8FC17 for ; Sat, 23 Jan 2010 01:02:13 +0000 (UTC) Received: from titan.flintsbach.schmalzbauer.de (titan.flintsbach.schmalzbauer.de [172.21.1.150]) (authenticated bits=0) by host.omnilan.net (8.13.8/8.13.8) with ESMTP id o0N12CVp099007 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 23 Jan 2010 02:02:12 +0100 (CET) (envelope-from h.schmalzbauer@omnilan.de) Message-ID: <4B5A4A8C.8070707@omnilan.de> Date: Sat, 23 Jan 2010 02:02:04 +0100 From: Harald Schmalzbauer Organization: OmniLAN User-Agent: Thunderbird 2.0.0.23 (X11/20090906) MIME-Version: 1.0 To: Mikolaj Golub References: <4B56AB6F.9010303@omnilan.de> <86eilhwzbh.fsf@kopusha.onet> In-Reply-To: <86eilhwzbh.fsf@kopusha.onet> X-Enigmail-Version: 0.95.6 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigF5C2FED34BEC60299B2004A5" Cc: freebsd-stable@freebsd.org Subject: Re: top Segmentation faulting on 8.0p2 amd64 (nss_ldapd 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, 23 Jan 2010 01:02:14 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigF5C2FED34BEC60299B2004A5 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Mikolaj Golub schrieb am 22.01.2010 23:26 (localtime): > On Wed, 20 Jan 2010 08:06:23 +0100 Harald Schmalzbauer wrote: >=20 >> Dear all, >> >> I have no idea why top crashes with segmentation fault on my amd64 >> machine running FreeBSD 8.0-RELEASE-p2. >> If someone wants to have a loot at the core dump: >> http://www.schmalzbauer.de/downloads/top.core >=20 > core file is useless without binary and libraries. So it is better to r= un gdb > on your host, produce backtrace and post here: >=20 > gdb /usr/bin/top top.core > bt >=20 > And sure a backtrace from the top built with -g would be much better. >=20 > cd /usr/src/usr.bin/top > CFLAGS=3D-g make Unfortunately nss_ldap seems to be the culprit. gdb /usr/bin/top top.core GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you = are welcome to change it and/or distribute copies of it under certain=20 conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for detail= s. This GDB was configured as "amd64-marcel-freebsd"... Core was generated by `top'. Program terminated with signal 11, Segmentation fault. Reading symbols from /lib/libncurses.so.8...done. Loaded symbols for /lib/libncurses.so.8 Reading symbols from /lib/libm.so.5...done. Loaded symbols for /lib/libm.so.5 Reading symbols from /lib/libkvm.so.5...done. Loaded symbols for /lib/libkvm.so.5 Reading symbols from /lib/libc.so.7...done. Loaded symbols for /lib/libc.so.7 Reading symbols from /usr/local/lib/nss_ldap.so.1...done. Loaded symbols for /usr/local/lib/nss_ldap.so.1 Reading symbols from /libexec/ld-elf.so.1...done. Loaded symbols for /libexec/ld-elf.so.1 bt: #0 0x0000000800d08403 in __nss_compat_gethostbyname () from=20 /usr/local/lib/nss_ldap.so.1 #0 0x0000000800d08403 in __nss_compat_gethostbyname () from=20 /usr/local/lib/nss_ldap.so.1 #1 0x0000000800d0606f in _nss_ldap_getpwent_r () from=20 /usr/local/lib/nss_ldap.so.1 #2 0x00000008009ffc54 in __nss_compat_getpwent_r () from /lib/libc.so.7 #3 0x0000000800a84a3d in nsdispatch () from /lib/libc.so.7 #4 0x0000000800a50976 in getpwent_r () from /lib/libc.so.7 #5 0x0000000800a50596 in sysctlbyname () from /lib/libc.so.7 #6 0x0000000000406c6d in machine_init (statics=3D0x7fffffffea30,=20 do_unames=3D1 '\001') at /usr/src/usr.bin/top/machine.c:257 #7 0x0000000000407a10 in main (argc=3D1, argv=3D0x7fffffffeb08) at /usr/src/usr.bin/top/../../contrib/top/top.c:458 I'm using nss_ldapd-0.7.2 and there's no way to live without ldap... Any help highly appreciated! Thanks, -Harry --------------enigF5C2FED34BEC60299B2004A5 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.13 (FreeBSD) iEYEARECAAYFAktaSpQACgkQLDqVQ9VXb8jj9gCgzlUrTLMGeFrSR8XCMSleXdho zd4An1qCxMXjLMGRi8N0QareTAb1ib9p =hTld -----END PGP SIGNATURE----- --------------enigF5C2FED34BEC60299B2004A5-- From owner-freebsd-stable@FreeBSD.ORG Sat Jan 23 01:20: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 682D6106568B for ; Sat, 23 Jan 2010 01:20:19 +0000 (UTC) (envelope-from amvandemore@gmail.com) Received: from mail-px0-f183.google.com (mail-px0-f183.google.com [209.85.216.183]) by mx1.freebsd.org (Postfix) with ESMTP id 3CD2C8FC1A for ; Sat, 23 Jan 2010 01:20:18 +0000 (UTC) Received: by pxi13 with SMTP id 13so1245259pxi.3 for ; Fri, 22 Jan 2010 17:20:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=Xq+OQgzHS7sfNDv2iY8I8lTJLnWN2RGA6jcQJ2Drh2A=; b=dKSumngcjaxZNtMxx5Fu3lw+X1GDHlGTZbNX4ZBuYLvSn+rf7bknFwI58SqcJfUtV5 qdd+gSW0suFElYnm6NYdGEj8t9OwAp03zAXrW6WaYxKIpzHcizs16qD30Mt7sGY0mpXN S+swxSQp8fPu3BjZSoOltPwLp2dgQCLIVCCAw= 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=t3g6u7ca5R0dST6HBqYxxxAmhmkII6o6wtdblAwMxYlIQmXlnIgxpILmgNknTVAthw UI9RZqxJehG4sPG21GAkBqEgrU2BEAV4BEBOlEGHo+ZNwOcggbbd3oByXwPRfLeydztS bIfEDFQAeQPt2PvcEQe5cuay1nTsW+qRTGfCw= MIME-Version: 1.0 Received: by 10.142.67.24 with SMTP id p24mr2480974wfa.265.1264209618483; Fri, 22 Jan 2010 17:20:18 -0800 (PST) In-Reply-To: <20100123004003.GA97111@icarus.home.lan> References: <20100123004003.GA97111@icarus.home.lan> Date: Fri, 22 Jan 2010 19:20:18 -0600 Message-ID: <6201873e1001221720m294c3f09tcf6ba88a94fdbfba@mail.gmail.com> From: Adam Vande More To: Jeremy Chadwick Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-stable@freebsd.org Subject: Re: posting coding bounties, appropriate money amounts? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 23 Jan 2010 01:20:19 -0000 On Fri, Jan 22, 2010 at 6:40 PM, Jeremy Chadwick wrote: > On Fri, Jan 22, 2010 at 07:49:46PM +0200, Dan Naumov wrote: > > I am curious about posting some coding bounties, my current interest > > revolves around improving the ZVOL functionality in FreeBSD: fixing > > the known ZVOL SWAP reliability/stability problems as well as making > > ZVOLs work as a dumpon device (as is already the case in OpenSolaris) > > for crash dumps. I am a private individual and not some huge Fortune > > 100 and while I am not exactly rich, I am willing to put some of my > > personal money towards this. I am curious though, what would be the > > best way to approach this: directly approaching committer(s) with the > > know-how-and-why of the areas involved or through the FreeBSD > > Foundation? And how would one go about calculating the appropriate > > amount of money for such a thing? > > For what it's worth: count me in here, and not just with regards to > zvol. I'd be more than happy to donate money to a pool (pun intended) > to get some of the ZFS-centric issues looked at / focused on, and > possibly fixed. > > I'd be willing to put up a thousand USD or possibly more depending on > what sort of work was being considered. I suppose a better choice would > be for someone here to make a list of issues which the community feels > need attention, and put the pooled donations to whatever things had > highest priority -- or, if that isn't plausible, then to what interested > developers wanted to work on. > > -- > | 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 | > To the best of my understanding, that is basically what donating to the FreeBSD Foundation accomplishes, although it would be nice so see some more transparency in their decision making process. -- Adam Vande More From owner-freebsd-stable@FreeBSD.ORG Sat Jan 23 02:22:13 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 D876D1065696 for ; Sat, 23 Jan 2010 02:22:13 +0000 (UTC) (envelope-from aw1@swelter.hanley.stade.co.uk) Received: from v-smtp-auth-relay-3.gradwell.net (v-smtp-auth-relay-3.gradwell.net [79.135.125.42]) by mx1.freebsd.org (Postfix) with ESMTP id 465778FC0C for ; Sat, 23 Jan 2010 02:22:12 +0000 (UTC) Received: from 93-97-22-18.zone5.bethere.co.uk ([93.97.22.18] helo=swelter.hanley.stade.co.uk country=GB ident=postmaster^pop3^stade#co$uk) by v-smtp-auth-relay-3.gradwell.net with esmtpa (Gradwell gwh-smtpd 1.290) id 4b5a4f91.1ae5.1 for freebsd-stable@freebsd.org; Sat, 23 Jan 2010 01:23:29 +0000 (envelope-sender ) Received: from swelter.hanley.stade.co.uk (localhost [127.0.0.1]) by swelter.hanley.stade.co.uk (8.14.3/8.14.3) with ESMTP id o0N1NSVi066222 for ; Sat, 23 Jan 2010 01:23:28 GMT (envelope-from aw1@swelter.hanley.stade.co.uk) Received: (from aw1@localhost) by swelter.hanley.stade.co.uk (8.14.3/8.14.3/Submit) id o0N1NSaI066221 for freebsd-stable@freebsd.org; Sat, 23 Jan 2010 01:23:28 GMT (envelope-from aw1) Date: Sat, 23 Jan 2010 01:23:28 +0000 From: Adrian Wontroba To: freebsd-stable@freebsd.org Message-ID: <20100123012328.GA3296@swelter.hanley.stade.co.uk> Mail-Followup-To: Adrian Wontroba , freebsd-stable@freebsd.org References: <20100122162155.GG3917@e-Gitt.NET> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100122162155.GG3917@e-Gitt.NET> User-Agent: Mutt/1.4.2.3i X-Operating-System: FreeBSD 8.0-STABLE Organization: Oh dear, I've joined one again. X-Virus-Scanned: clamav-milter 0.95.3 at swelter.hanley.stade.co.uk X-Virus-Status: Clean Subject: Re: 8.0-RELEASE -> -STABLE and size of / X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: aw1@stade.co.uk List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Jan 2010 02:22:13 -0000 On Fri, Jan 22, 2010 at 05:21:56PM +0100, Oliver Brandmueller wrote: > > I just noticed somthing: I setup an 8.0-RELEASE amd64 box, / is default > 512M. First step after setup was to csup to RELENG_8 and buildkernel and > buildworld (no custom kernel, no make.conf). > > Instaling the new kernel failed, since /boot/kernel/ is already well > over 230 MBytes in size. moving that to kernel.old and writing a new one > with about the same size fails due to no space left on device. > > This is not a question; I do know how to get around this and how to > configure custom kernels so they are a fragment of that size afterwards. > However, I think this is a clear POLA violation. So, either GENERIC with > less debugging information (symbols and stuff), which makes debugging > harder or setting a higher default for / would be options, if not anyone > else has better ideas. /usr/src/UPDATING has this which will allow you to remove symbols when installing a kernel: 20060118: This actually occured some time ago, but installing the kernel now also installs a bunch of symbol files for the kernel modules. This increases the size of /boot/kernel to about 67Mbytes. You will need twice this if you will eventually back this up to kernel.old on your next install. If you have a shortage of room in your root partition, you should add -DINSTALL_NODEBUG to your make arguments or add INSTALL_NODEBUG="yes" to your /etc/make.conf. I concur that the 235 MB size of an amd64 8.0 kernel is a bit of a surprise. An i386 kernel is a mere 135 MB. IMO increasing the sysinstall default root slice size for at least amd64 would be a good thing. -- Adrian Wontroba From owner-freebsd-stable@FreeBSD.ORG Sat Jan 23 03:20: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 E9848106566C for ; Sat, 23 Jan 2010 03:20:33 +0000 (UTC) (envelope-from freebsd@insightbb.com) Received: from mxsf00.insightbb.com (mxsf00.insightbb.com [74.128.0.70]) by mx1.freebsd.org (Postfix) with ESMTP id B35258FC1C for ; Sat, 23 Jan 2010 03:20:33 +0000 (UTC) X-IronPort-AV: E=Sophos;i="4.49,328,1262581200"; d="scan'208";a="743313644" Received: from unknown (HELO asav02.insightbb.com) ([172.31.249.123]) by mxsf00.insightbb.com with ESMTP; 22 Jan 2010 22:20:32 -0500 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiAFAED5WUvQLicL/2dsb2JhbACBRtcvhDwE X-IronPort-AV: E=Sophos;i="4.49,328,1262581200"; d="scan'208";a="344783163" Received: from 208-46-39-11.dia.static.qwest.net (HELO laptop2.stevenfriedrich.org) ([208.46.39.11]) by asavout02.manage.insightbb.com with ESMTP; 22 Jan 2010 22:20:32 -0500 From: Steven Friedrich To: freebsd-stable@freebsd.org Date: Fri, 22 Jan 2010 22:20:30 -0500 User-Agent: KMail/1.12.4 (FreeBSD/8.0-STABLE; KDE/4.3.4; i386; ; ) References: <20100122162155.GG3917@e-Gitt.NET> <201001221556.31278.freebsd@insightbb.com> <20100122233201.GI3917@e-Gitt.NET> In-Reply-To: <20100122233201.GI3917@e-Gitt.NET> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201001222220.31040.freebsd@insightbb.com> Cc: Subject: Re: 8.0-RELEASE -> -STABLE and size of / X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 23 Jan 2010 03:20:34 -0000 On Friday 22 January 2010 06:32:02 pm Oliver Brandmueller wrote: > Hi, > > On Fri, Jan 22, 2010 at 03:56:31PM -0500, Steven Friedrich wrote: > > in your /etc/make.conf, do you have a line like: > > makeoptions DEBUG=-g > > if so, comment it out. > > The GENEREIC kernel by default has the following config: > > makeoptions DEBUG=-g # Build kernel with gdb(1) debug > symbols > > You don't need anything special in your make.conf > > In fact having the debug symbols is useful in many cases. So raising the > default size for the / partition might be the better option (OK, doesn't > help for already installed systems of course). > > - Oliver > I'm sorry. My response to him should have been more precise. I was trying to clue him in on how to build a non-debug kernel, but my answer was in fact wrong. I said he may have a line in make.conf, but that was a mistake. I pulled the line from a kernel config file. If he wants to build a kernel with no symbols, as he stated he does, he needs to comment out the line and build a kernel. Could buildworld and installworld, too. But he and I went off topic. I should have changed the subject line to start a new thread to discuss building without symbols. He was complaining that it wasn't in the FAQ or the handbook. It's in GENERIC, which is required reading if you're ever going to build custom kernels. As for the main topic, I have been making 4GB root partitions for some time. Our disk requirements have been soaring over the last decade, while cost per MB have plummeted. I don't want to have to guess what sizes each partition should be. From owner-freebsd-stable@FreeBSD.ORG Sat Jan 23 10:10: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 6F97110656A4 for ; Sat, 23 Jan 2010 10:10: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 072398FC26 for ; Sat, 23 Jan 2010 10:10:08 +0000 (UTC) Received: from localhost (amavis.fra.cksoft.de [192.168.74.71]) by mail.cksoft.de (Postfix) with ESMTP id 7F95941C751; Sat, 23 Jan 2010 11:10:06 +0100 (CET) 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 d-hcNr3RnObD; Sat, 23 Jan 2010 11:10:05 +0100 (CET) Received: by mail.cksoft.de (Postfix, from userid 66) id DB44941C712; Sat, 23 Jan 2010 11:10:05 +0100 (CET) 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 D5B744448EC; Sat, 23 Jan 2010 10:09:01 +0000 (UTC) Date: Sat, 23 Jan 2010 10:09:00 +0000 (UTC) From: "Bjoern A. Zeeb" X-X-Sender: bz@maildrop.int.zabbadoz.net To: Nat Howard In-Reply-To: Message-ID: <20100123100713.X50938@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: IPSec NAT-T in transport 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: Sat, 23 Jan 2010 10:10:08 -0000 On Fri, 22 Jan 2010, Nat Howard wrote: > I'm very interested in this problem -- I want to run an L2TP server myself. Is anyone actually working on this? I might be able to chip in a few bucks... > > But I'm not seeing bad checksums. Here's my setup: > > > L2tp server A<---------------->B Freebsd NAT box C <-----------internal network----------->D my mac > > Where should I be seeing the bad checksums? A, B, C, or D? > > > Looking only at B, I don't see any bad udp checksums, but I'm seeing a bunch of these (IP numbers changed to bracketed names): This doesn't say if you are using IPsec but I will asume so, that would mean that you D "my mac" would initiate the connection and the A node "L2tp server" would then be the other end. If that's a FreeBSD box as well, you should check statistics there. The NAT gateway in between has nothing to do with this, only the IPsec ends. /bz -- Bjoern A. Zeeb It will not break if you know what you are doing. From owner-freebsd-stable@FreeBSD.ORG Sat Jan 23 11:43: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 07914106566B for ; Sat, 23 Jan 2010 11:43:16 +0000 (UTC) (envelope-from mail25@bzerk.org) Received: from ei.bzerk.org (tunnel490.ipv6.xs4all.nl [IPv6:2001:888:10:1ea::2]) by mx1.freebsd.org (Postfix) with ESMTP id 8D3468FC17 for ; Sat, 23 Jan 2010 11:43:15 +0000 (UTC) Received: from ei.bzerk.org (BOFH@localhost [127.0.0.1]) by ei.bzerk.org (8.14.3/8.14.3) with ESMTP id o0NBg9xL021563; Sat, 23 Jan 2010 12:42:09 +0100 (CET) (envelope-from mail25@bzerk.org) Received: (from bulk@localhost) by ei.bzerk.org (8.14.3/8.14.3/Submit) id o0NBg9mn021562; Sat, 23 Jan 2010 12:42:09 +0100 (CET) (envelope-from mail25@bzerk.org) Date: Sat, 23 Jan 2010 12:42:09 +0100 From: Ruben de Groot To: Adrian Wontroba , freebsd-stable@freebsd.org Message-ID: <20100123114209.GA21457@ei.bzerk.org> Mail-Followup-To: Ruben de Groot , Adrian Wontroba , freebsd-stable@freebsd.org References: <20100122162155.GG3917@e-Gitt.NET> <20100123012328.GA3296@swelter.hanley.stade.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100123012328.GA3296@swelter.hanley.stade.co.uk> User-Agent: Mutt/1.4.2.3i X-Spam-Status: No, score=-4.3 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on ei.bzerk.org X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.0.1 (ei.bzerk.org [127.0.0.1]); Sat, 23 Jan 2010 12:43:14 +0100 (CET) Cc: Subject: Re: 8.0-RELEASE -> -STABLE and size of / X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 23 Jan 2010 11:43:16 -0000 On Sat, Jan 23, 2010 at 01:23:28AM +0000, Adrian Wontroba typed: > I concur that the 235 MB size of an amd64 8.0 kernel is a bit of a > surprise. An i386 kernel is a mere 135 MB. IMO increasing the sysinstall > default root slice size for at least amd64 would be a good thing. To be a little more precise: it's not the >kernel< that is so big. It's all the (mostly not needed) modules and symbol files that fill up / From owner-freebsd-stable@FreeBSD.ORG Sat Jan 23 12:14: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 F421A1065676 for ; Sat, 23 Jan 2010 12:14:22 +0000 (UTC) (envelope-from doconnor@gsoft.com.au) Received: from cain.gsoft.com.au (cain.gsoft.com.au [203.31.81.10]) by mx1.freebsd.org (Postfix) with ESMTP id 6817B8FC1B for ; Sat, 23 Jan 2010 12:14:21 +0000 (UTC) Received: from inchoate.gsoft.com.au (ppp121-45-156-195.lns6.adl6.internode.on.net [121.45.156.195]) (authenticated bits=0) by cain.gsoft.com.au (8.13.8/8.13.8) with ESMTP id o0NCE67l038279 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Sat, 23 Jan 2010 22:44:06 +1030 (CST) (envelope-from doconnor@gsoft.com.au) From: "Daniel O'Connor" To: freebsd-stable@freebsd.org Date: Sat, 23 Jan 2010 22:43:49 +1030 User-Agent: KMail/1.9.10 References: <20100122162155.GG3917@e-Gitt.NET> <20100123012328.GA3296@swelter.hanley.stade.co.uk> <20100123114209.GA21457@ei.bzerk.org> In-Reply-To: <20100123114209.GA21457@ei.bzerk.org> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart2088545.upQzu0N247"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <201001232244.03752.doconnor@gsoft.com.au> X-Spam-Score: -1.674 () AWL,BAYES_00,RDNS_DYNAMIC X-Scanned-By: MIMEDefang 2.63 on 203.31.81.10 Cc: Ruben de Groot Subject: Re: 8.0-RELEASE -> -STABLE and size of / X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 23 Jan 2010 12:14:23 -0000 --nextPart2088545.upQzu0N247 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Sat, 23 Jan 2010, Ruben de Groot wrote: > On Sat, Jan 23, 2010 at 01:23:28AM +0000, Adrian Wontroba typed: > > I concur that the 235 MB size of an amd64 8.0 kernel is a bit of a > > surprise. An i386 kernel is a mere 135 MB. IMO increasing the > > sysinstall default root slice size for at least amd64 would be a > > good thing. > > To be a little more precise: it's not the >kernel< that is so big. > It's all the (mostly not needed) modules and symbol files that fill > up / Maybe they could be put somewhere else.. I don't think you need them unless remote debugging and in that case you=20 are multiuser (I would have thought anyway). If they went into /usr then /boot could remain slim. =2D-=20 Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C --nextPart2088545.upQzu0N247 Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.12 (FreeBSD) iD8DBQBLWugL5ZPcIHs/zowRAlDUAJ9lH2/sfznnAd2T+U0z6x0jr+dW3QCgnwla X19tviWjqPrxQS8/lN7xSRU= =WEMg -----END PGP SIGNATURE----- --nextPart2088545.upQzu0N247-- From owner-freebsd-stable@FreeBSD.ORG Sat Jan 23 12:57: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 517CD1065672 for ; Sat, 23 Jan 2010 12:57:52 +0000 (UTC) (envelope-from goran.lowkrantz@ismobile.com) Received: from mail.ismobile.com (mail.ismobile.com [62.119.44.68]) by mx1.freebsd.org (Postfix) with ESMTP id C28F28FC12 for ; Sat, 23 Jan 2010 12:57:51 +0000 (UTC) Received: from mail.ismobile.com (mail.ismobile.com [62.119.44.68]) by dkim.mail.arcticgroup.se (Postfix) with ESMTP id 935891D0E5; Sat, 23 Jan 2010 13:57:49 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=ismobile.com; h=date:from :to:cc:subject:message-id:in-reply-to:references:mime-version :content-type:content-transfer-encoding; s=selector1; bh=UkI9lCU 61qLmaocLwJ/ad4og704=; b=SObSm6T7/wLmmqntxzwU/E/8H1nGoIJOXvdrf+0 HAWQSkUWOC/6qRzUp0DO0NrtRdZ4Pf5AFl6fjzBNTDO/6hjMjjdlXDso6F7XODRy lhKaxEn35XFcx1c0JQRVLwjrtPOksD+NyidNAYmuKeuKpqoWmjQN2Vjmb+hJ8RRt qWe0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=ismobile.com; h=date:from:to :cc:subject:message-id:in-reply-to:references:mime-version :content-type:content-transfer-encoding; q=dns; s=selector1; b=m T/qQuIGAD3+bhnJtZ15X2c6agsfPGQPJmW0+b8LMlWEXsHCSVqYQy0+pNo7U2pcl TOh82D+f+gEu5i+Ok8bKnhN3KB6Cvcpihid8WLRoWwHIDGMpQtbE26ykSyy9c4Mo /DMxOsLNgPQ8L8/GPInCUiuXUEBhfFUhb89F3LMpLI= Received: from [10.59.1.10] (170.Red-213-98-170.staticIP.rima-tde.net [213.98.170.170]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.ismobile.com (Postfix) with ESMTPSA id 53CF21D013; Sat, 23 Jan 2010 13:57:45 +0100 (CET) Date: Sat, 23 Jan 2010 13:57:41 +0100 From: Goran Lowkrantz To: Harald Schmalzbauer Message-ID: <0B97CD566B7D5364FC60EB7C@[169.254.1.1]> In-Reply-To: <4B5A4A8C.8070707@omnilan.de> References: <4B56AB6F.9010303@omnilan.de> <86eilhwzbh.fsf@kopusha.onet> <4B5A4A8C.8070707@omnilan.de> X-Mailer: Mulberry/4.0.8 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Cc: freebsd-stable@freebsd.org, Mikolaj Golub Subject: Re: top Segmentation faulting on 8.0p2 amd64 (nss_ldapd 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, 23 Jan 2010 12:57:52 -0000 I had exactly this problem. Removing an old /etc/localtime fixed the=20 problem. /glz --On January 23, 2010 2:02:04 +0100 Harald Schmalzbauer=20 wrote: > Mikolaj Golub schrieb am 22.01.2010 23:26 (localtime): >> On Wed, 20 Jan 2010 08:06:23 +0100 Harald Schmalzbauer wrote: >> >>> Dear all, >>> >>> I have no idea why top crashes with segmentation fault on my amd64 >>> machine running FreeBSD 8.0-RELEASE-p2. >>> If someone wants to have a loot at the core dump: >>> http://www.schmalzbauer.de/downloads/top.core >> >> core file is useless without binary and libraries. So it is better to >> run gdb on your host, produce backtrace and post here: >> >> gdb /usr/bin/top top.core >> bt >> >> And sure a backtrace from the top built with -g would be much better. >> >> cd /usr/src/usr.bin/top >> CFLAGS=3D-g make > > Unfortunately nss_ldap seems to be the culprit. > > gdb /usr/bin/top top.core > GNU gdb 6.1.1 [FreeBSD] > Copyright 2004 Free Software Foundation, Inc. > GDB is free software, covered by the GNU General Public License, and you > are > welcome to change it and/or distribute copies of it under certain > conditions. > Type "show copying" to see the conditions. > There is absolutely no warranty for GDB. Type "show warranty" for > details. > This GDB was configured as "amd64-marcel-freebsd"... > Core was generated by `top'. > Program terminated with signal 11, Segmentation fault. > Reading symbols from /lib/libncurses.so.8...done. > Loaded symbols for /lib/libncurses.so.8 > Reading symbols from /lib/libm.so.5...done. > Loaded symbols for /lib/libm.so.5 > Reading symbols from /lib/libkvm.so.5...done. > Loaded symbols for /lib/libkvm.so.5 > Reading symbols from /lib/libc.so.7...done. > Loaded symbols for /lib/libc.so.7 > Reading symbols from /usr/local/lib/nss_ldap.so.1...done. > Loaded symbols for /usr/local/lib/nss_ldap.so.1 > Reading symbols from /libexec/ld-elf.so.1...done. > Loaded symbols for /libexec/ld-elf.so.1 > bt: ># 0 0x0000000800d08403 in __nss_compat_gethostbyname () from ># /usr/local/lib/nss_ldap.so.1 0 0x0000000800d08403 in ># __nss_compat_gethostbyname () from /usr/local/lib/nss_ldap.so.1 1 ># 0x0000000800d0606f in _nss_ldap_getpwent_r () from ># /usr/local/lib/nss_ldap.so.1 2 0x00000008009ffc54 in ># __nss_compat_getpwent_r () from /lib/libc.so.7 3 0x0000000800a84a3d in ># nsdispatch () from /lib/libc.so.7 ># 4 0x0000000800a50976 in getpwent_r () from /lib/libc.so.7 ># 5 0x0000000800a50596 in sysctlbyname () from /lib/libc.so.7 ># 6 0x0000000000406c6d in machine_init (statics=3D0x7fffffffea30, ># do_unames=3D1 '\001') > at /usr/src/usr.bin/top/machine.c:257 ># 7 0x0000000000407a10 in main (argc=3D1, argv=3D0x7fffffffeb08) > at /usr/src/usr.bin/top/../../contrib/top/top.c:458 > > I'm using nss_ldapd-0.7.2 and there's no way to live without ldap... > > Any help highly appreciated! > > Thanks, > > -Harry > ................................................... the future isMobile Goran Lowkrantz System Architect, isMobile AB Sandviksgatan 81, PO Box 58, S-971 03 Lule=E5, Sweden Mobile: +46(0)70-587 87 82 http://www.ismobile.com ............................................... From owner-freebsd-stable@FreeBSD.ORG Sat Jan 23 13:11: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 ECAEB106568D for ; Sat, 23 Jan 2010 13:11:18 +0000 (UTC) (envelope-from goran.lowkrantz@ismobile.com) Received: from mail.ismobile.com (mail.ismobile.com [62.119.44.68]) by mx1.freebsd.org (Postfix) with ESMTP id 8242B8FC14 for ; Sat, 23 Jan 2010 13:11:18 +0000 (UTC) Received: from mail.ismobile.com (mail.ismobile.com [62.119.44.68]) by dkim.mail.arcticgroup.se (Postfix) with ESMTP id 4026E1D368; Sat, 23 Jan 2010 14:11:17 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=ismobile.com; h=date:from :to:cc:subject:message-id:in-reply-to:references:mime-version :content-type:content-transfer-encoding; s=selector1; bh=AnZ3Bup SsFnPEQSs8wyzkbnij1Y=; b=O0YYnlYoJejZ6XADYVwgW+vqCH95v+hYvs6Q7em /JnPwQQuB+6roQ1QFu5jkNwj8cYa+RpSm7XDURHo5VUX7zVsiWkND08uoJpGl2Da bigjMSu83iCpIXH6PjsXhzZVk0/SGZaRcg0r8bmmnMMXyE2v2DfMIHiv8yJRda4z r9Bg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=ismobile.com; h=date:from:to :cc:subject:message-id:in-reply-to:references:mime-version :content-type:content-transfer-encoding; q=dns; s=selector1; b=Y GGownKDvKPmFRo5Bzqxt6PskoDSru0ht2rC0R38yuCnnktrqkQBug/4Ng80o30b5 bhsmB4swiH7fUhyTLTx36GEhi6FLy3gzXVUCWJC1zpjQK8PZFaHlxR50qGdmEWUU UTFggCP988bXICq+rEFUVF7mIR35YrL0KZ/tREcJD8= Received: from [10.59.1.10] (170.Red-213-98-170.staticIP.rima-tde.net [213.98.170.170]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.ismobile.com (Postfix) with ESMTPSA id 5D16E1D1AD; Sat, 23 Jan 2010 14:11:11 +0100 (CET) Date: Sat, 23 Jan 2010 14:11:08 +0100 From: Goran Lowkrantz To: Harald Schmalzbauer Message-ID: <3835A6DDECB69492C81ABB85@[169.254.1.1]> In-Reply-To: <0B97CD566B7D5364FC60EB7C@[169.254.1.1]> References: <4B56AB6F.9010303@omnilan.de> <86eilhwzbh.fsf@kopusha.onet> <4B5A4A8C.8070707@omnilan.de> <0B97CD566B7D5364FC60EB7C@[169.254.1.1]> X-Mailer: Mulberry/4.0.8 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Cc: freebsd-stable@freebsd.org, Mikolaj Golub Subject: Re: top Segmentation faulting on 8.0p2 amd64 (nss_ldapd 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, 23 Jan 2010 13:11:19 -0000 Sorry, noise. Problem can back after a reboot. But now it only affects non=20 super-users, it works just fine for root. When it first happened for me,=20 even root cored. /glz --On January 23, 2010 13:57:41 +0100 Goran Lowkrantz=20 wrote: > I had exactly this problem. Removing an old /etc/localtime fixed the > problem. > > /glz > > --On January 23, 2010 2:02:04 +0100 Harald Schmalzbauer > wrote: > >> Mikolaj Golub schrieb am 22.01.2010 23:26 (localtime): >>> On Wed, 20 Jan 2010 08:06:23 +0100 Harald Schmalzbauer wrote: >>> >>>> Dear all, >>>> >>>> I have no idea why top crashes with segmentation fault on my amd64 >>>> machine running FreeBSD 8.0-RELEASE-p2. >>>> If someone wants to have a loot at the core dump: >>>> http://www.schmalzbauer.de/downloads/top.core >>> >>> core file is useless without binary and libraries. So it is better to >>> run gdb on your host, produce backtrace and post here: >>> >>> gdb /usr/bin/top top.core >>> bt >>> >>> And sure a backtrace from the top built with -g would be much better. >>> >>> cd /usr/src/usr.bin/top >>> CFLAGS=3D-g make >> >> Unfortunately nss_ldap seems to be the culprit. >> >> gdb /usr/bin/top top.core >> GNU gdb 6.1.1 [FreeBSD] >> Copyright 2004 Free Software Foundation, Inc. >> GDB is free software, covered by the GNU General Public License, and you >> are >> welcome to change it and/or distribute copies of it under certain >> conditions. >> Type "show copying" to see the conditions. >> There is absolutely no warranty for GDB. Type "show warranty" for >> details. >> This GDB was configured as "amd64-marcel-freebsd"... >> Core was generated by `top'. >> Program terminated with signal 11, Segmentation fault. >> Reading symbols from /lib/libncurses.so.8...done. >> Loaded symbols for /lib/libncurses.so.8 >> Reading symbols from /lib/libm.so.5...done. >> Loaded symbols for /lib/libm.so.5 >> Reading symbols from /lib/libkvm.so.5...done. >> Loaded symbols for /lib/libkvm.so.5 >> Reading symbols from /lib/libc.so.7...done. >> Loaded symbols for /lib/libc.so.7 >> Reading symbols from /usr/local/lib/nss_ldap.so.1...done. >> Loaded symbols for /usr/local/lib/nss_ldap.so.1 >> Reading symbols from /libexec/ld-elf.so.1...done. >> Loaded symbols for /libexec/ld-elf.so.1 >> bt: >># 0 0x0000000800d08403 in __nss_compat_gethostbyname () from >># /usr/local/lib/nss_ldap.so.1 0 0x0000000800d08403 in >># __nss_compat_gethostbyname () from /usr/local/lib/nss_ldap.so.1 1 >># 0x0000000800d0606f in _nss_ldap_getpwent_r () from >># /usr/local/lib/nss_ldap.so.1 2 0x00000008009ffc54 in >># __nss_compat_getpwent_r () from /lib/libc.so.7 3 0x0000000800a84a3d in >># nsdispatch () from /lib/libc.so.7 >># 4 0x0000000800a50976 in getpwent_r () from /lib/libc.so.7 >># 5 0x0000000800a50596 in sysctlbyname () from /lib/libc.so.7 >># 6 0x0000000000406c6d in machine_init (statics=3D0x7fffffffea30, >># do_unames=3D1 '\001') >> at /usr/src/usr.bin/top/machine.c:257 >># 7 0x0000000000407a10 in main (argc=3D1, argv=3D0x7fffffffeb08) >> at /usr/src/usr.bin/top/../../contrib/top/top.c:458 >> >> I'm using nss_ldapd-0.7.2 and there's no way to live without ldap... >> >> Any help highly appreciated! >> >> Thanks, >> >> -Harry >> > > > > ................................................... the future isMobile > > Goran Lowkrantz > System Architect, isMobile AB > Sandviksgatan 81, PO Box 58, S-971 03 Lule=E5, Sweden > Mobile: +46(0)70-587 87 82 > http://www.ismobile.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" ................................................... the future isMobile Goran Lowkrantz System Architect, isMobile AB Sandviksgatan 81, PO Box 58, S-971 03 Lule=E5, Sweden Mobile: +46(0)70-587 87 82 http://www.ismobile.com ............................................... From owner-freebsd-stable@FreeBSD.ORG Sat Jan 23 13:32: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 62436106566C for ; Sat, 23 Jan 2010 13:32:17 +0000 (UTC) (envelope-from to.my.trociny@gmail.com) Received: from mail-fx0-f226.google.com (mail-fx0-f226.google.com [209.85.220.226]) by mx1.freebsd.org (Postfix) with ESMTP id E5E3D8FC08 for ; Sat, 23 Jan 2010 13:32:16 +0000 (UTC) Received: by fxm26 with SMTP id 26so2041854fxm.13 for ; Sat, 23 Jan 2010 05:32:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:to:cc:subject:references :organization:from:date:in-reply-to:message-id:user-agent :mime-version:content-type; bh=ijdBMjXGh13IpiR2APaJFueH/aSO9KC2jbc5y/+N2RE=; b=jpU1VjfSc3Md3T4rakMDy+BspZ9pib1vvrpiYrCMbhgg/oUzunYQaeJJkju3w8Zzv1 w9zhxULFG60iVIqsHksqiaXyN8bxz8Ql5vSmHJoL6XxZrKycFopbiNVA804w76CpUQvI 7R1Y2K9IGh7ucKKjOSS09mF8VM+yaSCohj7R0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=to:cc:subject:references:organization:from:date:in-reply-to :message-id:user-agent:mime-version:content-type; b=OoCjKXXlYTyQ+TbDzHumXYEp/iLgW54u1G/0pguVuqwdMkGnJnzhljWL2D3n/9bXCU QXCXWgxf74hABAWgnil7jNys4ppTQhdrHpJMFo02jeB36kvOCUYP9d8zmEhhE3FqJzGH ti0upBic8b1eNPhrnj6xvqRErmfYZuXqjKCpM= Received: by 10.103.81.5 with SMTP id i5mr2206624mul.29.1264253535480; Sat, 23 Jan 2010 05:32:15 -0800 (PST) Received: from localhost (vpn-193-138-135-114.customer.onet.com.ua [193.138.135.114]) by mx.google.com with ESMTPS id i7sm12997217mue.46.2010.01.23.05.32.14 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sat, 23 Jan 2010 05:32:14 -0800 (PST) To: Harald Schmalzbauer References: <4B56AB6F.9010303@omnilan.de> <86eilhwzbh.fsf@kopusha.onet> <4B5A4A8C.8070707@omnilan.de> Organization: TOA Ukraine From: Mikolaj Golub Date: Sat, 23 Jan 2010 15:32:11 +0200 In-Reply-To: <4B5A4A8C.8070707@omnilan.de> (Harald Schmalzbauer's message of "Sat\, 23 Jan 2010 02\:02\:04 +0100") Message-ID: <86tyudueuc.fsf@kopusha.onet> User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: freebsd-stable@freebsd.org Subject: Re: top Segmentation faulting on 8.0p2 amd64 (nss_ldapd 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, 23 Jan 2010 13:32:17 -0000 On Sat, 23 Jan 2010 02:02:04 +0100 Harald Schmalzbauer wrote: > gdb /usr/bin/top top.core > GNU gdb 6.1.1 [FreeBSD] > Copyright 2004 Free Software Foundation, Inc. > GDB is free software, covered by the GNU General Public License, and you are > welcome to change it and/or distribute copies of it under certain > conditions. > Type "show copying" to see the conditions. > There is absolutely no warranty for GDB. Type "show warranty" for details. > This GDB was configured as "amd64-marcel-freebsd"... > Core was generated by `top'. > Program terminated with signal 11, Segmentation fault. > Reading symbols from /lib/libncurses.so.8...done. > Loaded symbols for /lib/libncurses.so.8 > Reading symbols from /lib/libm.so.5...done. > Loaded symbols for /lib/libm.so.5 > Reading symbols from /lib/libkvm.so.5...done. > Loaded symbols for /lib/libkvm.so.5 > Reading symbols from /lib/libc.so.7...done. > Loaded symbols for /lib/libc.so.7 > Reading symbols from /usr/local/lib/nss_ldap.so.1...done. > Loaded symbols for /usr/local/lib/nss_ldap.so.1 > Reading symbols from /libexec/ld-elf.so.1...done. > Loaded symbols for /libexec/ld-elf.so.1 > bt: > #0 0x0000000800d08403 in __nss_compat_gethostbyname () from > /usr/local/lib/nss_ldap.so.1 > #0 0x0000000800d08403 in __nss_compat_gethostbyname () from > /usr/local/lib/nss_ldap.so.1 > #1 0x0000000800d0606f in _nss_ldap_getpwent_r () from > /usr/local/lib/nss_ldap.so.1 It is worth rebuilding and installing nss_ldap.so with debugging symbols. > #2 0x00000008009ffc54 in __nss_compat_getpwent_r () from /lib/libc.so.7 > #3 0x0000000800a84a3d in nsdispatch () from /lib/libc.so.7 > #4 0x0000000800a50976 in getpwent_r () from /lib/libc.so.7 > #5 0x0000000800a50596 in sysctlbyname () from /lib/libc.so.7 And may be libc.so :-) > #6 0x0000000000406c6d in machine_init (statics=0x7fffffffea30, > do_unames=1 '\001') > at /usr/src/usr.bin/top/machine.c:257 > #7 0x0000000000407a10 in main (argc=1, argv=0x7fffffffeb08) > at /usr/src/usr.bin/top/../../contrib/top/top.c:458 > > I'm using nss_ldapd-0.7.2 and there's no way to live without ldap... -- Mikolaj Golub From owner-freebsd-stable@FreeBSD.ORG Sat Jan 23 14:10: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 36DD01065670; Sat, 23 Jan 2010 14:10:48 +0000 (UTC) (envelope-from nox@jelal.kn-bremen.de) Received: from smtp.kn-bremen.de (gelbbaer.kn-bremen.de [78.46.108.116]) by mx1.freebsd.org (Postfix) with ESMTP id B79398FC13; Sat, 23 Jan 2010 14:10:47 +0000 (UTC) Received: by smtp.kn-bremen.de (Postfix, from userid 10) id 05D041E0076C; Sat, 23 Jan 2010 15:10:44 +0100 (CET) Received: from triton8.kn-bremen.de (noident@localhost [127.0.0.1]) by triton8.kn-bremen.de (8.14.3/8.14.3) with ESMTP id o0NE7lqh002621; Sat, 23 Jan 2010 15:07:47 +0100 (CET) (envelope-from nox@triton8.kn-bremen.de) Received: (from nox@localhost) by triton8.kn-bremen.de (8.14.3/8.14.3/Submit) id o0NE7l8j002620; Sat, 23 Jan 2010 15:07:47 +0100 (CET) (envelope-from nox) Date: Sat, 23 Jan 2010 15:07:47 +0100 (CET) From: Juergen Lock Message-Id: <201001231407.o0NE7l8j002620@triton8.kn-bremen.de> To: mav@FreeBSD.org X-Newsgroups: local.list.freebsd.current In-Reply-To: <4B55D9D4.1000008@FreeBSD.org> Organization: home Cc: FreeBSD-Current , FreeBSD Stable Subject: Re: Pack of CAM improvements X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 23 Jan 2010 14:10:48 -0000 In article <4B55D9D4.1000008@FreeBSD.org> you write: >Hi. Hi! > >I've made a patch, that should solve set of problems of CAM ATA and CAM >generally. I would like to ask for testing and feedback. > >What patch does: >- It unifies bus reset/probe sequence. Whenever bus attached at boot or >later, CAM will automatically reset and scan it. It allows to remove >duplicate code from many drivers. >- Any bus, attached before CAM completed it's boot-time initialization, >will equally join to the process, delaying boot if needed. >- New kern.cam.boot_delay loader tunable should help controllers that >are still unable to register their buses in time (such as slow USB/ >PCCard/ CardBus devices). >- To allow synchronization between different CAM levels, concept of >requests priorities was extended. Priorities now split between several >"run levels". Device can be freezed at specified level, allowing higher >priority requests to pass. For example, no payload requests allowed, >until PMP driver enable port. ATA XPT negotiate transfer parameters, >periph driver configure caching and so on. >- Frozen requests are no more counted by request allocation scheduler. >It fixes deadlocks, when frozen low priority payload requests occupying >slots, required by higher levels to manage theit execution. >- Two last changes were holding proper ATA reinitialization and error >recovery implementation. Now it is done: SATA controllers and Port >Multipliers now implement automatic hot-plug and should correctly >recover from timeouts and bus resets. > >Patch can be found here: >http://people.freebsd.org/~mav/cam-ata.20100119.patch > >Feedback as always welcome. Ok, applied this to stable/8, and the good news is the box still seems to run (using ahci(4) on an sb700 controller and siis(4) on a SiI3132 pcie card, altho atm there's only an optical drive on that one.) But what this still doesn't fix is the broken `test unit ready' command on ada devices, which also makes things like `cdrecord -scanbus' hang the bus. :( (A few days ago I also got a hang after wanting to try out xfburn, I suspect for the same reason...) Here is my earlier report: http://docs.freebsd.org/cgi/mid.cgi?20090817163144.GA2991 Oh and I also still use this patch to scsi_cd.c to be able to read discs that fail the `read toc' command, like bluray (data) discs. PR s here: http://www.freebsd.org/cgi/query-pr.cgi?pr=138789 Index: src/sys/cam/scsi/scsi_cd.c =================================================================== RCS file: /home/scvs/src/sys/cam/scsi/scsi_cd.c,v retrieving revision 1.107.2.6 diff -u -p -u -r1.107.2.6 scsi_cd.c --- src/sys/cam/scsi/scsi_cd.c 25 Dec 2009 08:06:35 -0000 1.107.2.6 +++ src/sys/cam/scsi/scsi_cd.c 23 Jan 2010 13:29:19 -0000 @@ -2874,11 +2874,17 @@ cdcheckmedia(struct cam_periph *periph) } softc->flags |= CD_FLAG_VALID_TOC; + +bailout: softc->disk->d_sectorsize = softc->params.blksize; softc->disk->d_mediasize = (off_t)softc->params.blksize * softc->params.disksize; +/* if bailout: + * is here read requests will fail when the toc cant be read although + * CD_FLAG_VALID_MEDIA is set. + */ /* * We unconditionally (re)set the blocksize each time the From owner-freebsd-stable@FreeBSD.ORG Sat Jan 23 14:50: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 A64AB106566C for ; Sat, 23 Jan 2010 14:50:53 +0000 (UTC) (envelope-from jonathan@kc8onw.net) Received: from mail.kc8onw.net (kc8onw.net [206.55.209.81]) by mx1.freebsd.org (Postfix) with ESMTP id 79B688FC13 for ; Sat, 23 Jan 2010 14:50:53 +0000 (UTC) Received: from [10.70.3.187] (c-98-223-164-104.hsd1.in.comcast.net [98.223.164.104]) by mail.kc8onw.net (Postfix) with ESMTPSA id 6D18321158 for ; Sat, 23 Jan 2010 09:50:52 -0500 (EST) Message-ID: <4B5B0C87.6090001@kc8onw.net> Date: Sat, 23 Jan 2010 09:49:43 -0500 From: Jonathan User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1.7) Gecko/20100111 Thunderbird/3.0.1 MIME-Version: 1.0 To: freebsd-stable@freebsd.org References: <7346c5c61001030842r7dc76199y51e4c1c90a3eea6e@mail.gmail.com> <7346c5c61001091706m45a3a2a5k3ca8bb0c4bec5ea8@mail.gmail.com> <7346c5c61001171521w1ca4738w98e8fcca24643cda@mail.gmail.com> <201001180829.48126.npapke@acm.org> <7346c5c61001190840k31466754i32b2ae833390b79b@mail.gmail.com> <20100119170101.GA80917@icarus.home.lan> In-Reply-To: <20100119170101.GA80917@icarus.home.lan> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: ZFS performance degradation over time X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 23 Jan 2010 14:50:53 -0000 On 1/19/2010 12:01 PM, Jeremy Chadwick wrote: > On Tue, Jan 19, 2010 at 11:40:50AM -0500, Garrett Moore wrote: >> I've been watching my memory usage and I have no idea what is consuming >> memory as 'Active'. >> >> Last night I had around 6500MB 'Active' again, 1500MB Wired, no inact, ~30MB >> buf, no free, and ~100MB swap used. My performance copying ZFS->ZFS was >> again slow (<1MB/s). I tried killing rTorrent and no significant amount of >> memory was reclaimed - maybe 100MB. `ps aux` showed no processes using any >> significant amount of memory, and I was definitely nowhere near 6500MB >> usage. >> >> I tried running the perl oneliner again to hog a bunch of memory, and almost >> all of the Active memory was IMMEDIATELY marked as Free, and my performance >> was excellent again. I'm having this same issue, although my performance does not go back to freshly booted levels it still goes from <1MBs to ~11MB/s after running that Perl one liner. I'm running RELENG 8 as of about 2 days ago FreeBSD 8.0-STABLE #2 r202777: Fri Jan 22 00:15:43 EST 2010 [...] amd64 Just to be clear it also seems to be related to something rtorrent does while downloading torrents but it's not rtorrent itself using the memory because quitting rtorrent doesn't release more than 100MB of multiple GB of memory marked as active but running the Perl one liner does. >> I'm not sure what in userland could be causing the issue. The only things >> I've installed are rTorrent, lighttpd, samba, smartmontools, vim, bash, >> Python, Perl, and SABNZBd. There is nothing that *should* be consuming any >> serious amount of memory. > > I've two recommendations: > > 1) Have you considered "upgrading" to RELENG_8 (e.g. 8.0-STABLE) instead > of sticking with 8.0-RELEASE? There's been a recent MFC to RELENG_8 > which pertain to ARC drainage. I'm referring to the commit labelled > revision 1.22.2.2 (RELENG_8): I definitely have that commit, see above. I just checked my arc size and it's only using ~170 of a ~600MB limit. This is after running the Perl script and without the strangely large amount of "active" memory, I forgot to run on before as well. This machine is just a personal file server so I can restart it as needed for testing and I have serial console access to it if needed. Thanks, Jonathan From owner-freebsd-stable@FreeBSD.ORG Sat Jan 23 14:51: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 C0365106566C; Sat, 23 Jan 2010 14:51:09 +0000 (UTC) (envelope-from to.my.trociny@gmail.com) Received: from mail-fx0-f226.google.com (mail-fx0-f226.google.com [209.85.220.226]) by mx1.freebsd.org (Postfix) with ESMTP id 272D98FC20; Sat, 23 Jan 2010 14:51:08 +0000 (UTC) Received: by fxm26 with SMTP id 26so2076519fxm.13 for ; Sat, 23 Jan 2010 06:51:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:to:cc:subject:references :organization:from:date:in-reply-to:message-id:user-agent :mime-version:content-type; bh=2oX4HIw7PMEf2Z+H5a4yCLpdVvoFVr1p8PUmtvc0GUw=; b=xEYj8RmyTBMzkSI+jI7MlTcQOhnBWAXIhFDlOwUzf2XGIUsMY9FMVFBWHNLnGBbEap NTodRVr6uuvOkaIYRozC6T1qxRYp0kxMBiIFputEAbZ2U+2dotwizK8Cci0otHTwy91Q e4dnStFZcODMeNI8TeFqFg77dILppI71ErAw4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=to:cc:subject:references:organization:from:date:in-reply-to :message-id:user-agent:mime-version:content-type; b=atBgxoyZ9VkvH18svZeKRIq++6BvutO6xJ+9wL4dmk97L871SNP0jloG5KlDBOsklH +SuTercGMmseD2RkL7Nb2G1nR7Z2+adBPXy5Mt9BGzZGI2qZc5jctagXxVSeUv80kQeK jeTe0gxb74xIjOYT9RHltHyNfkICajN4Xz86Y= Received: by 10.102.17.15 with SMTP id 15mr2210217muq.133.1264258267836; Sat, 23 Jan 2010 06:51:07 -0800 (PST) Received: from localhost (vpn-193-138-135-114.customer.onet.com.ua [193.138.135.114]) by mx.google.com with ESMTPS id b9sm13212343mug.9.2010.01.23.06.51.06 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sat, 23 Jan 2010 06:51:06 -0800 (PST) To: Rick Macklem References: <86ocl272mb.fsf@kopusha.onet> <86tyuqnz9x.fsf@zhuzha.ua1> <86zl4awmon.fsf@zhuzha.ua1> <86vdeywmha.fsf@zhuzha.ua1> <86vdeuuo2y.fsf@zhuzha.ua1> Organization: TOA Ukraine From: Mikolaj Golub Date: Sat, 23 Jan 2010 16:51:04 +0200 In-Reply-To: (Rick Macklem's message of "Fri\, 22 Jan 2010 17\:13\:09 -0500 \(EST\)") Message-ID: <86pr50vprb.fsf@kopusha.onet> User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: freebsd-fs@FreeBSD.org, freebsd-stable@FreeBSD.org Subject: Re: FreeBSD NFS client/Linux NFS server issue X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 23 Jan 2010 14:51:09 -0000 On Fri, 22 Jan 2010 17:13:09 -0500 (EST) Rick Macklem wrote: > On Fri, 22 Jan 2010, Rick Macklem wrote: > >> >> There should probably be some sort of 3 way handshake between >> the code in nfs_asyncio() after calling nfs_nfsnewiod() and the >> code near the beginning of nfssvc_iod(), but I think the following >> somewhat cheesy fix might do the trick: >> > [stuff deleted] > I know it's a little weird to reply to my own posting, but I think > this might be a reasonable patch (I have only tested it for a few > minutes at this point). > > I basically redefined nfs_iodwant[] as a tri-state variable (although > it was a struct proc *, it was only tested NULL/non-NULL). > 0 - was NULL > 1 - was non-NULL > -1 - just created by nfs_asyncio() and will be used by it > > I'll keep testing it, but hopefully someone else can test and/or > review it... rick I applied your patch to FreeBSD8.0 (the box I get on weekend :-), mounted 10 shares, set vfs.nfs.iodmaxidle=10 (to have nfsiod creation more frequently) and have been running tests for 4 hours -- just to check the patch does not break anything. No issues have been detected. It would be very nice to have this patch committed. -- Mikolaj Golub From owner-freebsd-stable@FreeBSD.ORG Sat Jan 23 15:27: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 E04F2106568B for ; Sat, 23 Jan 2010 15:27:50 +0000 (UTC) (envelope-from freebsd@southportcomputers.co.uk) Received: from ted.southportcomputers.co.uk (ted.southportcomputers.co.uk [92.48.124.28]) by mx1.freebsd.org (Postfix) with ESMTP id 9D3838FC1F for ; Sat, 23 Jan 2010 15:27:50 +0000 (UTC) Received: from office.southportcomputers.co.uk ([78.105.116.12] helo=[192.168.1.68]) by ted.southportcomputers.co.uk with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NYhtl-000KdL-Fz for freebsd-stable@freebsd.org; Sat, 23 Jan 2010 15:27:41 +0000 Message-ID: <4B5B1550.2070906@southportcomputers.co.uk> Date: Sat, 23 Jan 2010 15:27:12 +0000 From: Colin User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: freebsd-stable@freebsd.org References: <4B596838.9020609@southportcomputers.co.uk> <20100122094546.GB6681@titania.njm.me.uk> <20100122111708.GA67643@icarus.home.lan> <201001221029.43926.jhb@freebsd.org> In-Reply-To: <201001221029.43926.jhb@freebsd.org> Content-Type: text/plain; charset=iso-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ted.southportcomputers.co.uk X-AntiAbuse: Original Domain - freebsd.org X-AntiAbuse: Originator/Caller UID/GID - [26 6] / [26 6] X-AntiAbuse: Sender Address Domain - southportcomputers.co.uk X-Source: X-Source-Args: X-Source-Dir: Subject: Re: make buildkernel failing on zfs - fixed but now everything is slow X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 23 Jan 2010 15:27:51 -0000 Hi again folks. Thanks to all the suggestions I have gotten the new world/kernel up and running finally, unfortunately I seem to be having problems now. The entire system is sluggish and unresponsive. Even trying to scroll through a vi session jumps and pauses all the time. Whether it is bringing up an SSH session, something through apache or anything else on the system is can take anywhere up to 20 second to respond which is not good. top gives me the impression that its not any kind of runaway process or anything like that last pid: 78629; load averages: 0.00, 0.03, 0.06 116 processes: 1 running, 115 sleeping CPU: 0.6% user, 0.0% nice, 0.6% system, 0.0% interrupt, 98.9% idle Mem: 787M Active, 2057M Inact, 200M Wired, 101M Cache, 112M Buf, 114M Free Swap: 8000M Total, 1708K Used, 7998M Free There's nothing obvious that I can see in any other logfiles, are there any tools or other things that I can use to figure out why the system is so sluggish now? Cheers Colin. From owner-freebsd-stable@FreeBSD.ORG Sat Jan 23 15:32:13 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 930871065670 for ; Sat, 23 Jan 2010 15:32:13 +0000 (UTC) (envelope-from kensmith@buffalo.edu) Received: from localmailA.acsu.buffalo.edu (localmailA.acsu.buffalo.edu [128.205.5.196]) by mx1.freebsd.org (Postfix) with ESMTP id 623348FC20 for ; Sat, 23 Jan 2010 15:32:13 +0000 (UTC) Received: from localmailA.acsu.buffalo.edu (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 8537AB252 for ; Sat, 23 Jan 2010 10:32:12 -0500 (EST) Received: from localmailA.acsu.buffalo.edu (localhost [127.0.0.1]) by localmailA.acsu.buffalo.edu (Postfix) with ESMTP id 1B725B25B for ; Sat, 23 Jan 2010 10:32:12 -0500 (EST) Received: from mweb1.acsu.buffalo.edu (mweb1.acsu.buffalo.edu [128.205.5.238]) by localmailA.acsu.buffalo.edu (Prefixe) with ESMTP id 0D0FAB252 for ; Sat, 23 Jan 2010 10:32:12 -0500 (EST) Received: from [192.168.1.101] (cpe-76-180-182-44.buffalo.res.rr.com [76.180.182.44]) by mweb1.acsu.buffalo.edu (Postfix) with ESMTP id C69415B003A for ; Sat, 23 Jan 2010 10:32:11 -0500 (EST) From: Ken Smith To: freebsd-stable Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-V1cPMA4B2eAk2rOr8k4v" Organization: U. Buffalo Date: Sat, 23 Jan 2010 10:32:10 -0500 Message-ID: <1264260730.81422.5.camel@neo.cse.buffalo.edu> Mime-Version: 1.0 X-Mailer: Evolution 2.28.1 FreeBSD GNOME Team Port X-PM-EL-Spam-Prob: XX: 27% Subject: Beginning the 7.3-RELEASE release cycle... X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 23 Jan 2010 15:32:13 -0000 --=-V1cPMA4B2eAk2rOr8k4v Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Just a quick note to say we're beginning the release cycle for 7.3-RELEASE. Code freeze on stable/7 began now, and stable/7 has been adjusted to say that it is 7.3-PRERELEASE to reflect that. More details will follow but this is the current target schedule: 01/22: code freeze 01/25: BETA 02/08: RC1 02/22: RC2 03/01: RELEASE Thanks. --=20 Ken Smith - From there to here, from here to | kensmith@buffalo.edu there, funny things are everywhere. | - Theodore Geisel | --=-V1cPMA4B2eAk2rOr8k4v Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (FreeBSD) iEYEABECAAYFAktbFnoACgkQ/G14VSmup/YjqgCfW8G4dSVQrZVYFLAAFaah4BeX NSEAn3Qdous8AG8CqRuuPre4O0mP2TKt =O8sr -----END PGP SIGNATURE----- --=-V1cPMA4B2eAk2rOr8k4v-- From owner-freebsd-stable@FreeBSD.ORG Sat Jan 23 17:38: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 B3079106566C for ; Sat, 23 Jan 2010 17:38:04 +0000 (UTC) (envelope-from barney@pit.databus.com) Received: from mail1.aceinnovative.com (mail1.aceinnovative.com [66.114.74.12]) by mx1.freebsd.org (Postfix) with ESMTP id 6291D8FC08 for ; Sat, 23 Jan 2010 17:38:04 +0000 (UTC) Received: from pit.databus.com ([71.167.133.111]) (authenticated bits=0) by mail1.aceinnovative.com (8.13.8/8.13.8) with ESMTP id o0NHOteJ008823 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Sat, 23 Jan 2010 12:24:55 -0500 Received: from pit.databus.com (localhost [127.0.0.1]) by pit.databus.com (8.14.3/8.14.3) with ESMTP id o0NHOsS4069238 for ; Sat, 23 Jan 2010 12:24:55 -0500 (EST) (envelope-from barney@pit.databus.com) X-DKIM: Sendmail DKIM Filter v2.8.3 pit.databus.com o0NHOsS4069238 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=databus.com; s=20091218; t=1264267495; bh=9JSpdS2r/FuHk2twqQiAilx2Uq9eSc14JVXoVY/P/o4=; l=606; h=Date:From:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:In-Reply-To; b=DQZLoydAUSOt8Ll8eJhQxgwQaqXQQiv75DZrEmjD46dhUmmYrTZPPcgjK8hWvkD7p 8KU3FwLt9WnVkV9glvZ81UHmWeHsO9c0NrZLFji4t8ITHfjbfQbsHiPiYaYiaX992S 95EPlI4zm902hhYecREtkRV6U4fcueB1MpYN8Gq0= Received: (from barney@localhost) by pit.databus.com (8.14.3/8.14.3/Submit) id o0NHOs72069237 for freebsd-stable@freebsd.org; Sat, 23 Jan 2010 12:24:54 -0500 (EST) (envelope-from barney) Date: Sat, 23 Jan 2010 12:24:54 -0500 From: Barney Wolff Cc: freebsd-stable@freebsd.org Message-ID: <20100123172454.GA68693@pit.databus.com> References: <20100122162155.GG3917@e-Gitt.NET> <20100123012328.GA3296@swelter.hanley.stade.co.uk> <20100123114209.GA21457@ei.bzerk.org> <201001232244.03752.doconnor@gsoft.com.au> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201001232244.03752.doconnor@gsoft.com.au> User-Agent: Mutt/1.5.20 (2009-06-14) Subject: Re: 8.0-RELEASE -> -STABLE and size of / X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 23 Jan 2010 17:38:04 -0000 On Sat, Jan 23, 2010 at 10:43:49PM +1030, Daniel O'Connor wrote: > On Sat, 23 Jan 2010, Ruben de Groot wrote: > > To be a little more precise: it's not the >kernel< that is so big. > > It's all the (mostly not needed) modules and symbol files that fill > > up / > > Maybe they could be put somewhere else.. I have a stupid question: Why are modules built and installed for things that are already included in the kernel? That would seem (I haven't looked) to be a simple change that would both speed up builds and shrink /boot/kernel. -- Barney Wolff I never met a computer I didn't like. From owner-freebsd-stable@FreeBSD.ORG Sat Jan 23 17:46: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 0FAF0106566C; Sat, 23 Jan 2010 17:46:24 +0000 (UTC) (envelope-from gary.jennejohn@freenet.de) Received: from mout6.freenet.de (mout6.freenet.de [IPv6:2001:748:100:40::2:8]) by mx1.freebsd.org (Postfix) with ESMTP id 96B8A8FC16; Sat, 23 Jan 2010 17:46:23 +0000 (UTC) Received: from [195.4.92.20] (helo=10.mx.freenet.de) by mout6.freenet.de with esmtpa (ID gary.jennejohn@freenet.de) (port 25) (Exim 4.70 #1) id 1NYk3y-0000aK-SJ; Sat, 23 Jan 2010 18:46:22 +0100 Received: from p57ae1388.dip0.t-ipconnect.de ([87.174.19.136]:36163 helo=ernst.jennejohn.org) by 10.mx.freenet.de with esmtpa (ID gary.jennejohn@freenet.de) (port 25) (Exim 4.69 #94) id 1NYk3x-0005Do-Lr; Sat, 23 Jan 2010 18:46:22 +0100 Date: Sat, 23 Jan 2010 18:46:19 +0100 From: Gary Jennejohn To: Juergen Lock Message-ID: <20100123184619.257203d9@ernst.jennejohn.org> In-Reply-To: <201001231407.o0NE7l8j002620@triton8.kn-bremen.de> References: <4B55D9D4.1000008@FreeBSD.org> <201001231407.o0NE7l8j002620@triton8.kn-bremen.de> X-Mailer: Claws Mail 3.7.4 (GTK+ 2.16.2; amd64-portbld-freebsd9.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: mav@FreeBSD.org, FreeBSD-Current , Stable , FreeBSD Subject: Re: Pack of CAM improvements X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: gary.jennejohn@freenet.de List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Jan 2010 17:46:24 -0000 On Sat, 23 Jan 2010 15:07:47 +0100 (CET) Juergen Lock wrote: > But what > this still doesn't fix is the broken `test unit ready' command on ada > devices, which also makes things like `cdrecord -scanbus' hang the bus. :( > (A few days ago I also got a hang after wanting to try out xfburn, > I suspect for the same reason...) > > Here is my earlier report: > http://docs.freebsd.org/cgi/mid.cgi?20090817163144.GA2991 > I started seeing a problem a few days ago with one of my DVD drives (a burner at cd0) under 9-current, which makes it impossible to use it even to simply read a DVD. Here the (rather strange IMO) output in dmesg: cd0: Removable CD-ROM SCSI-0 device cd0: 66.700MB/s transfers (UDMA4, PIO size 65534bytes) cd0: Attempt to query device size failed: UNIT ATTENTION, Power on, reset, or bus device reset occurred cd1 at ata0 bus 0 scbus6 target 1 lun 0 cd1: Removable CD-ROM SCSI-0 device cd1: 33.300MB/s transfers (UDMA2, PIO size 65534bytes) cd1: Attempt to query device size failed: NOT READY, Medium not present - tray closed I haven't the foggiest why cd0 behaves diffrently from cd1, which is a vanilla DVD drive and just works. --- Gary Jennejohn From owner-freebsd-stable@FreeBSD.ORG Sat Jan 23 18:03: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 A5AA1106566B for ; Sat, 23 Jan 2010 18:03:51 +0000 (UTC) (envelope-from freebsd-stable@track.pupworks.com) Received: from pupworks.com (cl-252.chi-02.us.sixxs.net [IPv6:2001:4978:f:fb::2]) by mx1.freebsd.org (Postfix) with ESMTP id 6D1A08FC1C for ; Sat, 23 Jan 2010 18:03:51 +0000 (UTC) Received: from [IPv6:2001:4978:168::225:ff:fe4e:60d1] (unknown [IPv6:2001:4978:168:0:225:ff:fe4e:60d1]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by pupworks.com (Postfix) with ESMTPSA id 91C521E63CF1; Sat, 23 Jan 2010 18:03:50 +0000 (UTC) Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Nat Howard In-Reply-To: <20100123100713.X50938@maildrop.int.zabbadoz.net> Date: Sat, 23 Jan 2010 13:03:49 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <54E2892F-3F65-473E-9660-D2E8276E631B@track.pupworks.com> References: <20100123100713.X50938@maildrop.int.zabbadoz.net> To: "Bjoern A. Zeeb" X-Mailer: Apple Mail (2.1077) Cc: freebsd-stable@freebsd.org Subject: Re: IPSec NAT-T in transport 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: Sat, 23 Jan 2010 18:03:51 -0000 Much obliged for the answer, Bjoern, but I don't follow your logic --=20 If the NAT-T implementation on the L2TP Server (a freebsd box) is = broken, wouldn't it be the one generating things with the wrong = checksum? If that's so, then surely=20 the point "A" wouldn't record seeing any incoming checksum errors, as = they would all be outgoing packets, correct? =20 Thanks for helping to shed light on this puzzle! On Jan 23, 2010, at 5:09 AM, Bjoern A. Zeeb wrote: > On Fri, 22 Jan 2010, Nat Howard wrote: >=20 >> I'm very interested in this problem -- I want to run an L2TP server = myself. Is anyone actually working on this? I might be able to chip = in a few bucks... >>=20 >> But I'm not seeing bad checksums. Here's my setup: >>=20 >>=20 >> L2tp server A<---------------->B Freebsd NAT box C = <-----------internal network----------->D my mac >>=20 >> Where should I be seeing the bad checksums? A, B, C, or D? >>=20 >>=20 >> Looking only at B, I don't see any bad udp checksums, but I'm seeing = a bunch of these (IP numbers changed to bracketed names): >=20 > This doesn't say if you are using IPsec but I will asume so, that > would mean that you D "my mac" would initiate the connection and > the A node "L2tp server" would then be the other end. If that's a > FreeBSD box as well, you should check statistics there. The NAT > gateway in between has nothing to do with this, only the IPsec ends. >=20 > /bz >=20 > --=20 > Bjoern A. Zeeb It will not break if you know what you are = doing. From owner-freebsd-stable@FreeBSD.ORG Sat Jan 23 18:31: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 68E40106566B for ; Sat, 23 Jan 2010 18:31:00 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta08.emeryville.ca.mail.comcast.net (qmta08.emeryville.ca.mail.comcast.net [76.96.30.80]) by mx1.freebsd.org (Postfix) with ESMTP id 4E68C8FC19 for ; Sat, 23 Jan 2010 18:31:00 +0000 (UTC) Received: from omta02.emeryville.ca.mail.comcast.net ([76.96.30.19]) by qmta08.emeryville.ca.mail.comcast.net with comcast id Z5QP1d0060QkzPwA86X05S; Sat, 23 Jan 2010 18:31:00 +0000 Received: from koitsu.dyndns.org ([98.248.46.159]) by omta02.emeryville.ca.mail.comcast.net with comcast id Z6Wz1d00D3S48mS8N6X0MN; Sat, 23 Jan 2010 18:31:00 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id AB7581E3033; Sat, 23 Jan 2010 10:30:58 -0800 (PST) Date: Sat, 23 Jan 2010 10:30:58 -0800 From: Jeremy Chadwick To: freebsd-stable@freebsd.org Message-ID: <20100123183058.GA19836@icarus.home.lan> References: <4B596838.9020609@southportcomputers.co.uk> <20100122094546.GB6681@titania.njm.me.uk> <20100122111708.GA67643@icarus.home.lan> <201001221029.43926.jhb@freebsd.org> <4B5B1550.2070906@southportcomputers.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4B5B1550.2070906@southportcomputers.co.uk> User-Agent: Mutt/1.5.20 (2009-06-14) Subject: Re: make buildkernel failing on zfs - fixed but now everything is slow X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 23 Jan 2010 18:31:00 -0000 On Sat, Jan 23, 2010 at 03:27:12PM +0000, Colin wrote: > There's nothing obvious that I can see in any other logfiles, are > there any tools or other things that I can use to figure out why the > system is so sluggish now? A couple things I can think of: vmstat -c 30 -w 1 vmstat -i vmstat -s -- | 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 Sat Jan 23 18:52: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 3AB35106566B for ; Sat, 23 Jan 2010 18:52:43 +0000 (UTC) (envelope-from erwin@mail.droso.net) Received: from mail.droso.net (koala.ipv6.droso.net [IPv6:2001:6c8:6:c:20d:56ff:fe6f:f935]) by mx1.freebsd.org (Postfix) with ESMTP id E57A58FC0A for ; Sat, 23 Jan 2010 18:52:42 +0000 (UTC) Received: by mail.droso.net (Postfix, from userid 1001) id CDCF81CC5D; Sat, 23 Jan 2010 19:52:41 +0100 (CET) Date: Sat, 23 Jan 2010 19:52:41 +0100 From: Erwin Lansing To: Alexander Leidinger Message-ID: <20100123185241.GI23919@droso.net> References: <7346c5c61001030842r7dc76199y51e4c1c90a3eea6e@mail.gmail.com> <7346c5c61001091706m45a3a2a5k3ca8bb0c4bec5ea8@mail.gmail.com> <7346c5c61001171521w1ca4738w98e8fcca24643cda@mail.gmail.com> <201001180829.48126.npapke@acm.org> <7346c5c61001190840k31466754i32b2ae833390b79b@mail.gmail.com> <20100119170101.GA80917@icarus.home.lan> <20100120114730.916917ef0eu668n4@webmail.leidinger.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="kRPgt2ku+S/0Bic/" Content-Disposition: inline In-Reply-To: <20100120114730.916917ef0eu668n4@webmail.leidinger.net> X-Operating-System: FreeBSD/i386 7.2-STABLE User-Agent: Mutt/1.5.20 (2009-06-14) Cc: freebsd-stable@FreeBSD.org, Jeremy Chadwick Subject: Re: ZFS performance degradation over time X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 23 Jan 2010 18:52:43 -0000 --kRPgt2ku+S/0Bic/ Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Jan 20, 2010 at 11:47:30AM +0100, Alexander Leidinger wrote: >=20 > Quoting Jeremy Chadwick (from Tue, 19 Jan =20 > 2010 09:01:01 -0800): >=20 > > I've two recommendations: > > > > 1) Have you considered "upgrading" to RELENG_8 (e.g. 8.0-STABLE) instead > > of sticking with 8.0-RELEASE? There's been a recent MFC to RELENG_8 > > which pertain to ARC drainage. I'm referring to the commit labelled > > revision 1.22.2.2 (RELENG_8): > > > > http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/cddl/contrib/opensolaris/= uts/common/fs/zfs/arc.c >=20 > This patch can be merged stand-alone if necessary, no need to go to =20 > RELENG_8 if there are reservations. >=20 > The commit you refer to above is just doing this: limiting the arc =20 > more to the arc_max than it was the case before. >=20 > This patch is in 7-stable too (in case someone is interested). >=20 Two weeks ago, we started experiencing similar symptoms on the pointyhat package cluster. This was on 9.0-CURRENT from last September. Upgrading to last weeks HEAD has solved the problem for us. The system is heavily loaded both on CPU, memory and disk, and since the original patch was committed back in October, my guess is that it was this specific commit that solved the issue. I'd recommend people still experiencing this issue to upgrade to a system that includes this change, be it 8.0-STABLE or 7.2-STABLE after January 8, or manually merging it. Cheers, -erwin --=20 Erwin Lansing http://droso.org Prediction is very difficult especially about the future erwin@FreeBSD.org --kRPgt2ku+S/0Bic/ Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (FreeBSD) iD8DBQFLW0V5qy9aWxUlaZARAiWEAJ92IWkbKKCVc7MBa+rMaehgmnFdKwCfY2MD qjIXh1+Ljf2vqF8nav+/CB0= =QlqM -----END PGP SIGNATURE----- --kRPgt2ku+S/0Bic/-- From owner-freebsd-stable@FreeBSD.ORG Sat Jan 23 19:14: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 8044010656A5 for ; Sat, 23 Jan 2010 19:14:51 +0000 (UTC) (envelope-from freebsd@southportcomputers.co.uk) Received: from ted.southportcomputers.co.uk (ted.southportcomputers.co.uk [92.48.124.28]) by mx1.freebsd.org (Postfix) with ESMTP id A9ACD8FC26 for ; Sat, 23 Jan 2010 19:14:50 +0000 (UTC) Received: from office.southportcomputers.co.uk ([78.105.116.12] helo=[192.168.1.68]) by ted.southportcomputers.co.uk with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NYlRY-0007GC-7u for freebsd-stable@freebsd.org; Sat, 23 Jan 2010 19:14:49 +0000 Message-ID: <4B5B4AA4.5090200@southportcomputers.co.uk> Date: Sat, 23 Jan 2010 19:14:44 +0000 From: Colin User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: freebsd-stable@freebsd.org References: <4B596838.9020609@southportcomputers.co.uk> <20100122094546.GB6681@titania.njm.me.uk> <20100122111708.GA67643@icarus.home.lan> <201001221029.43926.jhb@freebsd.org> <4B5B1550.2070906@southportcomputers.co.uk> <20100123183058.GA19836@icarus.home.lan> In-Reply-To: <20100123183058.GA19836@icarus.home.lan> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ted.southportcomputers.co.uk X-AntiAbuse: Original Domain - freebsd.org X-AntiAbuse: Originator/Caller UID/GID - [26 6] / [26 6] X-AntiAbuse: Sender Address Domain - southportcomputers.co.uk X-Source: X-Source-Args: X-Source-Dir: Subject: Re: make buildkernel failing on zfs - fixed but now everything is slow X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 23 Jan 2010 19:14:51 -0000 Jeremy Chadwick wrote: > On Sat, Jan 23, 2010 at 03:27:12PM +0000, Colin wrote: > >> There's nothing obvious that I can see in any other logfiles, are >> there any tools or other things that I can use to figure out why the >> system is so sluggish now? >> > > A couple things I can think of: > > vmstat -c 30 -w 1 > vmstat -i > vmstat -s > > Thanks for the reply. I must admit that the ins and outs of paging and interrupts are something I don't have much expertise in. I've asked the colo company to look into it but I've put the output of those commands into pastebin incase anything stands out. http://www.pastebin.org/81107 You guys have been very helpful these couple of months so I guess I'd best go find that donate button. Its the least I can do! Cheers, Colin. From owner-freebsd-stable@FreeBSD.ORG Sat Jan 23 20:05: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 4C31F106566C for ; Sat, 23 Jan 2010 20:05:01 +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 0818F8FC24 for ; Sat, 23 Jan 2010 20:05:00 +0000 (UTC) Received: from elsa.codelab.cz (localhost.codelab.cz [127.0.0.1]) by elsa.codelab.cz (Postfix) with ESMTP id 01F1719E019; Sat, 23 Jan 2010 21:05:00 +0100 (CET) Received: from [192.168.1.2] (r5bb235.net.upc.cz [86.49.61.235]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by elsa.codelab.cz (Postfix) with ESMTPSA id EBF4B19E023; Sat, 23 Jan 2010 21:04:57 +0100 (CET) Message-ID: <4B5B5669.9080906@quip.cz> Date: Sat, 23 Jan 2010 21:04:57 +0100 From: Miroslav Lachman <000.fbsd@quip.cz> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9.1.7) Gecko/20100104 SeaMonkey/2.0.2 MIME-Version: 1.0 To: Jeremy Chadwick References: <20100122162155.GG3917@e-Gitt.NET> <20100122170716.GA75020@icarus.home.lan> In-Reply-To: <20100122170716.GA75020@icarus.home.lan> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org Subject: Re: 8.0-RELEASE -> -STABLE and size of / X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 23 Jan 2010 20:05:01 -0000 Jeremy Chadwick wrote: [...] > While I'm here, I figure I'd share how I end up partitioning most of the > server systems I maintain. I use this general "formula" when building a > new system, unless it's a 4-disk box (see bottom of mail): > > ad4s1a = / = UFS2 = 1GB > ad4s1b = swap = (2*RAM) or (2*MaxRAMPossible) > ad4s1d = /var = UFS2+SU = 16GB (mandatory: must be>= 2*RAM) > ad4s1e = /tmp = UFS2+SU = (2*RAM) > ad4s1f = /usr = UFS2+SU = 16GB Why you are suggesting /var >= 2*RAM? Is it just for saving crash dumps or anything else? And why so big /tmp? I am running servers with smaller sizes for years without any problem. (I am not using crash dumps and if I need it, it seems better to use dumpdir="/my/large/storage") Miroslav Lachman From owner-freebsd-stable@FreeBSD.ORG Sat Jan 23 20:21: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 6735E106568F for ; Sat, 23 Jan 2010 20:21:50 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta12.emeryville.ca.mail.comcast.net (qmta12.emeryville.ca.mail.comcast.net [76.96.27.227]) by mx1.freebsd.org (Postfix) with ESMTP id 4DD638FC24 for ; Sat, 23 Jan 2010 20:21:49 +0000 (UTC) Received: from omta05.emeryville.ca.mail.comcast.net ([76.96.30.43]) by qmta12.emeryville.ca.mail.comcast.net with comcast id Z7qi1d0010vp7WLAC8Mq6v; Sat, 23 Jan 2010 20:21:50 +0000 Received: from koitsu.dyndns.org ([98.248.46.159]) by omta05.emeryville.ca.mail.comcast.net with comcast id Z8Mp1d00W3S48mS8R8MqZW; Sat, 23 Jan 2010 20:21:50 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id B75EC1E3033; Sat, 23 Jan 2010 12:21:48 -0800 (PST) Date: Sat, 23 Jan 2010 12:21:48 -0800 From: Jeremy Chadwick To: freebsd-stable@freebsd.org Message-ID: <20100123202148.GA22096@icarus.home.lan> References: <20100122162155.GG3917@e-Gitt.NET> <20100122170716.GA75020@icarus.home.lan> <4B5B5669.9080906@quip.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4B5B5669.9080906@quip.cz> User-Agent: Mutt/1.5.20 (2009-06-14) Subject: Re: 8.0-RELEASE -> -STABLE and size of / X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 23 Jan 2010 20:21:50 -0000 On Sat, Jan 23, 2010 at 09:04:57PM +0100, Miroslav Lachman wrote: > Jeremy Chadwick wrote: > > [...] > > >While I'm here, I figure I'd share how I end up partitioning most of the > >server systems I maintain. I use this general "formula" when building a > >new system, unless it's a 4-disk box (see bottom of mail): > > > >ad4s1a = / = UFS2 = 1GB > >ad4s1b = swap = (2*RAM) or (2*MaxRAMPossible) > >ad4s1d = /var = UFS2+SU = 16GB (mandatory: must be>= 2*RAM) > >ad4s1e = /tmp = UFS2+SU = (2*RAM) > >ad4s1f = /usr = UFS2+SU = 16GB > > Why you are suggesting /var >= 2*RAM? Is it just for saving crash > dumps or anything else? 1) Kernel panics/crash dumps are a big focus, yes. There's nothing worse than experiencing one, only to find out that savecore(8) can't do its job because /var/crash lacks the space. The system then boots anyway, swap starts getting used as normal, and the dump is therefore lost. Chance of debugging this post-mortem: zero. Additionally, people these days are often upgrading RAM in their systems as well; they start out with 1-2GB and create /var possibly with the knowledge of the above ordeal (re: crash dumps). Then they later upgrade to 4GB or 8GB RAM, and suddenly realise that they can't grow /var to deal with a crash dump. 2) I tend to keep a large amount of logs on systems, going back weeks if not months. This is intentional; it's amazing how often a customer or user will ask for some information from 3 or 4 months prior. FreeBSD's Apache port out-of-the-box logs to /var/log/httpd-*, and what we do is mostly web content serving. Let's also not forget about /var/log/maillog. I also advocate use of /var/log/all.log. I think it's fairly well-established at this point that I focus on server environments and not workstations (where /var probably doesn't need to be anywhere near that size). Folks should always review their needs, keeping expansion possibility in mind, when doing filesystem creation. > And why so big /tmp? I am running servers with smaller sizes for years > without any problem. My recommendation above doesn't imply those who don't use it will have problems -- each environment/system is different. That said, it's amazing how much software out there blindly uses /tmp. Last year I ran into this situation: an older server (1GB /tmp) started behaving oddly due to /tmp filling. A user of the system was using lynx to download some large files (an ISO image and something else, I forget what). lynx saves data its downloading to /tmp, and once it completes, the user is prompted where to save the data (CWD being the default). "So tune lynx to use /var/tmp or some other path" -- sure, that'd work, except lynx is just one of many programs which could do this. I'd rather not "tune them all". :-) /tmp is more or less universal. Hope this sheds some light on my decisions. :-) -- | 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 Sat Jan 23 20:45: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 C0505106566B for ; Sat, 23 Jan 2010 20:45:16 +0000 (UTC) (envelope-from cvs-src@yandex.ru) Received: from forward11.mail.yandex.net (forward11.mail.yandex.net [95.108.130.93]) by mx1.freebsd.org (Postfix) with ESMTP id 716CC8FC17 for ; Sat, 23 Jan 2010 20:45:16 +0000 (UTC) Received: from smtp11.mail.yandex.net (smtp11.mail.yandex.net [95.108.130.67]) by forward11.mail.yandex.net (Yandex) with ESMTP id C6869F49012 for ; Sat, 23 Jan 2010 23:34:40 +0300 (MSK) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1264278880; bh=4ex+2nY/BY9K0uq72YSzrwZkf6eETZvDLJLdZhNu94M=; h=Message-ID:Date:From:MIME-Version:To:CC:Subject:Content-Type: Content-Transfer-Encoding; b=dyIWcFsstmoQvHzXEbMAJNExSHmdFpBexXIW+KBLXWMUn1w6rHzBIG2IxbmdOUyc7 qrJyLRURuGHVHUK4M1G2a2+ShYWqvWm+mIqvDGMfe77W51AFNebfVySJny6XtzAxqu fxQY6+9iKIIR38qUV2LCDJEkPSoQabvsanN7yO5Y= Received: from smeshariki2.local (unknown [77.66.250.137]) by smtp11.mail.yandex.net (Yandex) with ESMTPSA id EB9466730083; Sat, 23 Jan 2010 23:34:38 +0300 (MSK) Message-ID: <4B5B5D46.3040400@yandex.ru> Date: Sat, 23 Jan 2010 23:34:14 +0300 From: Ruslan Mahmatkhanov User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; ru-RU; rv:1.9.1.7) Gecko/20100122 Thunderbird/3.0.1 MIME-Version: 1.0 To: freebsd-stable@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Yandex-TimeMark: 1264278880 X-Yandex-Spam: 1 X-Yandex-Front: smtp11.mail.yandex.net Cc: cvs-src@yandex.ru Subject: Strange symbols in man-pages X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 23 Jan 2010 20:45:16 -0000 Good day! I'm viewing dd man-page in gnome with gnome-terminal and i see some strange symbols instead `-`. For example from man dd(1): http://www.onlinedisk.ru/get_image.php?id=327964 The problem is rised only when i on ru_RU.UTF-8 locale. There is no problem with C-locale. Is this known problem and does anybody have a solution? Thanks in advance and keep me in Cc: please (i'm not subscribed to freebsd-stable@). PS. Using 8.0-STABLE. From owner-freebsd-stable@FreeBSD.ORG Sat Jan 23 20:51: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 70C431065672 for ; Sat, 23 Jan 2010 20:51:00 +0000 (UTC) (envelope-from alteriks@gmail.com) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.159]) by mx1.freebsd.org (Postfix) with ESMTP id 0616F8FC1D for ; Sat, 23 Jan 2010 20:50:59 +0000 (UTC) Received: by fg-out-1718.google.com with SMTP id 16so419847fgg.13 for ; Sat, 23 Jan 2010 12:50:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type; bh=7xVZQMoNEwXWGDDE6Vmz880pvmnVF8ykblP8U8RrlpE=; b=cAP0DHln1GSfkUWmlA1FBqWmlrpYj8ltco/MOM6EtytBwliWBkFth/5VlpizTt/HBL qEsbyYfPzvqmycfJVO8WaI4EFvrxeT9wrjbjwXGTjPPTkbV58nDvoCbZvqjnScBP0y0O nWIRzcIhfgfB0gRVjpyd1HbaJa8U9OItMGkJQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=XRRCvw+I+axMFB+bCa34P83zDlSM8rJN1yLExskYXYTSq6zvtzV3aqg9cNSAwdpBQo KSiJNHSvH20pFn5gvRWXJrrNBp2hGWBv78pg1ucUk2dcqgD0icetHlfwFj1PI4JtaklQ 5kJ71LNwiIn0nBonqKHgUgyCsmjjBprwtsWew= MIME-Version: 1.0 Received: by 10.87.70.31 with SMTP id x31mr7454619fgk.19.1264278407440; Sat, 23 Jan 2010 12:26:47 -0800 (PST) Date: Sat, 23 Jan 2010 20:26:47 +0000 Message-ID: <684e57ec1001231226p447ea769q6379c1aa099b0216@mail.gmail.com> From: Krzysztof Dajka To: freebsd-stable@freebsd.org Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Extra keys in multimedia keyboard doesn't work X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 23 Jan 2010 20:51:00 -0000 Hi, I've recently got a new Microsoft Wireless Keyboard v2.0. I am curios whether multimedia keyboards work with FreeBSD out of box or should I configure something or use some quirks to enable extra keys. This keyboard works fine with Linux 2.6.30 all keys work otb. I tried using xev in FreeBSD but none of additional keys returned anything after pressing it. Are multimedia keyboard supported in FreeBSD or am I having bad luck with mine keyboard and should I send PR. My system: uname -a FreeBSD altstation 8.0-RELEASE-p2 FreeBSD 8.0-RELEASE-p2 #0: Tue Jan 5 21:11:58 UTC 2010 root@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC amd64 usbconfig -u 1 -a 3 dump_device_desc ugen1.3: at usbus1, cfg=0 md=HOST spd=FULL (12Mbps) pwr=ON bLength = 0x0012 bDescriptorType = 0x0001 bcdUSB = 0x0200 bDeviceClass = 0x0000 bDeviceSubClass = 0x0000 bDeviceProtocol = 0x0000 bMaxPacketSize0 = 0x0040 idVendor = 0x045e idProduct = 0x0745 bcdDevice = 0x0251 iManufacturer = 0x0001 iProduct = 0x0002 iSerialNumber = 0x0000 bNumConfigurations = 0x0001 Thanks in advance. From owner-freebsd-stable@FreeBSD.ORG Sat Jan 23 21:02:25 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 DCE761065670 for ; Sat, 23 Jan 2010 21:02:25 +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 965938FC08 for ; Sat, 23 Jan 2010 21:02:25 +0000 (UTC) Received: from elsa.codelab.cz (localhost.codelab.cz [127.0.0.1]) by elsa.codelab.cz (Postfix) with ESMTP id A42F319E019; Sat, 23 Jan 2010 22:02:23 +0100 (CET) Received: from [192.168.1.2] (r5bb235.net.upc.cz [86.49.61.235]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by elsa.codelab.cz (Postfix) with ESMTPSA id 6B41D19E023; Sat, 23 Jan 2010 22:02:21 +0100 (CET) Message-ID: <4B5B63DC.1000301@quip.cz> Date: Sat, 23 Jan 2010 22:02:20 +0100 From: Miroslav Lachman <000.fbsd@quip.cz> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9.1.7) Gecko/20100104 SeaMonkey/2.0.2 MIME-Version: 1.0 To: Jeremy Chadwick References: <20100122162155.GG3917@e-Gitt.NET> <20100122170716.GA75020@icarus.home.lan> <4B5B5669.9080906@quip.cz> <20100123202148.GA22096@icarus.home.lan> In-Reply-To: <20100123202148.GA22096@icarus.home.lan> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org Subject: Re: 8.0-RELEASE -> -STABLE and size of / X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 23 Jan 2010 21:02:25 -0000 Jeremy Chadwick wrote: [...] > 2) I tend to keep a large amount of logs on systems, going back weeks if > not months. This is intentional; it's amazing how often a customer or > user will ask for some information from 3 or 4 months prior. > > FreeBSD's Apache port out-of-the-box logs to /var/log/httpd-*, and what > we do is mostly web content serving. Let's also not forget about > /var/log/maillog. I also advocate use of /var/log/all.log. > > I think it's fairly well-established at this point that I focus on > server environments and not workstations (where /var probably doesn't > need to be anywhere near that size). Folks should always review their > needs, keeping expansion possibility in mind, when doing filesystem > creation. I keep log files (apache, lighttpd, proftpd, maillog) about 2 weeks on the machine (rotated daily), but I have them all for minimal 3 months on our central backup machine (I have most logs archived for more than 1 year - depending on free space of the backup storage ;]) >> And why so big /tmp? I am running servers with smaller sizes for years >> without any problem. > > My recommendation above doesn't imply those who don't use it will have > problems -- each environment/system is different. > > That said, it's amazing how much software out there blindly uses /tmp. > Last year I ran into this situation: an older server (1GB /tmp) started > behaving oddly due to /tmp filling. A user of the system was using lynx > to download some large files (an ISO image and something else, I forget > what). lynx saves data its downloading to /tmp, and once it completes, > the user is prompted where to save the data (CWD being the default). > > "So tune lynx to use /var/tmp or some other path" -- sure, that'd work, > except lynx is just one of many programs which could do this. I'd > rather not "tune them all". :-) /tmp is more or less universal. Most of our servers are without shell users and without programs like lynx :) So I hope I am safe with 1-2GB /tmp (I don't remember any accident with "no space left on device /tmp" for past 4-5 years. Maybe I am just lucky guy ;) > Hope this sheds some light on my decisions. :-) Thank you for you explanation, it makes sense in your environment. Miroslav Lachman From owner-freebsd-stable@FreeBSD.ORG Sat Jan 23 21:22:00 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 868E71065676 for ; Sat, 23 Jan 2010 21:22:00 +0000 (UTC) (envelope-from imb@protected-networks.net) Received: from sarah.protected-networks.net (sarah.protected-networks.net [IPv6:2001:470:1f07:4e1::1]) by mx1.freebsd.org (Postfix) with ESMTP id 27FFB8FC14 for ; Sat, 23 Jan 2010 21:22:00 +0000 (UTC) Received: from toshi.auburn.protected-networks.net (toshi.auburn.protected-networks.net [202.12.127.84]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "Iain Butler", Issuer "RSA Class 2 Personal CA" (verified OK)) (Authenticated sender: imb) by sarah.protected-networks.net (Postfix) with ESMTPSA id CD4BE612E for ; Sat, 23 Jan 2010 16:21:58 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=protected-networks.net; s=200705; t=1264281719; bh=BKvgpWLGWVYnjfCqzqzdK0y066CAVwFZiU1LFPcEoB8=; h=Message-ID:Date:From:MIME-Version:To:Subject:Content-Type; b=MMtWxstK7btLzfO+c0E2VTKFoE2VFx72LAAPzI2zGhNO8KmpOgVtuDJUJZFD9Bq80 mTZaPw/pFHr8Ba6UkRtdfKlFWw/ReSNUJWZGlTb2+WXOWkB3ra+kQsTDPArWDFx DomainKey-Signature: a=rsa-sha1; s=200509; d=protected-networks.net; c=nofws; q=dns; h=message-id:date:from:user-agent:mime-version:to:subject: x-enigmail-version:openpgp:content-type; b=hnQQ9Tki3RDr5Loc4w5tUoWIp/IQYyh5ryzsz+AytFu7tMZgU9IimH0OXduXoJC08 OXjZ6qitY+bEIY3E8HZcvbMFnjHNwdX6QyRU7Zro5pwOnYimFWqb+ChLlN8kiy2 Message-ID: <4B5B686E.6090500@protected-networks.net> Date: Sat, 23 Jan 2010 16:21:50 -0500 From: Michael Butler User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.9.1.7) Gecko/20100121 Thunderbird/3.0.1 MIME-Version: 1.0 To: stable@freebsd.org X-Enigmail-Version: 1.0 OpenPGP: id=0442D492 Content-Type: multipart/mixed; boundary="------------020101080504010803010404" X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Subject: RELENG_7: SVN rev 202895 fails to compile X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 23 Jan 2010 21:22:00 -0000 This is a multi-part message in MIME format. --------------020101080504010803010404 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The attached patch corrects the number of arguments given to vfs_unbusy() as introduced by SVN rev 202895 on the assumption that the idea was to migrate from vfs_rel() to vfs_unbusy() in those instances, imb -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (FreeBSD) iEYEARECAAYFAktbaG0ACgkQQv9rrgRC1JLiWACeNriU5ahu1GC5BmXKfnn0L5fQ oSgAn0/x4P0joInG0ZKYmzM65MDVns+v =JWN4 -----END PGP SIGNATURE----- --------------020101080504010803010404-- From owner-freebsd-stable@FreeBSD.ORG Sat Jan 23 21:25:37 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 CDD6B1065672 for ; Sat, 23 Jan 2010 21:25:37 +0000 (UTC) (envelope-from imb@protected-networks.net) Received: from sarah.protected-networks.net (sarah.protected-networks.net [IPv6:2001:470:1f07:4e1::1]) by mx1.freebsd.org (Postfix) with ESMTP id 901258FC12 for ; Sat, 23 Jan 2010 21:25:37 +0000 (UTC) Received: from toshi.auburn.protected-networks.net (toshi.auburn.protected-networks.net [202.12.127.84]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "Iain Butler", Issuer "RSA Class 2 Personal CA" (verified OK)) (Authenticated sender: imb) by sarah.protected-networks.net (Postfix) with ESMTPSA id B8FBF612E for ; Sat, 23 Jan 2010 16:25:36 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=protected-networks.net; s=200705; t=1264281936; bh=2k3ouCgM5KeXL5l7Hm9ix+RT4W6W8XHlyAHpke9qkOE=; h=Message-ID:Date:From:MIME-Version:To:Subject:References: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=QgSboAiXxqMRCG5peuKk/aMPRPc67ZB9pjtG2ErUPanMH8ZYi6WO+Vc2Ru1As/+cC jYGWhVLYvHwFejzI4cH+qzdRDz7hnfy4uakGQ59HAGu8FnBd5z1SFruToIFJU6l DomainKey-Signature: a=rsa-sha1; s=200509; d=protected-networks.net; c=nofws; q=dns; h=message-id:date:from:user-agent:mime-version:to:subject: references:in-reply-to:x-enigmail-version:openpgp:content-type:content-transfer-encoding; b=RCoAUqXBogAU75jjND+fDUDJyESj0h9L5eqWRKiJCZg+d7OkV6hriWZV1+rBObGA0 skX+02n7BSef1cOlRlvehiEfOdUGVvbAh2Dozdj0XsKKZQO/MgaRj4jergt9Joi Message-ID: <4B5B694F.8050708@protected-networks.net> Date: Sat, 23 Jan 2010 16:25:35 -0500 From: Michael Butler User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.9.1.7) Gecko/20100121 Thunderbird/3.0.1 MIME-Version: 1.0 To: stable@freebsd.org References: <4B5B686E.6090500@protected-networks.net> In-Reply-To: <4B5B686E.6090500@protected-networks.net> X-Enigmail-Version: 1.0 OpenPGP: id=0442D492 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Subject: Re: RELENG_7: SVN rev 202895 fails to compile X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 23 Jan 2010 21:25:37 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 01/23/10 16:21, Michael Butler wrote: > The attached patch corrects the number of arguments given to > vfs_unbusy() as introduced by SVN rev 202895 on the assumption that the > idea was to migrate from vfs_rel() to vfs_unbusy() in those instances, > > imb Ugh .. I hate it when that happens :-( *** src/sys/kern/vfs_syscalls.c.orig Sat Jan 23 16:13:07 2010 - --- src/sys/kern/vfs_syscalls.c Sat Jan 23 16:13:39 2010 *************** *** 337,343 **** } *buf = *sp; out: ! vfs_unbusy(mp); VFS_UNLOCK_GIANT(vfslocked); if (mtx_owned(&Giant)) printf("statfs(%d): %s: %d\n", vfslocked, path, error); - --- 337,343 ---- } *buf = *sp; out: ! vfs_unbusy(mp, td); VFS_UNLOCK_GIANT(vfslocked); if (mtx_owned(&Giant)) printf("statfs(%d): %s: %d\n", vfslocked, path, error); *************** *** 429,435 **** *buf = *sp; out: if (mp) ! vfs_unbusy(mp); VFS_UNLOCK_GIANT(vfslocked); return (error); } - --- 429,435 ---- *buf = *sp; out: if (mp) ! vfs_unbusy(mp, td); VFS_UNLOCK_GIANT(vfslocked); return (error); } -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (FreeBSD) iEYEARECAAYFAktbaU4ACgkQQv9rrgRC1JJFNACfT1cQo6RUiC6qWc5CfkyTDMhW nQgAn0TZwJxIR7Ijpt39yaAV+KH/+GFN =Fagv -----END PGP SIGNATURE----- From owner-freebsd-stable@FreeBSD.ORG Sat Jan 23 21:46: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 2FBD11065696 for ; Sat, 23 Jan 2010 21:46:30 +0000 (UTC) (envelope-from cliftonr@lava.net) Received: from outgoing03.lava.net (outgoing03.lava.net [IPv6:2001:1888:0:1:202:b3ff:fe1d:6b98]) by mx1.freebsd.org (Postfix) with ESMTP id CA6058FC12 for ; Sat, 23 Jan 2010 21:46:29 +0000 (UTC) Received: from malasada.lava.net (malasada.lava.net [64.65.64.17]) by outgoing03.lava.net (Postfix) with ESMTP id EAE2710168; Sat, 23 Jan 2010 11:46:28 -1000 (HST) Received: by malasada.lava.net (Postfix, from userid 102) id A1E15153882; Sat, 23 Jan 2010 11:46:28 -1000 (HST) Date: Sat, 23 Jan 2010 11:46:28 -1000 From: Clifton Royston To: Jeremy Chadwick Message-ID: <20100123214628.GA10271@lava.net> Mail-Followup-To: Jeremy Chadwick , freebsd-stable@freebsd.org References: <20100122162155.GG3917@e-Gitt.NET> <20100122170716.GA75020@icarus.home.lan> <4B5B5669.9080906@quip.cz> <20100123202148.GA22096@icarus.home.lan> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100123202148.GA22096@icarus.home.lan> User-Agent: Mutt/1.4.2.3i Cc: freebsd-stable@freebsd.org Subject: Re: 8.0-RELEASE -> -STABLE and size of / X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 23 Jan 2010 21:46:30 -0000 On Sat, Jan 23, 2010 at 12:21:48PM -0800, Jeremy Chadwick wrote: > On Sat, Jan 23, 2010 at 09:04:57PM +0100, Miroslav Lachman wrote: > > Jeremy Chadwick wrote: ... > > And why so big /tmp? I am running servers with smaller sizes for years > > without any problem. > > My recommendation above doesn't imply those who don't use it will have > problems -- each environment/system is different. > > That said, it's amazing how much software out there blindly uses /tmp. > Last year I ran into this situation: an older server (1GB /tmp) started > behaving oddly due to /tmp filling. A user of the system was using lynx > to download some large files (an ISO image and something else, I forget > what). lynx saves data its downloading to /tmp, and once it completes, > the user is prompted where to save the data (CWD being the default). Another example: the stock /usr/bin/sort uses /tmp for its temporary storage when it needs to start using disk. You can redirect that via -T if you think ahead and realize that it's going to be a problem, but if you are just whipping up a quick shell script and later happen to run it on much bigger inputs than you were expecting you can run out of space on /. (Yes, that happened to me fairly recently on several systems, when some log files weren't being rotated on schedule.) An alternative solution is to symlink /tmp to /var/tmp, which I've done on many systems, assuming that nothing in the /etc/rc sequence will need /tmp before filesystems are mounted. (I suppose putting it on its own filesystem also assumes that.) In general, I think you've got a good idea and I plan to start adopting that in the future. -- Clifton -- Clifton Royston -- cliftonr@iandicomputing.com / cliftonr@lava.net President - I and I Computing * http://www.iandicomputing.com/ Custom programming, network design, systems and network consulting services From owner-freebsd-stable@FreeBSD.ORG Sat Jan 23 21:59: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 86C57106568D; Sat, 23 Jan 2010 21:59:18 +0000 (UTC) (envelope-from lists@yamagi.org) Received: from mail.yamagi.org (yamagi.org [88.198.78.242]) by mx1.freebsd.org (Postfix) with ESMTP id 48ED58FC13; Sat, 23 Jan 2010 21:59:17 +0000 (UTC) Received: from [192.168.1.150] (f054138044.adsl.alicedsl.de [78.54.138.44]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yamagi.org (Postfix) with ESMTP id 6D8321084A16; Sat, 23 Jan 2010 22:39:30 +0100 (CET) Date: Sat, 23 Jan 2010 22:39:29 +0100 (CET) From: Yamagi Burmeister X-X-Sender: yamagi@idate.home.yamagi.org To: Alexander Motin In-Reply-To: <4B55D9D4.1000008@FreeBSD.org> Message-ID: References: <4B55D9D4.1000008@FreeBSD.org> User-Agent: Alpine 2.00 (OSX 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: FreeBSD-Current , FreeBSD Stable Subject: Re: Pack of CAM improvements X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 23 Jan 2010 21:59:18 -0000 On Tue, 19 Jan 2010, Alexander Motin wrote: > Hi. > > I've made a patch, that should solve set of problems of CAM ATA and CAM > generally. I would like to ask for testing and feedback. [snip] Hello, applied this patch to 8-stable recompiled the kernel and rebooted. The kernel did not boot it hangs while probing the ahci-controller. The error message is: ahcich0: Timeout on slot 0 ahcich0: is 00000002 cs 00000000 ss 000000000 rs 00000001 tfs 50 serr 00000000 run_interrupt_driven_hooks: still waiting after 60 seconds for xpt_config After that the kernel hangs forever. A 8-stable without the patch shows ahcich0: Timeout on slot 0 run_interrupt_driven_hooks: still waiting after 60 seconds for xpt_config and boots but doesn't find any hard disks. It's an Asus M3A-H/HDMI motherboard with AMD SB710 southbridge. The harddisk is an Western Digital WD10EAVS. Both are working with the old ata implementation in AHCI mode. pciconf output of the controller is atapci0@pci0:0:17:0: class=0x010601 card=0x43911002 chip=0x43911002 rev=0x00 hdr=0x00 Thanks, Yamagi -- Homepage: www.yamagi.org Jabber: yamagi@yamagi.org GnuPG/GPG: 0xEFBCCBCB From owner-freebsd-stable@FreeBSD.ORG Sat Jan 23 22:39:51 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 91224106568B for ; Sat, 23 Jan 2010 22:39:51 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (skuns.zoral.com.ua [91.193.166.194]) by mx1.freebsd.org (Postfix) with ESMTP id F3B158FC13 for ; Sat, 23 Jan 2010 22:39:50 +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 o0NMdkAM023944 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 24 Jan 2010 00:39:46 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.3/8.14.3) with ESMTP id o0NMdkHf005121; Sun, 24 Jan 2010 00:39:46 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.3/8.14.3/Submit) id o0NMdknw005120; Sun, 24 Jan 2010 00:39:46 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Sun, 24 Jan 2010 00:39:46 +0200 From: Kostik Belousov To: Michael Butler Message-ID: <20100123223946.GB3877@deviant.kiev.zoral.com.ua> References: <4B5B686E.6090500@protected-networks.net> <4B5B694F.8050708@protected-networks.net> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Y7xTucakfITjPcLV" Content-Disposition: inline In-Reply-To: <4B5B694F.8050708@protected-networks.net> 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=-4.4 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: stable@freebsd.org Subject: Re: RELENG_7: SVN rev 202895 fails to compile X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 23 Jan 2010 22:39:51 -0000 --Y7xTucakfITjPcLV Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Jan 23, 2010 at 04:25:35PM -0500, Michael Butler wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 >=20 > On 01/23/10 16:21, Michael Butler wrote: > > The attached patch corrects the number of arguments given to > > vfs_unbusy() as introduced by SVN rev 202895 on the assumption that the > > idea was to migrate from vfs_rel() to vfs_unbusy() in those instances, > >=20 > > imb Thank you for the report, it should be fixed by r202902. --Y7xTucakfITjPcLV Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (FreeBSD) iEYEARECAAYFAktberEACgkQC3+MBN1Mb4i47ACg5daD5Ny3PlWY6FIa2mV2cPDs Lp4AoPGwIb1pY0fKiIEJOd7posch1lxJ =fKu0 -----END PGP SIGNATURE----- --Y7xTucakfITjPcLV-- From owner-freebsd-stable@FreeBSD.ORG Sat Jan 23 23:19: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 18AFF106566C; Sat, 23 Jan 2010 23:19:10 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from esa-annu.mail.uoguelph.ca (esa-annu.mail.uoguelph.ca [131.104.91.36]) by mx1.freebsd.org (Postfix) with ESMTP id A49648FC1D; Sat, 23 Jan 2010 23:19:09 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAIQSW0uDaFvJ/2dsb2JhbADWFoQ7BA X-IronPort-AV: E=Sophos;i="4.49,331,1262581200"; d="scan'208";a="62710664" Received: from ganges.cs.uoguelph.ca ([131.104.91.201]) by esa-annu-pri.mail.uoguelph.ca with ESMTP; 23 Jan 2010 18:19:08 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by ganges.cs.uoguelph.ca (Postfix) with ESMTP id BAFFCFB8063; Sat, 23 Jan 2010 18:19:08 -0500 (EST) X-Virus-Scanned: amavisd-new at ganges.cs.uoguelph.ca Received: from ganges.cs.uoguelph.ca ([127.0.0.1]) by localhost (ganges.cs.uoguelph.ca [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DuIa2GmUAKfw; Sat, 23 Jan 2010 18:19:08 -0500 (EST) Received: from muncher.cs.uoguelph.ca (muncher.cs.uoguelph.ca [131.104.91.102]) by ganges.cs.uoguelph.ca (Postfix) with ESMTP id ECAAAFB8059; Sat, 23 Jan 2010 18:19:07 -0500 (EST) Received: from localhost (rmacklem@localhost) by muncher.cs.uoguelph.ca (8.11.7p3+Sun/8.11.6) with ESMTP id o0NNTjp24249; Sat, 23 Jan 2010 18:29:45 -0500 (EST) X-Authentication-Warning: muncher.cs.uoguelph.ca: rmacklem owned process doing -bs Date: Sat, 23 Jan 2010 18:29:45 -0500 (EST) From: Rick Macklem X-X-Sender: rmacklem@muncher.cs.uoguelph.ca To: Mikolaj Golub In-Reply-To: <86pr50vprb.fsf@kopusha.onet> Message-ID: References: <86ocl272mb.fsf@kopusha.onet> <86tyuqnz9x.fsf@zhuzha.ua1> <86zl4awmon.fsf@zhuzha.ua1> <86vdeywmha.fsf@zhuzha.ua1> <86vdeuuo2y.fsf@zhuzha.ua1> <86pr50vprb.fsf@kopusha.onet> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-fs@FreeBSD.org, freebsd-stable@FreeBSD.org Subject: Re: FreeBSD NFS client/Linux NFS server issue X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 23 Jan 2010 23:19:10 -0000 On Sat, 23 Jan 2010, Mikolaj Golub wrote: > > I applied your patch to FreeBSD8.0 (the box I get on weekend :-), mounted 10 > shares, set vfs.nfs.iodmaxidle=10 (to have nfsiod creation more frequently) > and have been running tests for 4 hours -- just to check the patch does not > break anything. No issues have been detected. > > It would be very nice to have this patch committed. > Thanks for doing the testing and good work w.r.t. figuring out the race. (I'll admit I didn't really have a clue what was causing your problem.) rick From owner-freebsd-stable@FreeBSD.ORG Sat Jan 23 23:55: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 7378E106566B for ; Sat, 23 Jan 2010 23:55:42 +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 2F97E8FC16 for ; Sat, 23 Jan 2010 23:55:42 +0000 (UTC) Received: from list by lo.gmane.org with local (Exim 4.50) id 1NYppH-0001fr-Jp for freebsd-stable@freebsd.org; Sun, 24 Jan 2010 00:55:35 +0100 Received: from 93-138-97-181.adsl.net.t-com.hr ([93.138.97.181]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 24 Jan 2010 00:55:35 +0100 Received: from ivoras by 93-138-97-181.adsl.net.t-com.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 24 Jan 2010 00:55:35 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-stable@freebsd.org From: Ivan Voras Date: Sun, 24 Jan 2010 00:55:13 +0100 Lines: 21 Message-ID: Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: 93-138-97-181.adsl.net.t-com.hr User-Agent: Thunderbird 2.0.0.21 (X11/20090612) Sender: news Subject: 8-stable crashes in vmware (possible em driver issue?) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 23 Jan 2010 23:55:42 -0000 I have a fairly recent 8-stable machine running under VMWare ESXi 3.5 (amd64 guest), which apparently crashes every few days from the same causes: em0: discard frame w/o packet header em0: discard frame w/o packet header em0: discard frame w/o packet header Panic string: sbsndptr: sockbuf 0xffffff007cca8c20 and mbuf 0xffffff00490a6400 clashing More information available here: http://ivoras.net/stuff/crash/info.0.txt http://ivoras.net/stuff/crash/core.txt.0.txt The crash looks like is provoked by ssh bruteforce attack attempts, some of which are blocked by an ipfw-based blocker. Any ideas? The machine was previously (until a month ago) running 7.2-RELEASE without these panics.