From owner-freebsd-stable@FreeBSD.ORG Sun May 2 02:14:08 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 5AD5B106566B; Sun, 2 May 2010 02:14:08 +0000 (UTC) (envelope-from chuzzwassa@gmail.com) Received: from mail-px0-f182.google.com (mail-px0-f182.google.com [209.85.212.182]) by mx1.freebsd.org (Postfix) with ESMTP id 22A2B8FC15; Sun, 2 May 2010 02:14:07 +0000 (UTC) Received: by pxi17 with SMTP id 17so824970pxi.13 for ; Sat, 01 May 2010 19:13:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=0iCRu3i1tAXg1aT0pUMaNgdbk3zCAHuOTq1zQrozGyE=; b=uBgTRvvvtm1eBDFkFaXWodSzxKyAfzQIdU7+Cr+bgIFuZdBwUq/9zoth8bym+k9JL9 Y6JQoez0NgPbBqRVmu8TP0tB9bBrQqazsWqacu7WOGReeR7m8szLda9NXbqFR/nbx3V9 poSHrbERTSl2c45XnYJIPiFKUP+cRaT4ccVRI= 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=UP49s99GhRM8p8FVUiPnGUsl74KY0fk+maeMjahEgUpN7yuJsRxd2EtTOpEywTCrAh EtGK0rD7Es+VHWLfz0aGm9b2+cVCYNChreZf5XSPKGI6HeNZzlOxhaHXzPS6hJvRTM8z 5K85VFrS157r3Tp23V/FUUI4Z/0Sa0o69tpW0= MIME-Version: 1.0 Received: by 10.142.122.6 with SMTP id u6mr1235413wfc.183.1272766439215; Sat, 01 May 2010 19:13:59 -0700 (PDT) Received: by 10.143.167.7 with HTTP; Sat, 1 May 2010 19:13:58 -0700 (PDT) In-Reply-To: References: Date: Sun, 2 May 2010 12:13:58 +1000 Message-ID: From: Andy Farkas To: Pete French Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-scsi@freebsd.org, freebsd-stable@freebsd.org, mav@freebsd.org Subject: Re: MFC of "Large set of CAM improvements" breaks I/O to Adaptec 29160 SCSI controller X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 02 May 2010 02:14:08 -0000 On Fri, Apr 30, 2010 at 4:42 AM, Pete French wrote: > > I've copied in the original poster of the problem to see how he is > doing, but as far as I am concerned the problem has gone away. Certainly > the things I was doing before to triger it no longer do so. Of course > in the normal state of things it was rarely locking up (every few days) > so I can't be sure just on a few hurs testing. But my initial impression > is that this fixes it. Good work! > Confirming patch fixes problem. Thanks Alexander, good pick-up on finding the missing bit of code! bootverbose <-- /me smacks forehead with palm of hand -andyf From owner-freebsd-stable@FreeBSD.ORG Sun May 2 18:55:34 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 5FDE81065672 for ; Sun, 2 May 2010 18:55:34 +0000 (UTC) (envelope-from gbell72@rogers.com) Received: from smtp106.rog.mail.re2.yahoo.com (smtp106.rog.mail.re2.yahoo.com [68.142.225.204]) by mx1.freebsd.org (Postfix) with SMTP id 0016B8FC1B for ; Sun, 2 May 2010 18:55:33 +0000 (UTC) Received: (qmail 52484 invoked from network); 2 May 2010 18:55:30 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=rogers.com; h=Received:X-Yahoo-SMTP:X-YMail-OSG:X-Yahoo-Newman-Property:Received:Date:From:To:Cc:Subject:Message-ID:References:MIME-Version:Content-Type:Content-Disposition:In-Reply-To:User-Agent; b=gHIuvOPxqtaZn+yUy/u/uv99K2S6vc9azeKnoQU9/IzZRBBl5JpS9+S1HTVt6b2b7rgyXOgsQhlHFB10D0NNANuAUj2A+ziqMx1ewma+4fFeaBYtnCgn0Zm8PGvbqPRaPhTvBKY7klsAYJrsv+5Y/w6PrGUYuIEM1/nbbLXiWbI= ; Received: from titan.home.lan (gbell72@99.233.37.65 with login) by smtp106.rog.mail.re2.yahoo.com with SMTP; 02 May 2010 11:55:30 -0700 PDT X-Yahoo-SMTP: vhm.KweswBB8JGCDQo2eYyVHJ4NQ9hKLMsE.Tsw.BQ-- X-YMail-OSG: amU6fXgVM1nDBGAk_n1tolsACCTjOWvHQolZiqy7MsB8ylMGC3FIx80l1ESdUibaFaSRwZLuuOCW3_EYrGJgkx6tT1rXZ6QBqvZmQMFy8KTKE4wttW2HXB7lz0nJz9ayXRPM5z5w_R334EG8g8o0gtRFrh_OUF1XYCF21u5VqVu4RvMUo7VpP9yv4FVMk4giaywsGJ6itpQlxuMrHS5PifSNQu0DqW_9TeryyfOHHiQFg_UgG0zYFepEZL1WIBNomUeghDuy2QRz6fYBofbuZUlOHDWTle0mQXdfWC9pLhnxAauXYfl.gD_b_js8pbOhbVzfOL7HtBoagBXxWGPGVbRrTRZGuCcx3nkhhyPQhOphujArLlG8XDCBn72FsQNXC3Aps4_AKE_btAo92S69 X-Yahoo-Newman-Property: ymail-3 Received: by titan.home.lan (Postfix, from userid 1001) id CE72417480; Sun, 2 May 2010 14:55:29 -0400 (EDT) Date: Sun, 2 May 2010 14:55:29 -0400 From: Gardner Bell To: Jeremy Chadwick Message-ID: <20100502185529.GA1783@titan.home.lan> References: <20100428182556.GA1730@titan.home.lan> <20100428191901.GA30062@icarus.home.lan> <20100428192634.GA30303@icarus.home.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100428192634.GA30303@icarus.home.lan> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: freebsd-stable@freebsd.org Subject: Re: BCM5704 routing 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: Sun, 02 May 2010 18:55:34 -0000 On Wed, Apr 28, 2010 at 12:26:34PM -0700, Jeremy Chadwick wrote: > On Wed, Apr 28, 2010 at 12:19:01PM -0700, Jeremy Chadwick wrote: > > On Wed, Apr 28, 2010 at 02:25:56PM -0400, Gardner Bell wrote: > > > I upgraded my gateway last week to RELENG_8 and noticed that I can no > > > longer forward or receive IP packets from hosts on internal LAN. When > > > trying to ping a host or the gateway IP itself, you get. > > > > > > # ping 192.168.1.10 > > > PING 192.168.1.10 (192.168.1.10): 56 data bytes > > > ^C > > > > > > --- 192.168.1.10 ping statistics --- > > > 5 packets transmitted, 0 packets received, 100% packet loss > > > > > > All rc.conf files on gateway and hosts themselves had correct settings. > > > > > > bge1@pci0:10:9:1: class=0x020000 card=0x164414e4 chip=0x164814e4 > > > rev=0x03 hdr=0x00 > > > vendor = 'Broadcom Corporation' > > > device = 'NetXtreme Dual Gigabit Adapter (BCM5704)' > > > class = network > > > subclass = ethernet > > > bar [10] = type Memory, range 64, base 0xdf330000, size 65536, > > > enabled > > > bar [18] = type Memory, range 64, base 0xdf320000, size 65536, > > > enabled > > > cap 07[40] = PCI-X 64-bit supports 133MHz, 2048 burst read, 1 split > > > transaction > > > cap 01[48] = powerspec 2 supports D0 D3 current D0 > > > cap 03[50] = VPD > > > cap 05[58] = MSI supports 8 messages, 64 bit > > > > > > Previously I was running 7.2 as gateway and never encountered any > > > problems. I've since gone back to release 7.3 and routing works as > > > expected. > > > > > > Any input would be appreciated. > > > > Output from the following when the machine is running RELENG_8: > > > > - ifconfig -a > > - netstat -i > > - netstat -rn > > - sysctl -a | grep bge > > - Contents of /etc/rc.conf > > I forgot one more: > > dmesg | grep -C 10 bge1 > Just wanted to follow up to say that I got RELENG_8 to work. Thanks anyway. From owner-freebsd-stable@FreeBSD.ORG Sun May 2 20:05:02 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 5CD6A1065670 for ; Sun, 2 May 2010 20:05:02 +0000 (UTC) (envelope-from jafa82@gmail.com) Received: from mail-vw0-f54.google.com (mail-vw0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id 885FC8FC08 for ; Sun, 2 May 2010 20:05:01 +0000 (UTC) Received: by vws7 with SMTP id 7so951195vws.13 for ; Sun, 02 May 2010 13:04:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:reply-to:to:subject:date :user-agent:mime-version:content-type:content-transfer-encoding :message-id; bh=mDnBcGxSrpGSVtl+v2E9W1AwQGLuh9JYokEMwRW6AIE=; b=RZZuD5xKqVBy/Tt63W/03sFoyp0iIvs6paoqGvVVtFTpIQBbaJ3VQURVxky8WFnQ5+ a7PtcCTcQ+KC3vuit1kY/69F/3dJEJj6+JUVcdcH7JsXQGw6IA+hwY+2WOfUFltPkbnI o9b8sBZ8oHl054EoNagixXBdhYF8jTdeBa27Q= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:reply-to:to:subject:date:user-agent:mime-version:content-type :content-transfer-encoding:message-id; b=HX6OjtKYPKMi9ZdWfv/FTbQuw1K8IKDvVs/Kz4QOooBqVd1kUS8fdNisEi43Zo9Y1b Y450fTa2Pwd7vvSG8VTeVoBHS5ZZOTyuvrqn9NcR7jbF5bITG5w9a59yM35jN+tF+0ln GcbVt9ZNC7Q9JUEjZyF6SYilbZTpmT2lMdJ1A= Received: by 10.220.128.12 with SMTP id i12mr5687900vcs.124.1272828969095; Sun, 02 May 2010 12:36:09 -0700 (PDT) Received: from merytaton.localnet (modemcable125.95-81-70.mc.videotron.ca [70.81.95.125]) by mx.google.com with ESMTPS id x6sm20040503vco.11.2010.05.02.12.36.07 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sun, 02 May 2010 12:36:08 -0700 (PDT) From: Eric Damien To: freebsd-stable@freebsd.org Date: Sun, 2 May 2010 15:36:05 -0400 User-Agent: KMail/1.12.4 (FreeBSD/8.0-STABLE; KDE/4.3.5; i386; ; ) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-Id: <201005021536.05389.jafa82@gmail.com> Subject: ZFS: separate pools X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: jafa82@gmail.com List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 May 2010 20:05:02 -0000 Hello list. I am taking my first steps with ZFS. In the past, I used to have two UFS slices: one dedicated to the o.s. partitions, and the second to data (/home, etc.). I read on that it was possible to recreate that logic with zfs, using separate pools. Considering the example of http://wiki.freebsd.org/RootOnZFS/GPTZFSBoot, any idea how I can adapt that to my needs? I am concerned about all the different mountpoints. Thanks. From owner-freebsd-stable@FreeBSD.ORG Mon May 3 02:53:52 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id EFC4C106564A for ; Mon, 3 May 2010 02:53:52 +0000 (UTC) (envelope-from morganw@chemikals.org) Received: from warped.bluecherry.net (warped.bluecherry.net [66.138.159.247]) by mx1.freebsd.org (Postfix) with ESMTP id C7DBF8FC1D for ; Mon, 3 May 2010 02:53:52 +0000 (UTC) Received: from volatile.chemikals.org (adsl-67-123-77.shv.bellsouth.net [98.67.123.77]) (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 19A1C87DAD3F; Sun, 2 May 2010 21:36:06 -0500 (CDT) Received: from localhost (morganw@localhost [127.0.0.1]) by volatile.chemikals.org (8.14.4/8.14.4) with ESMTP id o432a0gj086238; Sun, 2 May 2010 21:36:00 -0500 (CDT) (envelope-from morganw@chemikals.org) Date: Sun, 2 May 2010 21:36:00 -0500 (CDT) From: Wes Morgan X-X-Sender: morganw@volatile To: Eric Damien In-Reply-To: <201005021536.05389.jafa82@gmail.com> Message-ID: References: <201005021536.05389.jafa82@gmail.com> 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.3 at warped X-Virus-Status: Clean Cc: freebsd-stable@freebsd.org Subject: Re: ZFS: separate pools X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 03 May 2010 02:53:53 -0000 On Sun, 2 May 2010, Eric Damien wrote: > Hello list. > > I am taking my first steps with ZFS. In the past, I used to have two UFS > slices: one dedicated to the o.s. partitions, and the second to data (/home, > etc.). I read on that it was possible to recreate that logic with zfs, using > separate pools. > > Considering the example of > http://wiki.freebsd.org/RootOnZFS/GPTZFSBoot, > any idea how I can adapt that to my needs? I am concerned about all the > different mountpoints. Well, you need not create all those filesystems if you don't want them. The pool and FreeBSD will function just fine. However, as far as storage is concerned, there is no disadvantage to having additional mount pounts. The only limits each filesystem will have is a limit you explicitly impose. There are many advantages, though. Some datasets are inherently compressible or incompressible. Other datasets you may not want to schedule for snapshots, or allow files to be executed, suid, checksummed, block sizes, you name it (as the examples in the wiki demonstrate). Furthermore, each pool requires its own vdev. If you create slices on a drive and then make each slice its own pool, I would wonder if zfs's internal queuing would understand the topology and be able to work as efficiently. Just a thought, though. From owner-freebsd-stable@FreeBSD.ORG Mon May 3 03:04:03 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 5271F106566C for ; Mon, 3 May 2010 03:04:03 +0000 (UTC) (envelope-from bryce@bryce.net) Received: from mail-gy0-f182.google.com (mail-gy0-f182.google.com [209.85.160.182]) by mx1.freebsd.org (Postfix) with ESMTP id 19AAC8FC13 for ; Mon, 3 May 2010 03:04:02 +0000 (UTC) Received: by gyh20 with SMTP id 20so1054960gyh.13 for ; Sun, 02 May 2010 20:03:52 -0700 (PDT) MIME-Version: 1.0 Received: by 10.151.24.5 with SMTP id b5mr7134920ybj.79.1272854413749; Sun, 02 May 2010 19:40:13 -0700 (PDT) Received: by 10.150.57.11 with HTTP; Sun, 2 May 2010 19:40:13 -0700 (PDT) In-Reply-To: References: Date: Sun, 2 May 2010 21:40:13 -0500 Message-ID: From: Bryce Edwards To: freebsd-stable@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: 8-STABLE performance issues on Supermicro Core i7 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 03 May 2010 03:04:03 -0000 Hello, I've got a new Supermicro X58 system with an Intel Core i7 930 with 6 GB ram that is not performing nearly as fast as it should in many ways (compiling, network transfers). =A0To give an example, it has been building the gcc44 port for about 10 hours now and at the same time rsync'ing from a Linux box on the same Gigabit network is only getting throughput of between 10-25 MB/sec. =A0When I did a buildkernel for 8-STABLE, it took 17 hours! My investigations have shown inhibited performance on compute, network and storage activities. In the BIOS, I have played with a few settings and some actually made it worse. =A0What I have done now is disabled Hyperthreading and Turbo Boost. Thanks in advance for any ideas. Here's some system info and stats: bryce@tahiti[~]>uname -a FreeBSD tahiti.bryce.net 8.0-STABLE FreeBSD 8.0-STABLE #0: Wed Apr 28 10:53:37 CDT 2010 root@tahiti.bryce.net:/usr/obj/usr/src/sys/GENERIC =A0amd64 bryce@tahiti[~]>cat /boot/loader.conf ahci_load=3D"YES" ichsmb_load=3D"YES" smb_load=3D"YES" coretemp_load=3D"YES" zfs_load=3D"YES" vfs.root.mountfrom=3D"zfs:system" hint.p4tcc.0.disabled=3D1 hint.acpi_throttle.0.disabled=3D1 bryce@tahiti[~]>cat /etc/sysctl.conf kern.timecounter.hardware=3DHPET bryce@tahiti[~]>vmstat 1 =A0procs =A0 =A0 =A0memory =A0 =A0 =A0page =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0disks =A0 =A0 faults =A0 =A0 =A0 =A0 cpu =A0r b w =A0 =A0 avm =A0 =A0fre =A0 flt =A0re =A0pi =A0po =A0 =A0fr =A0sr a= d0 ad1 =A0 in =A0 sy cs us sy id =A05 0 0 =A0 1068M =A03478M =A0 572 =A0 1 =A0 1 =A0 0 =A0 862 =A0 0 =A0 0 = =A0 0 9370 16514 16157 71 22 =A07 =A05 0 0 =A0 1068M =A03478M =A0 =A0 2 =A0 0 =A0 0 =A0 0 =A0 =A0 0 =A0 0 =A0= 0 =A0 0 8008 14504 11716 81 17 =A02 =A05 0 0 =A0 1068M =A03478M =A0 =A0 0 =A0 0 =A0 0 =A0 0 =A0 =A0 0 =A0 0 =A0= 0 =A0 0 12429 22323 18125 77 23 =A00 =A05 0 0 =A0 1068M =A03478M =A0 =A0 0 =A0 0 =A0 0 =A0 0 =A0 =A0 0 =A0 0 =A0= 0 =A0 0 12348 22125 17988 73 27 =A00 bryce@tahiti[~]>vmstat -i interrupt =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0total =A0 =A0 = =A0 rate irq1: atkbd0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A09291 =A0 =A0 = =A0 =A0 =A00 irq17: fwohci0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 1 =A0 =A0 = =A0 =A0 =A00 cpu0: timer =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 75416246 =A0 =A0 =A0 20= 00 irq256: em0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0137590284 =A0 =A0 =A0 36= 49 irq257: em0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0206367605 =A0 =A0 =A0 54= 73 irq260: em0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A01 =A0 = =A0 =A0 =A0 =A00 irq266: ahci0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A09892384 =A0 =A0 =A0 = =A0262 cpu2: timer =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 75415653 =A0 =A0 =A0 20= 00 cpu3: timer =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 75415702 =A0 =A0 =A0 20= 00 cpu1: timer =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 75415561 =A0 =A0 =A0 20= 00 Total =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0655522728 =A0 =A0 = =A017385 bryce@tahiti[~]>netstat -I em0 -h 1 =A0 =A0 =A0 =A0 =A0 =A0input =A0 =A0 =A0 =A0 =A0(em0) =A0 =A0 =A0 =A0 =A0 o= utput =A0 packets =A0errs idrops =A0 =A0 =A0bytes =A0 =A0packets =A0errs =A0 =A0 = =A0bytes colls =A0 =A0 =A07.7K =A0 =A0 0 =A0 =A0 0 =A0 =A0 =A0 =A011M =A0 =A0 =A0 7.2K =A0= =A0 0 =A0 =A0 =A0 475K =A0 =A0 0 =A0 =A0 =A08.1K =A0 =A0 0 =A0 =A0 0 =A0 =A0 =A0 =A012M =A0 =A0 =A0 7.4K =A0= =A0 0 =A0 =A0 =A0 491K =A0 =A0 0 =A0 =A0 =A07.8K =A0 =A0 0 =A0 =A0 0 =A0 =A0 =A0 =A011M =A0 =A0 =A0 7.2K =A0= =A0 0 =A0 =A0 =A0 476K =A0 =A0 0 bryce@tahiti[/usr/adm]>iostat 1 =A0 =A0 =A0 tty =A0 =A0 =A0 =A0 =A0 =A0ada0 =A0 =A0 =A0 =A0 =A0 =A0 ada1 = =A0 =A0 =A0 =A0 =A0 =A0 ada2 =A0 =A0 =A0 =A0 =A0 =A0 cpu =A0tin =A0tout =A0KB/t tps =A0MB/s =A0 KB/t tps =A0MB/s =A0 KB/t tps =A0MB/= s =A0us ni sy in id =A0 0 =A0 108 22.35 =A0 3 =A00.07 =A020.61 =A0 3 =A00.07 =A058.60 =A0 0 =A0= 0.00 =A071 =A00 =A04 17 =A07 =A0 0 =A0 222 64.00 =A0 1 =A00.06 =A0128.00 =A0 1 =A00.12 =A0 0.00 =A0 0 = =A00.00 =A087 =A00 =A02 11 =A00 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 #0: Wed Apr 28 10:53:37 CDT 2010 root@tahiti.bryce.net:/usr/obj/usr/src/sys/GENERIC amd64 Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Intel(R) Core(TM) i7 CPU 930 @ 2.80GHz (2786.02-MHz K8-class = CPU) Origin =3D "GenuineIntel" Id =3D 0x106a5 Family =3D 6 Model =3D 1a St= epping =3D 5 Features=3D0xbfebfbff Features2=3D0x98e3bd AMD Features=3D0x28100800 AMD Features2=3D0x1 TSC: P-state invariant real memory =3D 6446645248 (6148 MB) avail memory =3D 6169243648 (5883 MB) ACPI APIC Table: <021210 APIC1519> 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: 2 cpu2 (AP): APIC ID: 4 cpu3 (AP): APIC ID: 6 ioapic0: Changing APIC ID to 1 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, cbf00000 (3) failed Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x808-0x80b on acpi0 cpu0: on acpi0 ACPI Warning: Incorrect checksum in table [OEMB] - 0x7B, should be 0x74 (20100331/tbutils-354) cpu1: on acpi0 cpu2: on acpi0 cpu3: on acpi0 acpi_hpet0: iomem 0xfed00000-0xfed003ff on acp= i0 Timecounter "HPET" frequency 14318180 Hz quality 900 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pcib1: at device 1.0 on pci0 pci1: on pcib1 pcib2: at device 3.0 on pci0 pci2: on pcib2 pcib3: at device 7.0 on pci0 pci3: on pcib3 vgapci0: port 0xcc00-0xcc7f mem 0xfa000000-0xfaffffff,0xd0000000-0xdfffffff,0xce000000-0xcfffffff irq 16 at device 0.0 on pci3 pci3: at device 0.1 (no driver attached) pci0: at device 20.0 (no driver attached) pci0: at device 20.1 (no driver attached) pci0: at device 20.2 (no driver attached) pci0: at device 20.3 (no driver attached) pci0: at device 22.0 (no driver attached) pci0: at device 22.1 (no driver attached) pci0: at device 22.2 (no driver attached) pci0: at device 22.3 (no driver attached) pci0: at device 22.4 (no driver attached) pci0: at device 22.5 (no driver attached) pci0: at device 22.6 (no driver attached) pci0: at device 22.7 (no driver attached) uhci0: port 0xbc00-0xbc1f irq 16 at device 26.0 on pci0 uhci0: [ITHREAD] uhci0: LegSup =3D 0x2f00 usbus0: on uhci0 uhci1: port 0xb880-0xb89f irq 21 at device 26.1 on pci0 uhci1: [ITHREAD] uhci1: LegSup =3D 0x2f00 usbus1: on uhci1 uhci2: port 0xb800-0xb81f irq 19 at device 26.2 on pci0 uhci2: [ITHREAD] uhci2: LegSup =3D 0x2f00 usbus2: on uhci2 ehci0: mem 0xf9fde000-0xf9fde3ff irq 18 at device 26.7 on pci0 ehci0: [ITHREAD] usbus3: EHCI version 1.0 usbus3: on ehci0 pcib4: irq 17 at device 28.0 on pci0 pci4: on pcib4 pcib5: irq 17 at device 28.4 on pci0 pci5: on pcib5 em0: port 0xdc00-0xdc1f mem 0xfbce0000-0xfbcfffff,0xfbcdc000-0xfbcdffff irq 16 at device 0.0 on pci5 em0: Using MSIX interrupts with 5 vectors em0: [ITHREAD] em0: [ITHREAD] em0: [ITHREAD] em0: [ITHREAD] em0: [ITHREAD] em0: Ethernet address: 00:30:48:fb:8a:06 pcib6: irq 16 at device 28.5 on pci0 pci6: on pcib6 em1: port 0xec00-0xec1f mem 0xfbde0000-0xfbdfffff,0xfbddc000-0xfbddffff irq 17 at device 0.0 on pci6 em1: Using MSIX interrupts with 5 vectors em1: [ITHREAD] em1: [ITHREAD] em1: [ITHREAD] em1: [ITHREAD] em1: [ITHREAD] em1: Ethernet address: 00:30:48:fb:8a:07 uhci3: port 0xb480-0xb49f irq 23 at device 29.0 on pci0 uhci3: [ITHREAD] uhci3: LegSup =3D 0x2f00 usbus4: on uhci3 uhci4: port 0xb400-0xb41f irq 19 at device 29.1 on pci0 uhci4: [ITHREAD] uhci4: LegSup =3D 0x2f00 usbus5: on uhci4 uhci5: port 0xb080-0xb09f irq 18 at device 29.2 on pci0 uhci5: [ITHREAD] uhci5: LegSup =3D 0x2f00 usbus6: on uhci5 ehci1: mem 0xf9fdc000-0xf9fdc3ff irq 23 at device 29.7 on pci0 ehci1: [ITHREAD] usbus7: EHCI version 1.0 usbus7: on ehci1 pcib7: at device 30.0 on pci0 pci7: on pcib7 fwohci0: mem 0xfbefb800-0xfbefbfff,0xfbefc000-0xfbefffff irq 17 at device 8.0 on pci7 fwohci0: [ITHREAD] fwohci0: OHCI version 1.10 (ROM=3D1) fwohci0: No. of Isochronous channels is 4. fwohci0: EUI64 00:30:48:00:00:01:7a:2d fwohci0: Phy 1394a available S400, 2 ports. fwohci0: Link S400, max_rec 2048 bytes. firewire0: on fwohci0 dcons_crom0: on firewire0 dcons_crom0: bus_addr 0x2718000 fwe0: on firewire0 if_fwe0: Fake Ethernet address: 02:30:48:01:7a:2d fwe0: Ethernet address: 02:30:48:01:7a:2d fwip0: on firewire0 fwip0: Firewire address: 00:30:48:00:00:01:7a:2d @ 0xfffe00000000, S400, maxrec 2048 fwohci0: Initiate bus reset fwohci0: fwohci_intr_core: BUS reset fwohci0: fwohci_intr_core: node_id=3D0x00000000, SelfID Count=3D1, CYCLEMAS= TER mode isab0: at device 31.0 on pci0 isa0: on isab0 ahci0: port 0xa480-0xa487,0xb000-0xb003,0xac00-0xac07,0xa880-0xa883,0xa800-0xa81f mem 0xf9fda000-0xf9fda7ff irq 19 at device 31.2 on pci0 ahci0: [ITHREAD] ahci0: AHCI v1.20 with 6 3Gbps ports, Port Multiplier not supported ahcich0: at channel 0 on ahci0 ahcich0: [ITHREAD] ahcich1: at channel 1 on ahci0 ahcich1: [ITHREAD] ahcich2: at channel 2 on ahci0 ahcich2: [ITHREAD] ahcich3: at channel 3 on ahci0 ahcich3: [ITHREAD] ahcich4: at channel 4 on ahci0 ahcich4: [ITHREAD] ahcich5: at channel 5 on ahci0 ahcich5: [ITHREAD] ichsmb0: port 0x400-0x41f mem 0xf9fd8000-0xf9fd80ff irq 18 at device 31.3 on pci0 ichsmb0: [ITHREAD] smbus0: on ichsmb0 smb0: on smbus0 acpi_button0: on acpi0 atrtc0: port 0x70-0x71 irq 8 on acpi0 uart0: <16550 or compatible> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 uart0: [FILTER] uart1: <16550 or compatible> port 0x2f8-0x2ff irq 3 on acpi0 uart1: [FILTER] ppc0: port 0x378-0x37f irq 7 on acpi0 ppc0: Generic chipset (NIBBLE-only) in COMPATIBLE mode ppc0: [ITHREAD] ppbus0: on ppc0 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] sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=3D0x300> vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 coretemp0: on cpu0 est0: on cpu0 coretemp1: on cpu1 est1: on cpu1 coretemp2: on cpu2 est2: on cpu2 coretemp3: on cpu3 est3: on cpu3 ZFS filesystem version 3 ZFS storage pool version 14 Timecounters tick every 1.000 msec firewire0: 1 nodes, maxhop <=3D 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: 480Mbps High Speed USB v2.0 usbus4: 12Mbps Full Speed USB v1.0 usbus5: 12Mbps Full Speed USB v1.0 usbus6: 12Mbps Full Speed USB v1.0 usbus7: 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 ugen6.1: at usbus6 uhub6: on usbus6 ugen7.1: at usbus7 uhub7: on usbus7 ada0 at ahcich0 bus 0 scbus0 target 0 lun 0 ada0: ATA-8 SATA 2.x device ada0: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) ada0: Command Queueing enabled ada0: 152627MB (312581808 512 byte sectors: 16H 63S/T 16383C) ada1 at ahcich1 bus 0 scbus1 target 0 lun 0 ada1: ATA-8 SATA 2.x device ada1: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) ada1: Command Queueing enabled ada1: 152627MB (312581808 512 byte sectors: 16H 63S/T 16383C) ada2 at ahcich2 bus 0 scbus2 target 0 lun 0 ada2: ATA-8 SATA 2.x device ada2: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) ada2: Command Queueing enabled ada2: 1907729MB (3907029168 512 byte sectors: 16H 63S/T 16383C) ada3 at ahcich3 bus 0 scbus3 target 0 lun 0 ada3: ATA-8 SATA 2.x device ada3: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) ada3: Command Queueing enabled ada3: 1907729MB (3907029168 512 byte sectors: 16H 63S/T 16383C) ada4 at ahcich4 bus 0 scbus4 target 0 lun 0 ada4: ATA-8 SATA 2.x device ada4: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) ada4: Command Queueing enabled ada4: 1907729MB (3907029168 512 byte sectors: 16H 63S/T 16383C) ada5 at ahcich5 bus 0 scbus5 target 0 lun 0 ada5: ATA-8 SATA 2.x device ada5: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) ada5: Command Queueing enabled ada5: 1907729MB (3907029168 512 byte sectors: 16H 63S/T 16383C) SMP: AP CPU #2 Launched! SMP: AP CPU #3 Launched! 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 uhub4: 2 ports with 2 removable, self powered uhub5: 2 ports with 2 removable, self powered uhub6: 2 ports with 2 removable, self powered Root mount waiting for: usbus7 usbus3 Root mount waiting for: usbus7 usbus3 uhub3: 6 ports with 6 removable, self powered uhub7: 6 ports with 6 removable, self powered Trying to mount root from zfs:system From owner-freebsd-stable@FreeBSD.ORG Mon May 3 04:21:00 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 3BE991065672 for ; Mon, 3 May 2010 04:21:00 +0000 (UTC) (envelope-from amvandemore@gmail.com) Received: from mail-qy0-f201.google.com (mail-qy0-f201.google.com [209.85.221.201]) by mx1.freebsd.org (Postfix) with ESMTP id E6FCF8FC0A for ; Mon, 3 May 2010 04:20:59 +0000 (UTC) Received: by qyk39 with SMTP id 39so3268942qyk.8 for ; Sun, 02 May 2010 21:20:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=vrX8OobS+mdd2Rix7pKrELrao28iKMhNWdqVYQqhwB8=; b=Xoi7DdJWggqEHuAWb5mud3U3cmkiArafqNWtUKkkoPnOBYnqZGdlacZRLRgVtH37bf d85QeHRwJ9oAhsGD64dTTIPNxhcK/mVy/s8E1+K1oT+FYwTi4Yt17fIs980VE1t85uWi LaeEKvs4iXpXML9uC4y1JA0/dgroMsXGABVLM= 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=jOOTOyLB4eHqdu4la/V50jpro4AZt6joju4HkBOQQPadGZ3WgnlTyA5cXKq9SDev4V +sB9ICPramKNonI+1/NIQoc+mSEFPOQb8Lbp3+i7K7Hvi7jc1FmKhd8opGVZZWD7/B62 Yjdy9h74rrwPIhcc/7WK72hnw/yauZu14fH4Q= MIME-Version: 1.0 Received: by 10.229.96.82 with SMTP id g18mr1480035qcn.82.1272860452944; Sun, 02 May 2010 21:20:52 -0700 (PDT) Received: by 10.229.99.67 with HTTP; Sun, 2 May 2010 21:20:52 -0700 (PDT) In-Reply-To: References: Date: Sun, 2 May 2010 23:20:52 -0500 Message-ID: From: Adam Vande More To: Bryce Edwards Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-stable@freebsd.org Subject: Re: 8-STABLE performance issues on Supermicro Core i7 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 03 May 2010 04:21:00 -0000 On Sun, May 2, 2010 at 9:40 PM, Bryce Edwards wrote: > Hello, > > I've got a new Supermicro X58 system with an Intel Core i7 930 with 6 > GB ram that is not performing nearly as fast as it should in many ways > (compiling, network transfers). To give an example, it has been > building the gcc44 port for about 10 hours now and at the same time > rsync'ing from a Linux box on the same Gigabit network is only getting > throughput of between 10-25 MB/sec. When I did a buildkernel for > 8-STABLE, it took 17 hours! My investigations have shown inhibited > performance on compute, network and storage activities. > > Have you investigated potential faulty HD? I have an i7 870 and your ahci interrupts are an order of magintude greater than mine. That could be many other things too, but I think a SMART scan could help. -- Adam Vande More From owner-freebsd-stable@FreeBSD.ORG Mon May 3 08:39:27 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E4CC11065670 for ; Mon, 3 May 2010 08:39:27 +0000 (UTC) (envelope-from se@FreeBSD.org) Received: from smtp109.plus.mail.re1.yahoo.com (smtp109.plus.mail.re1.yahoo.com [69.147.102.72]) by mx1.freebsd.org (Postfix) with SMTP id 85CFC8FC18 for ; Mon, 3 May 2010 08:39:27 +0000 (UTC) Received: (qmail 19312 invoked from network); 3 May 2010 08:39:26 -0000 Received: from [10.142.15.240] (se@80.187.209.46 with plain) by smtp109.plus.mail.re1.yahoo.com with SMTP; 03 May 2010 01:39:26 -0700 PDT X-Yahoo-SMTP: iDf2N9.swBDAhYEh7VHfpgq0lnq. X-YMail-OSG: pcdt3BcVM1kb2IPRG4f1NDKbnX4astDqCtAZL.YJVNMRyj3 txPUHxt23B1cWk1P8EuwZzKZB2mYY76gmZOeeqHRIYF8X.6p5Y12LI7qyTXC jNbYT.pvFfHG49zFFRkzW7tQXVs3n4SwhJzP2LkLu2osFH95CmOUJpyHQ1Pt 75WnIC4IiuMj0v5or6ZbVS5HcWIVgmrmcVT8Bul9gySPfHydofOBvpnyzDRq NF9TGjUSRUakjsRnWZhng_Bflo3.aNslGC_3BjBn14LTKZdaw99WCTFHCvuD QBjWLM45Bsos- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4BDE8BBF.10603@FreeBSD.org> Date: Mon, 03 May 2010 10:39:27 +0200 From: Stefan Esser User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.8.1.18) Gecko/20081105 Thunderbird/2.0.0.18 ThunderBrowse/3.2.2.1 Mnenhy/0.7.5.666 MIME-Version: 1.0 To: freebsd-stable@freebsd.org References: <4B28F841.1070900@skylinetele.com> <4BD54AC7.7090301@FreeBSD.org> <4BD5B91B.2050606@elischer.org> In-Reply-To: <4BD5B91B.2050606@elischer.org> X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit Subject: Re: net/mpd5, ppp, proxy-arp 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, 03 May 2010 08:39:28 -0000 Am 26.04.2010 18:02, schrieb Julian Elischer: > On 4/26/10 1:11 AM, Stefan Esser wrote: >> I debugged this problem and prepared a patch for discussion, which >> later was committed by Max Laier (if memory serves me right). The >> message was added in order to identify further situations, where >> network domains are added after network interfaces have been >> initialized. This message ought to be informational right now, since >> the interface init is repeated whenever a network domain is added >> as part of above mentioned patch. Init order should be fixed, if >> this message is printed for compiled in drivers, but in case of a >> kernel module (like netgraph) that adds a domain, it is unadvoidable >> that the init order is reversed. >> >> Perhaps the message should be made conditional on the start-up of >> the kernel not having finished, or it should be completely removed, >> since time has shown, that the init order is correct in general. >> >> I'll remove that message (or make it conditional on "bootverbose") >> unless there is opposition to this change ... > please do.. > > it's an unavoidable thing that domains added after boot > are done after boot completes :-) Hmmm, I had a look at the code over the weekend and I'm not sure, whether changes during the last 5 years did not break assumptions and introduced bugs in if_attachdomain1() in /sys/net/if.c ... The tests at the head of the function seem problematic, but will need further analysis. I'll have to check the conditions under which the TRY_LOCK may fail and the second if clause seems to prevent the execution of the core of the function for KLDs (which would be BAD). Since I'm travelling abroad and without access to the sources or a test system for most of the week, I cannot perform these tests. But I'd be very surprised, if the code still worked as I intended it more than 5 years ago ... I'll hold back any commits until I have been able to perform tests (or somebody else looks into this and gets to a conclusion ...). Best regards, STefan From owner-freebsd-stable@FreeBSD.ORG Mon May 3 10:42:00 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E9D59106566C for ; Mon, 3 May 2010 10:42:00 +0000 (UTC) (envelope-from auryn@zirakzigil.org) Received: from mail.zirakzigil.org (mail.zirakzigil.org [82.63.178.63]) by mx1.freebsd.org (Postfix) with ESMTP id 9779F8FC20 for ; Mon, 3 May 2010 10:41:59 +0000 (UTC) Received: from localhost (unknown [192.168.1.2]) by mail.zirakzigil.org (Postfix) with ESMTP id 3046E96ACD for ; Mon, 3 May 2010 12:41:53 +0200 (CEST) X-Virus-Scanned: amavisd-new at zirakzigil.org Received: from mail.zirakzigil.org ([192.168.1.2]) by localhost (ext.zirakzigil.org [192.168.1.2]) (amavisd-new, port 10024) with ESMTP id sgeQq1aWI6A2 for ; Mon, 3 May 2010 12:41:50 +0200 (CEST) Received: from aurynmob2.giulioferro.it (unknown [192.168.1.2]) (Authenticated sender: auryn@zirakzigil.org) by mail.zirakzigil.org (Postfix) with ESMTPA id 5F49C96AC1 for ; Mon, 3 May 2010 12:41:50 +0200 (CEST) Message-ID: <4BDEA86E.3050109@zirakzigil.org> Date: Mon, 03 May 2010 12:41:50 +0200 From: Giulio Ferro User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.1.7) Gecko/20100223 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 Subject: Freebsd 8.0 kmem map too small X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 03 May 2010 10:42:01 -0000 NFS server amd64 Freebsd 8.0 recent (2 days ago) This server has been running for several months without problems. Beginning last week, however, I'm experiencing panics (about 1 per day) with the error in the subject Current settings: vm.kmem_size_scale: 3 vm.kmem_size_max: 329853485875 vm.kmem_size_min: 0 vm.kmem_size: 2764046336 ... hw.physmem: 8568225792 hw.usermem: 6117404672 hw.realmem: 9395240960 ... vfs.zfs.l2arc_noprefetch: 0 vfs.zfs.l2arc_feed_secs_shift: 1 vfs.zfs.l2arc_feed_secs: 1 vfs.zfs.l2arc_headroom: 128 vfs.zfs.l2arc_write_boost: 67108864 vfs.zfs.l2arc_write_max: 67108864 vfs.zfs.arc_meta_limit: 431882240 vfs.zfs.arc_meta_used: 431874720 vfs.zfs.arc_min: 215941120 vfs.zfs.arc_max: 1727528960 I've set nothing in either /boot/loader.conf or sysctl.conf What should I do? From owner-freebsd-stable@FreeBSD.ORG Mon May 3 11:01:01 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A4962106566B for ; Mon, 3 May 2010 11:01:01 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta09.emeryville.ca.mail.comcast.net (qmta09.emeryville.ca.mail.comcast.net [76.96.30.96]) by mx1.freebsd.org (Postfix) with ESMTP id 8D79E8FC15 for ; Mon, 3 May 2010 11:01:01 +0000 (UTC) Received: from omta05.emeryville.ca.mail.comcast.net ([76.96.30.43]) by qmta09.emeryville.ca.mail.comcast.net with comcast id Cytj1e0030vp7WLA9z12oS; Mon, 03 May 2010 11:01:02 +0000 Received: from koitsu.dyndns.org ([98.248.46.159]) by omta05.emeryville.ca.mail.comcast.net with comcast id Cz111e00G3S48mS8Rz110s; Mon, 03 May 2010 11:01:02 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 1F1B29B425; Mon, 3 May 2010 04:01:00 -0700 (PDT) Date: Mon, 3 May 2010 04:01:00 -0700 From: Jeremy Chadwick To: Giulio Ferro Message-ID: <20100503110100.GA93137@icarus.home.lan> References: <4BDEA86E.3050109@zirakzigil.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4BDEA86E.3050109@zirakzigil.org> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: freebsd-stable@freebsd.org Subject: Re: Freebsd 8.0 kmem map too small X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 03 May 2010 11:01:01 -0000 On Mon, May 03, 2010 at 12:41:50PM +0200, Giulio Ferro wrote: > NFS server amd64 Freebsd 8.0 recent (2 days ago) > > This server has been running for several months without problems. > Beginning last week, however, I'm experiencing panics (about 1 per day) > with the error in the subject > > Current settings: > > > vm.kmem_size_scale: 3 > vm.kmem_size_max: 329853485875 > vm.kmem_size_min: 0 > vm.kmem_size: 2764046336 > ... > hw.physmem: 8568225792 > hw.usermem: 6117404672 > hw.realmem: 9395240960 > ... > vfs.zfs.l2arc_noprefetch: 0 > vfs.zfs.l2arc_feed_secs_shift: 1 > vfs.zfs.l2arc_feed_secs: 1 > vfs.zfs.l2arc_headroom: 128 > vfs.zfs.l2arc_write_boost: 67108864 > vfs.zfs.l2arc_write_max: 67108864 > vfs.zfs.arc_meta_limit: 431882240 > vfs.zfs.arc_meta_used: 431874720 > vfs.zfs.arc_min: 215941120 > vfs.zfs.arc_max: 1727528960 > > > I've set nothing in either /boot/loader.conf or sysctl.conf > > > What should I do? You need to adjust vm.kmem_size to provide more space for the ARC. Below are ZFS-relevant entries in our /boot/loader.conf on production RELENG_8 systems with 8GB of RAM. The reason we set kmem_size to half our physical system memory is because I didn't want to risk other processes which use a larger maxdsiz/dfldsiz/maxssiz to potentially exhaust all memory. # Increase vm.kmem_size to allow for ZFS ARC to utilise more memory. vm.kmem_size="4096M" vfs.zfs.arc_max="3584M" # Disable ZFS prefetching # http://southbrain.com/south/2008/04/the-nightmare-comes-slowly-zfs.html # Increases overall speed of ZFS, but when disk flushing/writes occur, # system is less responsive (due to extreme disk I/O). # NOTE: 8.0-RC1 disables this by default on systems <= 4GB RAM anyway # NOTE: System has 8GB of RAM, so prefetch would be enabled by default. vfs.zfs.prefetch_disable="1" # Decrease ZFS txg timeout value from 30 (default) to 5 seconds. This # should increase throughput and decrease the "bursty" stalls that # happen during immense I/O with ZFS. # http://lists.freebsd.org/pipermail/freebsd-fs/2009-December/007343.html # http://lists.freebsd.org/pipermail/freebsd-fs/2009-December/007355.html vfs.zfs.txg.timeout="5" -- | 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 May 3 12:26:59 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 185F2106564A for ; Mon, 3 May 2010 12:26:59 +0000 (UTC) (envelope-from auryn@zirakzigil.org) Received: from mail.zirakzigil.org (mail.zirakzigil.org [82.63.178.63]) by mx1.freebsd.org (Postfix) with ESMTP id AB4EC8FC08 for ; Mon, 3 May 2010 12:26:58 +0000 (UTC) Received: from localhost (unknown [192.168.1.2]) by mail.zirakzigil.org (Postfix) with ESMTP id 428EF964F6; Mon, 3 May 2010 14:26:49 +0200 (CEST) X-Virus-Scanned: amavisd-new at zirakzigil.org Received: from mail.zirakzigil.org ([192.168.1.2]) by localhost (ext.zirakzigil.org [192.168.1.2]) (amavisd-new, port 10024) with ESMTP id 9Xq5M7MjOYjS; Mon, 3 May 2010 14:26:46 +0200 (CEST) Received: from aurynmob2.giulioferro.it (unknown [192.168.1.2]) (Authenticated sender: auryn@zirakzigil.org) by mail.zirakzigil.org (Postfix) with ESMTPA id 38122964E5; Mon, 3 May 2010 14:26:46 +0200 (CEST) Message-ID: <4BDEC106.3040807@zirakzigil.org> Date: Mon, 03 May 2010 14:26:46 +0200 From: Giulio Ferro User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.1.7) Gecko/20100223 Thunderbird/3.0.1 MIME-Version: 1.0 To: Jeremy Chadwick , freebsd-stable@freebsd.org References: <4BDEA86E.3050109@zirakzigil.org> <20100503110100.GA93137@icarus.home.lan> In-Reply-To: <20100503110100.GA93137@icarus.home.lan> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: Re: Freebsd 8.0 kmem map too small X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 03 May 2010 12:26:59 -0000 On 03.05.2010 13:01, Jeremy Chadwick wrote: > On Mon, May 03, 2010 at 12:41:50PM +0200, Giulio Ferro wrote: > >> NFS server amd64 Freebsd 8.0 recent (2 days ago) >> >> This server has been running for several months without problems. >> Beginning last week, however, I'm experiencing panics (about 1 per day) >> with the error in the subject >> >> Current settings: >> >> >> vm.kmem_size_scale: 3 >> vm.kmem_size_max: 329853485875 >> vm.kmem_size_min: 0 >> vm.kmem_size: 2764046336 >> ... >> hw.physmem: 8568225792 >> hw.usermem: 6117404672 >> hw.realmem: 9395240960 >> ... >> vfs.zfs.l2arc_noprefetch: 0 >> vfs.zfs.l2arc_feed_secs_shift: 1 >> vfs.zfs.l2arc_feed_secs: 1 >> vfs.zfs.l2arc_headroom: 128 >> vfs.zfs.l2arc_write_boost: 67108864 >> vfs.zfs.l2arc_write_max: 67108864 >> vfs.zfs.arc_meta_limit: 431882240 >> vfs.zfs.arc_meta_used: 431874720 >> vfs.zfs.arc_min: 215941120 >> vfs.zfs.arc_max: 1727528960 >> >> >> I've set nothing in either /boot/loader.conf or sysctl.conf >> >> >> What should I do? >> > You need to adjust vm.kmem_size to provide more space for the ARC. > > Below are ZFS-relevant entries in our /boot/loader.conf on production > RELENG_8 systems with 8GB of RAM. The reason we set kmem_size to half > our physical system memory is because I didn't want to risk other > processes which use a larger maxdsiz/dfldsiz/maxssiz to potentially > exhaust all memory. > > > # Increase vm.kmem_size to allow for ZFS ARC to utilise more memory. > vm.kmem_size="4096M" > vfs.zfs.arc_max="3584M" > > # Disable ZFS prefetching > # http://southbrain.com/south/2008/04/the-nightmare-comes-slowly-zfs.html > # Increases overall speed of ZFS, but when disk flushing/writes occur, > # system is less responsive (due to extreme disk I/O). > # NOTE: 8.0-RC1 disables this by default on systems<= 4GB RAM anyway > # NOTE: System has 8GB of RAM, so prefetch would be enabled by default. > vfs.zfs.prefetch_disable="1" > > # Decrease ZFS txg timeout value from 30 (default) to 5 seconds. This > # should increase throughput and decrease the "bursty" stalls that > # happen during immense I/O with ZFS. > # http://lists.freebsd.org/pipermail/freebsd-fs/2009-December/007343.html > # http://lists.freebsd.org/pipermail/freebsd-fs/2009-December/007355.html > vfs.zfs.txg.timeout="5" > > > Thanks, I'll try these settings. I'll keep you posted. From owner-freebsd-stable@FreeBSD.ORG Mon May 3 18:30:27 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 648B5106564A for ; Mon, 3 May 2010 18:30:27 +0000 (UTC) (envelope-from bryce@bryce.net) Received: from mail-gy0-f182.google.com (mail-gy0-f182.google.com [209.85.160.182]) by mx1.freebsd.org (Postfix) with ESMTP id 2B5328FC17 for ; Mon, 3 May 2010 18:30:26 +0000 (UTC) Received: by gyh20 with SMTP id 20so1439902gyh.13 for ; Mon, 03 May 2010 11:30:20 -0700 (PDT) MIME-Version: 1.0 Received: by 10.151.59.15 with SMTP id m15mr7735989ybk.246.1272911417765; Mon, 03 May 2010 11:30:17 -0700 (PDT) Received: by 10.150.57.11 with HTTP; Mon, 3 May 2010 11:30:17 -0700 (PDT) In-Reply-To: References: Date: Mon, 3 May 2010 13:30:17 -0500 Message-ID: From: Bryce Edwards To: Adam Vande More Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-stable@freebsd.org Subject: Re: 8-STABLE performance issues on Supermicro Core i7 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 03 May 2010 18:30:27 -0000 I have tried both drives independently (two system drives currently in ZFS mirror), but the interrupts was something that caught my attention as well. I haven't yet tried polling yet on the em interface, but I still have interrupts like what you are seeing (minus the em ones) when I'm just compiling and not really using the network, so I was going to wait before going down that path. Bryce On Sun, May 2, 2010 at 11:20 PM, Adam Vande More wr= ote: > On Sun, May 2, 2010 at 9:40 PM, Bryce Edwards wrote: >> >> Hello, >> >> I've got a new Supermicro X58 system with an Intel Core i7 930 with 6 >> GB ram that is not performing nearly as fast as it should in many ways >> (compiling, network transfers). =A0To give an example, it has been >> building the gcc44 port for about 10 hours now and at the same time >> rsync'ing from a Linux box on the same Gigabit network is only getting >> throughput of between 10-25 MB/sec. =A0When I did a buildkernel for >> 8-STABLE, it took 17 hours! =A0My investigations have shown inhibited >> performance on compute, network and storage activities. >> > > Have you investigated potential faulty HD?=A0 I have an i7 870 and your a= hci > interrupts are an order of magintude greater than mine.=A0 That could be = many > other things too, but I think a SMART scan could help. > > -- > Adam Vande More > From owner-freebsd-stable@FreeBSD.ORG Mon May 3 20:04:25 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 8E197106566C for ; Mon, 3 May 2010 20:04:25 +0000 (UTC) (envelope-from newroswell@gmail.com) Received: from mail-px0-f182.google.com (mail-px0-f182.google.com [209.85.212.182]) by mx1.freebsd.org (Postfix) with ESMTP id 671F98FC15 for ; Mon, 3 May 2010 20:04:25 +0000 (UTC) Received: by pxi11 with SMTP id 11so425397pxi.13 for ; Mon, 03 May 2010 13:04:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:date:message-id :subject:from:to:content-type; bh=76tfeaSDcEtrqz8iscVxtvEU9bBPzgJ6/wBVEAi5sHU=; b=KAzPRlTwWrwJqHBt1d+0KPbiZ3+tKrmJw8fGOtBrf2UtXGgXf6bCnBK2QUtcW292Iv x5TQRb7figpB7iW6pPChQ9X3bYal3afSuxE9Ztf86mtyaZAX8AqoNXfTvzBTRABoWpoP hVN9bPlRQ+MIXJ1OfITNmO51+jtrVnEljB2v8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=RUBkB3AnrfB6Eae2MdlQSqTFD2E/cSCI0gEeEIixecnz/CDxkdNdBlrEmtYF/zaG5t 9tjhIw/H8T9XXZGdXRzuJuQh456iaoyYaHHw3uT4aNaZdkbB8IIsgvShjbD6+u/yNple ubSWkOK7A8Hyol1piE9UdFMuFx8Vc0NP1rLPo= MIME-Version: 1.0 Received: by 10.142.65.24 with SMTP id n24mr9599867wfa.302.1272915573790; Mon, 03 May 2010 12:39:33 -0700 (PDT) Received: by 10.142.230.11 with HTTP; Mon, 3 May 2010 12:39:33 -0700 (PDT) Date: Mon, 3 May 2010 12:39:33 -0700 Message-ID: From: Kevin Sanders To: freebsd-stable@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Subject: panic from sysctl with RELENG_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: Mon, 03 May 2010 20:04:25 -0000 I'm seeing the following panic several times a week. It happens when we have a periodic script run that is doing a "sysctl -a | grep | sed" to fetch information we use for logging. I'm not sure if it panics in the same OID every time, but a little investigation with KGDB on the core file shows it had reached vm.vmtotal this time. Is it a known issue, hopefully with a fix (besides not doing a sysctl -a)? Fatal trap 12: page fault while in kernel mode cpuid = 1; apic id = 01 fault virtual address = 0xa0d0c90 fault code = supervisor read data, page not present instruction pointer = 0x20:0xffffffff8058647e stack pointer = 0x28:0xffffff8077feb8c0 frame pointer = 0x28:0xffffff8077feb8e0 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 = 83436 (sysctl) Physical memory: 4078 MB Dumping 1701 MB: 1686 1670 1654 1638 1622 1606 1590 1574 1558 1542 1526 1510 1494 1478 1462 1446 1430 1414 1398 1382 1366 1350 1334 1318 1302 1286 1270 1254 1238 1222 1206 1190 1174 1158 1142 1126 1110 1094 1078 1062 1046 1030 1014 998 982 966 950 934 918 902 886 870 854 838 822 806 790 774 758 742 726 710 694 678 662 646 630 614 598 582 566 550 534 518 502 486 470 454 438 422 406 390 374 358 342 326 310 294 278 262 246 230 214 198 182 166 150 134 118 102 86 70 54 38 22 6 Reading symbols from /boot/kernel/accf_http.ko...Reading symbols from /boot/kernel/accf_http.ko.symbols...done. done. Loaded symbols for /boot/kernel/accf_http.ko Reading symbols from /boot/kernel/if_bridge.ko...Reading symbols from /boot/kernel/if_bridge.ko.symbols...done. done. Loaded symbols for /boot/kernel/if_bridge.ko Reading symbols from /boot/kernel/bridgestp.ko...Reading symbols from /boot/kernel/bridgestp.ko.symbols...done. done. Loaded symbols for /boot/kernel/bridgestp.ko Reading symbols from /boot/kernel/lsnet.ko...done. Loaded symbols for /boot/kernel/lsnet.ko Reading symbols from /boot/kernel/bpmod.ko...done. Loaded symbols for /boot/kernel/bpmod.ko #0 doadump () at pcpu.h:223 223 pcpu.h: No such file or directory. in pcpu.h (kgdb) #0 doadump () at pcpu.h:223 #1 0xffffffff801e2e6c in db_fncall (dummy1=Variable "dummy1" is not available. ) at /usr/src/sys/ddb/db_command.c:548 #2 0xffffffff801e311d in db_command (last_cmdp=0xffffffff80beb9a0, cmd_table=Variable "cmd_table" is not available. ) at /usr/src/sys/ddb/db_command.c:445 #3 0xffffffff801e7683 in db_script_exec ( scriptname=0xffffffff808e50d0 "kdb.enter.default", warnifnotfound=0) at /usr/src/sys/ddb/db_script.c:302 #4 0xffffffff801e777e in db_script_kdbenter (eventname=Variable "eventname" is not available. ) at /usr/src/sys/ddb/db_script.c:325 #5 0xffffffff801e53b4 in db_trap (type=Variable "type" is not available. ) at /usr/src/sys/ddb/db_main.c:228 #6 0xffffffff805c53d5 in kdb_trap (type=12, code=0, tf=0xffffff8077feb810) at /usr/src/sys/kern/subr_kdb.c:535 #7 0xffffffff8088316d in trap_fatal (frame=0xffffff8077feb810, eva=Variable "eva" is not available. ) at /usr/src/sys/amd64/amd64/trap.c:847 #8 0xffffffff80883544 in trap_pfault (frame=0xffffff8077feb810, usermode=0) at /usr/src/sys/amd64/amd64/trap.c:768 #9 0xffffffff80883f8f in trap (frame=0xffffff8077feb810) at /usr/src/sys/amd64/amd64/trap.c:494 #10 0xffffffff80869873 in calltrap () at /usr/src/sys/amd64/amd64/exception.S:224 #11 0xffffffff8058647e in _mtx_lock_sleep (m=0xffffff0073898000, tid=18446742975565457184, opts=Variable "opts" is not available. ) at /usr/src/sys/kern/kern_mutex.c:369 #12 0xffffffff807eda6e in vmtotal (oidp=0xffffffff80bb52c0, arg1=Variable "arg1" is not available. ) at /usr/src/sys/vm/vm_meter.c:186 #13 0xffffffff8059ebf8 in sysctl_root (oidp=Variable "oidp" is not available. ) at /usr/src/sys/kern/kern_sysctl.c:1418 #14 0xffffffff8059fea1 in userland_sysctl (td=0x0, name=0xffffff8077febaa0, namelen=2, old=0x0, oldlenp=Variable "oldlenp" is not available. ) at /usr/src/sys/kern/kern_sysctl.c:1522 #15 0xffffffff805a007a in __sysctl (td=0xffffff005182e720, uap=0xffffff8077febbf0) at /usr/src/sys/kern/kern_sysctl.c:1448 #16 0xffffffff808837b6 in syscall (frame=0xffffff8077febc80) at /usr/src/sys/amd64/amd64/trap.c:984 #17 0xffffffff80869b51 in Xfast_syscall () at /usr/src/sys/amd64/amd64/exception.S:373 #18 0x000000080073d9dc in ?? () From owner-freebsd-stable@FreeBSD.ORG Mon May 3 20:34:23 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 4D61D1065678 for ; Mon, 3 May 2010 20:34:23 +0000 (UTC) (envelope-from kurt.lidl@cello.com) Received: from Mail.Fairview-Park.Com (Mail.Fairview-Park.Com [98.141.206.6]) by mx1.freebsd.org (Postfix) with ESMTP id 07DBB8FC1A for ; Mon, 3 May 2010 20:34:22 +0000 (UTC) Received: from [192.168.8.101] (Kurt.Fairview-Park.Com [192.168.8.101]) by Mail.Fairview-Park.Com (8.14.3/8.14.3) with ESMTP id o43KL1hI045861 for ; Mon, 3 May 2010 16:21:10 -0400 (EDT) (envelope-from kurt.lidl@cello.com) X-FVP-rcvd: Kurt.Fairview-Park.Com [192.168.8.101] Mon, 3 May 2010 16:21:10 -0400 (EDT) Message-ID: <4BDF302D.9020500@cello.com> Date: Mon, 03 May 2010 16:21:01 -0400 From: Kurt Lidl Organization: Cello Software User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.9) Gecko/20100317 Lightning/1.0b1 Thunderbird/3.0.4 MIME-Version: 1.0 To: freebsd-stable@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.96 at Mail.Fairview-Park.Com X-Virus-Status: Clean Subject: raidz2 recovery problem on 8.0p2 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 03 May 2010 20:34:23 -0000 I have a 12GB memory machine, with a mpt controller in it, running a ZFS raidz2 for (test) data storage. The system also has a ZFS mirror in place for the OS, home directories, etc. I manually failed one of the disks in the JBOD shelf and watched as the mpt controller started logging errors. Ultimately, I tried to reboot the machine, but it panic'd instead of rebooting cleanly. It failed to crashdump too (Got about 200MB into the dump and stopped.) Upon reboot, I saw that zfs thought there were two da6 disk devices. Which was strange, since at this point, the machine should have had da0 through da6. I issued a 'zpool clear media da6' command, but that didn't resolve anything. Then I plugged the drive back into the JBOD and rebooted. Now I see the following: user@host: zpool status media pool: media state: DEGRADED status: One or more devices could not be used because the label is missing or invalid. Sufficient replicas exist for the pool to continue functioning in a degraded state. action: Replace the device using 'zpool replace'. see: http://www.sun.com/msg/ZFS-8000-4J scrub: none requested config: NAME STATE READ WRITE CKSUM media DEGRADED 0 0 0 raidz2 DEGRADED 0 0 0 da0 ONLINE 0 0 0 da1 ONLINE 0 0 0 da2 ONLINE 0 0 0 da3 ONLINE 0 0 0 da4 ONLINE 0 0 0 da5 ONLINE 0 0 0 da6 ONLINE 0 0 0 da6 FAULTED 0 98 0 corrupted data errors: No known data errors Note that there are *two* da6 devices listed, at least from zpool's point of view. A dmesg reports this: da0 at mpt0 bus 0 target 8 lun 0 da0: Fixed Direct Access SCSI-5 device da0: 300.000MB/s transfers da0: Command Queueing enabled da0: 1430799MB (2930277168 512 byte sectors: 255H 63S/T 182401C) da1 at mpt0 bus 0 target 9 lun 0 da1: Fixed Direct Access SCSI-5 device da1: 300.000MB/s transfers da1: Command Queueing enabled da1: 1430799MB (2930277168 512 byte sectors: 255H 63S/T 182401C) da2 at mpt0 bus 0 target 10 lun 0 da2: Fixed Direct Access SCSI-5 device da2: 300.000MB/s transfers da2: Command Queueing enabled da2: 1430799MB (2930277168 512 byte sectors: 255H 63S/T 182401C) da3 at mpt0 bus 0 target 11 lun 0 da3: Fixed Direct Access SCSI-5 device da3: 300.000MB/s transfers da3: Command Queueing enabled da3: 1430799MB (2930277168 512 byte sectors: 255H 63S/T 182401C) da4 at mpt0 bus 0 target 12 lun 0 da4: Fixed Direct Access SCSI-5 device da4: 300.000MB/s transfers da4: Command Queueing enabled da4: 1430799MB (2930277168 512 byte sectors: 255H 63S/T 182401C) da5 at mpt0 bus 0 target 13 lun 0 da5: Fixed Direct Access SCSI-5 device da5: 300.000MB/s transfers da5: Command Queueing enabled da5: 1430799MB (2930277168 512 byte sectors: 255H 63S/T 182401C) da6 at mpt0 bus 0 target 14 lun 0 da6: Fixed Direct Access SCSI-5 device da6: 300.000MB/s transfers da6: Command Queueing enabled da6: 1430799MB (2930277168 512 byte sectors: 255H 63S/T 182401C) da7 at mpt0 bus 0 target 15 lun 0 da7: Fixed Direct Access SCSI-5 device da7: 300.000MB/s transfers da7: Command Queueing enabled da7: 1430799MB (2930277168 512 byte sectors: 255H 63S/T 182401C) Any suggestions about how to get this raid back into a non-degraded state? For whatever it's worth, 'uname -a' reports: FreeBSD host.fairview-park.com 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 Thanks for any help. -Kurt From owner-freebsd-stable@FreeBSD.ORG Mon May 3 21:36:08 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id D218B106566C for ; Mon, 3 May 2010 21:36:08 +0000 (UTC) (envelope-from demelier.david@gmail.com) Received: from mail-bw0-f216.google.com (mail-bw0-f216.google.com [209.85.218.216]) by mx1.freebsd.org (Postfix) with ESMTP id 650698FC13 for ; Mon, 3 May 2010 21:36:08 +0000 (UTC) Received: by bwz8 with SMTP id 8so1726852bwz.3 for ; Mon, 03 May 2010 14:36:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:date:message-id :subject:from:to:content-type; bh=SvB+ZgUltJ7kXbXr3dl6wy0+jGEvF/vOUwp21lRhr2s=; b=l3hdY1tI3Pi19kpczTjg1UUT+xcB8LotcsWVdcabjW8eewo4nGifcj31Qp0XynCY3l wgslDfbmircyJ1d8Wt3H/i44erBWkQdYjB5HBU1WDcn66/Rcmq4g8XaEPizHjB/sIgr4 pnQx6sNdXkAfNyAFz/cNESFCn9t8LvzA+Nffg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=slP0Z5r2OuFt8TAhsftyIvwlPRVYobDAEHwf0AeityqIGN2HRsdumOnssa7P54HjJF MuL7YuN7wWOQ8VEiXzLfVHAl47ERslu/la8qeMdqgUiYtyfOG6Y5kWgAJkXEvy9Zm3FT uFz/VP1HEVTbGqsZMGoxNx8cuc11KxkRAMk20= MIME-Version: 1.0 Received: by 10.204.126.130 with SMTP id c2mr9624097bks.155.1272922562084; Mon, 03 May 2010 14:36:02 -0700 (PDT) Received: by 10.204.76.73 with HTTP; Mon, 3 May 2010 14:36:02 -0700 (PDT) Date: Mon, 3 May 2010 23:36:02 +0200 Message-ID: From: David DEMELIER To: freebsd-stable@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Subject: Kernel panic when unpluggin AC adaptor X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 03 May 2010 21:36:08 -0000 Hi, I just updated my 8.0-STABLE/amd64 today around 17h CEST, and it just panics when I unplug my AC. The current process = 11 (idle: cpu1) is this related to the cpufreq and related stuff ? It also says cannot dump. Device not defined or unavailable so I can't give you more infos now. King regards. -- Demelier David From owner-freebsd-stable@FreeBSD.ORG Mon May 3 21:57:35 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 147BD1065672 for ; Mon, 3 May 2010 21:57:35 +0000 (UTC) (envelope-from demelier.david@gmail.com) Received: from mail-bw0-f216.google.com (mail-bw0-f216.google.com [209.85.218.216]) by mx1.freebsd.org (Postfix) with ESMTP id 6111E8FC19 for ; Mon, 3 May 2010 21:57:34 +0000 (UTC) Received: by bwz8 with SMTP id 8so1736378bwz.3 for ; Mon, 03 May 2010 14:57:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=r1S8QlEbCl3DjNA+Yj+aGHv830A2sASEqJEDDL0Dh/U=; b=aFGpIVXdh/niuynWb6K4XDvxhd0Evcpig4twcVOiP9v+cMQJQ4tBVCnz3xNjSusAdx 8IXIXQGqucaAnYHTxHQdsSO4S/+efyne6FnEi1cNfHKtipo71k8SegTstJVqiSc/npWo Zal6R5xvij3g2h5gj/kh2oUSOswRZcmaaLIos= 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:content-transfer-encoding; b=NvBh0/z1M77TMiecgJWxsl0KxgVZfvwik/S8Am//bkNpP9Qc8ddjN10NvEqNFcVRCL AlrkvutF3UBoRyKDnjqLmmuhy2S1jxWPOoA9w85GLGObbG4qjT0EY6SXD0FibdX618M+ 1DrCnh4p2SUhJPicM9k0abTs5IMpC8ArDAk6w= MIME-Version: 1.0 Received: by 10.204.16.73 with SMTP id n9mr693333bka.21.1272923848485; Mon, 03 May 2010 14:57:28 -0700 (PDT) Received: by 10.204.76.73 with HTTP; Mon, 3 May 2010 14:57:28 -0700 (PDT) In-Reply-To: References: Date: Mon, 3 May 2010 23:57:28 +0200 Message-ID: From: David DEMELIER To: freebsd-stable@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: Kernel panic when unpluggin AC adaptor X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 03 May 2010 21:57:35 -0000 2010/5/3 David DEMELIER : > Hi, > > I just updated my 8.0-STABLE/amd64 today around 17h CEST, and it just > panics when I unplug my AC. =A0The current process =3D 11 (idle: cpu1) is > this related to the cpufreq and related stuff ? > > It also says cannot dump. Device not defined or unavailable so I can't > give you more infos now. > I can confirm that : #performance_cx_lowest=3D"HIGH" #performance_cpu_freq=3D${performance_cx_lowest} #economy_cx_lowest=3D"LOW" #economy_cpu_freq=3D${economy_cx_lowest} in rc.conf was the problem. --=20 Demelier David From owner-freebsd-stable@FreeBSD.ORG Mon May 3 22:22:39 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id BF23B1065670 for ; Mon, 3 May 2010 22:22:39 +0000 (UTC) (envelope-from akephalos.akephalos@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 49D658FC13 for ; Mon, 3 May 2010 22:22:38 +0000 (UTC) Received: by ewy26 with SMTP id 26so823827ewy.3 for ; Mon, 03 May 2010 15:22:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:date:from:to:cc:subject :message-id:in-reply-to:references:x-mailer:mime-version :content-type:content-transfer-encoding; bh=msciwvsA1F/HCE5zFuBHdXVHExla0az9ci8zrbL2aps=; b=DMjl6tL0HnlFFRERqDC7ApSfJw3gEVxsZG1AlnXp4dqIPbR/8alMUNy9SPTij6yIQr VJ+tRHf//FUBLkgkiW4xungMryhZKh1iXl/4dYmF9Q42JHFEIjbFTlsCZD9pH34uwk5J G0tF2l8Vc0K1wqFz3QAkVUDK91aebfOLypamc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:from:to:cc:subject:message-id:in-reply-to:references:x-mailer :mime-version:content-type:content-transfer-encoding; b=IWW8HrumXdf9D4SsEquucs6VXoZ9zYYlsM24umIOoE1tlSeLh+XadMKkOVC2xlPRb+ C7sQdJCW7u9d/Ngd7aqPNA+y0KXAKf+woZQI9wehJq+KsjHn4nGfBFdKzJmwiJgP8SoO 5GPfmlZxDWnkU8IQdUyY4DUnkIVp/kHySY9oE= Received: by 10.213.49.144 with SMTP id v16mr6029155ebf.46.1272925355676; Mon, 03 May 2010 15:22:35 -0700 (PDT) Received: from free.bsd369441.org (89-45-24-235.citynet.botosani.ro [89.45.24.235]) by mx.google.com with ESMTPS id 14sm3361723ewy.2.2010.05.03.15.22.34 (version=SSLv3 cipher=RC4-MD5); Mon, 03 May 2010 15:22:34 -0700 (PDT) Date: Tue, 4 May 2010 01:20:02 +0300 From: Akephalos To: Bryce Edwards Message-Id: <20100504012002.c260d075.akephalos.akephalos@gmail.com> In-Reply-To: References: X-Mailer: Sylpheed 3.0.1 (GTK+ 2.18.7; amd64-portbld-freebsd8.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: Adam Vande More , freebsd-stable@freebsd.org Subject: Re: 8-STABLE performance issues on Supermicro Core i7 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 03 May 2010 22:22:39 -0000 Maybe this is a ridiculous question, but did you check whether your CPU is used and accelerated in case you use powerd/cpufreq or another power-saving feature? I ask you because I had this problem and I recalled that the same thing gathered my attention in the beginning, slow compilations. Basically, my CPU was nost scaling upwards for technical reasons that I can't understand. Here's my thread: http://lists.freebsd.org/pipermail/freebsd-stable/2010-April/056105.html Cheers, Mihai On Mon, 3 May 2010 13:30:17 -0500 Bryce Edwards wrote: > I have tried both drives independently (two system drives currently > in ZFS mirror), but the interrupts was something that caught my > attention as well. I haven't yet tried polling yet on the em > interface, but I still have interrupts like what you are seeing (minus > the em ones) when I'm just compiling and not really using the network, > so I was going to wait before going down that path. > > Bryce > -- Mihai From owner-freebsd-stable@FreeBSD.ORG Mon May 3 22:30:34 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 3C2601065678 for ; Mon, 3 May 2010 22:30:34 +0000 (UTC) (envelope-from yanefbsd@gmail.com) Received: from mail-vw0-f54.google.com (mail-vw0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id D5C0A8FC19 for ; Mon, 3 May 2010 22:30:33 +0000 (UTC) Received: by vws7 with SMTP id 7so1980368vws.13 for ; Mon, 03 May 2010 15:30:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=mUMf/6JuG30l+atCG9IyI1LGirUmifZklYJv+6WymV8=; b=i9PZqDMtW5onISkgKTki6g/q2kBqiymG0ejGtgkZngJYEuXfaIWEvfVig+oyLvaOxd lwElYCOOhZpZKwqWwB9SaivNXO/DFlC9bf3jpaPrMqWlIyaCbokzASjU7gWlNq8g7QWk zBse9BYeiEYgE3Zgy/mFvu1m2LMOFO+jFNSsA= 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:content-transfer-encoding; b=qr2pBSRM4TwbetPyq2fSgheIeGUnKkqGPf5ujyAinxvNAqoPnErWd4YhYYWq2V1VPm GEwRodnPaX7DdZIe4nDmJjz8yy03mpUr0W0aue6nifvv5ZWIQFkkCqvzbMld+2pIzgGP 2xHP3iD4uq3Q5584qiJ7D/O1RoNCO9fQnsMzM= MIME-Version: 1.0 Received: by 10.224.69.159 with SMTP id z31mr3660648qai.273.1272925825297; Mon, 03 May 2010 15:30:25 -0700 (PDT) Received: by 10.229.251.17 with HTTP; Mon, 3 May 2010 15:30:24 -0700 (PDT) In-Reply-To: References: Date: Mon, 3 May 2010 15:30:24 -0700 Message-ID: From: Garrett Cooper To: David DEMELIER Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-stable@freebsd.org Subject: Re: Kernel panic when unpluggin AC adaptor X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 03 May 2010 22:30:34 -0000 On Mon, May 3, 2010 at 2:57 PM, David DEMELIER w= rote: > 2010/5/3 David DEMELIER : >> Hi, >> >> I just updated my 8.0-STABLE/amd64 today around 17h CEST, and it just >> panics when I unplug my AC. =A0The current process =3D 11 (idle: cpu1) i= s >> this related to the cpufreq and related stuff ? >> >> It also says cannot dump. Device not defined or unavailable so I can't >> give you more infos now. >> > > I can confirm that : > > #performance_cx_lowest=3D"HIGH" > #performance_cpu_freq=3D${performance_cx_lowest} > #economy_cx_lowest=3D"LOW" > #economy_cpu_freq=3D${economy_cx_lowest} > > in rc.conf was the problem. Set dumpdev in /boot/loader.conf to your swap device, reboot, and then try to reproduce the issue. Cheers, -Garrett From owner-freebsd-stable@FreeBSD.ORG Mon May 3 22:37:45 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 50FDA106566B for ; Mon, 3 May 2010 22:37:45 +0000 (UTC) (envelope-from jamesbrandongooch@gmail.com) Received: from mail-iw0-f175.google.com (mail-iw0-f175.google.com [209.85.223.175]) by mx1.freebsd.org (Postfix) with ESMTP id C25218FC16 for ; Mon, 3 May 2010 22:37:44 +0000 (UTC) Received: by iwn5 with SMTP id 5so3813606iwn.9 for ; Mon, 03 May 2010 15:37:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=zkeuD6DrCayd+xnbGJOnb4FWGlCB4FwYf+L4ZUGAsxI=; b=ZR30BV4946IbPJarR7KVD0yP710wVqTyEeQJdAmC7/6c3l0PhmSWG2UwxnByFg5gY3 9hK3mPLNl/nSCzPQ0jF6Qi9UWpINa2mFKTY3Fana26Im2ORw6s9h21AC4uARRZ8NiQu3 FIrRKVvM10cTtmoPkk830uUsnpcIZx+iBch9Q= 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:content-transfer-encoding; b=H9bfItQqN5zaMZVPmIf25xWQvNWEC5cyWObzyKbNakrbGtap41v+EN0JIM7Z/7m3xE IZ6pLT3G8/u+UupgcKDrZgMUXuozyQG7zN8xauwWETEBbCbWZoem9+lAxhMYxtHTxEam 8lo1iK26zpTv8sYF391eGWzbp53HYPB6AklPo= MIME-Version: 1.0 Received: by 10.231.59.18 with SMTP id j18mr46737ibh.88.1272926250879; Mon, 03 May 2010 15:37:30 -0700 (PDT) Received: by 10.231.113.36 with HTTP; Mon, 3 May 2010 15:37:30 -0700 (PDT) In-Reply-To: References: Date: Mon, 3 May 2010 17:37:30 -0500 Message-ID: From: Brandon Gooch To: David DEMELIER Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-stable@freebsd.org Subject: Re: Kernel panic when unpluggin AC adaptor X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 03 May 2010 22:37:45 -0000 On Mon, May 3, 2010 at 4:57 PM, David DEMELIER w= rote: > 2010/5/3 David DEMELIER : >> Hi, >> >> I just updated my 8.0-STABLE/amd64 today around 17h CEST, and it just >> panics when I unplug my AC. =A0The current process =3D 11 (idle: cpu1) i= s >> this related to the cpufreq and related stuff ? >> >> It also says cannot dump. Device not defined or unavailable so I can't >> give you more infos now. >> > > I can confirm that : > > #performance_cx_lowest=3D"HIGH" > #performance_cpu_freq=3D${performance_cx_lowest} > #economy_cx_lowest=3D"LOW" > #economy_cpu_freq=3D${economy_cx_lowest} > > in rc.conf was the problem. Can you get a backtrace? I've been experiencing something strange lately after applying optimization settings from: http://wiki.freebsd.org/TuningPowerConsumption I can't get a useful dump either, the machine is idle, and the backtrace is strange to me: db> show allpcpu Current CPU: 0 cpuid =3D 0 dynamic pcpu =3D 0x692d00 curthread =3D 0xffffff0001507390: pid 11 "idle: cpu0" curpcb =3D 0xffffff8000039d40 fpcurthread =3D none idlethread =3D 0xffffff0001507390: pid 11 "idle: cpu0" curpmap =3D 0 tssp =3D 0xffffffff80840580 commontssp =3D 0xffffffff80840580 rsp0 =3D 0xffffff8000039d40 gs32p =3D 0xffffffff8083f3b8 ldt =3D 0xffffffff8083f3f8 tss =3D 0xffffffff8083f3e8 cpuid =3D 1 dynamic pcpu =3D 0xffffff807f85ed00 curthread =3D 0xffffff0001507720: pid 11 "idle: cpu1" curpcb =3D 0xffffff8000034d40 fpcurthread =3D none idlethread =3D 0xffffff0001507720: pid 11 "idle: cpu1" curpmap =3D 0 tssp =3D 0xffffffff808405e8 commontssp =3D 0xffffffff808405e8 rsp0 =3D 0xffffff8000034d40 gs32p =3D 0xffffffff8083f420 ldt =3D 0xffffffff8083f460 tss =3D 0xffffffff8083f450 db> bt Tracing pid 11 tid 100004 td 0xffffff0001507390 rman_get_bushandle() at rman_get_bushandle+0x1 sched_idletd() at sched_idletd+0x123 fork_exit() at fork_exit+0x118 fork_trampoline() at fork_trampoline+0xe --- trap 0, rip =3D 0, rsp =3D 0xffffff8000039d30, rbp =3D 0 --- -Brandon From owner-freebsd-stable@FreeBSD.ORG Mon May 3 22:39:50 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id D99A4106564A for ; Mon, 3 May 2010 22:39:50 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta02.westchester.pa.mail.comcast.net (qmta02.westchester.pa.mail.comcast.net [76.96.62.24]) by mx1.freebsd.org (Postfix) with ESMTP id 8698E8FC08 for ; Mon, 3 May 2010 22:39:50 +0000 (UTC) Received: from omta19.westchester.pa.mail.comcast.net ([76.96.62.98]) by qmta02.westchester.pa.mail.comcast.net with comcast id D0Pf1e00C27AodY52Afq6r; Mon, 03 May 2010 22:39:50 +0000 Received: from koitsu.dyndns.org ([98.248.46.159]) by omta19.westchester.pa.mail.comcast.net with comcast id DAfp1e0053S48mS3fAfpwW; Mon, 03 May 2010 22:39:50 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 163859B425; Mon, 3 May 2010 15:39:48 -0700 (PDT) Date: Mon, 3 May 2010 15:39:48 -0700 From: Jeremy Chadwick To: Bryce Edwards Message-ID: <20100503223948.GA9134@icarus.home.lan> References: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Cc: freebsd-stable@freebsd.org Subject: Re: 8-STABLE performance issues on Supermicro Core i7 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 03 May 2010 22:39:51 -0000 On Sun, May 02, 2010 at 09:40:13PM -0500, Bryce Edwards wrote: > I've got a new Supermicro X58 system with an Intel Core i7 930 with 6 > GB ram that is not performing nearly as fast as it should in many ways > (compiling, network transfers).  To give an example, it has been > building the gcc44 port for about 10 hours now and at the same time > rsync'ing from a Linux box on the same Gigabit network is only getting > throughput of between 10-25 MB/sec.  When I did a buildkernel for > 8-STABLE, it took 17 hours! My investigations have shown inhibited > performance on compute, network and storage activities. > ... > Thanks in advance for any ideas. Here's some system info and stats: > ... > hint.p4tcc.0.disabled=1 > hint.acpi_throttle.0.disabled=1 Are you using powerd(8) on this machine? Does the behaviour change if you shut it off? > FreeBSD tahiti.bryce.net 8.0-STABLE FreeBSD 8.0-STABLE #0: Wed Apr 28 10:53:37 CDT 2010 > ... > bryce@tahiti[~]>cat /etc/sysctl.conf > kern.timecounter.hardware=HPET Can you explain why you're overriding the OSes choice here? According to other parts of your dmesg, ACPI-fast or ACPI-safe is a better choice. The output from "sysctl -a kern.timecounter" would list off all your timecounter choices. Why I ask: I tend to leave HPET disabled on Supermicro systems since ACPI-fast/safe have always been reliable for me on such. On every Supermicro system I've used, HPET has defaulted to disabled. > Dmesg output: > ... > ACPI Warning: Incorrect checksum in table [OEMB] - 0x7B, should be 0x74 (20100331/tbutils-354) I don't know if this could possibly explain the problem or not; freebsd-acpi might have some ideas. > pci0: at device 20.0 (no driver attached) > pci0: at device 20.1 (no driver attached) > pci0: at device 20.2 (no driver attached) > pci0: at device 20.3 (no driver attached) > pci0: at device 22.0 (no driver attached) > pci0: at device 22.1 (no driver attached) > pci0: at device 22.2 (no driver attached) > pci0: at device 22.3 (no driver attached) > pci0: at device 22.4 (no driver attached) > pci0: at device 22.5 (no driver attached) > pci0: at device 22.6 (no driver attached) > pci0: at device 22.7 (no driver attached) I have no idea what to make of this, but I see "interrupt controller" and I get a bit concerned. The reason is, ahci0 on your system ties in to pci0: > ahci0: port 0xa480-0xa487,0xb000-0xb003,0xac00-0xac07,0xa880-0xa883,0xa800-0xa81f mem 0xf9fda000-0xf9fda7ff irq 19 at device 31.2 on pci0 -- | 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 May 3 22:42:07 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B8F3F1065673 for ; Mon, 3 May 2010 22:42:07 +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 A08C58FC27 for ; Mon, 3 May 2010 22:42:07 +0000 (UTC) Received: from omta20.emeryville.ca.mail.comcast.net ([76.96.30.87]) by qmta01.emeryville.ca.mail.comcast.net with comcast id D1g11e0061smiN4A1Ai8s3; Mon, 03 May 2010 22:42:08 +0000 Received: from koitsu.dyndns.org ([98.248.46.159]) by omta20.emeryville.ca.mail.comcast.net with comcast id DAi71e00H3S48mS8gAi72B; Mon, 03 May 2010 22:42:08 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 592209B425; Mon, 3 May 2010 15:42:06 -0700 (PDT) Date: Mon, 3 May 2010 15:42:06 -0700 From: Jeremy Chadwick To: David DEMELIER Message-ID: <20100503224206.GB9134@icarus.home.lan> References: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Cc: freebsd-stable@freebsd.org Subject: Re: Kernel panic when unpluggin AC adaptor X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 03 May 2010 22:42:07 -0000 On Mon, May 03, 2010 at 11:57:28PM +0200, David DEMELIER wrote: > 2010/5/3 David DEMELIER : > > Hi, > > > > I just updated my 8.0-STABLE/amd64 today around 17h CEST, and it just > > panics when I unplug my AC.  The current process = 11 (idle: cpu1) is > > this related to the cpufreq and related stuff ? > > > > It also says cannot dump. Device not defined or unavailable so I can't > > give you more infos now. > > > > I can confirm that : > > #performance_cx_lowest="HIGH" > #performance_cpu_freq=${performance_cx_lowest} > #economy_cx_lowest="LOW" > #economy_cpu_freq=${economy_cx_lowest} > > in rc.conf was the problem. When these are commented out, can you provide the output from: sysctl -a dev.cpu Can you confirm whether or not powerd(8) is in use on this system when it panics? If so, does the problem go away if you disable powerd(8) but leave in (uncommented) the above rc.conf settings? -- | 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 May 3 22:48:17 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 53FF31065670 for ; Mon, 3 May 2010 22:48:17 +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 022E78FC08 for ; Mon, 3 May 2010 22:48:16 +0000 (UTC) Received: from omta21.westchester.pa.mail.comcast.net ([76.96.62.72]) by qmta12.westchester.pa.mail.comcast.net with comcast id D2vR1e0051ZXKqc5CAoH0o; Mon, 03 May 2010 22:48:17 +0000 Received: from koitsu.dyndns.org ([98.248.46.159]) by omta21.westchester.pa.mail.comcast.net with comcast id DAoG1e0053S48mS3hAoGjz; Mon, 03 May 2010 22:48:17 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id C24899B425; Mon, 3 May 2010 15:48:14 -0700 (PDT) Date: Mon, 3 May 2010 15:48:14 -0700 From: Jeremy Chadwick To: Bryce Edwards Message-ID: <20100503224814.GA9477@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) Cc: freebsd-stable@freebsd.org Subject: Re: 8-STABLE performance issues on Supermicro Core i7 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 03 May 2010 22:48:17 -0000 On Sun, May 02, 2010 at 09:40:13PM -0500, Bryce Edwards wrote: > I've got a new Supermicro X58 system with an Intel Core i7 930 with 6 > GB ram that is not performing nearly as fast as it should in many ways > (compiling, network transfers). By the way, an interesting thread you might read -- yes it's long. Subject "Only 70% of theoretical peak performance on FreeBSD 8/amd64, Corei7 920": http://lists.freebsd.org/pipermail/freebsd-stable/2010-April/thread.html#56253 The performance stats you're providing are much lower than 70% peak, so I'm not sure there's a correlation, but that's a thread which did bring up odd performance-affecting changes in the i5/i7 architecture: http://lists.freebsd.org/pipermail/freebsd-stable/2010-April/056332.html It's also hard to determine from the thread given its length, but I believe pinning a process to an individual CPU increased (~20%+) the OPs performance. http://lists.freebsd.org/pipermail/freebsd-stable/2010-April/056316.html http://lists.freebsd.org/pipermail/freebsd-stable/2010-April/056339.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 Tue May 4 02:16:59 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 81D3B106566C for ; Tue, 4 May 2010 02:16:59 +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 2194A8FC1D for ; Tue, 4 May 2010 02:16:58 +0000 (UTC) Received: (qmail 80337 invoked by uid 0); 4 May 2010 02:16:57 -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; 4 May 2010 02:16:57 -0000 Date: Mon, 3 May 2010 22:16:57 -0400 (EDT) From: Charles Sprickman X-X-Sender: spork@hotlap.local To: Wes Morgan In-Reply-To: Message-ID: References: <201005021536.05389.jafa82@gmail.com> User-Agent: Alpine 2.00 (OSX 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Eric Damien , freebsd-stable@freebsd.org Subject: Re: ZFS: separate pools X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 04 May 2010 02:16:59 -0000 On Sun, 2 May 2010, Wes Morgan wrote: > On Sun, 2 May 2010, Eric Damien wrote: > >> Hello list. >> >> I am taking my first steps with ZFS. In the past, I used to have two UFS >> slices: one dedicated to the o.s. partitions, and the second to data (/home, >> etc.). I read on that it was possible to recreate that logic with zfs, using >> separate pools. >> >> Considering the example of >> http://wiki.freebsd.org/RootOnZFS/GPTZFSBoot, >> any idea how I can adapt that to my needs? I am concerned about all the >> different mountpoints. > > Well, you need not create all those filesystems if you don't want them. > The pool and FreeBSD will function just fine. > > However, as far as storage is concerned, there is no disadvantage to > having additional mount pounts. The only limits each filesystem will have > is a limit you explicitly impose. There are many advantages, though. Some > datasets are inherently compressible or incompressible. Other datasets you > may not want to schedule for snapshots, or allow files to be executed, > suid, checksummed, block sizes, you name it (as the examples in the wiki > demonstrate). > > Furthermore, each pool requires its own vdev. If you create slices on a > drive and then make each slice its own pool, I would wonder if zfs's > internal queuing would understand the topology and be able to work as > efficiently. Just a thought, though. I have two boxes setup where zfs is on top of slices like that. One has a small zpool across 3 disks - the rest of those disks and 3 other disks of the same size also make up another zpool. The hardware is old, so performance just is not spectacular (old 8 port 3Ware PATA card). I can't tell if this config is contributing to the somewhat anemic (by today's standards) r/w speeds or not. Another has 4 drives with a gmirror setup on two of the drives for the OS (20G out of 1TB). This box performs extremely well (bonnie++ shows 123MB/s writes, 142MB/s reads). Just some random data. I know when I was reading about ZFS I did come across some vague notion that zfs wanted the entire drive to better deal with queueing, not sure if that was official Sun docs or some random blog though... Charles > _______________________________________________ > 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 May 4 02:34:59 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 9B3AA106564A for ; Tue, 4 May 2010 02:34:59 +0000 (UTC) (envelope-from emikulic@gmail.com) Received: from ipmail06.adl2.internode.on.net (ipmail06.adl2.internode.on.net [150.101.137.129]) by mx1.freebsd.org (Postfix) with ESMTP id 226878FC0C for ; Tue, 4 May 2010 02:34:58 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAOMh30uWZZrw/2dsb2JhbACSZ4pJcawUhycuiFOFEgQ Received: from ppp154-240.static.internode.on.net ([150.101.154.240]) by ipmail06.adl2.internode.on.net with ESMTP; 04 May 2010 12:04:57 +0930 Received: by ppp154-240.static.internode.on.net (Poo-fix, from userid 1001) id 67F815D06; Tue, 4 May 2010 12:34:57 +1000 (EST) Date: Tue, 4 May 2010 12:34:57 +1000 From: Emil Mikulic To: Charles Sprickman Message-ID: <20100504023457.GD7641@dmr.ath.cx> References: <201005021536.05389.jafa82@gmail.com> 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) Cc: freebsd-stable@freebsd.org Subject: Re: ZFS: separate pools X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 04 May 2010 02:34:59 -0000 On Mon, May 03, 2010 at 10:16:57PM -0400, Charles Sprickman wrote: > Just some random data. I know when I was reading about ZFS I did > come across some vague notion that zfs wanted the entire drive to > better deal with queueing, not sure if that was official Sun docs or > some random blog though... ZFS on Solaris only enables write caching when it's given an entire disk. pjd@ has stated that this does not affect FreeBSD, only Solaris. From owner-freebsd-stable@FreeBSD.ORG Tue May 4 02:38:07 2010 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A80A0106566B; Tue, 4 May 2010 02:38:07 +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 5C9DB8FC18; Tue, 4 May 2010 02:38:07 +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 o442c4IW006603; Mon, 3 May 2010 22:38:04 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-legacy.sentex.ca (freebsd-legacy.sentex.ca [64.7.128.104]) by smtp2.sentex.ca (8.14.4/8.14.4) with ESMTP id o442c4fQ068669; Mon, 3 May 2010 22:38:04 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-legacy.sentex.ca (Postfix, from userid 666) id 385BB241A2; Mon, 3 May 2010 22:38:04 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20100504023804.385BB241A2@freebsd-legacy.sentex.ca> Date: Mon, 3 May 2010 22:38:04 -0400 (EDT) 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_6 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: Tue, 04 May 2010 02:38:07 -0000 TB --- 2010-05-04 01:42:28 - tinderbox 2.6 running on freebsd-legacy.sentex.ca TB --- 2010-05-04 01:42:28 - starting RELENG_6 tinderbox run for i386/i386 TB --- 2010-05-04 01:42:28 - cleaning the object tree TB --- 2010-05-04 01:42:43 - cvsupping the source tree TB --- 2010-05-04 01:42:43 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /home/tinderbox/RELENG_6/i386/i386/supfile TB --- 2010-05-04 01:42:51 - building world TB --- 2010-05-04 01:42:51 - MAKEOBJDIRPREFIX=/obj TB --- 2010-05-04 01:42:51 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-05-04 01:42:51 - TARGET=i386 TB --- 2010-05-04 01:42:51 - TARGET_ARCH=i386 TB --- 2010-05-04 01:42:51 - TZ=UTC TB --- 2010-05-04 01:42:51 - __MAKE_CONF=/dev/null TB --- 2010-05-04 01:42:51 - cd /src TB --- 2010-05-04 01:42:51 - /usr/bin/make -B buildworld >>> 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 TB --- 2010-05-04 02:33:49 - generating LINT kernel config TB --- 2010-05-04 02:33:49 - cd /src/sys/i386/conf TB --- 2010-05-04 02:33:49 - /usr/bin/make -B LINT TB --- 2010-05-04 02:33:49 - building LINT kernel TB --- 2010-05-04 02:33:49 - MAKEOBJDIRPREFIX=/obj TB --- 2010-05-04 02:33:49 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-05-04 02:33:49 - TARGET=i386 TB --- 2010-05-04 02:33:49 - TARGET_ARCH=i386 TB --- 2010-05-04 02:33:49 - TZ=UTC TB --- 2010-05-04 02:33:49 - __MAKE_CONF=/dev/null TB --- 2010-05-04 02:33:49 - cd /src TB --- 2010-05-04 02:33:49 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Tue May 4 02:33:49 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 -c -O2 -pipe -fno-strict-aliasing -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ipfilter -I/src/sys/contrib/pf -I/src/sys/dev/ath -I/src/sys/contrib/ngatm -I/src/sys/dev/twa -I/src/sys/dev/em -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -ffreestanding -Werror -pg -mprofiler-epilogue /src/sys/dev/an/if_an_pccard.c cc -c -O2 -pipe -fno-strict-aliasing -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ipfilter -I/src/sys/contrib/pf -I/src/sys/dev/ath -I/src/sys/contrib/ngatm -I/src/sys/dev/twa -I/src/sys/dev/em -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -ffreestanding -Werror -pg -mprofiler-epilogue /src/sys/dev/an/if_an_pci.c cc -c -O2 -pipe -fno-strict-aliasing -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ipfilter -I/src/sys/contrib/pf -I/src/sys/dev/ath -I/src/sys/contrib/ngatm -I/src/sys/dev/twa -I/src/sys/dev/em -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -ffreestanding -Werror -pg -mprofiler-epilogue /src/sys/dev/asr/asr.c awk -f /src/sys/tools/makeobjops.awk /src/sys/dev/ata/ata_if.m -c ; cc -c -O2 -pipe -fno-strict-aliasing -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ipfilter -I/src/sys/contrib/pf -I/src/sys/dev/ath -I/src/sys/contrib/ngatm -I/src/sys/dev/twa -I/src/sys/dev/em -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -ffreestanding -Werror -pg -mprofiler-epilogue ata_if.c cc -c -O2 -pipe -fno-strict-aliasing -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ipfilter -I/src/sys/contrib/pf -I/src/sys/dev/ath -I/src/sys/contrib/ngatm -I/src/sys/dev/twa -I/src/sys/dev/em -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -ffreestanding -Werror -pg -mprofiler-epilogue /src/sys/dev/ata/ata-all.c /src/sys/dev/ata/ata-all.c: In function `ata_device_ioctl': /src/sys/dev/ata/ata-all.c:452: error: request for member `max_iosize' in something not a structure or union /src/sys/dev/ata/ata-all.c:452: error: request for member `max_iosize' in something not a structure or union *** Error code 1 Stop in /obj/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2010-05-04 02:38:03 - WARNING: /usr/bin/make returned exit code 1 TB --- 2010-05-04 02:38:03 - ERROR: failed to build lint kernel TB --- 2010-05-04 02:38:03 - 2761.38 user 372.75 system 3335.56 real http://tinderbox.freebsd.org/tinderbox-releng_6-RELENG_6-i386-i386.full From owner-freebsd-stable@FreeBSD.ORG Tue May 4 02:41:40 2010 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id BB9531065696; Tue, 4 May 2010 02:41:40 +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 770C78FC0C; Tue, 4 May 2010 02:41:40 +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 o442fb4R065659; Mon, 3 May 2010 22:41:37 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-legacy.sentex.ca (freebsd-legacy.sentex.ca [64.7.128.104]) by smtp1.sentex.ca (8.14.3/8.14.3) with ESMTP id o442fbaZ002386; Mon, 3 May 2010 22:41:37 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-legacy.sentex.ca (Postfix, from userid 666) id DF8A6241A2; Mon, 3 May 2010 22:41:36 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20100504024136.DF8A6241A2@freebsd-legacy.sentex.ca> Date: Mon, 3 May 2010 22:41:36 -0400 (EDT) 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_6 tinderbox] failure on amd64/amd64 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 May 2010 02:41:40 -0000 TB --- 2010-05-04 01:23:08 - tinderbox 2.6 running on freebsd-legacy.sentex.ca TB --- 2010-05-04 01:23:08 - starting RELENG_6 tinderbox run for amd64/amd64 TB --- 2010-05-04 01:23:08 - cleaning the object tree TB --- 2010-05-04 01:23:30 - cvsupping the source tree TB --- 2010-05-04 01:23:30 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /home/tinderbox/RELENG_6/amd64/amd64/supfile TB --- 2010-05-04 01:23:38 - building world TB --- 2010-05-04 01:23:38 - MAKEOBJDIRPREFIX=/obj TB --- 2010-05-04 01:23:38 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-05-04 01:23:38 - TARGET=amd64 TB --- 2010-05-04 01:23:38 - TARGET_ARCH=amd64 TB --- 2010-05-04 01:23:38 - TZ=UTC TB --- 2010-05-04 01:23:38 - __MAKE_CONF=/dev/null TB --- 2010-05-04 01:23:38 - cd /src TB --- 2010-05-04 01:23:38 - /usr/bin/make -B buildworld >>> 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 TB --- 2010-05-04 02:37:27 - generating LINT kernel config TB --- 2010-05-04 02:37:27 - cd /src/sys/amd64/conf TB --- 2010-05-04 02:37:27 - /usr/bin/make -B LINT TB --- 2010-05-04 02:37:27 - building LINT kernel TB --- 2010-05-04 02:37:27 - MAKEOBJDIRPREFIX=/obj TB --- 2010-05-04 02:37:27 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-05-04 02:37:27 - TARGET=amd64 TB --- 2010-05-04 02:37:27 - TARGET_ARCH=amd64 TB --- 2010-05-04 02:37:27 - TZ=UTC TB --- 2010-05-04 02:37:27 - __MAKE_CONF=/dev/null TB --- 2010-05-04 02:37:27 - cd /src TB --- 2010-05-04 02:37:27 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Tue May 4 02:37:27 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 -c -O2 -frename-registers -pipe -fno-strict-aliasing -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ipfilter -I/src/sys/contrib/pf -I/src/sys/dev/ath -I/src/sys/contrib/ngatm -I/src/sys/dev/twa -I/src/sys/dev/em -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -Werror -pg -mprofiler-epilogue /src/sys/dev/an/if_an_pccard.c cc -c -O2 -frename-registers -pipe -fno-strict-aliasing -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ipfilter -I/src/sys/contrib/pf -I/src/sys/dev/ath -I/src/sys/contrib/ngatm -I/src/sys/dev/twa -I/src/sys/dev/em -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -Werror -pg -mprofiler-epilogue /src/sys/dev/an/if_an_pci.c cc -c -O2 -frename-registers -pipe -fno-strict-aliasing -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ipfilter -I/src/sys/contrib/pf -I/src/sys/dev/ath -I/src/sys/contrib/ngatm -I/src/sys/dev/twa -I/src/sys/dev/em -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -Werror -pg -mprofiler-epilogue /src/sys/dev/asr/asr.c awk -f /src/sys/tools/makeobjops.awk /src/sys/dev/ata/ata_if.m -c ; cc -c -O2 -frename-registers -pipe -fno-strict-aliasing -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ipfilter -I/src/sys/contrib/pf -I/src/sys/dev/ath -I/src/sys/contrib/ngatm -I/src/sys/dev/twa -I/src/sys/dev/em -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -Werror -pg -mprofiler-epilogue ata_if.c cc -c -O2 -frename-registers -pipe -fno-strict-aliasing -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ipfilter -I/src/sys/contrib/pf -I/src/sys/dev/ath -I/src/sys/contrib/ngatm -I/src/sys/dev/twa -I/src/sys/dev/em -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -Werror -pg -mprofiler-epilogue /src/sys/dev/ata/ata-all.c /src/sys/dev/ata/ata-all.c: In function `ata_device_ioctl': /src/sys/dev/ata/ata-all.c:452: error: request for member `max_iosize' in something not a structure or union /src/sys/dev/ata/ata-all.c:452: error: request for member `max_iosize' in something not a structure or union *** Error code 1 Stop in /obj/amd64/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2010-05-04 02:41:36 - WARNING: /usr/bin/make returned exit code 1 TB --- 2010-05-04 02:41:36 - ERROR: failed to build lint kernel TB --- 2010-05-04 02:41:36 - 3895.71 user 547.20 system 4708.25 real http://tinderbox.freebsd.org/tinderbox-releng_6-RELENG_6-amd64-amd64.full From owner-freebsd-stable@FreeBSD.ORG Tue May 4 03:33:01 2010 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 47C171065670; Tue, 4 May 2010 03:33:01 +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 062F58FC08; Tue, 4 May 2010 03:32:59 +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 o443WvTI008657; Mon, 3 May 2010 23:32:57 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-legacy.sentex.ca (freebsd-legacy.sentex.ca [64.7.128.104]) by smtp2.sentex.ca (8.14.4/8.14.4) with ESMTP id o443WuhU089043; Mon, 3 May 2010 23:32:56 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-legacy.sentex.ca (Postfix, from userid 666) id B102F241A2; Mon, 3 May 2010 23:32:56 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20100504033256.B102F241A2@freebsd-legacy.sentex.ca> Date: Mon, 3 May 2010 23:32:56 -0400 (EDT) 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_6 tinderbox] failure on i386/pc98 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 May 2010 03:33:01 -0000 TB --- 2010-05-04 02:38:04 - tinderbox 2.6 running on freebsd-legacy.sentex.ca TB --- 2010-05-04 02:38:04 - starting RELENG_6 tinderbox run for i386/pc98 TB --- 2010-05-04 02:38:04 - cleaning the object tree TB --- 2010-05-04 02:38:24 - cvsupping the source tree TB --- 2010-05-04 02:38:24 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /home/tinderbox/RELENG_6/i386/pc98/supfile TB --- 2010-05-04 02:38:32 - building world TB --- 2010-05-04 02:38:32 - MAKEOBJDIRPREFIX=/obj TB --- 2010-05-04 02:38:32 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-05-04 02:38:32 - TARGET=pc98 TB --- 2010-05-04 02:38:32 - TARGET_ARCH=i386 TB --- 2010-05-04 02:38:32 - TZ=UTC TB --- 2010-05-04 02:38:32 - __MAKE_CONF=/dev/null TB --- 2010-05-04 02:38:32 - cd /src TB --- 2010-05-04 02:38:32 - /usr/bin/make -B buildworld >>> 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 TB --- 2010-05-04 03:29:40 - generating LINT kernel config TB --- 2010-05-04 03:29:40 - cd /src/sys/pc98/conf TB --- 2010-05-04 03:29:40 - /usr/bin/make -B LINT TB --- 2010-05-04 03:29:40 - building LINT kernel TB --- 2010-05-04 03:29:40 - MAKEOBJDIRPREFIX=/obj TB --- 2010-05-04 03:29:40 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-05-04 03:29:40 - TARGET=pc98 TB --- 2010-05-04 03:29:40 - TARGET_ARCH=i386 TB --- 2010-05-04 03:29:40 - TZ=UTC TB --- 2010-05-04 03:29:40 - __MAKE_CONF=/dev/null TB --- 2010-05-04 03:29:40 - cd /src TB --- 2010-05-04 03:29:40 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Tue May 4 03:29:40 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 -c -O2 -pipe -fno-strict-aliasing -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ipfilter -I/src/sys/contrib/pf -I/src/sys/dev/ath -I/src/sys/contrib/ngatm -I/src/sys/dev/twa -I/src/sys/dev/em -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -ffreestanding -Werror -pg -mprofiler-epilogue /src/sys/dev/an/if_an_isa.c cc -c -O2 -pipe -fno-strict-aliasing -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ipfilter -I/src/sys/contrib/pf -I/src/sys/dev/ath -I/src/sys/contrib/ngatm -I/src/sys/dev/twa -I/src/sys/dev/em -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -ffreestanding -Werror -pg -mprofiler-epilogue /src/sys/dev/an/if_an_pccard.c cc -c -O2 -pipe -fno-strict-aliasing -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ipfilter -I/src/sys/contrib/pf -I/src/sys/dev/ath -I/src/sys/contrib/ngatm -I/src/sys/dev/twa -I/src/sys/dev/em -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -ffreestanding -Werror -pg -mprofiler-epilogue /src/sys/dev/an/if_an_pci.c awk -f /src/sys/tools/makeobjops.awk /src/sys/dev/ata/ata_if.m -c ; cc -c -O2 -pipe -fno-strict-aliasing -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ipfilter -I/src/sys/contrib/pf -I/src/sys/dev/ath -I/src/sys/contrib/ngatm -I/src/sys/dev/twa -I/src/sys/dev/em -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -ffreestanding -Werror -pg -mprofiler-epilogue ata_if.c cc -c -O2 -pipe -fno-strict-aliasing -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ipfilter -I/src/sys/contrib/pf -I/src/sys/dev/ath -I/src/sys/contrib/ngatm -I/src/sys/dev/twa -I/src/sys/dev/em -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -ffreestanding -Werror -pg -mprofiler-epilogue /src/sys/dev/ata/ata-all.c /src/sys/dev/ata/ata-all.c: In function `ata_device_ioctl': /src/sys/dev/ata/ata-all.c:452: error: request for member `max_iosize' in something not a structure or union /src/sys/dev/ata/ata-all.c:452: error: request for member `max_iosize' in something not a structure or union *** Error code 1 Stop in /obj/pc98/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2010-05-04 03:32:56 - WARNING: /usr/bin/make returned exit code 1 TB --- 2010-05-04 03:32:56 - ERROR: failed to build lint kernel TB --- 2010-05-04 03:32:56 - 2681.51 user 381.12 system 3292.13 real http://tinderbox.freebsd.org/tinderbox-releng_6-RELENG_6-i386-pc98.full From owner-freebsd-stable@FreeBSD.ORG Tue May 4 03:36:12 2010 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 4D216106566B; Tue, 4 May 2010 03:36:12 +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 0697F8FC0C; Tue, 4 May 2010 03:36:11 +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 o443a9qu008721; Mon, 3 May 2010 23:36:09 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-legacy.sentex.ca (freebsd-legacy.sentex.ca [64.7.128.104]) by smtp2.sentex.ca (8.14.4/8.14.4) with ESMTP id o443a9FS090259; Mon, 3 May 2010 23:36:09 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-legacy.sentex.ca (Postfix, from userid 666) id 3EC7D241A2; Mon, 3 May 2010 23:36:09 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20100504033609.3EC7D241A2@freebsd-legacy.sentex.ca> Date: Mon, 3 May 2010 23:36:09 -0400 (EDT) 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_6 tinderbox] failure on sparc64/sparc64 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 May 2010 03:36:12 -0000 TB --- 2010-05-04 02:41:37 - tinderbox 2.6 running on freebsd-legacy.sentex.ca TB --- 2010-05-04 02:41:37 - starting RELENG_6 tinderbox run for sparc64/sparc64 TB --- 2010-05-04 02:41:37 - cleaning the object tree TB --- 2010-05-04 02:41:49 - cvsupping the source tree TB --- 2010-05-04 02:41:49 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /home/tinderbox/RELENG_6/sparc64/sparc64/supfile TB --- 2010-05-04 02:41:57 - building world TB --- 2010-05-04 02:41:57 - MAKEOBJDIRPREFIX=/obj TB --- 2010-05-04 02:41:57 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-05-04 02:41:57 - TARGET=sparc64 TB --- 2010-05-04 02:41:57 - TARGET_ARCH=sparc64 TB --- 2010-05-04 02:41:57 - TZ=UTC TB --- 2010-05-04 02:41:57 - __MAKE_CONF=/dev/null TB --- 2010-05-04 02:41:57 - cd /src TB --- 2010-05-04 02:41:57 - /usr/bin/make -B buildworld >>> 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 TB --- 2010-05-04 03:33:18 - generating LINT kernel config TB --- 2010-05-04 03:33:18 - cd /src/sys/sparc64/conf TB --- 2010-05-04 03:33:18 - /usr/bin/make -B LINT TB --- 2010-05-04 03:33:18 - building LINT kernel TB --- 2010-05-04 03:33:18 - MAKEOBJDIRPREFIX=/obj TB --- 2010-05-04 03:33:18 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-05-04 03:33:18 - TARGET=sparc64 TB --- 2010-05-04 03:33:18 - TARGET_ARCH=sparc64 TB --- 2010-05-04 03:33:18 - TZ=UTC TB --- 2010-05-04 03:33:18 - __MAKE_CONF=/dev/null TB --- 2010-05-04 03:33:18 - cd /src TB --- 2010-05-04 03:33:18 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Tue May 4 03:33:18 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 -c -O2 -pipe -fno-strict-aliasing -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ipfilter -I/src/sys/contrib/pf -I/src/sys/dev/ath -I/src/sys/contrib/ngatm -I/src/sys/dev/twa -I/src/sys/dev/em -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medlow -msoft-float -ffreestanding -Werror /src/sys/dev/an/if_an_pccard.c cc -c -O2 -pipe -fno-strict-aliasing -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ipfilter -I/src/sys/contrib/pf -I/src/sys/dev/ath -I/src/sys/contrib/ngatm -I/src/sys/dev/twa -I/src/sys/dev/em -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medlow -msoft-float -ffreestanding -Werror /src/sys/dev/an/if_an_pci.c cc -c -O2 -pipe -fno-strict-aliasing -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ipfilter -I/src/sys/contrib/pf -I/src/sys/dev/ath -I/src/sys/contrib/ngatm -I/src/sys/dev/twa -I/src/sys/dev/em -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medlow -msoft-float -ffreestanding -Werror /src/sys/dev/asr/asr.c awk -f /src/sys/tools/makeobjops.awk /src/sys/dev/ata/ata_if.m -c ; cc -c -O2 -pipe -fno-strict-aliasing -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ipfilter -I/src/sys/contrib/pf -I/src/sys/dev/ath -I/src/sys/contrib/ngatm -I/src/sys/dev/twa -I/src/sys/dev/em -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medlow -msoft-float -ffreestanding -Werror ata_if.c cc -c -O2 -pipe -fno-strict-aliasing -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ipfilter -I/src/sys/contrib/pf -I/src/sys/dev/ath -I/src/sys/contrib/ngatm -I/src/sys/dev/twa -I/src/sys/dev/em -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medlow -msoft-float -ffreestanding -Werror /src/sys/dev/ata/ata-all.c /src/sys/dev/ata/ata-all.c: In function `ata_device_ioctl': /src/sys/dev/ata/ata-all.c:452: error: request for member `max_iosize' in something not a structure or union /src/sys/dev/ata/ata-all.c:452: error: request for member `max_iosize' in something not a structure or union *** Error code 1 Stop in /obj/sparc64/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2010-05-04 03:36:09 - WARNING: /usr/bin/make returned exit code 1 TB --- 2010-05-04 03:36:09 - ERROR: failed to build lint kernel TB --- 2010-05-04 03:36:09 - 2727.24 user 352.25 system 3272.16 real http://tinderbox.freebsd.org/tinderbox-releng_6-RELENG_6-sparc64-sparc64.full From owner-freebsd-stable@FreeBSD.ORG Tue May 4 05:24:26 2010 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id F03021065670; Tue, 4 May 2010 05:24:26 +0000 (UTC) (envelope-from delphij@gmail.com) Received: from mail-pz0-f201.google.com (mail-pz0-f201.google.com [209.85.222.201]) by mx1.freebsd.org (Postfix) with ESMTP id BC4A68FC1A; Tue, 4 May 2010 05:24:26 +0000 (UTC) Received: by pzk39 with SMTP id 39so1684391pzk.7 for ; Mon, 03 May 2010 22:24:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=A+7NBPjcytFJHEJ5/TWl7RspRk4S3xl8EVKPXZZDrFo=; b=e7O7QfZq0WvMqeSF1jCv1EzNxP81VgiQE+LuILVHMhsiU4dvPvolqEP2GgnY+tMajA AzY9Ru0AivTDuAzSLkzwxMR0QYzjfcrlWP2KpXXsJHieNlQ66UZGM82YAnDHYnbNXMQS JXh1RnPBmWwTmLGFLc6IDA/r7o1CUIAUmBzXI= 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:content-transfer-encoding; b=wfOVff9b6C1ddAt9yUMO5Rt8xfHgLH+LvgzCwAWe05OsnRsdmq8VFtMuWmh1xC4LOF 9ducIWDIme2AC5llnPpaXcpF9nkUs2AJDrwRQGKFY9eSbbvMOPnEuqkpyJ2xqn83M6Yk zDokXT2Ge2snEWIew44R5aV7cCPJ6iqxeB3LQ= MIME-Version: 1.0 Received: by 10.141.14.6 with SMTP id r6mr4113157rvi.69.1272950655031; Mon, 03 May 2010 22:24:15 -0700 (PDT) Received: by 10.140.125.10 with HTTP; Mon, 3 May 2010 22:24:14 -0700 (PDT) In-Reply-To: <20100504033609.3EC7D241A2@freebsd-legacy.sentex.ca> References: <20100504033609.3EC7D241A2@freebsd-legacy.sentex.ca> Date: Mon, 3 May 2010 22:24:14 -0700 Message-ID: From: Xin LI To: FreeBSD Tinderbox Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: stable@freebsd.org, sparc64@freebsd.org Subject: Re: [releng_6 tinderbox] failure on sparc64/sparc64 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 04 May 2010 05:24:27 -0000 Sorry for the breakage. This should have been fixed now. On Mon, May 3, 2010 at 8:36 PM, FreeBSD Tinderbox w= rote: > TB --- 2010-05-04 02:41:37 - tinderbox 2.6 running on freebsd-legacy.sent= ex.ca > TB --- 2010-05-04 02:41:37 - starting RELENG_6 tinderbox run for sparc64/= sparc64 > TB --- 2010-05-04 02:41:37 - cleaning the object tree > TB --- 2010-05-04 02:41:49 - cvsupping the source tree > TB --- 2010-05-04 02:41:49 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -= s /home/tinderbox/RELENG_6/sparc64/sparc64/supfile > TB --- 2010-05-04 02:41:57 - building world > TB --- 2010-05-04 02:41:57 - MAKEOBJDIRPREFIX=3D/obj > TB --- 2010-05-04 02:41:57 - PATH=3D/usr/bin:/usr/sbin:/bin:/sbin > TB --- 2010-05-04 02:41:57 - TARGET=3Dsparc64 > TB --- 2010-05-04 02:41:57 - TARGET_ARCH=3Dsparc64 > TB --- 2010-05-04 02:41:57 - TZ=3DUTC > TB --- 2010-05-04 02:41:57 - __MAKE_CONF=3D/dev/null > TB --- 2010-05-04 02:41:57 - cd /src > TB --- 2010-05-04 02:41:57 - /usr/bin/make -B buildworld >>>> 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 > TB --- 2010-05-04 03:33:18 - generating LINT kernel config > TB --- 2010-05-04 03:33:18 - cd /src/sys/sparc64/conf > TB --- 2010-05-04 03:33:18 - /usr/bin/make -B LINT > TB --- 2010-05-04 03:33:18 - building LINT kernel > TB --- 2010-05-04 03:33:18 - MAKEOBJDIRPREFIX=3D/obj > TB --- 2010-05-04 03:33:18 - PATH=3D/usr/bin:/usr/sbin:/bin:/sbin > TB --- 2010-05-04 03:33:18 - TARGET=3Dsparc64 > TB --- 2010-05-04 03:33:18 - TARGET_ARCH=3Dsparc64 > TB --- 2010-05-04 03:33:18 - TZ=3DUTC > TB --- 2010-05-04 03:33:18 - __MAKE_CONF=3D/dev/null > TB --- 2010-05-04 03:33:18 - cd /src > TB --- 2010-05-04 03:33:18 - /usr/bin/make -B buildkernel KERNCONF=3DLINT >>>> Kernel build for LINT started on Tue May =C2=A04 03:33:18 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 -c -O2 -pipe -fno-strict-aliasing =C2=A0-Wall -Wredundant-decls -Wnest= ed-externs -Wstrict-prototypes =C2=A0-Wmissing-prototypes -Wpointer-arith -= Winline -Wcast-qual =C2=A0-fformat-extensions -std=3Dc99 =C2=A0-nostdinc -I= - =C2=A0-I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ipfilter = -I/src/sys/contrib/pf -I/src/sys/dev/ath -I/src/sys/contrib/ngatm -I/src/sy= s/dev/twa -I/src/sys/dev/em -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include= opt_global.h -fno-common -finline-limit=3D15000 --param inline-unit-growth= =3D100 --param large-function-growth=3D1000 -fno-builtin -mcmodel=3Dmedlow = -msoft-float -ffreestanding -Werror =C2=A0/src/sys/dev/an/if_an_pccard.c > cc -c -O2 -pipe -fno-strict-aliasing =C2=A0-Wall -Wredundant-decls -Wnest= ed-externs -Wstrict-prototypes =C2=A0-Wmissing-prototypes -Wpointer-arith -= Winline -Wcast-qual =C2=A0-fformat-extensions -std=3Dc99 =C2=A0-nostdinc -I= - =C2=A0-I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ipfilter = -I/src/sys/contrib/pf -I/src/sys/dev/ath -I/src/sys/contrib/ngatm -I/src/sy= s/dev/twa -I/src/sys/dev/em -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include= opt_global.h -fno-common -finline-limit=3D15000 --param inline-unit-growth= =3D100 --param large-function-growth=3D1000 -fno-builtin -mcmodel=3Dmedlow = -msoft-float -ffreestanding -Werror =C2=A0/src/sys/dev/an/if_an_pci.c > cc -c -O2 -pipe -fno-strict-aliasing =C2=A0-Wall -Wredundant-decls -Wnest= ed-externs -Wstrict-prototypes =C2=A0-Wmissing-prototypes -Wpointer-arith -= Winline -Wcast-qual =C2=A0-fformat-extensions -std=3Dc99 =C2=A0-nostdinc -I= - =C2=A0-I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ipfilter = -I/src/sys/contrib/pf -I/src/sys/dev/ath -I/src/sys/contrib/ngatm -I/src/sy= s/dev/twa -I/src/sys/dev/em -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include= opt_global.h -fno-common -finline-limit=3D15000 --param inline-unit-growth= =3D100 --param large-function-growth=3D1000 -fno-builtin -mcmodel=3Dmedlow = -msoft-float -ffreestanding -Werror =C2=A0/src/sys/dev/asr/asr.c > awk -f /src/sys/tools/makeobjops.awk /src/sys/dev/ata/ata_if.m -c ; =C2= =A0cc -c -O2 -pipe -fno-strict-aliasing =C2=A0-Wall -Wredundant-decls -Wnes= ted-externs -Wstrict-prototypes =C2=A0-Wmissing-prototypes -Wpointer-arith = -Winline -Wcast-qual =C2=A0-fformat-extensions -std=3Dc99 =C2=A0-nostdinc -= I- =C2=A0-I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ipfilter= -I/src/sys/contrib/pf -I/src/sys/dev/ath -I/src/sys/contrib/ngatm -I/src/s= ys/dev/twa -I/src/sys/dev/em -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -includ= e opt_global.h -fno-common -finline-limit=3D15000 --param inline-unit-growt= h=3D100 --param large-function-growth=3D1000 -fno-builtin -mcmodel=3Dmedlow= -msoft-float -ffreestanding -Werror =C2=A0ata_if.c > cc -c -O2 -pipe -fno-strict-aliasing =C2=A0-Wall -Wredundant-decls -Wnest= ed-externs -Wstrict-prototypes =C2=A0-Wmissing-prototypes -Wpointer-arith -= Winline -Wcast-qual =C2=A0-fformat-extensions -std=3Dc99 =C2=A0-nostdinc -I= - =C2=A0-I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ipfilter = -I/src/sys/contrib/pf -I/src/sys/dev/ath -I/src/sys/contrib/ngatm -I/src/sy= s/dev/twa -I/src/sys/dev/em -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include= opt_global.h -fno-common -finline-limit=3D15000 --param inline-unit-growth= =3D100 --param large-function-growth=3D1000 -fno-builtin -mcmodel=3Dmedlow = -msoft-float -ffreestanding -Werror =C2=A0/src/sys/dev/ata/ata-all.c > /src/sys/dev/ata/ata-all.c: In function `ata_device_ioctl': > /src/sys/dev/ata/ata-all.c:452: error: request for member `max_iosize' in= something not a structure or union > /src/sys/dev/ata/ata-all.c:452: error: request for member `max_iosize' in= something not a structure or union > *** Error code 1 > > Stop in /obj/sparc64/src/sys/LINT. > *** Error code 1 > > Stop in /src. > *** Error code 1 > > Stop in /src. > TB --- 2010-05-04 03:36:09 - WARNING: /usr/bin/make returned exit code = =C2=A01 > TB --- 2010-05-04 03:36:09 - ERROR: failed to build lint kernel > TB --- 2010-05-04 03:36:09 - 2727.24 user 352.25 system 3272.16 real > > > http://tinderbox.freebsd.org/tinderbox-releng_6-RELENG_6-sparc64-sparc64.= full > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" > --=20 Xin LI http://www.delphij.net From owner-freebsd-stable@FreeBSD.ORG Tue May 4 08:37:40 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 72C7B106566B for ; Tue, 4 May 2010 08:37:40 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta11.emeryville.ca.mail.comcast.net (qmta11.emeryville.ca.mail.comcast.net [76.96.27.211]) by mx1.freebsd.org (Postfix) with ESMTP id 5949D8FC19 for ; Tue, 4 May 2010 08:37:39 +0000 (UTC) Received: from omta07.emeryville.ca.mail.comcast.net ([76.96.30.59]) by qmta11.emeryville.ca.mail.comcast.net with comcast id DLd21e0011GXsucABLdgbx; Tue, 04 May 2010 08:37:40 +0000 Received: from koitsu.dyndns.org ([98.248.46.159]) by omta07.emeryville.ca.mail.comcast.net with comcast id DLdf1e0033S48mS8ULdgjf; Tue, 04 May 2010 08:37:40 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id BFCDE9B425; Tue, 4 May 2010 01:37:38 -0700 (PDT) Date: Tue, 4 May 2010 01:37:38 -0700 From: Jeremy Chadwick To: David DEMELIER Message-ID: <20100504083738.GA23820@icarus.home.lan> References: <20100503224206.GB9134@icarus.home.lan> 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) Cc: freebsd-stable@freebsd.org Subject: Re: Kernel panic when unpluggin AC adaptor X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 04 May 2010 08:37:40 -0000 On Tue, May 04, 2010 at 10:32:14AM +0200, David DEMELIER wrote: > Since I added dumpdev="/dev/ad4s1b" in my /boot/loader.conf it does > not panic anymore ... > > I'm not lucky (or ?). 1) dumpdev="xxx" should go into /etc/rc.conf, not /boot/loader.conf. Putting in in /boot/loader.conf will change/do nothing. You should probably be using 'dumpdev="auto"' anyway (it then uses whatever you define as swap in /etc/fstab). 2) If you meant to say /etc/rc.conf instead of /boot/loader.conf, setting dumpdev shouldn't fix your problem. I think it's a red herring. 3) You sent the above to me directly; please keep the mailing list CC'd, as others need to know what you've tried/done. Thanks. -- | 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 May 4 08:41:22 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id AFF651065674 for ; Tue, 4 May 2010 08:41:22 +0000 (UTC) (envelope-from demelier.david@gmail.com) Received: from mail-bw0-f228.google.com (mail-bw0-f228.google.com [209.85.218.228]) by mx1.freebsd.org (Postfix) with ESMTP id 393888FC23 for ; Tue, 4 May 2010 08:41:21 +0000 (UTC) Received: by bwz28 with SMTP id 28so1816521bwz.14 for ; Tue, 04 May 2010 01:41:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=JjmMxE7Mn/HMoEzC6wLiFp3AGBguyR5lz9zF2GRfa6Q=; b=ddd8UNmams7S8v7Cbz8mdpmGYF1hd5NouHZLjkTSV+nK0VssqGoTzvs2nJiv/Qr1Me XAw8aalF1skbSU7BHWO5o8wae9hFhK6R1t7w+bEgofM40uE4S9SMG+l6iCEOd8AxyRvG 44OqW2TnwPWjjCT2+c1vhbJF0FTM3zOfCZ/WE= 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:content-transfer-encoding; b=IjQuHgzb8LTVDMBYLaXJ7+9BnhtUL0IBF3VJFd5o3iofyPu9xTCCkET4iQ6TIp1m5k w6zOeHe5z9qCvUvHfdK6ojRdCCtsodZlC40F2qHmW84POS57ECsV3/ukkZ+u01cGs886 XUAICjsRzUAyEWwns9FH3zdX6LeQQ0W1kB2l8= MIME-Version: 1.0 Received: by 10.204.32.201 with SMTP id e9mr6554954bkd.47.1272962478471; Tue, 04 May 2010 01:41:18 -0700 (PDT) Received: by 10.204.76.73 with HTTP; Tue, 4 May 2010 01:41:18 -0700 (PDT) In-Reply-To: <20100504083738.GA23820@icarus.home.lan> References: <20100503224206.GB9134@icarus.home.lan> <20100504083738.GA23820@icarus.home.lan> Date: Tue, 4 May 2010 10:41:18 +0200 Message-ID: From: David DEMELIER To: Jeremy Chadwick Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-stable@freebsd.org Subject: Re: Kernel panic when unpluggin AC adaptor X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 04 May 2010 08:41:22 -0000 2010/5/4 Jeremy Chadwick : > On Tue, May 04, 2010 at 10:32:14AM +0200, David DEMELIER wrote: >> Since I added dumpdev=3D"/dev/ad4s1b" in my /boot/loader.conf it does >> not panic anymore ... >> >> I'm not lucky (or ?). > > 1) dumpdev=3D"xxx" should go into /etc/rc.conf, not /boot/loader.conf. > Putting in in /boot/loader.conf will change/do nothing. =A0You should > probably be using 'dumpdev=3D"auto"' anyway (it then uses whatever you > define as swap in /etc/fstab). > > 2) If you meant to say /etc/rc.conf instead of /boot/loader.conf, > setting dumpdev shouldn't fix your problem. =A0I think it's a red herring= . > > 3) You sent the above to me directly; please keep the mailing list CC'd, > as others need to know what you've tried/done. =A0Thanks. > Yes I also added dumpdev=3D"AUTO" in /etc/rc.conf at the beginning. That was Garett who told me to add it to loader.conf. $ sysctl dev.cpu dev.cpu.0.%desc: ACPI CPU dev.cpu.0.%driver: cpu dev.cpu.0.%location: handle=3D\_PR_.CPU0 dev.cpu.0.%pnpinfo: _HID=3Dnone _UID=3D0 dev.cpu.0.%parent: acpi0 dev.cpu.0.freq: 2101 dev.cpu.0.freq_levels: 2101/35000 1837/30625 1600/23888 1400/20902 1200/15000 1050/13125 900/11250 750/9375 600/7500 450/5625 300/3750 150/1875 dev.cpu.0.cx_supported: C1/1 C2/57 dev.cpu.0.cx_lowest: C1 dev.cpu.0.cx_usage: 100.00% 0.00% last 497us dev.cpu.1.%desc: ACPI CPU dev.cpu.1.%driver: cpu dev.cpu.1.%location: handle=3D\_PR_.CPU1 dev.cpu.1.%pnpinfo: _HID=3Dnone _UID=3D0 dev.cpu.1.%parent: acpi0 dev.cpu.1.cx_supported: C1/1 C2/57 dev.cpu.1.cx_lowest: C1 dev.cpu.1.cx_usage: 100.00% 0.00% last 497us (I used Cc: entry I hope it sends to all) --=20 Demelier David From owner-freebsd-stable@FreeBSD.ORG Tue May 4 08:53:35 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 42444106564A for ; Tue, 4 May 2010 08:53:35 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta08.westchester.pa.mail.comcast.net (qmta08.westchester.pa.mail.comcast.net [76.96.62.80]) by mx1.freebsd.org (Postfix) with ESMTP id E22998FC17 for ; Tue, 4 May 2010 08:53:34 +0000 (UTC) Received: from omta08.westchester.pa.mail.comcast.net ([76.96.62.12]) by qmta08.westchester.pa.mail.comcast.net with comcast id DLot1e0010Fqzac58LtbGk; Tue, 04 May 2010 08:53:35 +0000 Received: from koitsu.dyndns.org ([98.248.46.159]) by omta08.westchester.pa.mail.comcast.net with comcast id DLtZ1e0083S48mS3ULtaNG; Tue, 04 May 2010 08:53:34 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id B19259B425; Tue, 4 May 2010 01:53:32 -0700 (PDT) Date: Tue, 4 May 2010 01:53:32 -0700 From: Jeremy Chadwick To: David DEMELIER Message-ID: <20100504085332.GA24219@icarus.home.lan> References: <20100503224206.GB9134@icarus.home.lan> <20100504083738.GA23820@icarus.home.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Cc: freebsd-stable@freebsd.org Subject: Re: Kernel panic when unpluggin AC adaptor X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 04 May 2010 08:53:35 -0000 On Tue, May 04, 2010 at 10:41:18AM +0200, David DEMELIER wrote: > 2010/5/4 Jeremy Chadwick : > > On Tue, May 04, 2010 at 10:32:14AM +0200, David DEMELIER wrote: > >> Since I added dumpdev="/dev/ad4s1b" in my /boot/loader.conf it does > >> not panic anymore ... > >> > >> I'm not lucky (or ?). > > > > 1) dumpdev="xxx" should go into /etc/rc.conf, not /boot/loader.conf. > > Putting in in /boot/loader.conf will change/do nothing.  You should > > probably be using 'dumpdev="auto"' anyway (it then uses whatever you > > define as swap in /etc/fstab). > > > > 2) If you meant to say /etc/rc.conf instead of /boot/loader.conf, > > setting dumpdev shouldn't fix your problem.  I think it's a red herring. > > > > 3) You sent the above to me directly; please keep the mailing list CC'd, > > as others need to know what you've tried/done.  Thanks. > > Yes I also added dumpdev="AUTO" in /etc/rc.conf at the beginning. That > was Garett who told me to add it to loader.conf. I think he meant /etc/rc.conf. That's okay -- mistakes happen. All dumpdev="auto" will do is configure FreeBSD to automatically dump all kernel memory to swap + reboot the system. When FreeBSD next boots, it will use savecore(8) to save the contents of swap to a series of files in /var/crash for later debugging. > $ sysctl dev.cpu > dev.cpu.0.%desc: ACPI CPU > dev.cpu.0.%driver: cpu > dev.cpu.0.%location: handle=\_PR_.CPU0 > dev.cpu.0.%pnpinfo: _HID=none _UID=0 > dev.cpu.0.%parent: acpi0 > dev.cpu.0.freq: 2101 > dev.cpu.0.freq_levels: 2101/35000 1837/30625 1600/23888 1400/20902 1200/15000 1050/13125 900/11250 750/9375 600/7500 450/5625 300/3750 150/1875 > dev.cpu.0.cx_supported: C1/1 C2/57 > dev.cpu.0.cx_lowest: C1 > dev.cpu.0.cx_usage: 100.00% 0.00% last 497us > dev.cpu.1.%desc: ACPI CPU > dev.cpu.1.%driver: cpu > dev.cpu.1.%location: handle=\_PR_.CPU1 > dev.cpu.1.%pnpinfo: _HID=none _UID=0 > dev.cpu.1.%parent: acpi0 > dev.cpu.1.cx_supported: C1/1 C2/57 > dev.cpu.1.cx_lowest: C1 > dev.cpu.1.cx_usage: 100.00% 0.00% last 497us > > (I used Cc: entry I hope it sends to all) Can you confirm whether or not powerd(8) is in use on this system when it panics? If so, does the problem go away if you disable powerd(8) but leave in (uncommented) the performance_* and economy_* rc.conf settings? -- | 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 May 4 10:52:02 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 34C9A1065740 for ; Tue, 4 May 2010 10:52:02 +0000 (UTC) (envelope-from demelier.david@gmail.com) Received: from mail-bw0-f228.google.com (mail-bw0-f228.google.com [209.85.218.228]) by mx1.freebsd.org (Postfix) with ESMTP id B397B8FC16 for ; Tue, 4 May 2010 10:52:01 +0000 (UTC) Received: by bwz28 with SMTP id 28so1887522bwz.14 for ; Tue, 04 May 2010 03:51:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=tKEMTi9uC0fiWL+ldzuOnCgmhcQvxKzLJjFy/n/WcP8=; b=tLu12EJFj38NxIh8/CT2m6+ZV9LhLToOv/h4Q+3TFWDalztgYNfdR7MWy9cGvUyE69 se7sKd90K0ghHqs2lACbQ6nej8/AydzVKW5Xn8UvZqFd1ytd1cVJfSpQHMXLAT0iHn4V 8o62zTgtbOe83qDlbfQa+yv6iiA+O3qXxO5OA= 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=WCqORgCCG2JgiYP4WzSdBQLqtcuUY+lYZPq8ZOLMyZeJXWy/08EgOYIxdNj+rddApu M9EzmoBdsIL7uKkm4QX6mb5OrQG/dLtIJ/LNu6DW6oe79BBgCqqlrPTDoprKLtuId/wy jfF0j11Gg92r7Y8pXGjd/+kOGv1bFCXfCMklM= MIME-Version: 1.0 Received: by 10.204.34.10 with SMTP id j10mr871988bkd.87.1272970311683; Tue, 04 May 2010 03:51:51 -0700 (PDT) Received: by 10.204.76.73 with HTTP; Tue, 4 May 2010 03:51:51 -0700 (PDT) In-Reply-To: <20100504085332.GA24219@icarus.home.lan> References: <20100503224206.GB9134@icarus.home.lan> <20100504083738.GA23820@icarus.home.lan> <20100504085332.GA24219@icarus.home.lan> Date: Tue, 4 May 2010 12:51:51 +0200 Message-ID: From: David DEMELIER To: Jeremy Chadwick Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-stable@freebsd.org Subject: Re: Kernel panic when unpluggin AC adaptor X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 04 May 2010 10:52:02 -0000 I made a panic and it said Dumping 1176Mb but even after 5 minutes there was no output. Usually you'll have something like Dumping 1176Mb: 1176 1040 960 ... etc ? Here it's stays at Dumping 1176Mb: and no changes. Cheers, David. From owner-freebsd-stable@FreeBSD.ORG Tue May 4 16:35:59 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 0E89B106566B for ; Tue, 4 May 2010 16:35:59 +0000 (UTC) (envelope-from demelier.david@gmail.com) Received: from mail-bw0-f228.google.com (mail-bw0-f228.google.com [209.85.218.228]) by mx1.freebsd.org (Postfix) with ESMTP id 73DEA8FC0A for ; Tue, 4 May 2010 16:35:58 +0000 (UTC) Received: by bwz28 with SMTP id 28so2136715bwz.14 for ; Tue, 04 May 2010 09:35:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=zndn19fLeP25B4fPJCCf5O8MOLJ/m0wPu3Z3OHIZjfY=; b=MtjYtGNy03eoAUydfAUTz66x0N2tIwyRIbJLU6WnErLuDhylAEbYbGQl/k0I4o9vx+ 4v8wWOObf9E2wswAB2bgjb2/dtqA5WHQX8xyTmjQIS4tlamchtdLJt0W8fbYu5bKBptf axp21tEuTSTqstgdQkBu9LdC9A3Ul2nNzVNlU= 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=a+GZfrbuNII8zCJUl/D7jFD5sjmrdCkvUlnzfgwlCvD/QvpOW4uQr1pVk5fWZgLJsW jXvX4oBW0wnuLSpMiMGfgDNKo8X2p9RCIcqG/iUmJih2XxS/wIKvT8TzbVRtTXneSyH+ ulaqtGKTlzwUtk0N9bLiC1i2/bJU7DWCa0WYU= MIME-Version: 1.0 Received: by 10.204.140.213 with SMTP id j21mr1632279bku.110.1272990952525; Tue, 04 May 2010 09:35:52 -0700 (PDT) Received: by 10.204.76.73 with HTTP; Tue, 4 May 2010 09:35:52 -0700 (PDT) In-Reply-To: References: <20100503224206.GB9134@icarus.home.lan> <20100504083738.GA23820@icarus.home.lan> <20100504085332.GA24219@icarus.home.lan> Date: Tue, 4 May 2010 18:35:52 +0200 Message-ID: From: David DEMELIER To: Giovanni Trematerra Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-stable@freebsd.org Subject: Re: Kernel panic when unpluggin AC adaptor X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 04 May 2010 16:35:59 -0000 Good news ! It worked, check the picture here : http://img63.imageshack.us/img63/4244/dsc00361g.jpg From owner-freebsd-stable@FreeBSD.ORG Tue May 4 16:42:16 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E8F611065672 for ; Tue, 4 May 2010 16:42:16 +0000 (UTC) (envelope-from demelier.david@gmail.com) Received: from mail-ww0-f54.google.com (mail-ww0-f54.google.com [74.125.82.54]) by mx1.freebsd.org (Postfix) with ESMTP id 772218FC1F for ; Tue, 4 May 2010 16:42:16 +0000 (UTC) Received: by wwb13 with SMTP id 13so3131666wwb.13 for ; Tue, 04 May 2010 09:42:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:date:from:to:subject :message-id:mime-version:content-type:content-disposition:user-agent; bh=dhi+Rj4yFApksD0+L3Ald4Z5bIH+Eb/PWnQaIpeX4Hk=; b=dcvV057+9505xZUVt9l0Q8FKjoADhpyWW4H3Mx/hbhm251WOSJdvPGJm8bbagr+b9c pQTQ5sxYRzNzJhO89+Ny7i0W1hWLdIipp3KFP+OYiWyeCS4uV2e85clfns6iYV0iaJYw hM2otiFA9/HJJgxJQwQ6lhCl1C51eYHI1eT0g= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:from:to:subject:message-id:mime-version:content-type :content-disposition:user-agent; b=Qx/RAhq2ab00S9dUvass/vXE46qwvU3D4K2MBnBUUwluu1x8XsMO7+usNomhB4T/A6 pE7bzuJdgphuQnbAmXtp/auqUN0bF6CDq2IYzrnGXxAtFM5qhCgM/ziFtgvJt1rhIDh/ JxJ8g/cwtoynC+TX2O2goY1k/4dXlYw96PYU8= Received: by 10.227.146.13 with SMTP id f13mr1805441wbv.179.1272991332625; Tue, 04 May 2010 09:42:12 -0700 (PDT) Received: from Melon.malikania.fr (121.21.102-84.rev.gaoland.net [84.102.21.121]) by mx.google.com with ESMTPS id x14sm51425306wbs.0.2010.05.04.09.42.11 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 04 May 2010 09:42:12 -0700 (PDT) Date: Tue, 4 May 2010 18:41:58 +0200 From: Demelier David To: freebsd-stable@freebsd.org Message-ID: <20100504164158.GA4294@Melon.malikania.fr> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="vkogqOf2sHV7VnPd" Content-Disposition: inline User-Agent: Mutt/1.5.20 (2009-06-14) X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Little weird chars when using getty autologin X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 04 May 2010 16:42:17 -0000 --vkogqOf2sHV7VnPd Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi freebsd-stable, To access faster to my laptop I added a al capability in my getty to get my user auto logged in the ttyv0. It works but there is a lot of weird characters at the system name before the login prompt. Check the attachment. King regards, David. --vkogqOf2sHV7VnPd-- From owner-freebsd-stable@FreeBSD.ORG Tue May 4 19:44:50 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 9DB0C1065674 for ; Tue, 4 May 2010 19:44:50 +0000 (UTC) (envelope-from peter@kieser.ca) Received: from mail.pfak.org (mail.pfak.org [216.19.178.154]) by mx1.freebsd.org (Postfix) with ESMTP id 746348FC1C for ; Tue, 4 May 2010 19:44:49 +0000 (UTC) Received: from mail.pfak.org (localhost.pfak.org [127.0.0.1]) by mail.pfak.org (Postfix) with ESMTP id 68D734093; Tue, 4 May 2010 12:25:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=kieser.ca; h=message-id :date:from:mime-version:to:cc:subject:references:in-reply-to :content-type; s=mail; bh=SG7uL2fC5OcbdbKj7M4wE5MsqWU=; b=Vhyw5n 8i0DP6jRVdFLC9GrdWlz6R2pzIg2+KA6nza20+9wROmf2fvkKmnTwzibW9GBO6/P DQ4HehwXVpZqfDftedZ6mze/KYOnt3PTH9P0cSeOroPRdSSvJc24ABB0M6N/t3/z 1j6tfTp9YwP43bQw33OX8X0PKv/Rd1C7uhj00= DomainKey-Signature: a=rsa-sha1; c=nofws; d=kieser.ca; h=message-id:date :from:mime-version:to:cc:subject:references:in-reply-to :content-type; q=dns; s=mail; b=FOE4LoaVp+iG3dOAvKd2R2Dv7Dr/Vv74 b8JvsITB1rEyAHQOAU6NiKqppCW2rCgSXd7/icb5GzaNqrB/Z3f7U94aAXyitiuB s/YrrXzdMmF4ou6YPuv3yPi/UHvYdrvv/Bk3F0eF0qDimIKVe87+I5ZWnr9C9F2c fcxnzI9Tit0= Received: from [192.168.100.16] (216-19-178-131.stc.novuscom.net [216.19.178.131]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: peter@kieser.ca) by mail.pfak.org (Postfix) with ESMTPSA id 540E64052; Tue, 4 May 2010 12:25:39 -0700 (PDT) Message-ID: <4BE074B3.4050500@kieser.ca> Date: Tue, 04 May 2010 12:25:39 -0700 From: Peter Kieser User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: freebsd-net@freebsd.org References: <4BE0620A.3090906@kieser.ca> In-Reply-To: <4BE0620A.3090906@kieser.ca> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-stable@freebsd.org Subject: Re: Reproducible crash w/ IPv6 on FreeBSD 7.1 amd64 under VMware ESXi 3.5 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 04 May 2010 19:44:50 -0000 On further note: I belive that 'm' should not be NULL ... #9 0xffffffff8061277f in ip6_input (m=0xffffff0001611a00) at /usr/src/sys/netinet6/ip6_input.c:299 -Peter On 5/4/2010 11:06 AM, Peter Kieser wrote: > Hello, > > My FreeBSD 7.1 guest is crashing when I use IPv6 and ping6 an address > that doesn't respond to ICMP or isn't on the network. Am I the only > person that has run into this issue? I can reproduce it on a fresh > virtual machine, 100% of the time .. Does NOT occur (I've had machines > up for 200+ days) if I am not using IPv6. > > HOWTO Reproduce: > > 1. FreeBSD 7.1 amd64 Guest > 2. IPv6 networking enabled and configured > 3. ping6 against an IPv6 address that isn't active on your network and > leave it running > 4. Virtual machine will crash after a number of minutes (from 1~15 > minutes) > > What configuration: > > * Generic FreeBSD 7.1 kernel (No custom configuration) > * No VMware tools or kernel modules installed > * e1000 virtual Ethernet adapter > * LSI Logic virtual SCSI controller > * kern.hz set at 100 in /boot/loader.conf > > Kernel revision: > > FreeBSD freebsd71.pfak.org 7.1-RELEASE-p11 FreeBSD 7.1-RELEASE-p11 #0: > Tue May 4 10:28:31 PDT 2010 > root@freebsd71.pfak.org:/usr/obj/usr/src/sys/GENERIC amd64 > > Kernel dump W/ Backtrace: > > Fatal trap 12: page fault while in kernel mode > cpuid = 1; apic id = 01 > fault virtual address = 0x18 > fault code = supervisor read data, page not present > instruction pointer = 0x8:0xffffffff80505a66 > stack pointer = 0x10:0xffffffffac258a60 > frame pointer = 0x10:0x0 > code segment = base 0x0, limit 0xfffff, type 0x1b > = DPL 0, pres 1, long 1, def32 0, gran 1 > processor eflags = interrupt enabled, resume, IOPL = 0 > current process = 13 (swi1: net) > trap number = 12 > panic: page fault > cpuid = 1 > Uptime: 13m54s > Physical memory: 3827 MB > Dumping 323 MB: 308 292 276 260 244 228 212 196 180 164 148 132 116 > 100 84 68 52 36 20 4 > > #0 doadump () at pcpu.h:195 > 195 __asm __volatile("movq %%gs:0,%0" : "=r" (td)); > (kgdb) backtrace > #0 doadump () at pcpu.h:195 > #1 0x0000000000000004 in ?? () > #2 0xffffffff804b4d29 in boot (howto=260) at > /usr/src/sys/kern/kern_shutdown.c:418 > #3 0xffffffff804b5132 in panic (fmt=0x104
bounds>) at /usr/src/sys/kern/kern_shutdown.c:574 > #4 0xffffffff8078a1f3 in trap_fatal (frame=0xffffff00010ff000, > eva=Variable "eva" is not available. > ) at /usr/src/sys/amd64/amd64/trap.c:764 > #5 0xffffffff8078a5c5 in trap_pfault (frame=0xffffffffac2589b0, > usermode=0) at /usr/src/sys/amd64/amd64/trap.c:680 > #6 0xffffffff8078af08 in trap (frame=0xffffffffac2589b0) at > /usr/src/sys/amd64/amd64/trap.c:449 > #7 0xffffffff807706fe in calltrap () at > /usr/src/sys/amd64/amd64/exception.S:209 > #8 0xffffffff80505a66 in m_copydata (m=0x0, off=0, len=56, > cp=0xffffff00013b9980 "") at /usr/src/sys/kern/uipc_mbuf.c:813 > #9 0xffffffff8061277f in ip6_input (m=0xffffff0001611a00) at > /usr/src/sys/netinet6/ip6_input.c:299 > #10 0xffffffff8055ae59 in netisr_processqueue (ni=0xffffffff80acbb08) > at /usr/src/sys/net/netisr.c:143 > #11 0xffffffff8055b0eb in swi_net (dummy=Variable "dummy" is not > available. > ) at /usr/src/sys/net/netisr.c:250 > #12 0xffffffff804957c0 in ithread_loop (arg=0xffffff00010fac00) at > /usr/src/sys/kern/kern_intr.c:1088 > #13 0xffffffff80492663 in fork_exit (callout=0xffffffff80495650 > , arg=0xffffff00010fac00, frame=0xffffffffac258c80) > at /usr/src/sys/kern/kern_fork.c:804 > #14 0xffffffff80770ace in fork_trampoline () at > /usr/src/sys/amd64/amd64/exception.S:455 > #15 0x0000000000000000 in ?? () > #16 0x0000000000000000 in ?? () > #17 0x0000000000000001 in ?? () > #18 0x0000000000000000 in ?? () > #19 0x0000000000000000 in ?? () > #20 0x0000000000000000 in ?? () > #21 0x0000000000000000 in ?? () > #22 0x0000000000000000 in ?? () > #23 0x0000000000000000 in ?? () > #24 0x0000000000000000 in ?? () > #25 0x0000000000000000 in ?? () > #26 0x0000000000000000 in ?? () > #27 0x0000000000000000 in ?? () > #28 0x0000000000000000 in ?? () > #29 0x0000000000000000 in ?? () > #30 0x0000000000000000 in ?? () > #31 0x0000000000000000 in ?? () > #32 0x0000000000000000 in ?? () > #33 0x0000000000000000 in ?? () > #34 0x0000000000000000 in ?? () > #35 0x0000000000000000 in ?? () > #36 0x0000000000000000 in ?? () > #37 0x0000000000000000 in ?? () > #38 0x0000000000000000 in ?? () > #39 0x0000000000d43000 in ?? () > #40 0xffffffff80ab8440 in tdq_cpu () > #41 0x0000000000000000 in ?? () > #42 0xffffffff80ac3fc0 in tdq_cpu () > #43 0x0000000000000000 in ?? () > #44 0xffffff00010ff000 in ?? () > #45 0xffffffffac258628 in ?? () > #46 0xffffffff80ab77c0 in tdg_maxid () > #47 0xffffffff804d5954 in sched_switch (td=0x0, newtd=0x8005c7450, > flags=0) at /usr/src/sys/kern/sched_ule.c:1944 > #48 0x0000000000000000 in ?? () > #49 0x0000000000000000 in ?? () > #50 0x0000000000000000 in ?? () > #51 0x0000000000000000 in ?? () > ... > Cannot access memory at address 0xffffffffac259000 > (kgdb) > > -Peter > _______________________________________________ > 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" From owner-freebsd-stable@FreeBSD.ORG Tue May 4 20:01:47 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 94F11106564A for ; Tue, 4 May 2010 20:01:47 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (mx0.zoral.com.ua [91.193.166.200]) by mx1.freebsd.org (Postfix) with ESMTP id 078BC8FC1C for ; Tue, 4 May 2010 20:01:45 +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 o44K1dnO056485 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 4 May 2010 23:01:39 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4) with ESMTP id o44K1dGf051157; Tue, 4 May 2010 23:01:39 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4/Submit) id o44K1dB6051156; Tue, 4 May 2010 23:01:39 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Tue, 4 May 2010 23:01:39 +0300 From: Kostik Belousov To: David DEMELIER Message-ID: <20100504200139.GP23646@deviant.kiev.zoral.com.ua> References: <20100503224206.GB9134@icarus.home.lan> <20100504083738.GA23820@icarus.home.lan> <20100504085332.GA24219@icarus.home.lan> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="nLMor0SRtNCuLS/8" Content-Disposition: inline In-Reply-To: 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=-1.7 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_50, DNS_FROM_OPENWHOIS,URIBL_SBL autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: Giovanni Trematerra , freebsd-stable@freebsd.org Subject: Re: Kernel panic when unpluggin AC adaptor X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 04 May 2010 20:01:47 -0000 --nLMor0SRtNCuLS/8 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, May 04, 2010 at 06:35:52PM +0200, David DEMELIER wrote: > Good news ! It worked, check the picture here : >=20 > http://img63.imageshack.us/img63/4244/dsc00361g.jpg Please try adding code fragment like this: if (cx_next->p_lvlx =3D=3D NULL) printf("Going to panic.\n"); to dev/acpi/acpi_cpu.c:acpi_cpu_idle() function, right before CPU_GET_REG(cx_next->p_lvlx, 1); line and see if it prints the message immediately before the panic. --nLMor0SRtNCuLS/8 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (FreeBSD) iEYEARECAAYFAkvgfSIACgkQC3+MBN1Mb4hgXQCfZoB2ACP8BL29WZS/BoIxt/T3 LboAn0piHpPJjbd/oyY3IDhSiSAQvw1j =qIKK -----END PGP SIGNATURE----- --nLMor0SRtNCuLS/8-- From owner-freebsd-stable@FreeBSD.ORG Tue May 4 20:27:31 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 29FDC1065670 for ; Tue, 4 May 2010 20:27:31 +0000 (UTC) (envelope-from demelier.david@gmail.com) Received: from mail-bw0-f227.google.com (mail-bw0-f227.google.com [209.85.218.227]) by mx1.freebsd.org (Postfix) with ESMTP id A3B368FC14 for ; Tue, 4 May 2010 20:27:30 +0000 (UTC) Received: by bwz27 with SMTP id 27so2833486bwz.13 for ; Tue, 04 May 2010 13:27:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=QDFAClh91yZSIWI00l6TvYO2J52gML9ZN84tb2wNi1s=; b=Q1n3eYS/hUUfKHxLv3qRiuKRazAy+6/t44snY9rPwxQuaY8wnn8rlU+cGkKpEU/S51 d7yXn9jcpNALcJsmNeh6l2yJXuNA8diH/kaSk3y+GJNhg1K8M510Vjt++WZu6j0+Wogc J2KcmOILLdmZyx/d0gZNtC9V6GnVy1NNAjLLg= 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:content-transfer-encoding; b=ZWGHAuKrHIn1KxYK0bY7/sarBeNLwFOGWZAKlIRHxJWGVEYiZ4D7kWdfggUQyjd1tW KeyhaTejbVvF4N60qkpBZ8y+Dzbjaixoa96ldEfBtORHVsbJLvciEULL57u5SwkIv+oL VkHBeB6wz9n61unPOqCW1MvTDHphEEcYUM6o0= MIME-Version: 1.0 Received: by 10.204.134.193 with SMTP id k1mr4657586bkt.165.1273004844000; Tue, 04 May 2010 13:27:24 -0700 (PDT) Received: by 10.204.76.73 with HTTP; Tue, 4 May 2010 13:27:23 -0700 (PDT) In-Reply-To: <20100504200139.GP23646@deviant.kiev.zoral.com.ua> References: <20100504083738.GA23820@icarus.home.lan> <20100504085332.GA24219@icarus.home.lan> <20100504200139.GP23646@deviant.kiev.zoral.com.ua> Date: Tue, 4 May 2010 22:27:23 +0200 Message-ID: From: David DEMELIER To: Kostik Belousov Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Giovanni Trematerra , freebsd-stable@freebsd.org Subject: Re: Kernel panic when unpluggin AC adaptor X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 04 May 2010 20:27:31 -0000 2010/5/4 Kostik Belousov : > On Tue, May 04, 2010 at 06:35:52PM +0200, David DEMELIER wrote: >> Good news ! It worked, check the picture here : >> >> http://img63.imageshack.us/img63/4244/dsc00361g.jpg > > Please try adding code fragment like this: > =A0 =A0 =A0 =A0if (cx_next->p_lvlx =3D=3D NULL) > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0printf("Going to panic.\n"); > to =A0dev/acpi/acpi_cpu.c:acpi_cpu_idle() function, right before > =A0 =A0CPU_GET_REG(cx_next->p_lvlx, 1); > line and see if it prints the message immediately before the panic. > Yes it does at the beginning of the kernel panic. Cheers. --=20 Demelier David From owner-freebsd-stable@FreeBSD.ORG Tue May 4 20:38:13 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 51E781065675 for ; Tue, 4 May 2010 20:38:13 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (mx0.zoral.com.ua [91.193.166.200]) by mx1.freebsd.org (Postfix) with ESMTP id B7F808FC1B for ; Tue, 4 May 2010 20:38:12 +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 o44Kc9Il059484 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 4 May 2010 23:38:09 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4) with ESMTP id o44Kc95c051351; Tue, 4 May 2010 23:38:09 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4/Submit) id o44Kc9TB051350; Tue, 4 May 2010 23:38:09 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Tue, 4 May 2010 23:38:09 +0300 From: Kostik Belousov To: David DEMELIER Message-ID: <20100504203809.GR23646@deviant.kiev.zoral.com.ua> References: <20100504083738.GA23820@icarus.home.lan> <20100504085332.GA24219@icarus.home.lan> <20100504200139.GP23646@deviant.kiev.zoral.com.ua> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Bi+HF1AHjw0mn3zx" Content-Disposition: inline In-Reply-To: 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=-1.7 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_50, DNS_FROM_OPENWHOIS,URIBL_SBL autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: Giovanni Trematerra , freebsd-stable@freebsd.org, freebsd-acpi@freebsd.org Subject: Re: Kernel panic when unpluggin AC adaptor X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 04 May 2010 20:38:13 -0000 --Bi+HF1AHjw0mn3zx Content-Type: text/plain; charset=koi8-r Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, May 04, 2010 at 10:27:23PM +0200, David DEMELIER wrote: > 2010/5/4 Kostik Belousov : > > On Tue, May 04, 2010 at 06:35:52PM +0200, David DEMELIER wrote: > >> Good news ! It worked, check the picture here : > >> > >> http://img63.imageshack.us/img63/4244/dsc00361g.jpg > > > > Please try adding code fragment like this: > > =9A =9A =9A =9Aif (cx_next->p_lvlx =3D=3D NULL) > > =9A =9A =9A =9A =9A =9A =9A =9Aprintf("Going to panic.\n"); > > to =9Adev/acpi/acpi_cpu.c:acpi_cpu_idle() function, right before > > =9A =9ACPU_GET_REG(cx_next->p_lvlx, 1); > > line and see if it prints the message immediately before the panic. > > >=20 > Yes it does at the beginning of the kernel panic. Ok, so the point of panic is found, it is NULL cx_next->p_lvlx resource. With the data in hand, I recommend you to ask on acpi@ (added a Cc:) about the cause and possible solution. --Bi+HF1AHjw0mn3zx Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (FreeBSD) iEYEARECAAYFAkvghbAACgkQC3+MBN1Mb4gXlgCgsSPpn8IIMi0+2oZHTKz0haxO StgAoICD29XstQKYHcmwzOcQVubm4Qil =aXZF -----END PGP SIGNATURE----- --Bi+HF1AHjw0mn3zx-- From owner-freebsd-stable@FreeBSD.ORG Wed May 5 00:36:42 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 87A3D1065675; Wed, 5 May 2010 00:36:42 +0000 (UTC) (envelope-from rpaulo@freebsd.org) Received: from karen.lavabit.com (karen.lavabit.com [72.249.41.33]) by mx1.freebsd.org (Postfix) with ESMTP id 40EF78FC20; Wed, 5 May 2010 00:36:41 +0000 (UTC) Received: from e.earth.lavabit.com (e.earth.lavabit.com [192.168.111.14]) by karen.lavabit.com (Postfix) with ESMTP id 097CD11BA4D; Tue, 4 May 2010 19:19:49 -0500 (CDT) Received: from 10.0.10.3 (54.81.54.77.rev.vodafone.pt [77.54.81.54]) by lavabit.com with ESMTP id 1D0N7MKNW0LO; Tue, 04 May 2010 19:19:49 -0500 Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii From: Rui Paulo In-Reply-To: <20100504203809.GR23646@deviant.kiev.zoral.com.ua> Date: Wed, 5 May 2010 01:19:45 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <42ACDAF6-7EA9-4CE9-AA8D-FDA678A1EA74@FreeBSD.org> References: <20100504083738.GA23820@icarus.home.lan> <20100504085332.GA24219@icarus.home.lan> <20100504200139.GP23646@deviant.kiev.zoral.com.ua> <20100504203809.GR23646@deviant.kiev.zoral.com.ua> To: Kostik Belousov X-Mailer: Apple Mail (2.1078) Cc: David DEMELIER , Giovanni Trematerra , freebsd-stable@freebsd.org, freebsd-acpi@freebsd.org Subject: Re: Kernel panic when unpluggin AC adaptor X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 05 May 2010 00:36:42 -0000 On 4 May 2010, at 21:38, Kostik Belousov wrote: > On Tue, May 04, 2010 at 10:27:23PM +0200, David DEMELIER wrote: >> 2010/5/4 Kostik Belousov : >>> On Tue, May 04, 2010 at 06:35:52PM +0200, David DEMELIER wrote: >>>> Good news ! It worked, check the picture here : >>>>=20 >>>> http://img63.imageshack.us/img63/4244/dsc00361g.jpg >>>=20 >>> Please try adding code fragment like this: >>> if (cx_next->p_lvlx =3D=3D NULL) >>> printf("Going to panic.\n"); >>> to dev/acpi/acpi_cpu.c:acpi_cpu_idle() function, right before >>> CPU_GET_REG(cx_next->p_lvlx, 1); >>> line and see if it prints the message immediately before the panic. >>>=20 >>=20 >> Yes it does at the beginning of the kernel panic. >=20 > Ok, so the point of panic is found, it is NULL cx_next->p_lvlx = resource. > With the data in hand, I recommend you to ask on acpi@ (added a Cc:) > about the cause and possible solution. I don't remember the details, but I've seen this before. Does your CPU = Cx levels change when you plug/unplug the AC adapter? Regards, -- Rui Paulo From owner-freebsd-stable@FreeBSD.ORG Wed May 5 03:02:49 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A767F1065673 for ; Wed, 5 May 2010 03:02:49 +0000 (UTC) (envelope-from morganw@chemikals.org) Received: from warped.bluecherry.net (warped.bluecherry.net [66.138.159.247]) by mx1.freebsd.org (Postfix) with ESMTP id 3C3018FC18 for ; Wed, 5 May 2010 03:02:48 +0000 (UTC) Received: from volatile.chemikals.org (adsl-80-26-171.shv.bellsouth.net [98.80.26.171]) (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 2003E805E332; Tue, 4 May 2010 22:02:46 -0500 (CDT) Received: from localhost (morganw@localhost [127.0.0.1]) by volatile.chemikals.org (8.14.4/8.14.4) with ESMTP id o4532hDb071712; Tue, 4 May 2010 22:02:43 -0500 (CDT) (envelope-from morganw@chemikals.org) Date: Tue, 4 May 2010 22:02:43 -0500 (CDT) From: Wes Morgan X-X-Sender: morganw@volatile To: Kurt Lidl In-Reply-To: <4BDF302D.9020500@cello.com> Message-ID: References: <4BDF302D.9020500@cello.com> 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.3 at warped X-Virus-Status: Clean Cc: freebsd-stable@freebsd.org Subject: Re: raidz2 recovery problem on 8.0p2 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 05 May 2010 03:02:49 -0000 On Mon, 3 May 2010, Kurt Lidl wrote: > I have a 12GB memory machine, with a mpt controller in it, running a ZFS > raidz2 > for (test) data storage. The system also has a ZFS mirror in place for the > OS, > home directories, etc. > > I manually failed one of the disks in the JBOD shelf and watched as the mpt > controller started logging errors. Ultimately, I tried to reboot the machine, > but it panic'd instead of rebooting cleanly. It failed to crashdump too (Got > about 200MB into > the dump and stopped.) > > Upon reboot, I saw that zfs thought there were two da6 disk devices. > Which was strange, since at this point, the machine should have had > da0 through da6. I issued a 'zpool clear media da6' command, but > that didn't resolve anything. > > Then I plugged the drive back into the JBOD and rebooted. > Now I see the following: > > user@host: zpool status media > pool: media > state: DEGRADED > status: One or more devices could not be used because the label is missing or > invalid. Sufficient replicas exist for the pool to continue > functioning in a degraded state. > action: Replace the device using 'zpool replace'. > see: http://www.sun.com/msg/ZFS-8000-4J > scrub: none requested > config: > > NAME STATE READ WRITE CKSUM > media DEGRADED 0 0 0 > raidz2 DEGRADED 0 0 0 > da0 ONLINE 0 0 0 > da1 ONLINE 0 0 0 > da2 ONLINE 0 0 0 > da3 ONLINE 0 0 0 > da4 ONLINE 0 0 0 > da5 ONLINE 0 0 0 > da6 ONLINE 0 0 0 > da6 FAULTED 0 98 0 corrupted data > > errors: No known data errors > > Note that there are *two* da6 devices listed, at least from zpool's point of > view. > A dmesg reports this: > > da0 at mpt0 bus 0 target 8 lun 0 > da0: Fixed Direct Access SCSI-5 device > da0: 300.000MB/s transfers > da0: Command Queueing enabled > da0: 1430799MB (2930277168 512 byte sectors: 255H 63S/T 182401C) > da1 at mpt0 bus 0 target 9 lun 0 > da1: Fixed Direct Access SCSI-5 device > da1: 300.000MB/s transfers > da1: Command Queueing enabled > da1: 1430799MB (2930277168 512 byte sectors: 255H 63S/T 182401C) > da2 at mpt0 bus 0 target 10 lun 0 > da2: Fixed Direct Access SCSI-5 device > da2: 300.000MB/s transfers > da2: Command Queueing enabled > da2: 1430799MB (2930277168 512 byte sectors: 255H 63S/T 182401C) > da3 at mpt0 bus 0 target 11 lun 0 > da3: Fixed Direct Access SCSI-5 device > da3: 300.000MB/s transfers > da3: Command Queueing enabled > da3: 1430799MB (2930277168 512 byte sectors: 255H 63S/T 182401C) > da4 at mpt0 bus 0 target 12 lun 0 > da4: Fixed Direct Access SCSI-5 device > da4: 300.000MB/s transfers > da4: Command Queueing enabled > da4: 1430799MB (2930277168 512 byte sectors: 255H 63S/T 182401C) > da5 at mpt0 bus 0 target 13 lun 0 > da5: Fixed Direct Access SCSI-5 device > da5: 300.000MB/s transfers > da5: Command Queueing enabled > da5: 1430799MB (2930277168 512 byte sectors: 255H 63S/T 182401C) > da6 at mpt0 bus 0 target 14 lun 0 > da6: Fixed Direct Access SCSI-5 device > da6: 300.000MB/s transfers > da6: Command Queueing enabled > da6: 1430799MB (2930277168 512 byte sectors: 255H 63S/T 182401C) > da7 at mpt0 bus 0 target 15 lun 0 > da7: Fixed Direct Access SCSI-5 device > da7: 300.000MB/s transfers > da7: Command Queueing enabled > da7: 1430799MB (2930277168 512 byte sectors: 255H 63S/T 182401C) > > Any suggestions about how to get this raid back into a non-degraded state? Have you tried exporting and importing the pool? If that doesn't work, what is the output of zdb? From owner-freebsd-stable@FreeBSD.ORG Wed May 5 04:53:55 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E1D761065670 for ; Wed, 5 May 2010 04:53:54 +0000 (UTC) (envelope-from no-reply@dropbox.com) Received: from mailman.dropbox.com (mailman.dropbox.com [208.43.223.178]) by mx1.freebsd.org (Postfix) with ESMTP id B102C8FC12 for ; Wed, 5 May 2010 04:53:54 +0000 (UTC) Received: from mailman.dropbox.com (localhost [127.0.0.1]) by mailman.dropbox.com (Postfix) with ESMTP id 0047130638C for ; Wed, 5 May 2010 04:37:03 +0000 (UTC) X-DomainKeys: Sendmail DomainKeys Filter v0.6.0 mailman.dropbox.com 0047130638C DomainKey-Signature: a=rsa-sha1; s=m1; d=dropbox.com; c=simple; q=dns; b=NTXxRD9oWSzJnohbI71toJOtHca3iVz27y6CKo1oNYaYrSlPKlR0l5GwxEW9mD2N4 ub+Q4mAky/6KJ7hTgbK9KAXbYVxA6Qy06IscvOGDooOV04PX4imyJb8lLi1wuqErvaI h7EH+1RPG3U8BaIFb0Wm115UgjKAzwkchrkSCRc= MIME-Version: 1.0 From: Dropbox To: freebsd-stable@freebsd.org Date: Wed, 05 May 2010 04:37:02 +0000 Message-Id: <20100505043703.0047130638C@mailman.dropbox.com> Content-Type: text/plain; charset="utf8" Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Yaron Na has invited you to Dropbox X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: justame@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, 05 May 2010 04:53:55 -0000 We're excited to let you know that Yaron Na has invited you to Dropbox! Yaron Na has been using Dropbox to sync and share files online and across computers, and thought you might want it too. Visit http://www.dropbox.com/link/20.lS9xULnUd3/NjE2MzQzMjY3Nw to get started. - The Dropbox Team ____________________________________________________ To stop receiving invites from Dropbox, please go to http://www.dropbox.com/bl/e9e7c76679b9/freebsd-stable%40freebsd.org From owner-freebsd-stable@FreeBSD.ORG Wed May 5 06:32:29 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id CC1CD106566B for ; Wed, 5 May 2010 06:32:29 +0000 (UTC) (envelope-from auryn@zirakzigil.org) Received: from mail.zirakzigil.org (mail.zirakzigil.org [82.63.178.63]) by mx1.freebsd.org (Postfix) with ESMTP id 4553E8FC17 for ; Wed, 5 May 2010 06:32:29 +0000 (UTC) Received: from localhost (unknown [192.168.1.2]) by mail.zirakzigil.org (Postfix) with ESMTP id D685F978ED; Wed, 5 May 2010 08:32:16 +0200 (CEST) X-Virus-Scanned: amavisd-new at zirakzigil.org Received: from mail.zirakzigil.org ([192.168.1.2]) by localhost (ext.zirakzigil.org [192.168.1.2]) (amavisd-new, port 10024) with ESMTP id 3Kjm-u7K2Idw; Wed, 5 May 2010 08:32:14 +0200 (CEST) Received: from [192.168.229.30] (unknown [192.168.1.2]) (Authenticated sender: auryn@zirakzigil.org) by mail.zirakzigil.org (Postfix) with ESMTPA id 12FEA978E4; Wed, 5 May 2010 08:32:14 +0200 (CEST) Message-ID: <4BE110E3.8040902@zirakzigil.org> Date: Wed, 05 May 2010 08:32:03 +0200 From: Giulio Ferro User-Agent: Thunderbird 2.0.0.24 (X11/20100411) MIME-Version: 1.0 To: Jeremy Chadwick , freebsd-stable@freebsd.org References: <4BDEA86E.3050109@zirakzigil.org> <20100503110100.GA93137@icarus.home.lan> <4BDEC106.3040807@zirakzigil.org> In-Reply-To: <4BDEC106.3040807@zirakzigil.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: Re: Freebsd 8.0 kmem map too small X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 05 May 2010 06:32:29 -0000 Giulio Ferro wrote: > Thanks, I'll try these settings. > > I'll keep you posted. Nope, it's happened again... Now I've tried to rise vm.kmem_size to 6G... I'm really astounded at how unstable zfs is, it's causing me a lot of problem. Why isn't it stated in the handbook that zfs isn't up to production yet? From owner-freebsd-stable@FreeBSD.ORG Wed May 5 07:40:01 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 9BAFF1065675; Wed, 5 May 2010 07:40:01 +0000 (UTC) (envelope-from demelier.david@gmail.com) Received: from mail-wy0-f182.google.com (mail-wy0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id CA8608FC19; Wed, 5 May 2010 07:40:00 +0000 (UTC) Received: by wyf23 with SMTP id 23so560035wyf.13 for ; Wed, 05 May 2010 00:39:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:date:from:to:cc:subject :message-id:references:mime-version:content-type:content-disposition :in-reply-to:user-agent; bh=lbk/dFCi/z6rFH89Dn6lj6AIU2w3kH4aCB52uoIXJng=; b=IQcqq09G0vJ4rw4zv2cJSuEGzYIcjGCZ8ZZwJPH7p8RbivEupoZsBH48eQOTGG3PN9 TfRUOiidq6esyMibV1c/3pc6GTzYqQxfhWuCqkeRkp/QTpBg9HgOUGysgVQVqBf7wRzV zu1VASCxiEU53gq8/IZo0T/Sk9Oa1auFFTNrI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; b=YOMATGZfGXaXRNdAdFZqAgYDy94ChKQ/owpvBF/d5FMQVPD+it34JnnqjTqmEYOb13 MWGAqfJ1PuE0/BiN8FFL89DyyGbSncSFN59hERB8nQi+QFdhZjYJ2L8pJw+5DYURWh2g GVU6A6Cy02DT2IO2iez+Izs0ERpiqZDp10YNw= Received: by 10.227.155.213 with SMTP id t21mr2227397wbw.66.1273045191334; Wed, 05 May 2010 00:39:51 -0700 (PDT) Received: from Abricot.malikania.fr (121.21.102-84.rev.gaoland.net [84.102.21.121]) by mx.google.com with ESMTPS id x14sm56580679wbs.18.2010.05.05.00.39.50 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 05 May 2010 00:39:50 -0700 (PDT) Date: Wed, 5 May 2010 09:40:46 +0200 From: Demelier David To: Rui Paulo Message-ID: <20100505074045.GA28030@Abricot.malikania.fr> References: <20100504085332.GA24219@icarus.home.lan> <20100504200139.GP23646@deviant.kiev.zoral.com.ua> <20100504203809.GR23646@deviant.kiev.zoral.com.ua> <42ACDAF6-7EA9-4CE9-AA8D-FDA678A1EA74@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <42ACDAF6-7EA9-4CE9-AA8D-FDA678A1EA74@FreeBSD.org> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: Kostik Belousov , Giovanni Trematerra , freebsd-stable@freebsd.org, freebsd-acpi@freebsd.org Subject: Re: Kernel panic when unpluggin AC adaptor X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 05 May 2010 07:40:01 -0000 On Wed, May 05, 2010 at 01:19:45AM +0100, Rui Paulo wrote: > On 4 May 2010, at 21:38, Kostik Belousov wrote: > > > On Tue, May 04, 2010 at 10:27:23PM +0200, David DEMELIER wrote: > >> 2010/5/4 Kostik Belousov : > >>> On Tue, May 04, 2010 at 06:35:52PM +0200, David DEMELIER wrote: > >>>> Good news ! It worked, check the picture here : > >>>> > >>>> http://img63.imageshack.us/img63/4244/dsc00361g.jpg > >>> > >>> Please try adding code fragment like this: > >>> if (cx_next->p_lvlx == NULL) > >>> printf("Going to panic.\n"); > >>> to dev/acpi/acpi_cpu.c:acpi_cpu_idle() function, right before > >>> CPU_GET_REG(cx_next->p_lvlx, 1); > >>> line and see if it prints the message immediately before the panic. > >>> > >> > >> Yes it does at the beginning of the kernel panic. > > > > Ok, so the point of panic is found, it is NULL cx_next->p_lvlx resource. > > With the data in hand, I recommend you to ask on acpi@ (added a Cc:) > > about the cause and possible solution. > > I don't remember the details, but I've seen this before. Does your CPU Cx levels change when you plug/unplug the AC adapter? > May 4 15:48:32 Melon power_profile: changed to 'economy' May 4 15:48:35 Melon power_profile: changed to 'performance' I think yes. King regards. -- Demelier David From owner-freebsd-stable@FreeBSD.ORG Wed May 5 07:52:44 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 73CF71065672 for ; Wed, 5 May 2010 07:52:44 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta09.emeryville.ca.mail.comcast.net (qmta09.emeryville.ca.mail.comcast.net [76.96.30.96]) by mx1.freebsd.org (Postfix) with ESMTP id 5B1F48FC14 for ; Wed, 5 May 2010 07:52:43 +0000 (UTC) Received: from omta19.emeryville.ca.mail.comcast.net ([76.96.30.76]) by qmta09.emeryville.ca.mail.comcast.net with comcast id DjqJ1e0041eYJf8A9jskFx; Wed, 05 May 2010 07:52:44 +0000 Received: from koitsu.dyndns.org ([98.248.46.159]) by omta19.emeryville.ca.mail.comcast.net with comcast id Djsj1e0053S48mS01jsj4t; Wed, 05 May 2010 07:52:44 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 4693B9B425; Wed, 5 May 2010 00:52:42 -0700 (PDT) Date: Wed, 5 May 2010 00:52:42 -0700 From: Jeremy Chadwick To: Giulio Ferro Message-ID: <20100505075242.GA57550@icarus.home.lan> References: <4BDEA86E.3050109@zirakzigil.org> <20100503110100.GA93137@icarus.home.lan> <4BDEC106.3040807@zirakzigil.org> <4BE110E3.8040902@zirakzigil.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4BE110E3.8040902@zirakzigil.org> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: freebsd-stable@freebsd.org Subject: Re: Freebsd 8.0 kmem map too small X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 05 May 2010 07:52:44 -0000 On Wed, May 05, 2010 at 08:32:03AM +0200, Giulio Ferro wrote: > Giulio Ferro wrote: > >Thanks, I'll try these settings. > > > >I'll keep you posted. > > Nope, it's happened again... Now I've tried to rise vm.kmem_size to 6G... Did you set both vm.kmem_size and vfs.zfs.arc_max, setting the latter to something *less* than vm.kmem_size? > I'm really astounded at how unstable zfs is, it's causing me a lot > of problem. > > Why isn't it stated in the handbook that zfs isn't up to production yet? I'm not at liberty to comment + answer this question. -- | 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 May 5 08:46:39 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 723341065670 for ; Wed, 5 May 2010 08:46:39 +0000 (UTC) (envelope-from auryn@zirakzigil.org) Received: from mail.zirakzigil.org (mail.zirakzigil.org [82.63.178.63]) by mx1.freebsd.org (Postfix) with ESMTP id 13E288FC12 for ; Wed, 5 May 2010 08:46:38 +0000 (UTC) Received: from localhost (unknown [192.168.1.2]) by mail.zirakzigil.org (Postfix) with ESMTP id 649C19645F; Wed, 5 May 2010 10:46:33 +0200 (CEST) X-Virus-Scanned: amavisd-new at zirakzigil.org Received: from mail.zirakzigil.org ([192.168.1.2]) by localhost (ext.zirakzigil.org [192.168.1.2]) (amavisd-new, port 10024) with ESMTP id Tu79RjZ5Aib0; Wed, 5 May 2010 10:46:30 +0200 (CEST) Received: from aurynmob2.giulioferro.it (unknown [192.168.1.2]) (Authenticated sender: auryn@zirakzigil.org) by mail.zirakzigil.org (Postfix) with ESMTPA id C7BFB96454; Wed, 5 May 2010 10:46:30 +0200 (CEST) Message-ID: <4BE13067.1060606@zirakzigil.org> Date: Wed, 05 May 2010 10:46:31 +0200 From: Giulio Ferro User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.1.7) Gecko/20100223 Thunderbird/3.0.1 MIME-Version: 1.0 To: Jeremy Chadwick , freebsd-stable@freebsd.org, freebsd-fs@freebsd.org References: <4BDEA86E.3050109@zirakzigil.org> <20100503110100.GA93137@icarus.home.lan> <4BDEC106.3040807@zirakzigil.org> <4BE110E3.8040902@zirakzigil.org> <20100505075242.GA57550@icarus.home.lan> In-Reply-To: <20100505075242.GA57550@icarus.home.lan> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: Re: Freebsd 8.0 kmem map too small X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 05 May 2010 08:46:39 -0000 On 05.05.2010 09:52, Jeremy Chadwick wrote: Nope, it's happened again... Now I've tried to rise vm.kmem_size to 6G... > Did you set both vm.kmem_size and vfs.zfs.arc_max, setting the latter to > something *less* than vm.kmem_size? > > Yes. After your suggestion, I set vfs.zfs.arc_max: 3758096384 vm.kmem_size: 4G Now: vfs.zfs.arc_max: 3758096384 vm.kmem_size: 6392119296 >> I'm really astounded at how unstable zfs is, it's causing me a lot >> of problem. >> >> Why isn't it stated in the handbook that zfs isn't up to production yet? >> > I'm not at liberty to comment + answer this question. > > Why people responsible for ZFS on freebsd aren't saying anything? What's the status of this issue? Is someone working on this??? From owner-freebsd-stable@FreeBSD.ORG Wed May 5 09:14:10 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id ABBE8106564A; Wed, 5 May 2010 09:14:10 +0000 (UTC) (envelope-from auryn@zirakzigil.org) Received: from mail.zirakzigil.org (mail.zirakzigil.org [82.63.178.63]) by mx1.freebsd.org (Postfix) with ESMTP id 1CCCF8FC08; Wed, 5 May 2010 09:14:09 +0000 (UTC) Received: from localhost (unknown [192.168.1.2]) by mail.zirakzigil.org (Postfix) with ESMTP id 25C9096ABD; Wed, 5 May 2010 11:14:09 +0200 (CEST) X-Virus-Scanned: amavisd-new at zirakzigil.org Received: from mail.zirakzigil.org ([192.168.1.2]) by localhost (ext.zirakzigil.org [192.168.1.2]) (amavisd-new, port 10024) with ESMTP id ZuP0nMVb+KUZ; Wed, 5 May 2010 11:14:06 +0200 (CEST) Received: from aurynmob2.giulioferro.it (unknown [192.168.1.2]) (Authenticated sender: auryn@zirakzigil.org) by mail.zirakzigil.org (Postfix) with ESMTPA id 0D03996AAF; Wed, 5 May 2010 11:14:06 +0200 (CEST) Message-ID: <4BE136DE.5010904@zirakzigil.org> Date: Wed, 05 May 2010 11:14:06 +0200 From: Giulio Ferro User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.1.7) Gecko/20100223 Thunderbird/3.0.1 MIME-Version: 1.0 To: Simun Mikecin References: <4BDEA86E.3050109@zirakzigil.org> <20100503110100.GA93137@icarus.home.lan> <4BDEC106.3040807@zirakzigil.org> <4BE110E3.8040902@zirakzigil.org> <20100505075242.GA57550@icarus.home.lan> <4BE13067.1060606@zirakzigil.org> <483679.65695.qm@web112403.mail.gq1.yahoo.com> In-Reply-To: <483679.65695.qm@web112403.mail.gq1.yahoo.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-fs@freebsd.org, freebsd-stable@freebsd.org Subject: Re: Freebsd 8.0 kmem map too small X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 05 May 2010 09:14:10 -0000 On 05.05.2010 11:11, Simun Mikecin wrote: > ----- Original Message ---- > >>> I'm really astounded at how unstable zfs is, it's >>> >> causing me a lot >> >>> of problem. >>> >>> Why isn't it >>> >> stated in the handbook that zfs isn't up to production yet? >> >>> >>> >> Why people responsible for ZFS on >> freebsd aren't saying anything? What's the status of this issue? Is someone >> working on this??? >> > > How much RAM do you have? Are you using i386 or amd64? Have you tried removing all zfs and kmem sysctl's so the system uses default values? > > This is the first post of the current thread: it should tell you everything -------------------------------------------------------------------- NFS server amd64 Freebsd 8.0 recent (2 days ago) This server has been running for several months without problems. Beginning last week, however, I'm experiencing panics (about 1 per day) with the error in the subject Current settings: vm.kmem_size_scale: 3 vm.kmem_size_max: 329853485875 vm.kmem_size_min: 0 vm.kmem_size: 2764046336 ... hw.physmem: 8568225792 hw.usermem: 6117404672 hw.realmem: 9395240960 ... vfs.zfs.l2arc_noprefetch: 0 vfs.zfs.l2arc_feed_secs_shift: 1 vfs.zfs.l2arc_feed_secs: 1 vfs.zfs.l2arc_headroom: 128 vfs.zfs.l2arc_write_boost: 67108864 vfs.zfs.l2arc_write_max: 67108864 vfs.zfs.arc_meta_limit: 431882240 vfs.zfs.arc_meta_used: 431874720 vfs.zfs.arc_min: 215941120 vfs.zfs.arc_max: 1727528960 I've set nothing in either /boot/loader.conf or sysctl.conf What should I do? -------------------------------------------------------------------- From owner-freebsd-stable@FreeBSD.ORG Wed May 5 09:49:28 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id D08D31065672; Wed, 5 May 2010 09:49:28 +0000 (UTC) (envelope-from rpaulo@freebsd.org) Received: from karen.lavabit.com (karen.lavabit.com [72.249.41.33]) by mx1.freebsd.org (Postfix) with ESMTP id 606E18FC0C; Wed, 5 May 2010 09:49:28 +0000 (UTC) Received: from e.earth.lavabit.com (e.earth.lavabit.com [192.168.111.14]) by karen.lavabit.com (Postfix) with ESMTP id 4074311BA1D; Wed, 5 May 2010 04:49:27 -0500 (CDT) Received: from 10.0.10.3 (54.81.54.77.rev.vodafone.pt [77.54.81.54]) by lavabit.com with ESMTP id 94UZTEC4PIEG; Wed, 05 May 2010 04:49:27 -0500 Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii From: Rui Paulo In-Reply-To: <20100505074045.GA28030@Abricot.malikania.fr> Date: Wed, 5 May 2010 10:49:23 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <4DEBDE2C-C0D2-469D-AC42-DD5027926424@FreeBSD.org> References: <20100504085332.GA24219@icarus.home.lan> <20100504200139.GP23646@deviant.kiev.zoral.com.ua> <20100504203809.GR23646@deviant.kiev.zoral.com.ua> <42ACDAF6-7EA9-4CE9-AA8D-FDA678A1EA74@FreeBSD.org> <20100505074045.GA28030@Abricot.malikania.fr> To: Demelier David X-Mailer: Apple Mail (2.1078) Cc: Kostik Belousov , Giovanni Trematerra , freebsd-stable@freebsd.org, freebsd-acpi@freebsd.org Subject: Re: Kernel panic when unpluggin AC adaptor X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 05 May 2010 09:49:28 -0000 On 5 May 2010, at 08:40, Demelier David wrote: > On Wed, May 05, 2010 at 01:19:45AM +0100, Rui Paulo wrote: >> On 4 May 2010, at 21:38, Kostik Belousov wrote: >>=20 >>> On Tue, May 04, 2010 at 10:27:23PM +0200, David DEMELIER wrote: >>>> 2010/5/4 Kostik Belousov : >>>>> On Tue, May 04, 2010 at 06:35:52PM +0200, David DEMELIER wrote: >>>>>> Good news ! It worked, check the picture here : >>>>>>=20 >>>>>> http://img63.imageshack.us/img63/4244/dsc00361g.jpg >>>>>=20 >>>>> Please try adding code fragment like this: >>>>> if (cx_next->p_lvlx =3D=3D NULL) >>>>> printf("Going to panic.\n"); >>>>> to dev/acpi/acpi_cpu.c:acpi_cpu_idle() function, right before >>>>> CPU_GET_REG(cx_next->p_lvlx, 1); >>>>> line and see if it prints the message immediately before the = panic. >>>>>=20 >>>>=20 >>>> Yes it does at the beginning of the kernel panic. >>>=20 >>> Ok, so the point of panic is found, it is NULL cx_next->p_lvlx = resource. >>> With the data in hand, I recommend you to ask on acpi@ (added a Cc:) >>> about the cause and possible solution. >>=20 >> I don't remember the details, but I've seen this before. Does your = CPU Cx levels change when you plug/unplug the AC adapter? >>=20 >=20 > May 4 15:48:32 Melon power_profile: changed to 'economy' > May 4 15:48:35 Melon power_profile: changed to 'performance' I wasn't asking about the profiles. Show us the output of sysctl dev.cpu = with and without the AC cord plugged in. Regards, -- Rui Paulo From owner-freebsd-stable@FreeBSD.ORG Wed May 5 11:03:52 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 37FB01065678; Wed, 5 May 2010 11:03:52 +0000 (UTC) (envelope-from demelier.david@gmail.com) Received: from mail-ww0-f54.google.com (mail-ww0-f54.google.com [74.125.82.54]) by mx1.freebsd.org (Postfix) with ESMTP id 63F898FC18; Wed, 5 May 2010 11:03:51 +0000 (UTC) Received: by wwb39 with SMTP id 39so400887wwb.13 for ; Wed, 05 May 2010 04:03:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:date:from:to:cc:subject :message-id:references:mime-version:content-type:content-disposition :in-reply-to:user-agent; bh=1JW5mpfKrcC1r2YSHJTZz0ac5N3ma5jXG631aqy8Z1Q=; b=XD7UlCfi9jjVlB6vVuOhPNs+97k04AWI2+6NBvMYW4p4Be0ks4mQHP70DOZIANtJlV 8bmEYU4AXgiMBuiRCW56TULC6a7tD7IymAZSzULz+cLzRfnX3uHH2RqpAam3P5JKSQin fNozS5+4iggWgq1GU+EHB/XF9W0xq9v+/QW0A= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; b=fR0KMbQxYGv9WSVdx5z9eXl/jMoyVPIbHO3yyDBxjcvpzwuICdObyu96K6SiRl6eep xWcJqE5XAFeXgJIALbipdgbgZINRH+dIA5LU6nTyEmYyiTrcZn/in+GQgeRGfymskvvu d6qd8XeMu5r3scGO2Fb9Xra20hkKiwaQ9nIuE= Received: by 10.227.142.71 with SMTP id p7mr2561051wbu.201.1273057427868; Wed, 05 May 2010 04:03:47 -0700 (PDT) Received: from Melon.malikania.fr (wifi-osiris-sec-183-144.u-strasbg.fr [130.79.183.144]) by mx.google.com with ESMTPS id x14sm57743796wbs.12.2010.05.05.04.03.45 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 05 May 2010 04:03:46 -0700 (PDT) Date: Wed, 5 May 2010 13:03:32 +0200 From: Demelier David To: Rui Paulo Message-ID: <20100505110332.GA1578@Melon.malikania.fr> References: <20100504200139.GP23646@deviant.kiev.zoral.com.ua> <20100504203809.GR23646@deviant.kiev.zoral.com.ua> <42ACDAF6-7EA9-4CE9-AA8D-FDA678A1EA74@FreeBSD.org> <20100505074045.GA28030@Abricot.malikania.fr> <4DEBDE2C-C0D2-469D-AC42-DD5027926424@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4DEBDE2C-C0D2-469D-AC42-DD5027926424@FreeBSD.org> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: Kostik Belousov , Giovanni Trematerra , freebsd-stable@freebsd.org, freebsd-acpi@freebsd.org Subject: Re: Kernel panic when unpluggin AC adaptor X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 05 May 2010 11:03:52 -0000 On Wed, May 05, 2010 at 10:49:23AM +0100, Rui Paulo wrote: > > On 5 May 2010, at 08:40, Demelier David wrote: > > > On Wed, May 05, 2010 at 01:19:45AM +0100, Rui Paulo wrote: > >> On 4 May 2010, at 21:38, Kostik Belousov wrote: > >> > >>> On Tue, May 04, 2010 at 10:27:23PM +0200, David DEMELIER wrote: > >>>> 2010/5/4 Kostik Belousov : > >>>>> On Tue, May 04, 2010 at 06:35:52PM +0200, David DEMELIER wrote: > >>>>>> Good news ! It worked, check the picture here : > >>>>>> > >>>>>> http://img63.imageshack.us/img63/4244/dsc00361g.jpg > >>>>> > >>>>> Please try adding code fragment like this: > >>>>> if (cx_next->p_lvlx == NULL) > >>>>> printf("Going to panic.\n"); > >>>>> to dev/acpi/acpi_cpu.c:acpi_cpu_idle() function, right before > >>>>> CPU_GET_REG(cx_next->p_lvlx, 1); > >>>>> line and see if it prints the message immediately before the panic. > >>>>> > >>>> > >>>> Yes it does at the beginning of the kernel panic. > >>> > >>> Ok, so the point of panic is found, it is NULL cx_next->p_lvlx resource. > >>> With the data in hand, I recommend you to ask on acpi@ (added a Cc:) > >>> about the cause and possible solution. > >> > >> I don't remember the details, but I've seen this before. Does your CPU Cx levels change when you plug/unplug the AC adapter? > >> > > > > May 4 15:48:32 Melon power_profile: changed to 'economy' > > May 4 15:48:35 Melon power_profile: changed to 'performance' > > I wasn't asking about the profiles. Show us the output of sysctl dev.cpu with and without the AC cord plugged in. > That is when I have ac unplugged : $ sysctl dev.cpu dev.cpu.0.%desc: ACPI CPU dev.cpu.0.%driver: cpu dev.cpu.0.%location: handle=\_PR_.CPU0 dev.cpu.0.%pnpinfo: _HID=none _UID=0 dev.cpu.0.%parent: acpi0 dev.cpu.0.freq: 1200 dev.cpu.0.freq_levels: 2101/35000 1837/30625 1600/23888 1400/20902 1200/15000 1050/13125 900/11250 750/9375 600/7500 450/5625 300/3750 150/1875 dev.cpu.0.cx_supported: C1/1 C2/57 dev.cpu.0.cx_lowest: C2 dev.cpu.0.cx_usage: 7.22% 92.77% last 2482us dev.cpu.1.%desc: ACPI CPU dev.cpu.1.%driver: cpu dev.cpu.1.%location: handle=\_PR_.CPU1 dev.cpu.1.%pnpinfo: _HID=none _UID=0 dev.cpu.1.%parent: acpi0 dev.cpu.1.cx_supported: C1/1 C2/57 dev.cpu.1.cx_lowest: C2 dev.cpu.1.cx_usage: 5.55% 94.44% last 7724us -- Demelier David From owner-freebsd-stable@FreeBSD.ORG Wed May 5 11:45:51 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id C398D1065672; Wed, 5 May 2010 11:45:51 +0000 (UTC) (envelope-from rpaulo@freebsd.org) Received: from karen.lavabit.com (karen.lavabit.com [72.249.41.33]) by mx1.freebsd.org (Postfix) with ESMTP id 7D7578FC12; Wed, 5 May 2010 11:45:51 +0000 (UTC) Received: from e.earth.lavabit.com (e.earth.lavabit.com [192.168.111.14]) by karen.lavabit.com (Postfix) with ESMTP id 64F9011B902; Wed, 5 May 2010 06:45:50 -0500 (CDT) Received: from 10.0.10.3 (54.81.54.77.rev.vodafone.pt [77.54.81.54]) by lavabit.com with ESMTP id MIVDB8GQ67BD; Wed, 05 May 2010 06:45:50 -0500 Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii From: Rui Paulo In-Reply-To: <20100505110332.GA1578@Melon.malikania.fr> Date: Wed, 5 May 2010 12:45:46 +0100 Content-Transfer-Encoding: 7bit Message-Id: <96F538BA-488A-46B3-99A0-BC324DB0F73A@FreeBSD.org> References: <20100504200139.GP23646@deviant.kiev.zoral.com.ua> <20100504203809.GR23646@deviant.kiev.zoral.com.ua> <42ACDAF6-7EA9-4CE9-AA8D-FDA678A1EA74@FreeBSD.org> <20100505074045.GA28030@Abricot.malikania.fr> <4DEBDE2C-C0D2-469D-AC42-DD5027926424@FreeBSD.org> <20100505110332.GA1578@Melon.malikania.fr> To: Demelier David X-Mailer: Apple Mail (2.1078) Cc: Kostik Belousov , Giovanni Trematerra , freebsd-stable@freebsd.org, freebsd-acpi@freebsd.org Subject: Re: Kernel panic when unpluggin AC adaptor X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 05 May 2010 11:45:51 -0000 Please try this patch: Index: acpi_cpu.c =================================================================== --- acpi_cpu.c (revision 207322) +++ acpi_cpu.c (working copy) @@ -997,12 +997,12 @@ if (notify != ACPI_NOTIFY_CX_STATES) return; + ACPI_SERIAL_BEGIN(cpu); /* Update the list of Cx states. */ acpi_cpu_cx_cst(sc); acpi_cpu_cx_list(sc); /* Update the new lowest useable Cx state for all CPUs. */ - ACPI_SERIAL_BEGIN(cpu); cpu_cx_count = 0; for (i = 0; i < cpu_ndevices; i++) { isc = device_get_softc(cpu_devices[i]); Regards, -- Rui Paulo From owner-freebsd-stable@FreeBSD.ORG Wed May 5 12:00:00 2010 Return-Path: Delivered-To: stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 1A8761065673 for ; Wed, 5 May 2010 12:00:00 +0000 (UTC) (envelope-from gds@otenet.gr) Received: from aiolos.otenet.gr (aiolos.otenet.gr [83.235.67.30]) by mx1.freebsd.org (Postfix) with ESMTP id 8198A8FC08 for ; Wed, 5 May 2010 11:59:59 +0000 (UTC) Received: from [127.0.0.1] (ppp089210206068.dsl.hol.gr [89.210.206.68]) (authenticated bits=0) by aiolos.otenet.gr (8.13.8/8.13.8/Debian-3) with ESMTP id o45BLgnZ019294 for ; Wed, 5 May 2010 14:21:46 +0300 Message-ID: <4BE154BE.9050409@otenet.gr> Date: Wed, 05 May 2010 14:21:34 +0300 From: dafne User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: stable@FreeBSD.org Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 100505-0, 05/05/2010), Outbound message X-Antivirus-Status: Clean Cc: Subject: subsribe X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 05 May 2010 12:00:00 -0000 From owner-freebsd-stable@FreeBSD.ORG Wed May 5 12:41:42 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id C8A1C1065679 for ; Wed, 5 May 2010 12:41:42 +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 54D688FC1D for ; Wed, 5 May 2010 12:41:41 +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 o45CfeVE075364 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 5 May 2010 14:41:41 +0200 (CEST) (envelope-from h.schmalzbauer@omnilan.de) Message-ID: <4BE16784.8050400@omnilan.de> Date: Wed, 05 May 2010 14:41:40 +0200 From: Harald Schmalzbauer Organization: OmniLAN User-Agent: Thunderbird 2.0.0.23 (X11/20090906) MIME-Version: 1.0 To: FreeBSD Stable X-Enigmail-Version: 0.95.6 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigF882454B7297B5A9D4A5538D" Subject: ZFS (zpool) doesn't detect failed drive X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 May 2010 12:41:42 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigF882454B7297B5A9D4A5538D Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: quoted-printable Hello, one drive of my mirror failed today, but 'zpool staus' shows it "online".= Every process using a ZFS mount hangs. Also 'zpool offline /dev/ad1'=20 hangs infinitely. Here's the dmesg of the failing (and correctly detached) device: ad1: TIMEOUT - FLUSHCACHE48 retrying (1 retry left) ata3: port is not ready (timeout 10000ms) tfd =3D 00000080 ata3: hardware reset timeout ad1: FAILURE - device detached But: zpool status pool: URUBAmirrorP1 state: ONLINE status: One or more devices are faulted in response to IO failures. action: Make sure the affected devices are connected, then run 'zpool=20 clear'. see: http://www.sun.com/msg/ZFS-8000-JQ scrub: none requested config: NAME STATE READ WRITE CKSUM URUBAmirrorP1 ONLINE 0 7K 0 ad1 ONLINE 3 14,9K 0 ad2 ONLINE 0 0 0 Reboot doesn't work, somebody had to reset the machine. How should such a error event be handled??? Isn't a mirror useless if=20 there's no way to continue with one remaining good drive? If the OS was on the same pool the complete machine is unaccessable with = a failing drive..?!? Thanks, -Harry --------------enigF882454B7297B5A9D4A5538D 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) iEYEARECAAYFAkvhZ4QACgkQLDqVQ9VXb8gmqACgtNZdKOaSuuWH9poO0lK8XzvU JQkAniEJS2+ouUufjNzI7SVM25C2W+HF =pEos -----END PGP SIGNATURE----- --------------enigF882454B7297B5A9D4A5538D-- From owner-freebsd-stable@FreeBSD.ORG Wed May 5 13:24:34 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id F0340106564A for ; Wed, 5 May 2010 13:24:34 +0000 (UTC) (envelope-from kamikaze@bsdforen.de) Received: from mail.bsdforen.de (bsdforen.de [212.204.60.79]) by mx1.freebsd.org (Postfix) with ESMTP id B28398FC12 for ; Wed, 5 May 2010 13:24:34 +0000 (UTC) Received: from mobileKamikaze.norad (vpn-cl-162-131.rz.uni-karlsruhe.de [141.3.162.131]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.bsdforen.de (Postfix) with ESMTP id 406F98A1C07 for ; Wed, 5 May 2010 15:24:33 +0200 (CEST) Message-ID: <4BE17191.6040305@bsdforen.de> Date: Wed, 05 May 2010 15:24:33 +0200 From: Dominic Fandrey User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-GB; rv:1.9.1.9) Gecko/20100331 Thunderbird/3.0.4 MIME-Version: 1.0 To: freebsd-stable@freebsd.org X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: geom_sched influence on SU consistency X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 05 May 2010 13:24:35 -0000 I'm wondering how geom_sched influences soft-update consistency. To my understanding it's very important to SU, that the file system controls writing sequences. Because geom_sched is transparent, i.e. UFS does not know about access scheduling, I'm afraid that the use of geom_sched would endanger my file system consistency in case of a crash. Can anyone put my fears to rest or confirm them? -- A: Because it fouls the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail? From owner-freebsd-stable@FreeBSD.ORG Wed May 5 13:33:15 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 1A00E106564A; Wed, 5 May 2010 13:33:15 +0000 (UTC) (envelope-from pjd@garage.freebsd.pl) Received: from mail.garage.freebsd.pl (chello089077043238.chello.pl [89.77.43.238]) by mx1.freebsd.org (Postfix) with ESMTP id 51A1C8FC1F; Wed, 5 May 2010 13:33:13 +0000 (UTC) Received: by mail.garage.freebsd.pl (Postfix, from userid 65534) id 8603945F22; Wed, 5 May 2010 15:33:11 +0200 (CEST) Received: from localhost (pdawidek.wheel.pl [10.0.1.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.garage.freebsd.pl (Postfix) with ESMTP id E431845E49; Wed, 5 May 2010 15:33:06 +0200 (CEST) Date: Wed, 5 May 2010 15:33:02 +0200 From: Pawel Jakub Dawidek To: Giulio Ferro Message-ID: <20100505133302.GB1626@garage.freebsd.pl> References: <4BDEA86E.3050109@zirakzigil.org> <20100503110100.GA93137@icarus.home.lan> <4BDEC106.3040807@zirakzigil.org> <4BE110E3.8040902@zirakzigil.org> <20100505075242.GA57550@icarus.home.lan> <4BE13067.1060606@zirakzigil.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="kORqDWCi7qDJ0mEj" Content-Disposition: inline In-Reply-To: <4BE13067.1060606@zirakzigil.org> User-Agent: Mutt/1.4.2.3i X-PGP-Key-URL: http://people.freebsd.org/~pjd/pjd.asc X-OS: FreeBSD 9.0-CURRENT amd64 X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on mail.garage.freebsd.pl X-Spam-Level: X-Spam-Status: No, score=-5.9 required=4.5 tests=ALL_TRUSTED,BAYES_00 autolearn=ham version=3.0.4 Cc: freebsd-fs@freebsd.org, freebsd-stable@freebsd.org, Jeremy Chadwick Subject: Re: Freebsd 8.0 kmem map too small X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 05 May 2010 13:33:15 -0000 --kORqDWCi7qDJ0mEj Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, May 05, 2010 at 10:46:31AM +0200, Giulio Ferro wrote: > On 05.05.2010 09:52, Jeremy Chadwick wrote: >=20 > Nope, it's happened again... Now I've tried to rise vm.kmem_size to 6G... >=20 >=20 > >Did you set both vm.kmem_size and vfs.zfs.arc_max, setting the latter to > >something *less* than vm.kmem_size? > > > > =20 >=20 > Yes. > After your suggestion, I set > vfs.zfs.arc_max: 3758096384 > vm.kmem_size: 4G >=20 > Now: > vfs.zfs.arc_max: 3758096384 > vm.kmem_size: 6392119296 Could you try to track down the commit that is causing your problems? Could you try 8-STABLE kernel from before r206815? --=20 Pawel Jakub Dawidek http://www.wheelsystems.com pjd@FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! --kORqDWCi7qDJ0mEj Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (FreeBSD) iEYEARECAAYFAkvhc40ACgkQForvXbEpPzQDMgCg3wAjzXe1GtF6AQFHxSKjt0zs NVMAoJEU5jdMGAFYPSI1vWlMRY4fTE+w =Q7ev -----END PGP SIGNATURE----- --kORqDWCi7qDJ0mEj-- From owner-freebsd-stable@FreeBSD.ORG Wed May 5 13:57:55 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 534091065670; Wed, 5 May 2010 13:57:55 +0000 (UTC) (envelope-from demelier.david@gmail.com) Received: from mail-ww0-f54.google.com (mail-ww0-f54.google.com [74.125.82.54]) by mx1.freebsd.org (Postfix) with ESMTP id 84B258FC15; Wed, 5 May 2010 13:57:54 +0000 (UTC) Received: by wwb39 with SMTP id 39so537148wwb.13 for ; Wed, 05 May 2010 06:57:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:date:from:to:cc:subject :message-id:references:mime-version:content-type:content-disposition :in-reply-to:user-agent; bh=VCUqo4ZRDcwfJj22hA6BEGSHv21/FUJwpm7iXo6k+3I=; b=x0zP1EirJHjEkuz5KB6f5MsMkB1KPl0xNPLC7Vf/pcA5GGHzVJLfa2SDZZh+n8clXP 0rH9VqAuOQ5pOn9lmktBVzcy92w1y6cwNxkHGIVd022g4KJ2Iql3Xs373TwCXSyIu9R5 6gG0wB+Gh+cNG56UYfqluINKFrJ6ACnEMTOQM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; b=cOkOWLarsLTTqwN6dNArwZVo1yOFoEwVnuAIkdike48ux0ja82mChPaMExawLubeRq OEGvZVp9G8X4DkFLGz/+/Xd5Iah+VSGJNOttJc3eZJAV0lgrGq6XlOPdQYcHHYwdwcgJ xobwYvUVoArdmtn1uFWTBYH5Hjm8uOhw/81PU= Received: by 10.216.89.74 with SMTP id b52mr208143wef.77.1273067867523; Wed, 05 May 2010 06:57:47 -0700 (PDT) Received: from Melon.malikania.fr (wifi-osiris-sec-181-106.u-strasbg.fr [130.79.181.106]) by mx.google.com with ESMTPS id g17sm2754884wee.17.2010.05.05.06.57.46 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 05 May 2010 06:57:46 -0700 (PDT) Date: Wed, 5 May 2010 15:57:43 +0200 From: Demelier David To: Rui Paulo Message-ID: <20100505135743.GA1613@Melon.malikania.fr> References: <20100504200139.GP23646@deviant.kiev.zoral.com.ua> <20100504203809.GR23646@deviant.kiev.zoral.com.ua> <42ACDAF6-7EA9-4CE9-AA8D-FDA678A1EA74@FreeBSD.org> <20100505074045.GA28030@Abricot.malikania.fr> <4DEBDE2C-C0D2-469D-AC42-DD5027926424@FreeBSD.org> <20100505110332.GA1578@Melon.malikania.fr> <96F538BA-488A-46B3-99A0-BC324DB0F73A@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <96F538BA-488A-46B3-99A0-BC324DB0F73A@FreeBSD.org> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: Kostik Belousov , Giovanni Trematerra , freebsd-stable@freebsd.org, freebsd-acpi@freebsd.org Subject: Re: Kernel panic when unpluggin AC adaptor X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 05 May 2010 13:57:55 -0000 On Wed, May 05, 2010 at 12:45:46PM +0100, Rui Paulo wrote: > Please try this patch: > > Index: acpi_cpu.c > =================================================================== > --- acpi_cpu.c (revision 207322) > +++ acpi_cpu.c (working copy) > @@ -997,12 +997,12 @@ > if (notify != ACPI_NOTIFY_CX_STATES) > return; > > + ACPI_SERIAL_BEGIN(cpu); > /* Update the list of Cx states. */ > acpi_cpu_cx_cst(sc); > acpi_cpu_cx_list(sc); > > /* Update the new lowest useable Cx state for all CPUs. */ > - ACPI_SERIAL_BEGIN(cpu); > cpu_cx_count = 0; > for (i = 0; i < cpu_ndevices; i++) { > isc = device_get_softc(cpu_devices[i]); > Tested, but exactly same panic an backtrace. Cheers. -- Demelier David From owner-freebsd-stable@FreeBSD.ORG Wed May 5 14:12:53 2010 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B539E106566C; Wed, 5 May 2010 14:12:53 +0000 (UTC) (envelope-from ben@wanderview.com) Received: from mail.wanderview.com (mail.wanderview.com [66.92.166.102]) by mx1.freebsd.org (Postfix) with ESMTP id 528488FC1A; Wed, 5 May 2010 14:12:52 +0000 (UTC) Received: from xykon.in.wanderview.com (xykon.in.wanderview.com [10.76.10.152]) (authenticated bits=0) by mail.wanderview.com (8.14.4/8.14.4) with ESMTP id o45ECnqS027944 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 5 May 2010 14:12:49 GMT (envelope-from ben@wanderview.com) Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii From: Ben Kelly In-Reply-To: <20100505133302.GB1626@garage.freebsd.pl> Date: Wed, 5 May 2010 10:12:49 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <533152DA-3B2F-4994-9206-727A2B0010AD@wanderview.com> References: <4BDEA86E.3050109@zirakzigil.org> <20100503110100.GA93137@icarus.home.lan> <4BDEC106.3040807@zirakzigil.org> <4BE110E3.8040902@zirakzigil.org> <20100505075242.GA57550@icarus.home.lan> <4BE13067.1060606@zirakzigil.org> <20100505133302.GB1626@garage.freebsd.pl> To: Pawel Jakub Dawidek X-Mailer: Apple Mail (2.1078) X-Spam-Score: -1.01 () ALL_TRUSTED,T_RP_MATCHES_RCVD X-Scanned-By: MIMEDefang 2.67 on 10.76.20.1 Cc: freebsd-fs@FreeBSD.org, Giulio Ferro , FreeBSD Stable Subject: Re: Freebsd 8.0 kmem map too small X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 05 May 2010 14:12:53 -0000 On May 5, 2010, at 9:33 AM, Pawel Jakub Dawidek wrote: > On Wed, May 05, 2010 at 10:46:31AM +0200, Giulio Ferro wrote: >> On 05.05.2010 09:52, Jeremy Chadwick wrote: >>=20 >> Nope, it's happened again... Now I've tried to rise vm.kmem_size to = 6G... >>=20 >>=20 >>> Did you set both vm.kmem_size and vfs.zfs.arc_max, setting the = latter to >>> something *less* than vm.kmem_size? >>>=20 >>>=20 >>=20 >> Yes. >> After your suggestion, I set >> vfs.zfs.arc_max: 3758096384 >> vm.kmem_size: 4G >>=20 >> Now: >> vfs.zfs.arc_max: 3758096384 >> vm.kmem_size: 6392119296 >=20 > Could you try to track down the commit that is causing your problems? > Could you try 8-STABLE kernel from before r206815? Are others generally able to run ARC values so close to kmem size? My = experience has been that you really need the ARC to be much smaller than = the kmem limit (like 25% or less) due to fragmentation of kmem_map. - Ben= From owner-freebsd-stable@FreeBSD.ORG Wed May 5 14:46:25 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 1EED91065748 for ; Wed, 5 May 2010 14:46:25 +0000 (UTC) (envelope-from korvus@comcast.net) Received: from qmta15.westchester.pa.mail.comcast.net (qmta15.westchester.pa.mail.comcast.net [76.96.59.228]) by mx1.freebsd.org (Postfix) with ESMTP id BABA78FC13 for ; Wed, 5 May 2010 14:46:24 +0000 (UTC) Received: from omta22.westchester.pa.mail.comcast.net ([76.96.62.73]) by qmta15.westchester.pa.mail.comcast.net with comcast id Doqw1e00B1ap0As5FqmRh2; Wed, 05 May 2010 14:46:25 +0000 Received: from [192.168.2.164] ([206.210.89.202]) by omta22.westchester.pa.mail.comcast.net with comcast id Dqm81e00H4Mx3R23iqmCdQ; Wed, 05 May 2010 14:46:23 +0000 Message-ID: <4BE184AE.7070307@comcast.net> Date: Wed, 05 May 2010 10:46:06 -0400 From: Steve Polyack User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.1.7) Gecko/20100311 Thunderbird/3.0.1 MIME-Version: 1.0 To: Ben Kelly References: <4BDEA86E.3050109@zirakzigil.org> <20100503110100.GA93137@icarus.home.lan> <4BDEC106.3040807@zirakzigil.org> <4BE110E3.8040902@zirakzigil.org> <20100505075242.GA57550@icarus.home.lan> <4BE13067.1060606@zirakzigil.org> <20100505133302.GB1626@garage.freebsd.pl> <533152DA-3B2F-4994-9206-727A2B0010AD@wanderview.com> In-Reply-To: <533152DA-3B2F-4994-9206-727A2B0010AD@wanderview.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-fs@freebsd.org, FreeBSD Stable , Pawel Jakub Dawidek Subject: Re: Freebsd 8.0 kmem map too small X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 05 May 2010 14:46:25 -0000 On 05/05/10 10:12, Ben Kelly wrote: > On May 5, 2010, at 9:33 AM, Pawel Jakub Dawidek wrote: > > >> On Wed, May 05, 2010 at 10:46:31AM +0200, Giulio Ferro wrote: >> >>> On 05.05.2010 09:52, Jeremy Chadwick wrote: >>> >>> Nope, it's happened again... Now I've tried to rise vm.kmem_size to 6G... >>> >>> >>> >>>> Did you set both vm.kmem_size and vfs.zfs.arc_max, setting the latter to >>>> something *less* than vm.kmem_size? >>>> >>>> >>>> >>> Yes. >>> After your suggestion, I set >>> vfs.zfs.arc_max: 3758096384 >>> vm.kmem_size: 4G >>> >>> Now: >>> vfs.zfs.arc_max: 3758096384 >>> vm.kmem_size: 6392119296 >>> >> Could you try to track down the commit that is causing your problems? >> Could you try 8-STABLE kernel from before r206815? >> > > Are others generally able to run ARC values so close to kmem size? My experience has been that you really need the ARC to be much smaller than the kmem limit (like 25% or less) due to fragmentation of kmem_map. > > On a system here with 8GB of RAM and a very large zpool consisting of multiple zdevs, little tuning was needed. The system is running 8-STABLE(amd64) as of a month or two ago. The only things I have set in /boot/loader.conf are: vm.kmem_size="12G" vfs.zfs.arc_max="4G" Setting kmem_size to 12G came from a combination of recommendations I saw in various mailing list posts (you can probably dig them up). Setting it to the physical memory size was the initial recommendation, while others recommended 1.5x physical memory size to help prevent fragmentation/wasted space in kmem. Regardless, this has served us quite well for the ~6 months the system has been in use. It has never crashed, even under intensive multi-threaded benchmarking. -Steve From owner-freebsd-stable@FreeBSD.ORG Wed May 5 14:56:44 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 2170810656C2 for ; Wed, 5 May 2010 14:56:44 +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 9A66D8FC19 for ; Wed, 5 May 2010 14:56:42 +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 o45Eufeq077183 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 5 May 2010 16:56:41 +0200 (CEST) (envelope-from h.schmalzbauer@omnilan.de) Message-ID: <4BE18729.3050209@omnilan.de> Date: Wed, 05 May 2010 16:56:41 +0200 From: Harald Schmalzbauer Organization: OmniLAN User-Agent: Thunderbird 2.0.0.23 (X11/20090906) MIME-Version: 1.0 To: FreeBSD Stable References: <4BE16784.8050400@omnilan.de> In-Reply-To: <4BE16784.8050400@omnilan.de> X-Enigmail-Version: 0.95.6 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig8BD6264B362B074B88954B27" Subject: Re: ZFS (zpool) doesn't detect failed drive X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 May 2010 14:56:44 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig8BD6264B362B074B88954B27 Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: quoted-printable Harald Schmalzbauer schrieb am 05.05.2010 14:41 (localtime): > Hello, >=20 > one drive of my mirror failed today, but 'zpool staus' shows it "online= ". > Every process using a ZFS mount hangs. Also 'zpool offline /dev/ad1'=20 > hangs infinitely. =2E.. Sorry, I made an error with zpool create. Somehow the little word=20 "mirror" must have been lost. So the pool wasn't a mirror but a stripe.=20 Then of course I can't make one vdev offline. Sorry for the noise. But I took the opportunity to do some tests with that failing drive and=20 created a _real_ mirror. That works without failures, but using the=20 mirror again leads to: ad1: TIMEOUT - FLUSHCACHE48 retrying (1 retry left) ad1: TIMEOUT - FLUSHCACHE48 retrying (1 retry left) ad1: TIMEOUT - FLUSHCACHE48 retrying (1 retry left) ad1: TIMEOUT - FLUSHCACHE48 retrying (1 retry left) ad1: TIMEOUT - FLUSHCACHE48 retrying (1 retry left) ad1: TIMEOUT - FLUSHCACHE48 retrying (1 retry left) ata3: port is not ready (timeout 10000ms) tfd =3D 00000080 ata3: hardware reset timeout ad1: FAILURE - device detached Now zpool reporsts the vdev ad1 still online although it has been=20 detached and 'atacontrol list' doesn't show it anymore: zpool status pool: URUBAmirrorP1 state: ONLINE status: One or more devices has experienced an unrecoverable error. An attempt was made to correct the error. Applications are=20 unaffected. action: Determine if the device needs to be replaced, and clear the error= s using 'zpool clear' or replace the device with 'zpool replace'. see: http://www.sun.com/msg/ZFS-8000-9P scrub: none requested config: NAME STATE READ WRITE CKSUM URUBAmirrorP1 ONLINE 0 0 0 mirror ONLINE 0 0 0 ad1 ONLINE 3 302K 0 ad2 ONLINE 0 0 0 errors: No known data errors atacontrol list ATA channel 2: Master: ad0 SATA revision 1.x Slave: no device present ATA channel 3: Master: no device present Slave: no device present ATA channel 4: Master: ad2 SATA revision 2.x Slave: no device present ATA channel 5: Master: ad3 SATA revision 1.x Slave: no device present How should such a failure be handled? Do I have to manually mark the drive offline for zpool? Thanks, -Harry --------------enig8BD6264B362B074B88954B27 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) iEYEARECAAYFAkvhhykACgkQLDqVQ9VXb8jSkgCgpLygtJqPYi+8ZrCCuUdyI7Pw LmQAnRn4VGBFQDN8ufU2ckVDMBT9x/NA =9sN5 -----END PGP SIGNATURE----- --------------enig8BD6264B362B074B88954B27-- From owner-freebsd-stable@FreeBSD.ORG Wed May 5 15:10:43 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 62308106566C for ; Wed, 5 May 2010 15:10:43 +0000 (UTC) (envelope-from rizzo.unipi@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 E98CF8FC14 for ; Wed, 5 May 2010 15:10:42 +0000 (UTC) Received: by ewy26 with SMTP id 26so1357111ewy.3 for ; Wed, 05 May 2010 08:10:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type; bh=HhdC/UQWGcwUyvZReiwnvD9oDqe+YS8p4GmkITKyAWE=; b=spN/G2RDbE3ZkTdoOWCngK0HQA9zMLGSkvD6m3L2Dn/3CXKTWZUHXNf7kGPALe1rvZ Y+0er/yBZwnDYffaQaHswUYm6wyzbdjxrwNUfdGr3Qdke5K381vGTXAJiJQDQyu76SbZ YAq0giPNlmjVEMIzoGSQL5W0/Qedb7SJAgRyU= 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=L/KpuqnFtETm2hBNZAiaDuocvtpFkQQlbgquULfUvLEv1mTqrl7fAdRTlIp9Z2vVsZ QVQFOU3w+wtZqed2hJdLYVhb9yAG/1QR8U922ExtLbYaIaCI8PiQ4vyq6SybRLo8rPNZ JAUE8+rugohzXOcCtpGhFdHTOdSQnMKe0xjAY= MIME-Version: 1.0 Received: by 10.213.42.19 with SMTP id q19mr2680968ebe.50.1273070692470; Wed, 05 May 2010 07:44:52 -0700 (PDT) Sender: rizzo.unipi@gmail.com Received: by 10.213.15.209 with HTTP; Wed, 5 May 2010 07:44:51 -0700 (PDT) In-Reply-To: <4BE17191.6040305@bsdforen.de> References: <4BE17191.6040305@bsdforen.de> Date: Wed, 5 May 2010 16:44:51 +0200 X-Google-Sender-Auth: f3pr7Rw29kKHMYXX_DuwnLVD06s Message-ID: From: Luigi Rizzo To: Dominic Fandrey Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-stable@freebsd.org Subject: Re: geom_sched influence on SU consistency X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 05 May 2010 15:10:43 -0000 On Wed, May 5, 2010 at 3:24 PM, Dominic Fandrey wrote: > I'm wondering how geom_sched influences soft-update consistency. > > To my understanding it's very important to SU, that the file system > controls writing sequences. Because geom_sched is transparent, > i.e. UFS does not know about access scheduling, I'm afraid that > the use of geom_sched would endanger my file system consistency > in case of a crash. > > Can anyone put my fears to rest or confirm them? geom_sched is no different from the standard (elevator) disk scheduler or tagged queueing -- these system may already serve queued requests out of order. if a client wants to enforce a specific ordering of requests it can easily do so by waiting the completion of a previous request before issuing a new one. From owner-freebsd-stable@FreeBSD.ORG Wed May 5 15:17:09 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id D7FFA1065673 for ; Wed, 5 May 2010 15:17:09 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta06.emeryville.ca.mail.comcast.net (qmta06.emeryville.ca.mail.comcast.net [76.96.30.56]) by mx1.freebsd.org (Postfix) with ESMTP id C05758FC2E for ; Wed, 5 May 2010 15:17:08 +0000 (UTC) Received: from omta15.emeryville.ca.mail.comcast.net ([76.96.30.71]) by qmta06.emeryville.ca.mail.comcast.net with comcast id Dns21e0011Y3wxoA6rH9dE; Wed, 05 May 2010 15:17:09 +0000 Received: from koitsu.dyndns.org ([98.248.46.159]) by omta15.emeryville.ca.mail.comcast.net with comcast id DrH81e00F3S48mS8brH8Rp; Wed, 05 May 2010 15:17:09 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 2BD139B425; Wed, 5 May 2010 08:17:07 -0700 (PDT) Date: Wed, 5 May 2010 08:17:07 -0700 From: Jeremy Chadwick To: Harald Schmalzbauer Message-ID: <20100505151707.GA68166@icarus.home.lan> References: <4BE16784.8050400@omnilan.de> <4BE18729.3050209@omnilan.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4BE18729.3050209@omnilan.de> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: FreeBSD Stable Subject: Re: ZFS (zpool) doesn't detect failed drive X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 May 2010 15:17:10 -0000 On Wed, May 05, 2010 at 04:56:41PM +0200, Harald Schmalzbauer wrote: > Harald Schmalzbauer schrieb am 05.05.2010 14:41 (localtime): > >Hello, > > > >one drive of my mirror failed today, but 'zpool staus' shows it "online". > >Every process using a ZFS mount hangs. Also 'zpool offline > >/dev/ad1' hangs infinitely. > ... > Sorry, I made an error with zpool create. Somehow the little word > "mirror" must have been lost. So the pool wasn't a mirror but a > stripe. Then of course I can't make one vdev offline. Sorry for the > noise. > But I took the opportunity to do some tests with that failing drive > and created a _real_ mirror. That works without failures, but using > the mirror again leads to: > ad1: TIMEOUT - FLUSHCACHE48 retrying (1 retry left) > ad1: TIMEOUT - FLUSHCACHE48 retrying (1 retry left) > ad1: TIMEOUT - FLUSHCACHE48 retrying (1 retry left) > ad1: TIMEOUT - FLUSHCACHE48 retrying (1 retry left) > ad1: TIMEOUT - FLUSHCACHE48 retrying (1 retry left) > ad1: TIMEOUT - FLUSHCACHE48 retrying (1 retry left) > ata3: port is not ready (timeout 10000ms) tfd = 00000080 > ata3: hardware reset timeout > ad1: FAILURE - device detached > > Now zpool reporsts the vdev ad1 still online although it has been > detached and 'atacontrol list' doesn't show it anymore: > > zpool status > pool: URUBAmirrorP1 > state: ONLINE > status: One or more devices has experienced an unrecoverable error. An > attempt was made to correct the error. Applications are > unaffected. > action: Determine if the device needs to be replaced, and clear the errors > using 'zpool clear' or replace the device with 'zpool replace'. > see: http://www.sun.com/msg/ZFS-8000-9P > scrub: none requested > config: > > NAME STATE READ WRITE CKSUM > URUBAmirrorP1 ONLINE 0 0 0 > mirror ONLINE 0 0 0 > ad1 ONLINE 3 302K 0 > ad2 ONLINE 0 0 0 > > errors: No known data errors > > atacontrol list > ATA channel 2: > Master: ad0 SATA revision 1.x > Slave: no device present > ATA channel 3: > Master: no device present > Slave: no device present > ATA channel 4: > Master: ad2 SATA revision 2.x > Slave: no device present > ATA channel 5: > Master: ad3 SATA revision 1.x > Slave: no device present > > How should such a failure be handled? > Do I have to manually mark the drive offline for zpool? You shouldn't have to; this should happen automatically when the underlying device goes away. GEOM should see the device gone, and ZFS should therefore be marking the pool as DEGRADED and the ad1 disk as FAULTED (or possibly OFFLINE). Is AHCI in use + enabled (in the BIOS) on this system? If not, I could see this being a potential problem but have no idea where it should be fixed. If AHCI is available/in use, can you try using ahci_load="yes" in /boot/loader.conf[1] to see if CAM handles this situation better? Quick atacontrol<-->camcontrol conversion chart: atacontrol list = camcontrol devlist atacontrol cap = camcontrol identify atacontrol detach = not needed AFAIK (just yank the disk) atacontrol attach = may not be needed, but if disk doesn't reappear try "camcontrol reset" or "camcontrol rescan" [1]: WARNING: this will change your device names from ad0->ada0, ad1->ada1, etc., so you may have to boot single-user and fix /etc/fstab. No need to mess with ZFS after the device naming changes; ZFS will taste metadata on all disks attached and automatically load the pools (one thing about ZFS I greatly appreciate. :-) ) -- | 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 May 5 15:17:14 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 5B25A106564A for ; Wed, 5 May 2010 15:17:14 +0000 (UTC) (envelope-from korvus@comcast.net) Received: from qmta11.emeryville.ca.mail.comcast.net (qmta11.emeryville.ca.mail.comcast.net [76.96.27.211]) by mx1.freebsd.org (Postfix) with ESMTP id 450598FC12 for ; Wed, 5 May 2010 15:17:14 +0000 (UTC) Received: from omta07.emeryville.ca.mail.comcast.net ([76.96.30.59]) by qmta11.emeryville.ca.mail.comcast.net with comcast id DpQQ1e0021GXsucABr45Yh; Wed, 05 May 2010 15:04:05 +0000 Received: from [192.168.2.164] ([206.210.89.202]) by omta07.emeryville.ca.mail.comcast.net with comcast id Dr3t1e0074Mx3R28Ur3wM6; Wed, 05 May 2010 15:04:02 +0000 Message-ID: <4BE188D8.3090301@comcast.net> Date: Wed, 05 May 2010 11:03:52 -0400 From: Steve Polyack User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.1.7) Gecko/20100311 Thunderbird/3.0.1 MIME-Version: 1.0 To: Harald Schmalzbauer References: <4BE16784.8050400@omnilan.de> <4BE18729.3050209@omnilan.de> In-Reply-To: <4BE18729.3050209@omnilan.de> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit Cc: FreeBSD Stable Subject: Re: ZFS (zpool) doesn't detect failed drive X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 May 2010 15:17:14 -0000 On 05/05/10 10:56, Harald Schmalzbauer wrote: > Harald Schmalzbauer schrieb am 05.05.2010 14:41 (localtime): >> Hello, >> >> one drive of my mirror failed today, but 'zpool staus' shows it >> "online". >> Every process using a ZFS mount hangs. Also 'zpool offline /dev/ad1' >> hangs infinitely. > ... > Sorry, I made an error with zpool create. Somehow the little word > "mirror" must have been lost. So the pool wasn't a mirror but a > stripe. Then of course I can't make one vdev offline. Sorry for the > noise. > But I took the opportunity to do some tests with that failing drive > and created a _real_ mirror. That works without failures, but using > the mirror again leads to: > ad1: TIMEOUT - FLUSHCACHE48 retrying (1 retry left) > ad1: TIMEOUT - FLUSHCACHE48 retrying (1 retry left) > ad1: TIMEOUT - FLUSHCACHE48 retrying (1 retry left) > ad1: TIMEOUT - FLUSHCACHE48 retrying (1 retry left) > ad1: TIMEOUT - FLUSHCACHE48 retrying (1 retry left) > ad1: TIMEOUT - FLUSHCACHE48 retrying (1 retry left) > ata3: port is not ready (timeout 10000ms) tfd = 00000080 > ata3: hardware reset timeout > ad1: FAILURE - device detached > > Now zpool reporsts the vdev ad1 still online although it has been > detached and 'atacontrol list' doesn't show it anymore: > > zpool status > pool: URUBAmirrorP1 > state: ONLINE > status: One or more devices has experienced an unrecoverable error. An > attempt was made to correct the error. Applications are > unaffected. > action: Determine if the device needs to be replaced, and clear the > errors > using 'zpool clear' or replace the device with 'zpool replace'. > see: http://www.sun.com/msg/ZFS-8000-9P > scrub: none requested > config: > > NAME STATE READ WRITE CKSUM > URUBAmirrorP1 ONLINE 0 0 0 > mirror ONLINE 0 0 0 > ad1 ONLINE 3 302K 0 > ad2 ONLINE 0 0 0 > > errors: No known data errors > > atacontrol list > ATA channel 2: > Master: ad0 SATA revision 1.x > Slave: no device present > ATA channel 3: > Master: no device present > Slave: no device present > ATA channel 4: > Master: ad2 SATA revision 2.x > Slave: no device present > ATA channel 5: > Master: ad3 SATA revision 1.x > Slave: no device present > > How should such a failure be handled? > Do I have to manually mark the drive offline for zpool? > > Thanks, > > -Harry > You may want to try newer controller drivers like ahci(4) if possible. Otherwise, building the kernel with ATA_CAM may accomplish something similar. I'm not sure, but I'm speculating that the newer ATA/CAM system may feed the proper notifications back to the ZFS systems. I use many drives on the siis(4) driver, which is CAM-enabled, and haven't had any issues. However, I have not had an outright drive failure. I do recall testing situations where we would yank a working drive, and I seem to remember it working correctly after the last set of CAM improvements. It may not be something you can try on a production system, but if you can experiment, it's worth a shot. Note that your device names WILL change to adaX instead of adX. I would definitely recommend you glabel(8) and create the zpool/zdevs using the glabel devices instead to circumvent any future problems associated with device numbering. Steve From owner-freebsd-stable@FreeBSD.ORG Wed May 5 15:19:34 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 585781065673 for ; Wed, 5 May 2010 15:19:34 +0000 (UTC) (envelope-from fjwcash@gmail.com) Received: from mail-iw0-f175.google.com (mail-iw0-f175.google.com [209.85.223.175]) by mx1.freebsd.org (Postfix) with ESMTP id 0EB0B8FC0C for ; Wed, 5 May 2010 15:19:33 +0000 (UTC) Received: by iwn5 with SMTP id 5so6268756iwn.9 for ; Wed, 05 May 2010 08:19:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:content-type; bh=C29gEfZQQpsprR6LC2LTqm3slJXBu8AepZc6rFNe0C8=; b=NWdXOJORZBxP0qRManeJuDYxmeejCl/YsmdB8dlf+kuDDPzGljrCzft7XAX79+YGw/ MT1VIE/vgQ7tDTM1j6OrufHuyF6IvaK762H3bYFCt6XNbRq/XX7hRPBJsBnqJtEnOC13 SfMbjDCfqq94xKYwL0fGXiTxA0uismbahG4NI= 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=SX2pRkOIeycr3kmagptFnz7hja1hYX9LzN4Tw6mDavp1mo3cXe8hn8u1QMDrIh/Hqs SyYJpFdfZlES7GDLhSnflnSWzdEZIq+Hp8GCeVszmvjoSrJkNloL7kGlzj8nQNeIbYMR O+EFAeBH26dnhM4XANxTia68cv2hSW5TQPhbI= MIME-Version: 1.0 Received: by 10.231.166.16 with SMTP id k16mr1840434iby.14.1273072763033; Wed, 05 May 2010 08:19:23 -0700 (PDT) Received: by 10.231.16.69 with HTTP; Wed, 5 May 2010 08:19:22 -0700 (PDT) In-Reply-To: <4BE110E3.8040902@zirakzigil.org> References: <4BDEA86E.3050109@zirakzigil.org> <20100503110100.GA93137@icarus.home.lan> <4BDEC106.3040807@zirakzigil.org> <4BE110E3.8040902@zirakzigil.org> Date: Wed, 5 May 2010 08:19:22 -0700 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: Freebsd 8.0 kmem map too small X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 05 May 2010 15:19:34 -0000 On Tue, May 4, 2010 at 11:32 PM, Giulio Ferro wrote: > Giulio Ferro wrote: > >> Thanks, I'll try these settings. >> >> I'll keep you posted. >> > > Nope, it's happened again... Now I've tried to rise vm.kmem_size to 6G... > I'm really astounded at how unstable zfs is, it's causing me a lot of > problem. > Why isn't it stated in the handbook that zfs isn't up to production yet? > As with everything related to computers, it all depends on your uses. We've been using FreeBSD+ZFS since it first hit 7.0 with very few problems. The first month of use required a lot of tuning and testing, though, to find the correct kmem, arc, etc settings for our workload. Once we found them, though, things have been rockstable. We rsync 120 remote Linux and FreeBSD servers to our 24-drive, 18 TB backup server, every night. And then rsync that to another similar server. And share out a couple of filesytems via NFS and another couple via Samba. Expect to spend a week or two to tune ZFS, and to rebuild the pool at least once to find the optimal vdev layout. But once that's done, expect it to be solid. -- Freddie Cash fjwcash@gmail.com From owner-freebsd-stable@FreeBSD.ORG Wed May 5 15:44:37 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 2B1F91065673 for ; Wed, 5 May 2010 15:44:37 +0000 (UTC) (envelope-from tevans.uk@googlemail.com) Received: from mail-fx0-f54.google.com (mail-fx0-f54.google.com [209.85.161.54]) by mx1.freebsd.org (Postfix) with ESMTP id B6CC98FC14 for ; Wed, 5 May 2010 15:44:36 +0000 (UTC) Received: by fxm15 with SMTP id 15so4846239fxm.13 for ; Wed, 05 May 2010 08:44:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:received:date:message-id :subject:from:to:content-type; bh=IUawA/fMiTtj5zs0UiGW6M54x1PbB2ZpLsMyPjuDcHg=; b=NntsyOo7jZn9Oq/WWQBBz4GNvsW5D3/lRpg4YzXlgfst6vQt2YuoqZYal37v0QsiT4 9lKJm+v/p9m3yDtlDNArvrBCsUIaZXKn5KgUUXPuJapv0jcXCjOe28xPtcsNOGC8rFl0 26R890Q5IB7wAG6vTCophw4o8ByWS5n78onyw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=vB6nRwYJXQS4RpsRHcH+tk23fIdd2Vq2djYTOrpHcRXatxdF1/D04ZaZ/BzUb3zNGW wSejcTWjaRW4/xH5cIoUkSNnwqp6MMY/7ePe7m7no455M5GNMyelcRBIe4S9QTHZ9C19 7//Nr6StGX6xhgIVJPa6NFPKbz890SQrIFv2Q= MIME-Version: 1.0 Received: by 10.239.183.138 with SMTP id u10mr700797hbg.65.1273074272083; Wed, 05 May 2010 08:44:32 -0700 (PDT) Received: by 10.239.142.17 with HTTP; Wed, 5 May 2010 08:44:32 -0700 (PDT) Date: Wed, 5 May 2010 16:44:32 +0100 Message-ID: From: Tom Evans To: FreeBSD Stable Content-Type: text/plain; charset=UTF-8 Subject: Different sizes between zfs list and zpool list X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 05 May 2010 15:44:37 -0000 Hi all When looking at the size of a pool, this information can be got from both zpool list and zfs list: > $ zfs list NAME USED AVAIL REFER MOUNTPOINT tank 5.69T 982G 36.5K /tank > $ zpool list NAME SIZE USED AVAIL CAP HEALTH ALTROOT tank 8.14T 6.86T 1.28T 84% ONLINE - Why the different sizes? The pool is a raidz of 6 x 1.5 TB drives. Cheers Tom From owner-freebsd-stable@FreeBSD.ORG Wed May 5 15:57:02 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id CD2961065670 for ; Wed, 5 May 2010 15:57:02 +0000 (UTC) (envelope-from fjwcash@gmail.com) Received: from mail-gw0-f54.google.com (mail-gw0-f54.google.com [74.125.83.54]) by mx1.freebsd.org (Postfix) with ESMTP id 887C38FC08 for ; Wed, 5 May 2010 15:57:02 +0000 (UTC) Received: by gwj21 with SMTP id 21so2472022gwj.13 for ; Wed, 05 May 2010 08:56:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:content-type; bh=u8kDrBxKCdvxHW3YFi73Zmn5S91TwzMuBjptHvJkazo=; b=HEBCQ1eAfdM3r/NoqESYYHNMJq3QDgwwkSWCnBy4pml6dEA7DyXKtlXuTYGnZIAxZ8 fwtXPmPvqgr430e4C/n77cgA/3NBS8ghzxaetEl4kWEPpm/lrjXDobsPMWyvA6UQcPZs rNdhZHojXVsFNOeI8s4PYrwUsKJfSz2Jsb2Ms= 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=JUCnGRaKENFbA5dZlQdELlG3kPdBe3gBU0OIohkKosi6BfFPZGL4lgQw0gI9o5VPbA w78RvkhLNtUC6nENI4k5YK/Apba8nMgGQZ1fyVizV2gpMl9zMVBmw7Ljo/WmzkIWG0D7 6D+FV+/AgfFiEEfVzq6B3r5WuVHbGoVZa/2lM= MIME-Version: 1.0 Received: by 10.231.59.203 with SMTP id m11mr1166175ibh.72.1273075018911; Wed, 05 May 2010 08:56:58 -0700 (PDT) Received: by 10.231.16.69 with HTTP; Wed, 5 May 2010 08:56:58 -0700 (PDT) In-Reply-To: References: Date: Wed, 5 May 2010 08:56:58 -0700 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: Different sizes between zfs list and zpool list X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 05 May 2010 15:57:03 -0000 On Wed, May 5, 2010 at 8:44 AM, Tom Evans wrote: > When looking at the size of a pool, this information can be got from > both zpool list and zfs list: > > > $ zfs list > NAME USED AVAIL REFER MOUNTPOINT > tank 5.69T 982G 36.5K /tank > > > $ zpool list > NAME SIZE USED AVAIL CAP HEALTH ALTROOT > tank 8.14T 6.86T 1.28T 84% ONLINE - > > Why the different sizes? > The pool is a raidz of 6 x 1.5 TB drives. > zpool lists the raw storage available to the pool. Every single bit of every single drive is listed here. This will be 6 x 1 TB. zfs lists only the amount of storage available to be used, after all redundancy is taken into account. This will be 5 x 1 TB. -- Freddie Cash fjwcash@gmail.com From owner-freebsd-stable@FreeBSD.ORG Wed May 5 15:58:35 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id F02B6106564A for ; Wed, 5 May 2010 15:58:35 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta13.westchester.pa.mail.comcast.net (qmta13.westchester.pa.mail.comcast.net [76.96.59.243]) by mx1.freebsd.org (Postfix) with ESMTP id 9FDA38FC0A for ; Wed, 5 May 2010 15:58:35 +0000 (UTC) Received: from omta19.westchester.pa.mail.comcast.net ([76.96.62.98]) by qmta13.westchester.pa.mail.comcast.net with comcast id Dmwu1e00527AodY5Drybum; Wed, 05 May 2010 15:58:35 +0000 Received: from koitsu.dyndns.org ([98.248.46.159]) by omta19.westchester.pa.mail.comcast.net with comcast id Drya1e00D3S48mS3frybKG; Wed, 05 May 2010 15:58:35 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 4FF379B42E; Wed, 5 May 2010 08:58:33 -0700 (PDT) Date: Wed, 5 May 2010 08:58:33 -0700 From: Jeremy Chadwick To: Tom Evans Message-ID: <20100505155833.GA69377@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) Cc: FreeBSD Stable Subject: Re: Different sizes between zfs list and zpool list X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 05 May 2010 15:58:36 -0000 On Wed, May 05, 2010 at 04:44:32PM +0100, Tom Evans wrote: > When looking at the size of a pool, this information can be got from > both zpool list and zfs list: > > > $ zfs list > NAME USED AVAIL REFER MOUNTPOINT > tank 5.69T 982G 36.5K /tank > > > $ zpool list > NAME SIZE USED AVAIL CAP HEALTH ALTROOT > tank 8.14T 6.86T 1.28T 84% ONLINE - > > Why the different sizes? > > The pool is a raidz of 6 x 1.5 TB drives. Is the tank filesystem using compression? "zfs get all" would help shed some light here. There is some variance in AVAIL on all of our systems, and I see identical on Solaris 10. My guess is (the equivalent of) parity of raidz has something to do with it. However, in the case of our systems, USED always matches between zfs list and zpool list. -- | 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 May 5 16:08:11 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 1EDAE1065670 for ; Wed, 5 May 2010 16:08:11 +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 C1E508FC1D for ; Wed, 5 May 2010 16:08:10 +0000 (UTC) Received: from omta13.westchester.pa.mail.comcast.net ([76.96.62.52]) by qmta12.westchester.pa.mail.comcast.net with comcast id Dm9l1e00517dt5G5Cs8BKA; Wed, 05 May 2010 16:08:11 +0000 Received: from koitsu.dyndns.org ([98.248.46.159]) by omta13.westchester.pa.mail.comcast.net with comcast id Ds891e00m3S48mS3Zs8AZD; Wed, 05 May 2010 16:08:11 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id A6BFD9B425; Wed, 5 May 2010 09:08:08 -0700 (PDT) Date: Wed, 5 May 2010 09:08:08 -0700 From: Jeremy Chadwick To: Tom Evans Message-ID: <20100505160808.GA69687@icarus.home.lan> References: <20100505155833.GA69377@icarus.home.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100505155833.GA69377@icarus.home.lan> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: FreeBSD Stable Subject: Re: Different sizes between zfs list and zpool list X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 05 May 2010 16:08:11 -0000 On Wed, May 05, 2010 at 08:58:33AM -0700, Jeremy Chadwick wrote: > On Wed, May 05, 2010 at 04:44:32PM +0100, Tom Evans wrote: > > When looking at the size of a pool, this information can be got from > > both zpool list and zfs list: > > > > > $ zfs list > > NAME USED AVAIL REFER MOUNTPOINT > > tank 5.69T 982G 36.5K /tank > > > > > $ zpool list > > NAME SIZE USED AVAIL CAP HEALTH ALTROOT > > tank 8.14T 6.86T 1.28T 84% ONLINE - > > > > Why the different sizes? > > > > The pool is a raidz of 6 x 1.5 TB drives. > > Is the tank filesystem using compression? "zfs get all" would help shed > some light here. > > There is some variance in AVAIL on all of our systems, and I see > identical on Solaris 10. My guess is (the equivalent of) parity of > raidz has something to do with it. > > However, in the case of our systems, USED always matches between zfs > list and zpool list. I should have provided some actual sample data to back this up. I only checked one of our systems, which uses mirror. Here's a better sample set. Some of these use the 'quota' property, but none use compression. host1$ zfs list NAME USED AVAIL REFER MOUNTPOINT data 4.49G 681G 18K none data/home 793M 681G 793M /home data/storage 3.72G 681G 3.72G /storage host1$ zpool list NAME SIZE USED AVAIL CAP HEALTH ALTROOT data 696G 4.49G 692G 0% ONLINE - host1$ zpool status ... NAME STATE READ WRITE CKSUM data ONLINE 0 0 0 ad6 ONLINE 0 0 0 host2$ zfs list NAME USED AVAIL REFER MOUNTPOINT data 312G 1.48T 24.0K none data/backups 312G 1.48T 312G /backups data/home 48.0K 256G 48.0K /home host2$ zpool list NAME SIZE USED AVAIL CAP HEALTH ALTROOT data 2.72T 469G 2.26T 16% ONLINE - host2$ zpool status ... NAME STATE READ WRITE CKSUM data ONLINE 0 0 0 raidz1 ONLINE 0 0 0 ada1 ONLINE 0 0 0 ada2 ONLINE 0 0 0 ada3 ONLINE 0 0 0 host3$ zfs list NAME USED AVAIL REFER MOUNTPOINT pool 45.5G 175G 45.4G /home host3$ zpool list NAME SIZE USED AVAIL CAP HEALTH ALTROOT pool 224G 45.5G 179G 20% ONLINE - host3$ zpool status ... NAME STATE READ WRITE CKSUM pool ONLINE 0 0 0 mirror ONLINE 0 0 0 ad4s1g ONLINE 0 0 0 ad6 ONLINE 0 0 0 host4$ zfs list NAME USED AVAIL REFER MOUNTPOINT data 250G 664G 18K none data/cvs 299K 8.00G 299K /cvs data/home 643M 15.4G 643M /home data/storage 249G 664G 249G /storage host4$ zpool list NAME SIZE USED AVAIL CAP HEALTH ALTROOT data 928G 250G 678G 26% ONLINE - host4$ zpool status ... NAME STATE READ WRITE CKSUM data ONLINE 0 0 0 mirror ONLINE 0 0 0 ada1 ONLINE 0 0 0 ada2 ONLINE 0 0 0 So in summary, Freddie's explanation sounds spot 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 Wed May 5 16:20:15 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 1235C1065679 for ; Wed, 5 May 2010 16:20:15 +0000 (UTC) (envelope-from tevans.uk@googlemail.com) Received: from mail-fx0-f54.google.com (mail-fx0-f54.google.com [209.85.161.54]) by mx1.freebsd.org (Postfix) with ESMTP id 9436E8FC21 for ; Wed, 5 May 2010 16:20:14 +0000 (UTC) Received: by fxm15 with SMTP id 15so4883128fxm.13 for ; Wed, 05 May 2010 09:20:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=tf/9pcYKrSMrjcjbio7BcL5rjKjGEiPv0/2dUQ1Lvvk=; b=HoPAJUqxhrYfxRBgF131KcWJrG3LoqAEKDDLQ8y+hVG/D+PqlNqeQzw4gPB+0oDHp8 Azt0+XeBcyZgOiIRkwdiVUxn/7yTZbqqiY/Se1vQxqcVdd+6Mr4hek4P+gvz9bmpouj5 iSL1Mo4camTi/L2uoR/EX5T7ZOsj08+lcWIj0= 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:content-transfer-encoding; b=Byx1g0oHjG3JwzMgGV8stp8SksuuWTs0L7kewHxBidypuHLjOdefRdEzj9d7H3gppf LyOvv0RKschUKWLxdRgKfJYj9wK/QaaHHYGt9XXy6wAs4egCSmts8YgzOgXlSIX8dPfN EM/FeGZ9iwgEUVysN+tHFPA/+FHIPuPFmZqWs= MIME-Version: 1.0 Received: by 10.239.132.145 with SMTP id 17mr942187hbr.177.1273076407126; Wed, 05 May 2010 09:20:07 -0700 (PDT) Received: by 10.239.142.17 with HTTP; Wed, 5 May 2010 09:20:06 -0700 (PDT) In-Reply-To: References: Date: Wed, 5 May 2010 17:20:06 +0100 Message-ID: From: Tom Evans To: Freddie Cash Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: FreeBSD Stable Subject: Re: Different sizes between zfs list and zpool list X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 05 May 2010 16:20:15 -0000 On Wed, May 5, 2010 at 4:56 PM, Freddie Cash wrote: > On Wed, May 5, 2010 at 8:44 AM, Tom Evans wrot= e: > >> When looking at the size of a pool, this information can be got from >> both zpool list and zfs list: >> >> > $ zfs list >> NAME =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 USED =C2=A0AVAIL =C2=A0REFER =C2=A0MOUNTPOINT >> tank =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A05.69T =C2=A0 982G =C2=A036.5K =C2=A0/tank >> >> > $ zpool list >> NAME =C2=A0 SIZE =C2=A0 USED =C2=A0AVAIL =C2=A0 =C2=A0CAP =C2=A0HEALTH = =C2=A0ALTROOT >> tank =C2=A08.14T =C2=A06.86T =C2=A01.28T =C2=A0 =C2=A084% =C2=A0ONLINE = =C2=A0- >> >> Why the different sizes? >> The pool is a raidz of 6 x 1.5 TB drives. >> > > zpool lists the raw storage available to the pool. =C2=A0Every single bit= of > every single drive is listed here. =C2=A0This will be 6 x 1 TB. > > zfs lists only the amount of storage available to be used, after all > redundancy is taken into account. =C2=A0This will be 5 x 1 TB. > > -- > Freddie Cash > fjwcash@gmail.com Ah, that makes sense - also explains why the df output matches up precisely with the zfs list output. Thanks Tom From owner-freebsd-stable@FreeBSD.ORG Wed May 5 16:29:04 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id DE091106566C for ; Wed, 5 May 2010 16:29:04 +0000 (UTC) (envelope-from fjwcash@gmail.com) Received: from mail-yw0-f181.google.com (mail-yw0-f181.google.com [209.85.211.181]) by mx1.freebsd.org (Postfix) with ESMTP id 974298FC0A for ; Wed, 5 May 2010 16:29:04 +0000 (UTC) Received: by ywh11 with SMTP id 11so2360705ywh.7 for ; Wed, 05 May 2010 09:29:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:content-type; bh=0R2nQoo+z4NenRSCp8xobOwEw6fvQU9WqaSm6dicLos=; b=KgSUG9+taS3AMjNUf6w3KOnzNZ4UTYgX005iV41jpzAAaSylcKXCYVoA5Mx1i3ERkN kR/O3I3sSnusgEFtXFmCVmUy7esOddXhMVQPRITEAcuA5aUZcjlJtl9Lbqqqlo+icmp7 aaK4uUezJ/nQNvrKlwzwJsX7jXHob3Gm+8sUA= 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=uiCQXe9AZP9JWj9tIPFkd0IEAI4kZz/Dqu8viIT5RjWgj+IBYM1AAI9tMu8+KnZQd+ +Kcr6QZ1wggmcCg1vTIQZTfyjoIhQFFr9Ie5G8I5EpkSTM3novSqN+OUIuJee1WMXvwQ wm/WKno4F7ibAyDqtD/tZZSSo6IxRBotmBRMo= MIME-Version: 1.0 Received: by 10.231.168.1 with SMTP id s1mr945210iby.84.1273076934488; Wed, 05 May 2010 09:28:54 -0700 (PDT) Received: by 10.231.16.69 with HTTP; Wed, 5 May 2010 09:28:54 -0700 (PDT) In-Reply-To: References: Date: Wed, 5 May 2010 09:28:54 -0700 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: Different sizes between zfs list and zpool list X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 05 May 2010 16:29:04 -0000 On Wed, May 5, 2010 at 9:20 AM, Tom Evans wrote: > On Wed, May 5, 2010 at 4:56 PM, Freddie Cash wrote: > > On Wed, May 5, 2010 at 8:44 AM, Tom Evans > wrote: > > > >> When looking at the size of a pool, this information can be got from > >> both zpool list and zfs list: > >> > >> > $ zfs list > >> NAME USED AVAIL REFER MOUNTPOINT > >> tank 5.69T 982G 36.5K /tank > >> > >> > $ zpool list > >> NAME SIZE USED AVAIL CAP HEALTH ALTROOT > >> tank 8.14T 6.86T 1.28T 84% ONLINE - > >> > >> Why the different sizes? > >> The pool is a raidz of 6 x 1.5 TB drives. > >> > > > > zpool lists the raw storage available to the pool. Every single bit of > > every single drive is listed here. This will be 6 x 1 TB. > > > > zfs lists only the amount of storage available to be used, after all > > redundancy is taken into account. This will be 5 x 1 TB. > > Ah, that makes sense - also explains why the df output matches up > precisely with the zfs list output. > Things get really interesting once you enable compression on a filesystem, as then du, df, and zfs list will all be different. :) There's a great post on the zfs-discuss mailing list that covers this. I'll see if I can dig it up. -- Freddie Cash fjwcash@gmail.com From owner-freebsd-stable@FreeBSD.ORG Wed May 5 16:36:23 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 093C6106564A for ; Wed, 5 May 2010 16:36:23 +0000 (UTC) (envelope-from fjwcash@gmail.com) Received: from mail-gy0-f182.google.com (mail-gy0-f182.google.com [209.85.160.182]) by mx1.freebsd.org (Postfix) with ESMTP id B4C6E8FC14 for ; Wed, 5 May 2010 16:36:22 +0000 (UTC) Received: by gyh20 with SMTP id 20so2496996gyh.13 for ; Wed, 05 May 2010 09:36:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:content-type; bh=A1Axgwi6kl/MtCKIOn6t4tPKqQzfUFBVLIL5ghYL+xc=; b=Tb+xLu5QvkCQN1EwnItOaAP9VKuZdL+fSfFR0CMTtZDESmiboQRLeQ7TzTBeUPm7Sh SOuh0YMKEq4WhKyN6jyiUYIwx+I54//qUmjcvftSfbtBUn7jkvxNWRqCjcom0ZVwVOqd WcGSOlxpMtEERh3bLyJeHEY/8M0yuP4TUqzeY= 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=ahrInoGMK2VM6l0O7SJeSap+vXqcuh0taQnd8XPCiXtoMYQwlVP4B5LckGpTo++rz0 a1m0K/YcR5G1ftxuRY2hF339LHrqZQ4djsVVfxhzBOVBE6j8JOZIeDVI4/MY7r1H1zE6 O2H6MZSLOoN62Cbi0mEesRxqfreu+di0ukmis= MIME-Version: 1.0 Received: by 10.231.172.210 with SMTP id m18mr204573ibz.21.1273077358430; Wed, 05 May 2010 09:35:58 -0700 (PDT) Received: by 10.231.16.69 with HTTP; Wed, 5 May 2010 09:35:58 -0700 (PDT) In-Reply-To: References: Date: Wed, 5 May 2010 09:35:58 -0700 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: Different sizes between zfs list and zpool list X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 05 May 2010 16:36:23 -0000 On Wed, May 5, 2010 at 9:28 AM, Freddie Cash wrote: > On Wed, May 5, 2010 at 9:20 AM, Tom Evans wrote: > >> On Wed, May 5, 2010 at 4:56 PM, Freddie Cash wrote: >> > On Wed, May 5, 2010 at 8:44 AM, Tom Evans >> wrote: >> > >> >> When looking at the size of a pool, this information can be got from >> >> both zpool list and zfs list: >> >> >> >> > $ zfs list >> >> NAME USED AVAIL REFER MOUNTPOINT >> >> tank 5.69T 982G 36.5K /tank >> >> >> >> > $ zpool list >> >> NAME SIZE USED AVAIL CAP HEALTH ALTROOT >> >> tank 8.14T 6.86T 1.28T 84% ONLINE - >> >> >> >> Why the different sizes? >> >> The pool is a raidz of 6 x 1.5 TB drives. >> >> >> > >> > zpool lists the raw storage available to the pool. Every single bit of >> > every single drive is listed here. This will be 6 x 1 TB. >> > >> > zfs lists only the amount of storage available to be used, after all >> > redundancy is taken into account. This will be 5 x 1 TB. >> >> Ah, that makes sense - also explains why the df output matches up >> precisely with the zfs list output. >> > > Things get really interesting once you enable compression on a filesystem, > as then du, df, and zfs list will all be different. :) > > There's a great post on the zfs-discuss mailing list that covers this. > I'll see if I can dig it up. > >From a message by Will Murnane to zfs-discuss (in response to Harry Putnam): ------BEGIN QUOTE------ On Sun, Apr 18, 2010 at 20:08, Harry Putnam wrote: > Seems like you can get some pretty large discrepancies in sizes of > pools. and directories. They all answer different things, sure, but they're all things that an administrator might want to know. > zpool list "How many bytes are in use on the storage device? How many unallocated bytes are there?" > zfs list "If I have to ship this filesystem to another box (uncompressed and not deduped) how many bytes is that?" > du "How many bytes are used to store the contents of the files in this directory?" and "ls -l": "How many bytes are addressable in this file?" > Do no other administrators feel the > need to know accurate sizes? It's important to consider what you want this data for. Considering upgrading your storage to get more room? Check out "zpool list". Need to know whether accounting or engineering is using more space? Look at "zfs list". Looking at a sparse or compressed file, and want to know how many bytes are allocated to it? "du" does the trick. Planning to email someone a file, and want to know if it'll fit in their 10MB quota? "ls -l" is the relevant command. In short, there are many commands because there are many answers, and many questions. No single tool has all the information available to it. ------END QUOTE------ IOW zpool shows the total bytes of storage available in the pool. zfs shows the total bytes of storage available to the filesystem, after redundancy is taken into account. du shows the total bytes of storage used by a directory, after compression and dedupe is taken into account. "ls -l" shows the total bytes of storage currently used to store a file, after compression, dedupe, thin-provisioning, sparseness, etc. -- Freddie Cash fjwcash@gmail.com From owner-freebsd-stable@FreeBSD.ORG Wed May 5 21:07:19 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 7E435106564A for ; Wed, 5 May 2010 21:07:19 +0000 (UTC) (envelope-from giovanni.trematerra@gmail.com) Received: from mail-fx0-f54.google.com (mail-fx0-f54.google.com [209.85.161.54]) by mx1.freebsd.org (Postfix) with ESMTP id D39B28FC12 for ; Wed, 5 May 2010 21:07:18 +0000 (UTC) Received: by fxm15 with SMTP id 15so5123357fxm.13 for ; Wed, 05 May 2010 14:07:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=5PyJYnVgS0n4JXW6vsRgF6/a89bnv5kuWwcjINiLxpQ=; b=lGHO8yPSLSb9E473G8KQNSE0HQFjrn/y9NhvakzA/InhE1tJroUquI0nm4M32uClh/ hi1Qct4ToyRmG4aWugdKDtgFEzrDPshMfBOErcj8B84J1Tk9ZBKZjNx/JZELW2nv5BpD lch4YXT5yWV1K5DK2q4tipx7OrXyzABdQkkxM= 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=G/50butlIuIPRDWsyWFj892k6knGYD2GQkDJZUGwFXO1uC8gWAu4DRWjFdq7G/4CQc rNQ6FgX5QcLWAsmje8oEoa0WSBEZ+Yv+Jl1A2B/CB2f8+1cLfEACElnlMtp5U8Q8CgoJ cgkVZKmaiE8bRymg0HxG2waVP3pBM8BK8NdmU= MIME-Version: 1.0 Received: by 10.223.24.130 with SMTP id v2mr5870071fab.61.1273093630393; Wed, 05 May 2010 14:07:10 -0700 (PDT) Received: by 10.223.103.209 with HTTP; Wed, 5 May 2010 14:07:10 -0700 (PDT) In-Reply-To: <20100505135743.GA1613@Melon.malikania.fr> References: <20100504200139.GP23646@deviant.kiev.zoral.com.ua> <20100504203809.GR23646@deviant.kiev.zoral.com.ua> <42ACDAF6-7EA9-4CE9-AA8D-FDA678A1EA74@FreeBSD.org> <20100505074045.GA28030@Abricot.malikania.fr> <4DEBDE2C-C0D2-469D-AC42-DD5027926424@FreeBSD.org> <20100505110332.GA1578@Melon.malikania.fr> <96F538BA-488A-46B3-99A0-BC324DB0F73A@FreeBSD.org> <20100505135743.GA1613@Melon.malikania.fr> Date: Wed, 5 May 2010 23:07:10 +0200 Message-ID: From: Giovanni Trematerra To: Demelier David Content-Type: text/plain; charset=ISO-8859-1 Cc: Kostik Belousov , freebsd-stable@freebsd.org, freebsd-acpi@freebsd.org, Rui Paulo Subject: Re: Kernel panic when unpluggin AC adaptor X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 05 May 2010 21:07:19 -0000 Would you be so kind to try to revert this patch? I'm just guessing You have to pass -R flag to patch program to apply the patch ========================= --- head/sys/dev/acpica/acpi_acad.c 2009/06/05 18:44:36 193530 +++ head/sys/dev/acpica/acpi_acad.c 2009/09/30 17:07:49 197649 @@ -109,13 +109,14 @@ ACPI_SERIAL_BEGIN(acad); if (newstatus != -1 && sc->status != newstatus) { sc->status = newstatus; + ACPI_SERIAL_END(acad); power_profile_set_state(newstatus ? POWER_PROFILE_PERFORMANCE : POWER_PROFILE_ECONOMY); ACPI_VPRINT(dev, acpi_device_get_parent_softc(dev), "%s Line\n", newstatus ? "On" : "Off"); acpi_UserNotify("ACAD", h, newstatus); - } - ACPI_SERIAL_END(acad); + } else + ACPI_SERIAL_END(acad); } static void From owner-freebsd-stable@FreeBSD.ORG Wed May 5 21:19:45 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 6C947106564A for ; Wed, 5 May 2010 21:19:45 +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 E769A8FC1C for ; Wed, 5 May 2010 21:19:44 +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 o45LJhVT082267 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 5 May 2010 23:19:43 +0200 (CEST) (envelope-from h.schmalzbauer@omnilan.de) Message-ID: <4BE1E0DD.6070107@omnilan.de> Date: Wed, 05 May 2010 23:19:25 +0200 From: Harald Schmalzbauer Organization: OmniLAN User-Agent: Thunderbird 2.0.0.23 (X11/20090906) MIME-Version: 1.0 To: Jack Vogel References: <4BC82B80.3070108@omnilan.de> <20100416092803.GA17526@icarus.home.lan> <4BC82FF7.1030700@omnilan.de> <201004160822.09359.jhb@freebsd.org> <4BC8A76A.6000107@omnilan.de> <4BC8CB9E.8060802@omnilan.de> <4BD75D2E.50302@omnilan.de> In-Reply-To: X-Enigmail-Version: 0.95.6 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig9CBEA88FF2495A0EE6372B5E" Cc: freebsd-stable@freebsd.org Subject: Re: em WOL_MCAST repowers machine after poweroff [Was: Re: em JumboFrame improovement and PCIe addon-card regression] X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 05 May 2010 21:19:45 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig9CBEA88FF2495A0EE6372B5E Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Jack Vogel schrieb am 27.04.2010 23:58 (localtime): > Thanks Harald, >=20 > Have already been made aware of this, its due to the broadcast WOL bein= g=20 > enabled, I will be > fixing the problem shortly. Sorry for the inconvenience. Hello Jack, I saw your RELENG_8 change and recompiled one kernel today. It seems=20 that you only disabled WOL_*CAST for 7.0.5 adapters. Here's one=20 S3200SHLX board, which has two onboard nics (em0 with WOL_*CAST disabled = and em1 with WOL_* enabled): em0: port 0x30e0-0x30ff mem = 0xe1b00000-0xe1b1ffff,0xe1b20000-0xe1b20fff irq 20 at device 25.0 on pci0= em0: Using MSI interrupt em0: flags=3D8843 metric 0 mtu 15= 00 options=3D219b em1: port=20 0x1000-0x103f mem 0xe1920000-0xe193ffff,0xe1900000-0xe191ffff irq 18 at=20 device 2.0 on pci4 em1: flags=3D8843 metric 0 mtu=20 1500=20 options=3D389b I set this options manually on another box and with these em1 settings=20 the machine powers up immediately. But I have a much more severe problem: I disabled WOL_MCAST with ifconfig for one of my cold-standby machines.=20 But the machine doesn't wake up any more, even if I can see the WOL=20 packets arriving at the NIC (LED blinks). Since the machine also doesn't power up on WOL when shutted down via=20 ESXi I thought that was an issue with BIOS49, which I recently upgraded=20 to. I filed an intel reseller case -> status still in progress. Is it possible that the new code also broke intentionally WOL events? Thanks, -Harry --------------enig9CBEA88FF2495A0EE6372B5E 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) iEYEARECAAYFAkvh4O8ACgkQLDqVQ9VXb8jkogCghNOs2zmxTpGcpjEKgYz0RHYR ffoAoJVSAQDhBLHUqZeK9bnTfTty/2gc =xj7c -----END PGP SIGNATURE----- --------------enig9CBEA88FF2495A0EE6372B5E-- From owner-freebsd-stable@FreeBSD.ORG Wed May 5 21:53:26 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 4A2CE106566B for ; Wed, 5 May 2010 21:53:26 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: from mail-wy0-f182.google.com (mail-wy0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id C8DDA8FC15 for ; Wed, 5 May 2010 21:53:25 +0000 (UTC) Received: by wyf23 with SMTP id 23so1225845wyf.13 for ; Wed, 05 May 2010 14:53:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=EodXkX6G7jlcglFRZWwuYWKnP3+iNCcSLmh2Gx2P6ck=; b=nyDoeQzCpKWrVhc9F7vqw6lDt7yTEAL+ocuUstwarDOi4pRsQKZ4aIUm6v2IzXOfMg +Lu+y1swB4pZjN0FTSfB2iFO/RqaNXAtwEVsLZY1wNNH9TCEAK2A3LmQ1rCwAmkYIZ6E gHF8gMKDgaBTAgNmZXr/OzCQRJ6RTP0D9G2gQ= 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=SJpxi9KP7jxmnLg5f6832Cv9BSbkFZbU8bc1YhQEhiXQ41cteodxS6plnGFbtpPJyb 8dBzPNLsA7Aw1F4S55h9XZ/1ADdcL6qYGomm//ccz0V9XGv2OQiZ8xTwULzW/1Vyj7M0 m9yyxRdZzAqMeRifh6q4Psx5vZ8LLHvVmnAl4= MIME-Version: 1.0 Received: by 10.216.86.129 with SMTP id w1mr2318476wee.174.1273096394769; Wed, 05 May 2010 14:53:14 -0700 (PDT) Received: by 10.216.29.129 with HTTP; Wed, 5 May 2010 14:53:14 -0700 (PDT) In-Reply-To: <4BE1E0DD.6070107@omnilan.de> References: <4BC82B80.3070108@omnilan.de> <201004160822.09359.jhb@freebsd.org> <4BC8A76A.6000107@omnilan.de> <4BC8CB9E.8060802@omnilan.de> <4BD75D2E.50302@omnilan.de> <4BE1E0DD.6070107@omnilan.de> Date: Wed, 5 May 2010 14:53:14 -0700 Message-ID: From: Jack Vogel To: Harald Schmalzbauer Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-stable@freebsd.org Subject: Re: em WOL_MCAST repowers machine after poweroff [Was: Re: em JumboFrame improovement and PCIe addon-card regression] X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 05 May 2010 21:53:26 -0000 Oppps, forgot about the lem case, sorry, and here I made lem so i wouldnt have to touch that code, lol :) As for WOL not working at all, that's something I'll have to check on. Jack On Wed, May 5, 2010 at 2:19 PM, Harald Schmalzbauer < h.schmalzbauer@omnilan.de> wrote: > Jack Vogel schrieb am 27.04.2010 23:58 (localtime): > > Thanks Harald, >> >> Have already been made aware of this, its due to the broadcast WOL being >> enabled, I will be >> fixing the problem shortly. Sorry for the inconvenience. >> > > Hello Jack, > > I saw your RELENG_8 change and recompiled one kernel today. It seems that > you only disabled WOL_*CAST for 7.0.5 adapters. Here's one S3200SHLX board, > which has two onboard nics (em0 with WOL_*CAST disabled and em1 with WOL_* > enabled): > > em0: port 0x30e0-0x30ff mem > 0xe1b00000-0xe1b1ffff,0xe1b20000-0xe1b20fff irq 20 at device 25.0 on pci0 > em0: Using MSI interrupt > em0: flags=8843 metric 0 mtu 1500 > > options=219b > > em1: port 0x1000-0x103f > mem 0xe1920000-0xe193ffff,0xe1900000-0xe191ffff irq 18 at device 2.0 on pci4 > em1: flags=8843 metric 0 mtu 1500 > options=389b > > I set this options manually on another box and with these em1 settings the > machine powers up immediately. > But I have a much more severe problem: > I disabled WOL_MCAST with ifconfig for one of my cold-standby machines. But > the machine doesn't wake up any more, even if I can see the WOL packets > arriving at the NIC (LED blinks). > Since the machine also doesn't power up on WOL when shutted down via ESXi I > thought that was an issue with BIOS49, which I recently upgraded to. I filed > an intel reseller case -> status still in progress. > Is it possible that the new code also broke intentionally WOL events? > > Thanks, > > -Harry > > From owner-freebsd-stable@FreeBSD.ORG Thu May 6 02:45:39 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id AC59B106564A for ; Thu, 6 May 2010 02:45:39 +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 26F098FC0A for ; Thu, 6 May 2010 02:45:38 +0000 (UTC) Received: from ur.gsoft.com.au (Ur.gsoft.com.au [203.31.81.44]) (authenticated bits=0) by cain.gsoft.com.au (8.14.4/8.14.3) with ESMTP id o462jGrv042917 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 6 May 2010 12:15:21 +0930 (CST) (envelope-from doconnor@gsoft.com.au) Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii From: "Daniel O'Connor" In-Reply-To: <4BE188D8.3090301@comcast.net> Date: Thu, 6 May 2010 12:15:15 +0930 Content-Transfer-Encoding: quoted-printable Message-Id: <41F1859A-4C53-4D39-8B53-B2994954D772@gsoft.com.au> References: <4BE16784.8050400@omnilan.de> <4BE18729.3050209@omnilan.de> <4BE188D8.3090301@comcast.net> To: Steve Polyack X-Mailer: Apple Mail (2.1078) X-Spam-Score: -2.51 () ALL_TRUSTED,BAYES_00,T_RP_MATCHES_RCVD X-Scanned-By: MIMEDefang 2.67 on 203.31.81.10 Cc: Harald Schmalzbauer , FreeBSD Stable Subject: Re: ZFS (zpool) doesn't detect failed drive X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 May 2010 02:45:39 -0000 On 06/05/2010, at 12:33, Steve Polyack wrote: > It may not be something you can try on a production system, but if you = can experiment, it's worth a shot. Note that your device names WILL = change to adaX instead of adX. I would definitely recommend you = glabel(8) and create the zpool/zdevs using the glabel devices instead to = circumvent any future problems associated with device numbering. If you partitioned them with GPT then you can use GPT IDs :) -- 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 Thu May 6 09:09:41 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id AA92B1065677 for ; Thu, 6 May 2010 09:09:41 +0000 (UTC) (envelope-from michal@ionic.co.uk) Received: from mail1.sharescope.co.uk (pm1.ionic.co.uk [85.159.80.19]) by mx1.freebsd.org (Postfix) with ESMTP id 3EE0C8FC12 for ; Thu, 6 May 2010 09:09:40 +0000 (UTC) Received: from localhost (unknown [127.0.0.1]) by mail1.sharescope.co.uk (Postfix) with ESMTP id E751EFC0AF for ; Thu, 6 May 2010 09:09:39 +0000 (UTC) X-Virus-Scanned: amavisd-new at sharescope.co.uk Received: from mail1.sharescope.co.uk ([127.0.0.1]) by localhost (mail1.sharescope.co.uk [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xz9NUFhI27Qo for ; Thu, 6 May 2010 10:09:35 +0100 (BST) Received: from [192.168.2.37] (office.ionic.co.uk [85.159.85.2]) (Authenticated sender: chris@sharescope.co.uk) by mail1.sharescope.co.uk (Postfix) with ESMTPSA id 21AFFFC0AE for ; Thu, 6 May 2010 10:09:35 +0100 (BST) Message-ID: <4BE2874D.10909@ionic.co.uk> Date: Thu, 06 May 2010 10:09:33 +0100 From: Michal User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100317 Lightning/1.0b1 Thunderbird/3.0.4 MIME-Version: 1.0 To: freebsd-stable@freebsd.org X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: iscsi, zfs, RAIS = Cheap SAN...maybe X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 06 May 2010 09:09:41 -0000 *I apologise about the length of this e-mail, I tried to cover all details* I am following up on a previous post which is here http://unix.derkeiler.com/Mailing-Lists/FreeBSD/stable/2010-03/msg00392.html The sum up my end goal is this; "To have a SAN type system where I have multiple servers that contain multiple disks. I can lose a server and due to RAID1 across the servers, the data will still be on the network, IO will increase due to their being multiple servers to read from simultaneously as opposed to one NAS box and lastly to be able to add new servers to the system to increase the storage (to the end users the amount of available space increases). Stage one is to create a two server system that can take a failure of a server. Second stage is to get better IO from two servers then from one NAS box. Last stage is to have all that and the ability to easily add more storage" I have created 3 (not great spec just some spear) servers, two of which have 2 HDD's each and I will call storedevice1 and storedevice2 these are my devices that will hold the data. My 3rd server is my controller which controls the devices. Each server has two hard drives which using iscsi-target I export as data0 and data1 and in the controller I use the iscsi-initiator to connect to these 4 HDD's. Here is the config files storedevice1: #cat /usr/local/etc/iscsi/targets # extents file start length #extent0 /tmp/iscsi-target0 0 100MB extent0 /data0/data 0 28GB extent1 /data1/data 0 28GB # target flags storage netmask target0 rw extent0 192.168.2.0/24 target1 rw extent1 192.168.2.0/24 # ls -lh /data0/ total 2195442 drwxrwxr-x 2 root operator 512B Apr 20 17:49 .snap -rw-r--r-- 1 root wheel 28G May 5 21:37 data # ls -lh /data1/ total 2195442 drwxrwxr-x 2 root operator 512B Apr 22 13:27 .snap -rw-r--r-- 1 root wheel 28G May 5 21:37 data storedevice2: #cat /usr/local/etc/iscsi/targets # extents file start length extent2 /data0/data 0 28GB extent3 /data1/data 0 28GB # target flags storage netmask target2 rw extent2 192.168.2.0/24 target3 rw extent3 192.168.2.0/24 # ls -lh /data0/ total 2191250 drwxrwxr-x 2 root operator 512B Apr 22 15:09 .snap -rw-r--r-- 1 root wheel 28G May 5 21:37 data # ls -lh /data1/ total 2191250 drwxrwxr-x 2 root operator 512B Apr 22 17:40 .snap -rw-r--r-- 1 root wheel 28G May 5 21:37 data which gives me 4 extents and 4 targets accross both. /dataX/data is a file which I think it needs to be (???) On my controller I have; OffSanCtrl1# cat /etc/iscsi.conf offsan0 { TargetName = iqn.1994-04.org.netbsd.iscsi-target:target0 TargetAddress = 192.168.2.160:3260,1 } offsan1 { TargetName = iqn.1994-04.org.netbsd.iscsi-target:target1 TargetAddress = 192.168.2.160:3260,1 } offsan2 { TargetName = iqn.1994-04.org.netbsd.iscsi-target:target2 TargetAddress = 192.168.2.161:3260,1 offsan3 { TargetName = iqn.1994-04.org.netbsd.iscsi-target:target3 TargetAddress = 192.168.2.161:3260,1 } which is my initiator and connects to my 4 targets Up to this point I think I am doing everything correctly. I then setup a zpool on the controller OffSanCtrl1# zpool status pool: store0 state: ONLINE scrub: none requested config: NAME STATE READ WRITE CKSUM store0 ONLINE 0 0 0 mirror ONLINE 0 0 0 da1s1d ONLINE 0 0 0 da3s1d ONLINE 0 0 0 mirror ONLINE 0 0 0 da2s1d ONLINE 0 0 0 da4s1d ONLINE 0 0 0 errors: No known data errors with da1s1d and da2s1d being from storedevice1 and da3s1d and da4s1d from storedevice2 so if I am correct this should be a a sort of RAID10 (anything that could be done better please tell me). I now set-up zfs on this zpool (again, I think I'm doing this the right way) OffSanCtrl1# zfs list NAME USED AVAIL REFER MOUNTPOINT store0 4.12G 50.5G 19K /store0 store0/users 4.12G 50.5G 4.12G /store0/users Lastly, I need to be able to allow network users/servers to connect to this. My choices I think are iscsi and samba as I have *nix and windows machines, so I'll try iscsi. From the controller, create a target from the zfs mount point I have created. If I am correct, a user should be able to connect to the target from the controller, write data which will actually be writing data across both storedevice's OffSanCtrl1# cat /usr/local/etc/iscsi/targets # extents file start length extent0 /store0/users/data 0 55G # target flags storage netmask target9 rw extent0 192.168.2.0/24 It didn't work until I created a file called data under /store0/users/ so I guess this relies on a file of some sort..maybe?? I think this bit I've done wrong. I test this from a windows7 machine, open up the iscsi-initiator, connect to the controller, it connects and I can see the drive so I format it and mount it. I can then write data to the drive and read data from it. So...it works...to a degree...though I think what is actually happening is it's writing data to the controller somewhere and NOT to the storedevices...however I'm getting a bit lost. I get quite good write speeds at first and it slowly craws down to about 5MB/s...but with small files and to begind with, with big files it is very fast and impressive. What is causing the slow down, I am not sure...possibly RAM...cache...I'm not using amazing servers as storedevice1/2 so it could possibly be that. But I know I have lots of things to do...so I'm asking for any advice and assistance from the community. P.S Please note at this point I am not looking at ZIL or things like that, I simply want a working system to test the theory and build a proposal with. I know better servers will give me better IO, but should not affect testing redundency, failovers etc etc which is what I need to work out. Many thanks...even if you just read this beast of an e-mail From owner-freebsd-stable@FreeBSD.ORG Thu May 6 12:11:51 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 23988106566B for ; Thu, 6 May 2010 12:11:51 +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 75CFD8FC14 for ; Thu, 6 May 2010 12:11:50 +0000 (UTC) Received: from bb.ipt.ru ([194.62.233.89]) by services.ipt.ru with esmtp (Exim 4.54 (FreeBSD)) id 1O9zvf-000HWy-JE; Thu, 06 May 2010 16:11:47 +0400 From: Boris Samorodov To: Michal References: <4BE2874D.10909@ionic.co.uk> Date: Thu, 06 May 2010 16:11:47 +0400 In-Reply-To: <4BE2874D.10909@ionic.co.uk> (michal@ionic.co.uk's message of "Thu, 06 May 2010 10:09:33 +0100") Message-ID: <73575852@bb.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-stable@freebsd.org Subject: Re: iscsi, zfs, RAIS = Cheap SAN...maybe X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 06 May 2010 12:11:51 -0000 Hi! On Thu, 06 May 2010 10:09:33 +0100 Michal wrote: > Many thanks...even if you just read this beast of an e-mail This is not an answer to your questions but my tiny experience in this area. I created two USB 2G storages with FreeBSD current i386: node001 and node002. Each system has one 250G hard disk. Both nodes export their disks via iscsi: ----- node001% sudo istgtcontrol list lun0 storage "/dev/ad0" 250059350016 DONE LIST command ----- node002% sudo istgtcontrol list lun0 storage "/dev/ad4" 250059350016 DONE LIST command ----- I used my workstation as a controller. And since it's an i386 (FreeBSD-CURRENT) I didn't try zfs but created a gmirror: ----- da0 at iscsi0 bus 0 scbus7 target 0 lun 0 da0: Fixed Direct Access SCSI-5 device da0: 238475MB (488397168 512 byte sectors: 255H 63S/T 30401C) da1 at iscsi0 bus 0 scbus7 target 1 lun 0 da1: Fixed Direct Access SCSI-5 device da1: 238475MB (488397168 512 byte sectors: 255H 63S/T 30401C) GEOM_MIRROR: Device mirror/storage0 launched (2/2). ----- bsam% gmirror status Name Status Components mirror/storage0 COMPLETE da0 da1 bsam% mount -p | grep storage /dev/mirror/storage0 /storage ufs rw 2 2 ----- While using 100Mb/s network connection I've got 7-8 MB/s writes (after some sysctl tuning, 3-4 MB/s without). And switching to 1Gb/s network connection (Intel Gigabit Ethernet Controllers) gave me something like 20 Mb/s writes (no tuning): ----- bsam% dd if=/dev/zero of=/storage/file.2G bs=1M count=2000 2000+0 records in 2000+0 records out 2097152000 bytes transferred in 108.479201 secs (19332296 bytes/sec) bsam% netstat -w10 input (Total) output packets errs idrops bytes packets errs bytes colls 21 0 0 1658 9 0 582 0 44 0 0 5425 35 0 3014 0 70470 0 0 5640905 114909 0 184072616 0 157670 0 0 11966753 257062 0 390774311 0 175056 0 0 11951631 285343 0 390099162 0 156502 0 0 11867216 255072 0 387223400 0 174907 0 0 11947580 285064 0 390607312 0 155607 0 0 11800874 253530 0 385202710 0 173359 0 0 11835884 282798 0 386524530 0 157604 0 0 11922283 256966 0 389324902 0 174224 0 0 11919850 284396 0 390212650 0 173677 0 0 11853356 283110 0 386944770 0 174934 0 0 11932229 285361 0 389785504 0 69574 0 0 4584810 113056 0 148735429 0 282 0 0 22196 374 0 452062 0 20 0 0 2054 14 0 2473 0 ----- node001% netstat -w10 input (Total) output packets errs idrops bytes packets errs bytes colls 12 0 0 1008 1 0 178 0 17 0 0 1626 2 0 292 0 60498 0 0 88413959 37258 0 2616474 0 139627 0 0 204095754 86076 0 6064930 0 139188 0 0 203450154 85816 0 6047488 0 138486 0 0 202411672 85363 0 6000534 0 139258 0 0 203561033 85848 0 6049360 0 137636 0 0 201181818 84866 0 5981524 0 138262 0 0 202064896 85169 0 6004090 0 139297 0 0 203633800 85829 0 6031458 0 138884 0 0 203011098 85495 0 6025390 0 138280 0 0 202089488 85166 0 6004198 0 139272 0 0 203583962 85828 0 6047758 0 58465 0 0 85346106 36192 0 2545632 0 193 0 0 236228 132 0 10360 0 ----- node002% netstat -w10 input (Total) output packets errs idrops bytes packets errs bytes colls 12 0 0 1008 1 0 178 0 16 0 0 1566 2 0 292 0 73703 0 0 107730061 44956 0 3134984 0 139420 0 0 203862166 85058 0 5899360 0 139295 0 0 203674472 85024 0 5896468 0 138129 0 0 201945040 84345 0 5850658 0 139068 0 0 203351261 84873 0 5886130 0 138214 0 0 202097218 84293 0 5846170 0 137860 0 0 201540738 84120 0 5835754 0 138751 0 0 202889156 84668 0 5871694 0 139260 0 0 203626362 84907 0 5888854 0 138468 0 0 202435390 84534 0 5863900 0 139210 0 0 203557426 84865 0 5885938 0 45288 0 0 66099374 27684 0 1924360 0 193 0 0 236228 136 0 10624 0 11 0 0 1574 3 0 518 0 ----- Well, there were no tuning at all since I didn't have much spare time to exteriment. Here is some more info about hard and soft. Controller: ----- bsam% uname -a FreeBSD bsam.sem.ipt.ru 9.0-CURRENT FreeBSD 9.0-CURRENT #2 r207498: Sun May 2 16:19:56 MSD 2010 bsam@bsam.sem.ipt.ru:/home/bsam/FreeBSD/base/head/obj/storage/src/sys/BB i386 age0@pci0:2:0:0: class=0x020000 card=0x82261043 chip=0x10481969 rev=0xb0 hdr=0x00 vendor = 'Attansic (Now owned by Atheros)' device = 'Gigabit Ethernet 10/100/1000 Base-T Controller (Atheros L1)' class = network subclass = ethernet cap 01[40] = powerspec 2 supports D0 D3 current D0 cap 05[48] = MSI supports 1 message, 64 bit enabled with 1 message cap 10[58] = PCI-Express 1 endpoint max data 128(128) link x1(x1) ----- Node001: ----- node001% uname -a FreeBSD node001.sem.ipt.ru 9.0-CURRENT FreeBSD 9.0-CURRENT #13 r206496: Mon Apr 12 18:28:45 MSD 2010 bsam@bsam.sem.ipt.ru:/m/home/bsam/FreeBSD/base/head/obj/m/home/bsam/FreeBSD/base/head/src/sys/BB i386 em0@pci0:2:1:0: class=0x020000 card=0x002e8086 chip=0x100e8086 rev=0x02 hdr=0x00 vendor = 'Intel Corporation' device = 'Gigabit Ethernet Controller (82540EM)' class = network subclass = ethernet cap 01[dc] = powerspec 2 supports D0 D3 current D0 cap 07[e4] = PCI-X supports 2048 burst read, 1 split transaction cap 05[f0] = MSI supports 1 message, 64 bit ----- Node002: ----- node002% uname -a FreeBSD node002.sem.ipt.ru 9.0-CURRENT FreeBSD 9.0-CURRENT #13 r206496: Mon Apr 12 18:28:45 MSD 2010 bsam@bsam.sem.ipt.ru:/m/home/bsam/FreeBSD/base/head/obj/m/home/bsam/FreeBSD/base/head/src/sys/BB i386 em0@pci0:0:10:0: class=0x020000 card=0x13768086 chip=0x107c8086 rev=0x05 hdr=0x00 vendor = 'Intel Corporation' device = 'Gigabit Ethernet Controller (Copper) rev 5 (82541PI)' class = network subclass = ethernet cap 01[dc] = powerspec 2 supports D0 D3 current D0 cap 07[e4] = PCI-X supports 2048 burst read, 1 split transaction ----- -- 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 May 6 16:14:24 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id DDEAD1065673; Thu, 6 May 2010 16:14:24 +0000 (UTC) (envelope-from ruben@verweg.com) Received: from erg.verweg.com (erg.verweg.com [94.142.245.8]) by mx1.freebsd.org (Postfix) with ESMTP id 5AE898FC08; Thu, 6 May 2010 16:14:23 +0000 (UTC) Received: from [192.168.1.27] (helium.xs4all.nl [83.163.52.241]) (authenticated bits=0) by erg.verweg.com (8.14.4/8.14.3) with ESMTP id o46G0YHi085469 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 6 May 2010 16:00:40 GMT (envelope-from ruben@verweg.com) X-Authentication-Warning: erg.verweg.com: Host helium.xs4all.nl [83.163.52.241] claimed to be [192.168.1.27] Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii From: Ruben van Staveren In-Reply-To: <20100505133302.GB1626@garage.freebsd.pl> Date: Thu, 6 May 2010 18:00:33 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4BDEA86E.3050109@zirakzigil.org> <20100503110100.GA93137@icarus.home.lan> <4BDEC106.3040807@zirakzigil.org> <4BE110E3.8040902@zirakzigil.org> <20100505075242.GA57550@icarus.home.lan> <4BE13067.1060606@zirakzigil.org> <20100505133302.GB1626@garage.freebsd.pl> To: Pawel Jakub Dawidek X-Mailer: Apple Mail (2.1078) X-Spam-Status: No, score=2.5 required=5.0 tests=DATE_IN_FUTURE_12_24 autolearn=no version=3.3.1 X-Spam-Level: ** X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on erg.verweg.com X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.3 (erg.verweg.com [94.142.245.8]); Thu, 06 May 2010 16:00:41 +0000 (UTC) Cc: freebsd-fs@freebsd.org, Giulio Ferro , freebsd-stable@freebsd.org, Jeremy Chadwick Subject: Re: Freebsd 8.0 kmem map too small X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 06 May 2010 16:14:25 -0000 On 5 May 2010, at 15:33, Pawel Jakub Dawidek wrote: > Could you try to track down the commit that is causing your problems? > Could you try 8-STABLE kernel from before r206815? I do suspect something similar like that, and try to roll the kernel = back too. I was just fine with 8.0 with zfs-on-root till the last update when my = typical workload (portupgrade every now and then, make world) resulted = in kmem map too small panics and more sluggish performance (spending = most time in zio->io_cv) during pkgdb -F on a i386 system with 2gb = memory. I have 1gb memory sized amd64 vmware fusion vm's that run = without incident using the same workload. I had to bump KVA_PAGES to 512 and set vm.kmem_size=3D1024M to have this = i386 system stable again. Prior to that I tried to lower the arc cache = size but that resulted in a unresponsive system that I could not = diagnose. Regards, Ruben From owner-freebsd-stable@FreeBSD.ORG Fri May 7 05:28:47 2010 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 214F0106564A; Fri, 7 May 2010 05:28:47 +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 5B5D38FC12; Fri, 7 May 2010 05:28:44 +0000 (UTC) Received: from lp.gddsn.org.cn (unknown [10.44.8.159]) (Authenticated sender: wsk) by gddsn.org.cn (Postfix) with ESMTPA id BCC5E2E043; Fri, 7 May 2010 12:00:16 +0800 (CST) Message-ID: <4BE3A512.10307@gddsn.org.cn> Date: Fri, 07 May 2010 13:28:50 +0800 From: wsk User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; zh-CN; rv:1.9.1.9) Gecko/20100426 Thunderbird/3.0.4 MIME-Version: 1.0 To: stable@freebsd.org, eclipse@freebsd.org Content-Type: multipart/mixed; boundary="------------070705000002050306020901" X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Subject: eclipse-devel caused gdb exited on signal 6 (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: Fri, 07 May 2010 05:28:47 -0000 This is a multi-part message in MIME format. --------------070705000002050306020901 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit install eclipse 3.5.2 sucessed from ports and got core dumped. pid 2047 (gdb), uid 1001: exited on signal 6 (core dumped) 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"...(no debugging symbols found)... Core was generated by `gdb'. Program terminated with signal 6, Aborted. Reading symbols from /lib/libm.so.5...(no debugging symbols found)...done. Loaded symbols for /lib/libm.so.5 Reading symbols from /lib/libreadline.so.8...(no debugging symbols found)...done. Loaded symbols for /lib/libreadline.so.8 Reading symbols from /lib/libncurses.so.8...(no debugging symbols found)...done. Loaded symbols for /lib/libncurses.so.8 Reading symbols from /usr/lib/libgnuregex.so.5...(no debugging symbols found)...done. Loaded symbols for /usr/lib/libgnuregex.so.5 Reading symbols from /lib/libc.so.7...(no debugging symbols found)...done. Loaded symbols for /lib/libc.so.7 Reading symbols from /usr/lib/libthread_db.so...(no debugging symbols found)...done. Loaded symbols for /usr/lib/libthread_db.so Reading symbols from /libexec/ld-elf.so.1...(no debugging symbols found)...done. Loaded symbols for /libexec/ld-elf.so.1 #0 0x0000000800e1226c in kill () from /lib/libc.so.7 (gdb) bt #0 0x0000000800e1226c in kill () from /lib/libc.so.7 #1 0x0000000800e1106b in abort () from /lib/libc.so.7 #2 0x00000000004830d5 in safe_strerror () #3 0x00000000004832b9 in internal_verror () #4 0x0000000000483351 in internal_error () #5 0x0000000000522760 in _initialize_svr4_solib () #6 0x0000000000522a40 in _initialize_svr4_solib () #7 0x0000000000492bfe in throw_exception () #8 0x0000000000492c53 in catch_errors () #9 0x000000000047705f in no_shared_libraries () #10 0x000000000047724b in solib_add () #11 0x0000000000526f94 in ps_plog () #12 0x0000000000438628 in attach_command () #13 0x0000000000492230 in command_line_input () #14 0x0000000000492bfe in throw_exception () #15 0x0000000000492c53 in catch_errors () #16 0x0000000000492d33 in catch_command_errors () #17 0x00000000004356e5 in gdb_main () #18 0x0000000000492bfe in throw_exception () #19 0x0000000000492c53 in catch_errors () #20 0x0000000000434f84 in gdb_main () #21 0x0000000000434f56 in main () (gdb) --------------070705000002050306020901 Content-Type: text/plain; name="hs_err_pid2042.log" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="hs_err_pid2042.log" IwojIEEgZmF0YWwgZXJyb3IgaGFzIGJlZW4gZGV0ZWN0ZWQgYnkgdGhlIEphdmEgUnVudGlt ZSBFbnZpcm9ubWVudDoKIwojICBTSUdTRUdWICgweGIpIGF0IHBjPTB4MDAwMDAwMDkwMGFj M2EwMCwgcGlkPTIwNDIsIHRpZD0zNDM3MjM2NTg4OAojCiMgSlJFIHZlcnNpb246IDYuMC1i MTcKIyBKYXZhIFZNOiBPcGVuSkRLIDY0LUJpdCBTZXJ2ZXIgVk0gKDE0LjAtYjE2IG1peGVk IG1vZGUgYnNkLWFtZDY0ICkKIyBQcm9ibGVtYXRpYyBmcmFtZToKIyBDICAweDAwMDAwMDA5 MDBhYzNhMDAKIwojIElmIHlvdSB3b3VsZCBsaWtlIHRvIHN1Ym1pdCBhIGJ1ZyByZXBvcnQs IHBsZWFzZSB2aXNpdDoKIyAgIGh0dHA6Ly9qYXZhLnN1bi5jb20vd2ViYXBwcy9idWdyZXBv cnQvY3Jhc2guanNwCiMgVGhlIGNyYXNoIGhhcHBlbmVkIG91dHNpZGUgdGhlIEphdmEgVmly dHVhbCBNYWNoaW5lIGluIG5hdGl2ZSBjb2RlLgojIFNlZSBwcm9ibGVtYXRpYyBmcmFtZSBm b3Igd2hlcmUgdG8gcmVwb3J0IHRoZSBidWcuCiMKCi0tLS0tLS0tLS0tLS0tLSAgVCBIIFIg RSBBIEQgIC0tLS0tLS0tLS0tLS0tLQoKQ3VycmVudCB0aHJlYWQgKDB4MDAwMDAwMDgwMWNl ZDgwMCk6ICBKYXZhVGhyZWFkICJtYWluIiBbX3RocmVhZF9pbl9uYXRpdmUsIGlkPTEyNjI3 NTIwLCBzdGFjaygweDAwMDA3ZmZmZmZhZmYwMDAsMHgwMDAwN2ZmZmZmYmZmMDAwKV0KCnNp Z2luZm86c2lfc2lnbm89U0lHU0VHVjogc2lfZXJybm89MCwgc2lfY29kZT0xIChTRUdWX01B UEVSUiksIHNpX2FkZHI9MHgwMDAwMDAwOTAwYWMzYTAwCgpSZWdpc3RlcnM6ClJBWD0weDAw MDAwMDAwMDAwMDAwMDEsIFJCWD0weDAwMDAwMDAwMDAwMDAwMDEsIFJDWD0weDAwMDAwMDAw MDAwMDAwMDAsIFJEWD0weDAwMDAwMDAwMDAwMDAwMDEKUlNQPTB4MDAwMDdmZmZmZmJmY2E2 OCwgUkJQPTB4MDAwMDAwMDg5NWRhN2UwMCwgUlNJPTB4MDAwMDAwMDAwMDAwMDAwMiwgUkRJ PTB4MDAwMDAwMDAwMDAwMDAzZgpSOCA9MHgwMDAwMDAwMDAwMDAwMDAwLCBSOSA9MHgwMDAw MDAwMDAwMDAwMDAwLCBSMTA9MHgwMDAwMDAwODk1ZGE3ZTEwLCBSMTE9MHgwMDAwMDAwOGEx MGY5YTEwClIxMj0weDAwMDAwMDA4OWU2ZTc1MDAsIFIxMz0weDAwMDAwMDA4OWU2ZTc1MDAs IFIxND0weDAwMDAwMDAwMDAwMDAxMDAsIFIxNT0weDAwMDAwMDA4OWVjMzRmYzAKUklQPTB4 MDAwMDAwMDkwMGFjM2EwMCwgRUZMPTB4MDAwMDAwMDAwMDAwMDAwMSwgRVJSPTB4MDAwMDAw MDAwMDAwMDAxNAogIFRSQVBOTz0weDAwMDAwMDAwMDAwMDAwMGMKClRvcCBvZiBTdGFjazog KHNwPTB4MDAwMDdmZmZmZmJmY2E2OCkKMHgwMDAwN2ZmZmZmYmZjYTY4OiAgIDAwMDAwMDA4 YTMxMWQzMzEgMDAwMDAwMDg5ZTZlNzUwMAoweDAwMDA3ZmZmZmZiZmNhNzg6ICAgMDAwMDAw MDAwMDAwMDEwMCAwMDAwMDAwMDAwMDAwMDAxCjB4MDAwMDdmZmZmZmJmY2E4ODogICAwMDAw MDAwODk1ZGE3ZTAwIDAwMDAwMDA4OWU2ZTc1MDAKMHgwMDAwN2ZmZmZmYmZjYTk4OiAgIDAw MDAwMDA4YTMwZWY4ZmYgMDAwMDdmZmZmZmJmY2NkMAoweDAwMDA3ZmZmZmZiZmNhYTg6ICAg MDAwMDAwMDgwMGNhMTk0MCAwMDAwMDAwMDAwMDAwMDAxCjB4MDAwMDdmZmZmZmJmY2FiODog ICAwMDAwMDAwODAwZDhmODAwIDAwMDAwMDA4OWVjMzRmYzAKMHgwMDAwN2ZmZmZmYmZjYWM4 OiAgIDAwMDAwMDA4YTFjOGQ1ODYgMDAwMDAwMDhhMTExMjY4OAoweDAwMDA3ZmZmZmZiZmNh ZDg6ICAgMDAwMDAwMDhhMTExMjZiYiAwMDAwMDAwOGExMTEyNmJiCjB4MDAwMDdmZmZmZmJm Y2FlODogICAwMDAwMDAwOGExMTEyNjgwIDAwMDAwMDA4YTExMTI2ODgKMHgwMDAwN2ZmZmZm YmZjYWY4OiAgIDAwMDAwMDAwYTExMTI2YmIgMDAwMDAwMDhhMjYyNWQwMAoweDAwMDA3ZmZm ZmZiZmNiMDg6ICAgMDAwMDdmZmZmZmJmY2FmYyAwMDAwMDAwOGExMTEyNmE5CjB4MDAwMDdm ZmZmZmJmY2IxODogICAwMDAwMDAwMzAwMDAwMDEyIDAwMDAwMDAwMDAwMDAwMDAKMHgwMDAw N2ZmZmZmYmZjYjI4OiAgIDAwMDAwMDAzZmZiZmNjMDAgMDAwMDdmZmZmZmJmY2NkMAoweDAw MDA3ZmZmZmZiZmNiMzg6ICAgMDAwMDAwMDA4MDA3MDA1NyAwMDAwMDAwMDAwMDAwMDAxCjB4 MDAwMDdmZmZmZmJmY2I0ODogICAwMDAwMDAwOGExYzhmMmM4IDAwMDAwMDAwMDAwMDAwMDAK MHgwMDAwN2ZmZmZmYmZjYjU4OiAgIDAwMDA3ZmZmZmZiZmNkYzAgMDAwMDAwMDgwMGNhMTk0 MAoweDAwMDA3ZmZmZmZiZmNiNjg6ICAgMDAwMDAwMDhhMjVhMWY0MyAwMDAwMDAwMGZmYmZj YmUwCjB4MDAwMDdmZmZmZmJmY2I3ODogICAwMDAwMDAwOGExMTEyNjgwIDAwMDAwMDA4YTJj ZWJiYjAKMHgwMDAwN2ZmZmZmYmZjYjg4OiAgIDAwMDAwMDA4YTJiZGRiOWUgMDAwMDAwMDhh MTExMjY4MAoweDAwMDA3ZmZmZmZiZmNiOTg6ICAgMDAwMDAwMDgwMGQ4ZjgwMCAwMDAwN2Zm ZmZmYmZjYzcwCjB4MDAwMDdmZmZmZmJmY2JhODogICAwMDAwMDAwOGEyNWExNjM5IDAwMDAw MDAwMDAwMDAwMDAKMHgwMDAwN2ZmZmZmYmZjYmI4OiAgIDAwMDAwMDA4YTI1YTIwYzcgMDAw MDdmZmZmZmJmY2M4MAoweDAwMDA3ZmZmZmZiZmNiYzg6ICAgMDAwMDAwMDhhMjVhMjEwOSAw MDAwN2ZmZmZmYmZjYzcwCjB4MDAwMDdmZmZmZmJmY2JkODogICAwMDAwMDAwOGEyNTdkZGNh IDAwMDA3ZmZmZmZiZmNjMDAKMHgwMDAwN2ZmZmZmYmZjYmU4OiAgIDAwMDEwMDExMDAwMDAw MTIgMDAwMDAwMDAwMDAwMDAzZgoweDAwMDA3ZmZmZmZiZmNiZjg6ICAgMDAwMDdmZmZmZmJm Y2MwMCA3MDcwNDE0YzU1NTg3MzZlCjB4MDAwMDdmZmZmZmJmY2MwODogICAyZTZjNmM2MTc0 NzM2ZTQ5IDAwMDAwMDAwMDAwMDczNmEKMHgwMDAwN2ZmZmZmYmZjYzE4OiAgIDAwMDAwMDA4 YTI1YTI5MjAgMDAwMDAwMDhhMmNlYmI5OAoweDAwMDA3ZmZmZmZiZmNjMjg6ICAgMDAwMDAw MDhhMmJkZGNiZSAwMDAwMDAwODllYzM1MDUwCjB4MDAwMDdmZmZmZmJmY2MzODogICAwMDAw MDAwOGEyYmQ0OGE4IDAwMThjMzNkNmRjMTU2ZTQKMHgwMDAwN2ZmZmZmYmZjYzQ4OiAgIDAw MDAwMDAwMDAwMTgxYTQgMDAwMDAwMDAwMDAwMDAwMAoweDAwMDA3ZmZmZmZiZmNjNTg6ICAg MDAwMDAwMDA0YmQ5M2QzYiAwMDAwMDAwOGExMTEyNjg4IAoKSW5zdHJ1Y3Rpb25zOiAocGM9 MHgwMDAwMDAwOTAwYWMzYTAwKQoweDAwMDAwMDA5MDBhYzM5ZjA6ICAgCltlcnJvciBvY2N1 cnJlZCBkdXJpbmcgZXJyb3IgcmVwb3J0aW5nIChwcmludGluZyByZWdpc3RlcnMsIHRvcCBv ZiBzdGFjaywgaW5zdHJ1Y3Rpb25zIG5lYXIgcGMpLCBpZCAweGJdCgpTdGFjazogWzB4MDAw MDdmZmZmZmFmZjAwMCwweDAwMDA3ZmZmZmZiZmYwMDBdLCAgc3A9MHgwMDAwN2ZmZmZmYmZj YTY4LCAgZnJlZSBzcGFjZT0xMDE0awpOYXRpdmUgZnJhbWVzOiAoSj1jb21waWxlZCBKYXZh IGNvZGUsIGo9aW50ZXJwcmV0ZWQsIFZ2PVZNIGNvZGUsIEM9bmF0aXZlIGNvZGUpCkMgIDB4 MDAwMDAwMDkwMGFjM2EwMAoKSmF2YSBmcmFtZXM6IChKPWNvbXBpbGVkIEphdmEgY29kZSwg aj1pbnRlcnByZXRlZCwgVnY9Vk0gY29kZSkKaiAgb3JnLmVjbGlwc2Uuc3d0LmludGVybmFs Lm1vemlsbGEuWFBDT00uX0NhbGwoSkpKSkpJKUkrMApqICBvcmcuZWNsaXBzZS5zd3QuaW50 ZXJuYWwubW96aWxsYS5YUENPTS5DYWxsKEpKSkpKSSlJKzE3CmogIG9yZy5lY2xpcHNlLnN3 dC5icm93c2VyLk1vemlsbGEuY3JlYXRlKExvcmcvZWNsaXBzZS9zd3Qvd2lkZ2V0cy9Db21w b3NpdGU7SSlWKzE1NjkKaiAgb3JnLmVjbGlwc2Uuc3d0LmJyb3dzZXIuQnJvd3Nlci48aW5p dD4oTG9yZy9lY2xpcHNlL3N3dC93aWRnZXRzL0NvbXBvc2l0ZTtJKVYrMjI3CmogIG9yZy5l Y2xpcHNlLmpmYWNlLmludGVybmFsLnRleHQuaHRtbC5Ccm93c2VySW5mb3JtYXRpb25Db250 cm9sLmlzQXZhaWxhYmxlKExvcmcvZWNsaXBzZS9zd3Qvd2lkZ2V0cy9Db21wb3NpdGU7KVor MTIKaiAgb3JnLmVjbGlwc2UuamR0LmludGVybmFsLnVpLnRleHQuamF2YS5BYnN0cmFjdEph dmFDb21wbGV0aW9uUHJvcG9zYWwuZ2V0SW5mb3JtYXRpb25Db250cm9sQ3JlYXRvcigpTG9y Zy9lY2xpcHNlL2pmYWNlL3RleHQvSUluZm9ybWF0aW9uQ29udHJvbENyZWF0b3I7KzkKaiAg b3JnLmVjbGlwc2UuamZhY2UudGV4dC5jb250ZW50YXNzaXN0LkFkZGl0aW9uYWxJbmZvQ29u dHJvbGxlci5jb21wdXRlSW5mb3JtYXRpb24oKVYrMTgKaiAgb3JnLmVjbGlwc2UuamZhY2Uu dGV4dC5BYnN0cmFjdEluZm9ybWF0aW9uQ29udHJvbE1hbmFnZXIuZG9TaG93SW5mb3JtYXRp b24oKVYrMTEKaiAgb3JnLmVjbGlwc2UuamZhY2UudGV4dC5BYnN0cmFjdEluZm9ybWF0aW9u Q29udHJvbE1hbmFnZXIuc2hvd0luZm9ybWF0aW9uKClWKzgKaiAgb3JnLmVjbGlwc2UuamZh Y2UudGV4dC5jb250ZW50YXNzaXN0LkFkZGl0aW9uYWxJbmZvQ29udHJvbGxlci5zaG93SW5m b3JtYXRpb24oTG9yZy9lY2xpcHNlL2pmYWNlL3RleHQvY29udGVudGFzc2lzdC9JQ29tcGxl dGlvblByb3Bvc2FsO0xqYXZhL2xhbmcvT2JqZWN0OylWKzY0CmogIG9yZy5lY2xpcHNlLmpm YWNlLnRleHQuY29udGVudGFzc2lzdC5BZGRpdGlvbmFsSW5mb0NvbnRyb2xsZXIkMTAuc2hv d0luZm9ybWF0aW9uKExvcmcvZWNsaXBzZS9qZmFjZS90ZXh0L2NvbnRlbnRhc3Npc3QvSUNv bXBsZXRpb25Qcm9wb3NhbDtMamF2YS9sYW5nL09iamVjdDspVisyNQpqICBvcmcuZWNsaXBz ZS5qZmFjZS50ZXh0LmNvbnRlbnRhc3Npc3QuQWRkaXRpb25hbEluZm9Db250cm9sbGVyJDku cnVuKClWKzM2CmogIG9yZy5lY2xpcHNlLnN3dC53aWRnZXRzLlJ1bm5hYmxlTG9jay5ydW4o KVYrMTEKaiAgb3JnLmVjbGlwc2Uuc3d0LndpZGdldHMuU3luY2hyb25pemVyLnJ1bkFzeW5j TWVzc2FnZXMoWilaKzI5CmogIG9yZy5lY2xpcHNlLnN3dC53aWRnZXRzLkRpc3BsYXkucnVu QXN5bmNNZXNzYWdlcyhaKVorNQpqICBvcmcuZWNsaXBzZS5zd3Qud2lkZ2V0cy5EaXNwbGF5 LnJlYWRBbmREaXNwYXRjaCgpWis0OApqICBvcmcuZWNsaXBzZS51aS5pbnRlcm5hbC5Xb3Jr YmVuY2gucnVuRXZlbnRMb29wKExvcmcvZWNsaXBzZS9qZmFjZS93aW5kb3cvV2luZG93JElF eGNlcHRpb25IYW5kbGVyO0xvcmcvZWNsaXBzZS9zd3Qvd2lkZ2V0cy9EaXNwbGF5OylWKzkK aiAgb3JnLmVjbGlwc2UudWkuaW50ZXJuYWwuV29ya2JlbmNoLnJ1blVJKClJKzM5MwpqICBv cmcuZWNsaXBzZS51aS5pbnRlcm5hbC5Xb3JrYmVuY2guYWNjZXNzJDQoTG9yZy9lY2xpcHNl L3VpL2ludGVybmFsL1dvcmtiZW5jaDspSSsxCmogIG9yZy5lY2xpcHNlLnVpLmludGVybmFs LldvcmtiZW5jaCQ1LnJ1bigpVis1NQpqICBvcmcuZWNsaXBzZS5jb3JlLmRhdGFiaW5kaW5n Lm9ic2VydmFibGUuUmVhbG0ucnVuV2l0aERlZmF1bHQoTG9yZy9lY2xpcHNlL2NvcmUvZGF0 YWJpbmRpbmcvb2JzZXJ2YWJsZS9SZWFsbTtMamF2YS9sYW5nL1J1bm5hYmxlOylWKzEyCmog IG9yZy5lY2xpcHNlLnVpLmludGVybmFsLldvcmtiZW5jaC5jcmVhdGVBbmRSdW5Xb3JrYmVu Y2goTG9yZy9lY2xpcHNlL3N3dC93aWRnZXRzL0Rpc3BsYXk7TG9yZy9lY2xpcHNlL3VpL2Fw cGxpY2F0aW9uL1dvcmtiZW5jaEFkdmlzb3I7KUkrMTgKaiAgb3JnLmVjbGlwc2UudWkuUGxh dGZvcm1VSS5jcmVhdGVBbmRSdW5Xb3JrYmVuY2goTG9yZy9lY2xpcHNlL3N3dC93aWRnZXRz L0Rpc3BsYXk7TG9yZy9lY2xpcHNlL3VpL2FwcGxpY2F0aW9uL1dvcmtiZW5jaEFkdmlzb3I7 KUkrMgpqICBvcmcuZWNsaXBzZS51aS5pbnRlcm5hbC5pZGUuYXBwbGljYXRpb24uSURFQXBw bGljYXRpb24uc3RhcnQoTG9yZy9lY2xpcHNlL2VxdWlub3gvYXBwL0lBcHBsaWNhdGlvbkNv bnRleHQ7KUxqYXZhL2xhbmcvT2JqZWN0Oys4NApqICBvcmcuZWNsaXBzZS5lcXVpbm94Lmlu dGVybmFsLmFwcC5FY2xpcHNlQXBwSGFuZGxlLnJ1bihMamF2YS9sYW5nL09iamVjdDspTGph dmEvbGFuZy9PYmplY3Q7KzEzNQpqICBvcmcuZWNsaXBzZS5jb3JlLnJ1bnRpbWUuaW50ZXJu YWwuYWRhcHRvci5FY2xpcHNlQXBwTGF1bmNoZXIucnVuQXBwbGljYXRpb24oTGphdmEvbGFu Zy9PYmplY3Q7KUxqYXZhL2xhbmcvT2JqZWN0OysxMDMKaiAgb3JnLmVjbGlwc2UuY29yZS5y dW50aW1lLmludGVybmFsLmFkYXB0b3IuRWNsaXBzZUFwcExhdW5jaGVyLnN0YXJ0KExqYXZh L2xhbmcvT2JqZWN0OylMamF2YS9sYW5nL09iamVjdDsrMjkKaiAgb3JnLmVjbGlwc2UuY29y ZS5ydW50aW1lLmFkYXB0b3IuRWNsaXBzZVN0YXJ0ZXIucnVuKExqYXZhL2xhbmcvT2JqZWN0 OylMamF2YS9sYW5nL09iamVjdDsrMTQ5CmogIG9yZy5lY2xpcHNlLmNvcmUucnVudGltZS5h ZGFwdG9yLkVjbGlwc2VTdGFydGVyLnJ1bihbTGphdmEvbGFuZy9TdHJpbmc7TGphdmEvbGFu Zy9SdW5uYWJsZTspTGphdmEvbGFuZy9PYmplY3Q7KzE4Mwp2ICB+U3R1YlJvdXRpbmVzOjpj YWxsX3N0dWIKaiAgc3VuLnJlZmxlY3QuTmF0aXZlTWV0aG9kQWNjZXNzb3JJbXBsLmludm9r ZTAoTGphdmEvbGFuZy9yZWZsZWN0L01ldGhvZDtMamF2YS9sYW5nL09iamVjdDtbTGphdmEv bGFuZy9PYmplY3Q7KUxqYXZhL2xhbmcvT2JqZWN0OyswCmogIHN1bi5yZWZsZWN0Lk5hdGl2 ZU1ldGhvZEFjY2Vzc29ySW1wbC5pbnZva2UoTGphdmEvbGFuZy9PYmplY3Q7W0xqYXZhL2xh bmcvT2JqZWN0OylMamF2YS9sYW5nL09iamVjdDsrODcKaiAgc3VuLnJlZmxlY3QuRGVsZWdh dGluZ01ldGhvZEFjY2Vzc29ySW1wbC5pbnZva2UoTGphdmEvbGFuZy9PYmplY3Q7W0xqYXZh L2xhbmcvT2JqZWN0OylMamF2YS9sYW5nL09iamVjdDsrNgpqICBqYXZhLmxhbmcucmVmbGVj dC5NZXRob2QuaW52b2tlKExqYXZhL2xhbmcvT2JqZWN0O1tMamF2YS9sYW5nL09iamVjdDsp TGphdmEvbGFuZy9PYmplY3Q7KzE2MQpqICBvcmcuZWNsaXBzZS5lcXVpbm94LmxhdW5jaGVy Lk1haW4uaW52b2tlRnJhbWV3b3JrKFtMamF2YS9sYW5nL1N0cmluZztbTGphdmEvbmV0L1VS TDspVisyMTEKaiAgb3JnLmVjbGlwc2UuZXF1aW5veC5sYXVuY2hlci5NYWluLmJhc2ljUnVu KFtMamF2YS9sYW5nL1N0cmluZzspVisxMTQKaiAgb3JnLmVjbGlwc2UuZXF1aW5veC5sYXVu Y2hlci5NYWluLnJ1bihbTGphdmEvbGFuZy9TdHJpbmc7KUkrNApqICBvcmcuZWNsaXBzZS5l cXVpbm94LmxhdW5jaGVyLk1haW4ubWFpbihbTGphdmEvbGFuZy9TdHJpbmc7KVYrMTAKdiAg flN0dWJSb3V0aW5lczo6Y2FsbF9zdHViCgotLS0tLS0tLS0tLS0tLS0gIFAgUiBPIEMgRSBT IFMgIC0tLS0tLS0tLS0tLS0tLQoKSmF2YSBUaHJlYWRzOiAoID0+IGN1cnJlbnQgdGhyZWFk ICkKICAweDAwMDAwMDA4MDFjZDY4MDAgSmF2YVRocmVhZCAiQWRkaXRpb25hbCBpbmZvIHRp bWVyIiBbX3RocmVhZF9ibG9ja2VkLCBpZD0tMTc3NzA4OTcyOCwgc3RhY2soMHgwMDAwN2Zm ZmZlNGU5MDAwLDB4MDAwMDdmZmZmZTVlOTAwMCldCiAgMHgwMDAwMDAwODAxY2RhMDAwIEph dmFUaHJlYWQgIm9yZy5lY2xpcHNlLmpkdC5pbnRlcm5hbC51aS50ZXh0LkphdmFSZWNvbmNp bGVyIiBkYWVtb24gW190aHJlYWRfYmxvY2tlZCwgaWQ9LTE2MzYyMzY4NjQsIHN0YWNrKDB4 MDAwMDdmZmZmZDhkZDAwMCwweDAwMDA3ZmZmZmQ5ZGQwMDApXQogIDB4MDAwMDAwMDg5Yjg1 MzAwMCBKYXZhVGhyZWFkICJbVGhyZWFkUG9vbCBNYW5hZ2VyXSAtIElkbGUgVGhyZWFkIiBk YWVtb24gW190aHJlYWRfYmxvY2tlZCwgaWQ9LTE2OTE1NDU1MzYsIHN0YWNrKDB4MDAwMDdm ZmZmZGFkZjAwMCwweDAwMDA3ZmZmZmRiZGYwMDApXQogIDB4MDAwMDAwMDg5YWQ3MDAwMCBK YXZhVGhyZWFkICJCdW5kbGUgRmlsZSBDbG9zZXIiIGRhZW1vbiBbX3RocmVhZF9ibG9ja2Vk LCBpZD0tMTcwMzQzMzkyMCwgc3RhY2soMHgwMDAwN2ZmZmZkY2UxMDAwLDB4MDAwMDdmZmZm ZGRlMTAwMCldCiAgMHgwMDAwMDAwODlhN2I3ODAwIEphdmFUaHJlYWQgIldvcmtlci03IiBb X3RocmVhZF9ibG9ja2VkLCBpZD0tMTcxMTEzODA0OCwgc3RhY2soMHgwMDAwN2ZmZmZkZGUy MDAwLDB4MDAwMDdmZmZmZGVlMjAwMCldCiAgMHgwMDAwMDAwODlhMDExODAwIEphdmFUaHJl YWQgIldvcmtlci02IiBbX3RocmVhZF9ibG9ja2VkLCBpZD0tMTc4MTg4NDE2MCwgc3RhY2so MHgwMDAwN2ZmZmZkZWUzMDAwLDB4MDAwMDdmZmZmZGZlMzAwMCldCiAgMHgwMDAwMDAwODli ODdkODAwIEphdmFUaHJlYWQgIldvcmtlci01IiBbX3RocmVhZF9ibG9ja2VkLCBpZD0tMTY4 NDkxMDkxMiwgc3RhY2soMHgwMDAwN2ZmZmZkZmU0MDAwLDB4MDAwMDdmZmZmZTBlNDAwMCld CiAgMHgwMDAwMDAwODAxY2U0MDAwIEphdmFUaHJlYWQgIldvcmtlci00IiBbX3RocmVhZF9i bG9ja2VkLCBpZD0tMTc3NzA4ODgzMiwgc3RhY2soMHgwMDAwN2ZmZmZlMGU1MDAwLDB4MDAw MDdmZmZmZTFlNTAwMCldCiAgMHgwMDAwMDAwODlhMDEyODAwIEphdmFUaHJlYWQgIldvcmtl ci0zIiBbX3RocmVhZF9ibG9ja2VkLCBpZD0tMTc4MTg4MTkyMCwgc3RhY2soMHgwMDAwN2Zm ZmZlMWU2MDAwLDB4MDAwMDdmZmZmZTJlNjAwMCldCiAgMHgwMDAwMDAwODAwYzg4MDAwIEph dmFUaHJlYWQgIldvcmtlci0yIiBbX3RocmVhZF9ibG9ja2VkLCBpZD0xMzIxMDU2MCwgc3Rh Y2soMHgwMDAwN2ZmZmZlMmU3MDAwLDB4MDAwMDdmZmZmZTNlNzAwMCldCiAgMHgwMDAwMDAw ODAxY2RiMDAwIEphdmFUaHJlYWQgIm9yZy5lY2xpcHNlLmpkdC5pbnRlcm5hbC51aS50ZXh0 LkphdmFSZWNvbmNpbGVyIiBkYWVtb24gW190aHJlYWRfYmxvY2tlZCwgaWQ9LTE3NzcwODY1 OTIsIHN0YWNrKDB4MDAwMDdmZmZmZTNlODAwMCwweDAwMDA3ZmZmZmU0ZTgwMDApXQogIDB4 MDAwMDAwMDgwMWNkYzgwMCBKYXZhVGhyZWFkICJKYXZhIGluZGV4aW5nIiBkYWVtb24gW190 aHJlYWRfYmxvY2tlZCwgaWQ9LTE3NzcwODEyMTYsIHN0YWNrKDB4MDAwMDdmZmZmZTVlYTAw MCwweDAwMDA3ZmZmZmU2ZWEwMDApXQogIDB4MDAwMDAwMDgwMGQxOTAwMCBKYXZhVGhyZWFk ICJbVGltZXJdIC0gTWFpbiBRdWV1ZSBIYW5kbGVyIiBkYWVtb24gW190aHJlYWRfYmxvY2tl ZCwgaWQ9LTE2ODEwOTE2NDgsIHN0YWNrKDB4MDAwMDdmZmZmZThlZDAwMCwweDAwMDA3ZmZm ZmU5ZWQwMDApXQogIDB4MDAwMDAwMDgwMGM4ODgwMCBKYXZhVGhyZWFkICJXb3JrZXItMSIg W190aHJlYWRfYmxvY2tlZCwgaWQ9MTMyMTEwMDgsIHN0YWNrKDB4MDAwMDdmZmZmZWFlZjAw MCwweDAwMDA3ZmZmZmViZWYwMDApXQogIDB4MDAwMDAwMDg5OWQ3NzgwMCBKYXZhVGhyZWFk ICJQcm92aXNpb25pbmcgRXZlbnQgRGlzcGF0Y2hlciIgZGFlbW9uIFtfdGhyZWFkX2Jsb2Nr ZWQsIGlkPS0xNzE1MDU1NjE2LCBzdGFjaygweDAwMDA3ZmZmZmViZjAwMDAsMHgwMDAwN2Zm ZmZlY2YwMDAwKV0KICAweDAwMDAwMDA4OTlkNzkwMDAgSmF2YVRocmVhZCAiV29ya2VyLTAi IFtfdGhyZWFkX2Jsb2NrZWQsIGlkPS0xNzE1MDUzMzc2LCBzdGFjaygweDAwMDA3ZmZmZmVj ZjEwMDAsMHgwMDAwN2ZmZmZlZGYxMDAwKV0KICAweDAwMDAwMDA4OTlkNzk4MDAgSmF2YVRo cmVhZCAiRnJhbWV3b3JrIEV2ZW50IERpc3BhdGNoZXIiIGRhZW1vbiBbX3RocmVhZF9ibG9j a2VkLCBpZD0tMTcxNTA1MTEzNiwgc3RhY2soMHgwMDAwN2ZmZmZlZGYyMDAwLDB4MDAwMDdm ZmZmZWVmMjAwMCldCiAgMHgwMDAwMDAwODAxY2U0ODAwIEphdmFUaHJlYWQgIlN0YXJ0IExl dmVsIEV2ZW50IERpc3BhdGNoZXIiIGRhZW1vbiBbX3RocmVhZF9ibG9ja2VkLCBpZD0tMTc3 NzA3MTM2MCwgc3RhY2soMHgwMDAwN2ZmZmZlZWYzMDAwLDB4MDAwMDdmZmZmZWZmMzAwMCld CiAgMHgwMDAwMDAwODAxY2U2MDAwIEphdmFUaHJlYWQgIlN0YXRlIERhdGEgTWFuYWdlciIg ZGFlbW9uIFtfdGhyZWFkX2Jsb2NrZWQsIGlkPS0xNzc3MDY5MTIwLCBzdGFjaygweDAwMDA3 ZmZmZmVmZjQwMDAsMHgwMDAwN2ZmZmZmMGY0MDAwKV0KICAweDAwMDAwMDA4MDFjZTg4MDAg SmF2YVRocmVhZCAiTG93IE1lbW9yeSBEZXRlY3RvciIgZGFlbW9uIFtfdGhyZWFkX2Jsb2Nr ZWQsIGlkPTI5Njc2ODAwLCBzdGFjaygweDAwMDA3ZmZmZmYxZjYwMDAsMHgwMDAwN2ZmZmZm MmY2MDAwKV0KICAweDAwMDAwMDA4MDFjZTkwMDAgSmF2YVRocmVhZCAiQ29tcGlsZXJUaHJl YWQxIiBkYWVtb24gW190aHJlYWRfYmxvY2tlZCwgaWQ9Mjk2NzkwNDAsIHN0YWNrKDB4MDAw MDdmZmZmZjJmNzAwMCwweDAwMDA3ZmZmZmYzZjcwMDApXQogIDB4MDAwMDAwMDgwMWNlYTAw MCBKYXZhVGhyZWFkICJDb21waWxlclRocmVhZDAiIGRhZW1vbiBbX3RocmVhZF9ibG9ja2Vk LCBpZD0yOTY4MTI4MCwgc3RhY2soMHgwMDAwN2ZmZmZmM2Y4MDAwLDB4MDAwMDdmZmZmZjRm ODAwMCldCiAgMHgwMDAwMDAwODAxY2VhODAwIEphdmFUaHJlYWQgIlNpZ25hbCBEaXNwYXRj aGVyIiBkYWVtb24gW190aHJlYWRfYmxvY2tlZCwgaWQ9Mjk2ODM1MjAsIHN0YWNrKDB4MDAw MDdmZmZmZjRmOTAwMCwweDAwMDA3ZmZmZmY1ZjkwMDApXQogIDB4MDAwMDAwMDgwMWNlYjgw MCBKYXZhVGhyZWFkICJGaW5hbGl6ZXIiIGRhZW1vbiBbX3RocmVhZF9ibG9ja2VkLCBpZD0y OTY4NTc2MCwgc3RhY2soMHgwMDAwN2ZmZmZmNWZhMDAwLDB4MDAwMDdmZmZmZjZmYTAwMCld CiAgMHgwMDAwMDAwODAxY2VkMDAwIEphdmFUaHJlYWQgIlJlZmVyZW5jZSBIYW5kbGVyIiBk YWVtb24gW190aHJlYWRfYmxvY2tlZCwgaWQ9Mjk2ODgwMDAsIHN0YWNrKDB4MDAwMDdmZmZm ZjZmYjAwMCwweDAwMDA3ZmZmZmY3ZmIwMDApXQo9PjB4MDAwMDAwMDgwMWNlZDgwMCBKYXZh VGhyZWFkICJtYWluIiBbX3RocmVhZF9pbl9uYXRpdmUsIGlkPTEyNjI3NTIwLCBzdGFjaygw eDAwMDA3ZmZmZmZhZmYwMDAsMHgwMDAwN2ZmZmZmYmZmMDAwKV0KCk90aGVyIFRocmVhZHM6 CiAgMHgwMDAwMDAwODAxZDJmODAwIFZNVGhyZWFkIFtzdGFjazogMHgwMDAwN2ZmZmZmN2Zj MDAwLDB4MDAwMDdmZmZmZjhmYzAwMF0gW2lkPTI5NjkwMjQwXQogIDB4MDAwMDAwMDgwMWQy ZjAwMCBXYXRjaGVyVGhyZWFkIFtzdGFjazogMHgwMDAwN2ZmZmZmMGY1MDAwLDB4MDAwMDdm ZmZmZjFmNTAwMF0gW2lkPTI5Njc1MDA4XQoKVk0gc3RhdGU6bm90IGF0IHNhZmVwb2ludCAo bm9ybWFsIGV4ZWN1dGlvbikKClZNIE11dGV4L01vbml0b3IgY3VycmVudGx5IG93bmVkIGJ5 IGEgdGhyZWFkOiBOb25lCgpIZWFwCiBQU1lvdW5nR2VuICAgICAgdG90YWwgMTQyODQ4Sywg dXNlZCA0NzkyNEsgWzB4MDAwMDAwMDg2YTZhMDAwMCwgMHgwMDAwMDAwODdmNzIwMDAwLCAw eDAwMDAwMDA4OTUxNDAwMDApCiAgZWRlbiBzcGFjZSAxMTE5MzZLLCAxNSUgdXNlZCBbMHgw MDAwMDAwODZhNmEwMDAwLDB4MDAwMDAwMDg2Yjc0MGZhMCwweDAwMDAwMDA4NzEzZjAwMDAp CiAgZnJvbSBzcGFjZSAzMDkxMkssIDk5JSB1c2VkIFsweDAwMDAwMDA4NzQwODAwMDAsMHgw MDAwMDAwODc1ZWFjMWE4LDB4MDAwMDAwMDg3NWViMDAwMCkKICB0byAgIHNwYWNlIDQ1NjMy SywgMCUgdXNlZCBbMHgwMDAwMDAwODcxM2YwMDAwLDB4MDAwMDAwMDg3MTNmMDAwMCwweDAw MDAwMDA4NzQwODAwMDApCiBQU09sZEdlbiAgICAgICAgdG90YWwgMTc0Nzg0SywgdXNlZCA0 NjMxN0sgWzB4MDAwMDAwMDgxNTE0MDAwMCwgMHgwMDAwMDAwODFmYmYwMDAwLCAweDAwMDAw MDA4NmE2YTAwMDApCiAgb2JqZWN0IHNwYWNlIDE3NDc4NEssIDI2JSB1c2VkIFsweDAwMDAw MDA4MTUxNDAwMDAsMHgwMDAwMDAwODE3ZTdiNzc4LDB4MDAwMDAwMDgxZmJmMDAwMCkKIFBT UGVybUdlbiAgICAgICB0b3RhbCA2Njc1MkssIHVzZWQgNjY2MzVLIFsweDAwMDAwMDA4MDUx NDAwMDAsIDB4MDAwMDAwMDgwOTI3MDAwMCwgMHgwMDAwMDAwODE1MTQwMDAwKQogIG9iamVj dCBzcGFjZSA2Njc1MkssIDk5JSB1c2VkIFsweDAwMDAwMDA4MDUxNDAwMDAsMHgwMDAwMDAw ODA5MjUyY2YwLDB4MDAwMDAwMDgwOTI3MDAwMCkKCkR5bmFtaWMgbGlicmFyaWVzOgoweDAw MDAwMDAwMDA0MDAwMDAgCS91c3IvbG9jYWwvb3BlbmpkazYvYmluL2phdmEKMHgwMDAwMDAw ODAwNjUwMDAwIAkvbGliL2xpYnouc28uNQoweDAwMDAwMDA4MDA3NjUwMDAgCS9saWIvbGli dGhyLnNvLjMKMHgwMDAwMDAwODAwODdkMDAwIAkvbGliL2xpYmMuc28uNwoweDAwMDAwMDA4 MDBlMDAwMDAgCS91c3IvbG9jYWwvb3BlbmpkazYvanJlL2xpYi9hbWQ2NC9zZXJ2ZXIvbGli anZtLnNvCjB4MDAwMDAwMDgwMTc3YzAwMCAJL3Vzci9saWIvbGlic3RkYysrLnNvLjYKMHgw MDAwMDAwODAwYWI5MDAwIAkvbGliL2xpYm0uc28uNQoweDAwMDAwMDA4MDE5ODcwMDAgCS9s aWIvbGliZ2NjX3Muc28uMQoweDAwMDAwMDA4MDFhOTQwMDAgCS91c3IvbG9jYWwvb3Blbmpk azYvanJlL2xpYi9hbWQ2NC9saWJ2ZXJpZnkuc28KMHgwMDAwMDAwODAxZTAwMDAwIAkvdXNy L2xvY2FsL29wZW5qZGs2L2pyZS9saWIvYW1kNjQvbGliamF2YS5zbwoweDAwMDAwMDA4MDFm MmIwMDAgCS91c3IvbG9jYWwvb3BlbmpkazYvanJlL2xpYi9hbWQ2NC9uYXRpdmVfdGhyZWFk cy9saWJocGkuc28KMHgwMDAwMDAwODAyMDM3MDAwIAkvdXNyL2xvY2FsL29wZW5qZGs2L2py ZS9saWIvYW1kNjQvbGliemlwLnNvCjB4MDAwMDAwMDg5NWE3NTAwMCAJL3Vzci9sb2NhbC9s aWIvZWNsaXBzZS1kZXZlbC9wbHVnaW5zL29yZy5lY2xpcHNlLmVxdWlub3gubGF1bmNoZXIu Z3RrLmZyZWVic2QueDg2XzY0XzEuMC4yMDAuMjAxMDA1MDUwNjA1L2VjbGlwc2VfMTIwOC5z bwoweDAwMDAwMDA4OTYyMDAwMDAgCS91c3IvbG9jYWwvbGliL2xpYmdvYmplY3QtMi4wLnNv LjAKMHgwMDAwMDAwODk2MzQyMDAwIAkvdXNyL2xvY2FsL2xpYi9saWJnbGliLTIuMC5zby4w CjB4MDAwMDAwMDg5NjRmZTAwMCAJL3Vzci9sb2NhbC9saWIvbGliaW50bC5zby44CjB4MDAw MDAwMDg5NjYwNzAwMCAJL3Vzci9sb2NhbC9saWIvbGliaWNvbnYuc28uMwoweDAwMDAwMDA4 OTY4MDEwMDAgCS91c3IvbG9jYWwvbGliL2xpYnBjcmUuc28uMAoweDAwMDAwMDA4OTY5MzEw MDAgCS91c3IvbG9jYWwvbGliL2xpYmdkay14MTEtMi4wLnNvLjAKMHgwMDAwMDAwODk2YWRi MDAwIAkvdXNyL2xvY2FsL2xpYi9saWJwYW5nb2NhaXJvLTEuMC5zby4wCjB4MDAwMDAwMDg5 NmJlNzAwMCAJL3Vzci9sb2NhbC9saWIvbGlicGFuZ29mdDItMS4wLnNvLjAKMHgwMDAwMDAw ODk2ZDE5MDAwIAkvdXNyL2xvY2FsL2xpYi9saWJwYW5nby0xLjAuc28uMAoweDAwMDAwMDA4 OTZlNjAwMDAgCS91c3IvbG9jYWwvbGliL2xpYlhpbmVyYW1hLnNvLjEKMHgwMDAwMDAwODk2 ZjYyMDAwIAkvdXNyL2xvY2FsL2xpYi9saWJYaS5zby42CjB4MDAwMDAwMDg5NzA3MDAwMCAJ L3Vzci9sb2NhbC9saWIvbGliWHJhbmRyLnNvLjIKMHgwMDAwMDAwODk3MTc4MDAwIAkvdXNy L2xvY2FsL2xpYi9saWJYY3Vyc29yLnNvLjEKMHgwMDAwMDAwODk3MjgyMDAwIAkvdXNyL2xv Y2FsL2xpYi9saWJYY29tcG9zaXRlLnNvLjEKMHgwMDAwMDAwODk3Mzg1MDAwIAkvdXNyL2xv Y2FsL2xpYi9saWJYZXh0LnNvLjYKMHgwMDAwMDAwODk3NDk2MDAwIAkvdXNyL2xvY2FsL2xp Yi9saWJYZGFtYWdlLnNvLjEKMHgwMDAwMDAwODk3NTk4MDAwIAkvdXNyL2xvY2FsL2xpYi9s aWJYZml4ZXMuc28uMwoweDAwMDAwMDA4OTc2OWQwMDAgCS91c3IvbG9jYWwvbGliL2xpYmNh aXJvLnNvLjIKMHgwMDAwMDAwODk3ODE1MDAwIAkvdXNyL2xvY2FsL2xpYi9saWJwaXhtYW4t MS5zby45CjB4MDAwMDAwMDg5Nzk2YTAwMCAJL3Vzci9sb2NhbC9saWIvbGliZm9udGNvbmZp Zy5zby4xCjB4MDAwMDAwMDg5N2E5YzAwMCAJL3Vzci9sb2NhbC9saWIvbGliZnJlZXR5cGUu c28uOQoweDAwMDAwMDA4OTdjMWQwMDAgCS91c3IvbG9jYWwvbGliL2xpYmV4cGF0LnNvLjYK MHgwMDAwMDAwODk3ZDQwMDAwIAkvdXNyL2xvY2FsL2xpYi9saWJwbmcuc28uNgoweDAwMDAw MDA4OTdlNjYwMDAgCS91c3IvbG9jYWwvbGliL2xpYnhjYi1yZW5kZXItdXRpbC5zby4wCjB4 MDAwMDAwMDg5N2Y2OTAwMCAJL3Vzci9sb2NhbC9saWIvbGlieGNiLXJlbmRlci5zby4wCjB4 MDAwMDAwMDg5ODA3MTAwMCAJL3Vzci9sb2NhbC9saWIvbGliWHJlbmRlci5zby4xCjB4MDAw MDAwMDg5ODE3YTAwMCAJL3Vzci9sb2NhbC9saWIvbGliWDExLnNvLjYKMHgwMDAwMDAwODk4 M2E5MDAwIAkvdXNyL2xvY2FsL2xpYi9saWJ4Y2Iuc28uMgoweDAwMDAwMDA4OTg0YzMwMDAg CS91c3IvbG9jYWwvbGliL2xpYlhhdS5zby42CjB4MDAwMDAwMDg5ODVjNjAwMCAJL3Vzci9s b2NhbC9saWIvbGliWGRtY3Auc28uNgoweDAwMDAwMDA4OTg2Y2IwMDAgCS91c3IvbG9jYWwv bGliL2xpYnB0aHJlYWQtc3R1YnMuc28uMAoweDAwMDAwMDA4OTg3Y2MwMDAgCS91c3IvbGli L2xpYnJwY3N2Yy5zby41CjB4MDAwMDAwMDg5ODhkNTAwMCAJL3Vzci9sb2NhbC9saWIvbGli Z2RrX3BpeGJ1Zi0yLjAuc28uMAoweDAwMDAwMDA4OTg5ZWYwMDAgCS91c3IvbG9jYWwvbGli L2xpYmdpby0yLjAuc28uMAoweDAwMDAwMDA4OThiOGMwMDAgCS91c3IvbG9jYWwvbGliL2xp Ymdtb2R1bGUtMi4wLnNvLjAKMHgwMDAwMDAwODk4YzhmMDAwIAkvdXNyL2xvY2FsL2xpYi9s aWJndGsteDExLTIuMC5zby4wCjB4MDAwMDAwMDg5OTE3NzAwMCAJL3Vzci9sb2NhbC9saWIv bGliYXRrLTEuMC5zby4wCjB4MDAwMDAwMDg5OTI5NjAwMCAJL3Vzci9sb2NhbC9saWIvZ3Rr LTIuMC8yLjEwLjAvZW5naW5lcy9saWJjbGVhcmxvb2tzLnNvCjB4MDAwMDAwMDg5OTNiZTAw MCAJL3Vzci9sb2NhbC9saWIvZ3RrLTIuMC9tb2R1bGVzL2xpYmdub21lYnJlYWtwYWQuc28K MHgwMDAwMDAwODk5NGMxMDAwIAkvdXNyL2xpYi9saWJlbGYuc28uMQoweDAwMDAwMDA4OTk1 ZDkwMDAgCS91c3IvbG9jYWwvbGliL2d0ay0yLjAvMi4xMC4wL2xvYWRlcnMvbGlicGl4YnVm bG9hZGVyLWJtcC5zbwoweDAwMDAwMDA4OTk2ZGQwMDAgCS91c3IvbG9jYWwvb3BlbmpkazYv anJlL2xpYi9hbWQ2NC9saWJuZXQuc28KMHgwMDAwMDAwODk5YTAwMDAwIAkvdXNyL2xvY2Fs L29wZW5qZGs2L2pyZS9saWIvYW1kNjQvbGlibmlvLnNvCjB4MDAwMDAwMDg5YmUwMDAwMCAJ L2hvbWUvd3NrLy5lY2xpcHNlL29yZy5lY2xpcHNlLnBsYXRmb3JtXzMuNS4wXzEyMTYzNDIw ODIvY29uZmlndXJhdGlvbi9vcmcuZWNsaXBzZS5vc2dpL2J1bmRsZXMvMTQ0LzEvLmNwL2xp YnN3dC1ndGstMzU1Ny5zbwoweDAwMDAwMDA4OWJmNDUwMDAgCS9ob21lL3dzay8uZWNsaXBz ZS9vcmcuZWNsaXBzZS5wbGF0Zm9ybV8zLjUuMF8xMjE2MzQyMDgyL2NvbmZpZ3VyYXRpb24v b3JnLmVjbGlwc2Uub3NnaS9idW5kbGVzLzE0NC8xLy5jcC9saWJzd3QtcGktZ3RrLTM1NTcu c28KMHgwMDAwMDAwODljMGI1MDAwIAkvdXNyL2xvY2FsL2xpYi9saWJndGhyZWFkLTIuMC5z by4wCjB4MDAwMDAwMDg5YzFiOTAwMCAJL3Vzci9sb2NhbC9saWIvbGliWHRzdC5zby42CjB4 MDAwMDAwMDg5YzM3YjAwMCAJL3Vzci9sb2NhbC9saWIvcGFuZ28vMS42LjAvbW9kdWxlcy9w YW5nby1iYXNpYy1mYy5zbwoweDAwMDAwMDA4OWNlODUwMDAgCS91c3IvbG9jYWwvbGliL2d0 ay0yLjAvMi4xMC4wL2xvYWRlcnMvbGlicGl4YnVmbG9hZGVyLWdpZi5zbwoweDAwMDAwMDA4 OWNmOGIwMDAgCS91c3IvbG9jYWwvbGliL2d0ay0yLjAvMi4xMC4wL2xvYWRlcnMvbGlicGl4 YnVmbG9hZGVyLXBuZy5zbwoweDAwMDAwMDA4OWFhMTIwMDAgCS9ob21lL3dzay8uZWNsaXBz ZS9vcmcuZWNsaXBzZS5wbGF0Zm9ybV8zLjUuMF8xMjE2MzQyMDgyL2NvbmZpZ3VyYXRpb24v b3JnLmVjbGlwc2Uub3NnaS9idW5kbGVzLzI4LzEvLmNwL29zL2ZyZWVic2QveDg2XzY0L2xp YmxvY2FsZmlsZV8xXzBfMC5zbwoweDAwMDAwMDA4OWVlMDAwMDAgCS9ob21lL3dzay8uZWNs aXBzZS9vcmcuZWNsaXBzZS5wbGF0Zm9ybV8zLjUuMF8xMjE2MzQyMDgyL2NvbmZpZ3VyYXRp b24vb3JnLmVjbGlwc2Uub3NnaS9idW5kbGVzLzE0NC8xLy5jcC9saWJzd3QtYXRrLWd0ay0z NTU3LnNvCjB4MDAwMDAwMDhhMDQwMDAwMCAJL2hvbWUvd3NrLy5lY2xpcHNlL29yZy5lY2xp cHNlLnBsYXRmb3JtXzMuNS4wXzEyMTYzNDIwODIvY29uZmlndXJhdGlvbi9vcmcuZWNsaXBz ZS5vc2dpL2J1bmRsZXMvMTQ0LzEvLmNwL2xpYnN3dC1jYWlyby1ndGstMzU1Ny5zbwoweDAw MDAwMDA4OWZjMDAwMDAgCS91c3IvbG9jYWwvbGliL2d0ay0yLjAvaW1tb2R1bGVzL2ltLXNj aW0uc28KMHgwMDAwMDAwOGEwNTBkMDAwIAkvdXNyL2xvY2FsL2xpYi9saWJzY2ltLTEuMC5z by4xMAoweDAwMDAwMDA4YTA3MTAwMDAgCS91c3IvbG9jYWwvbGliL2xpYnNjaW0teDExdXRp bHMtMS4wLnNvLjEwCjB4MDAwMDAwMDhhMDgxMjAwMCAJL3Vzci9sb2NhbC9saWIvc2NpbS0x LjAvMS40LjAvQ29uZmlnL3NvY2tldC5zbwoweDAwMDAwMDA4YTA5MWEwMDAgCS91c3IvbG9j YWwvbGliL3NjaW0tMS4wLzEuNC4wL0lNRW5naW5lL3NvY2tldC5zbwoweDAwMDAwMDA4YTBl ZTcwMDAgCS9ob21lL3dzay8uZWNsaXBzZS9vcmcuZWNsaXBzZS5wbGF0Zm9ybV8zLjUuMF8x MjE2MzQyMDgyL2NvbmZpZ3VyYXRpb24vb3JnLmVjbGlwc2Uub3NnaS9idW5kbGVzLzE0NC8x Ly5jcC9saWJzd3QteHBjb21pbml0LWd0ay0zNTU3LnNvCjB4MDAwMDAwMDhhMTgxODAwMCAJ L3Vzci9sb2NhbC9saWIvbGlieHVsL2xpYnh1bC5zbwoweDAwMDAwMDA4YTE2MDAwMDAgCS91 c3IvbG9jYWwvbGliL2xpYnh1bC9saWJ4cGNvbS5zbwoweDAwMDAwMDA4YTJiYmIwMDAgCS91 c3IvbG9jYWwvbGliL2xpYnBsZHM0LnNvLjEKMHgwMDAwMDAwOGEyY2VkMDAwIAkvdXNyL2xv Y2FsL2xpYi9saWJwbGM0LnNvLjEKMHgwMDAwMDAwOGEyZTIwMDAwIAkvdXNyL2xvY2FsL2xp Yi9saWJuc3ByNC5zby4xCjB4MDAwMDAwMDhhMmY1ODAwMCAJL3Vzci9sb2NhbC9saWIvbGli eHVsL2xpYnNxbGl0ZTMuc28KMHgwMDAwMDAwOGEzMGNlMDAwIAkvdXNyL2xvY2FsL2xpYi9s aWJ4dWwvbGlibW96anMuc28KMHgwMDAwMDAwOGEzMjdhMDAwIAkvdXNyL2xvY2FsL2xpYi9s aWJ4dWwvbGlic21pbWUzLnNvCjB4MDAwMDAwMDhhMzNhMzAwMCAJL3Vzci9sb2NhbC9saWIv bGlieHVsL2xpYnNzbDMuc28KMHgwMDAwMDAwOGEzNGQ2MDAwIAkvdXNyL2xvY2FsL2xpYi9s aWJ4dWwvbGlibnNzMy5zbwoweDAwMDAwMDA4YTM2ZmIwMDAgCS91c3IvbG9jYWwvbGliL2xp Ynh1bC9saWJuc3N1dGlsMy5zbwoweDAwMDAwMDA4YTM4MTgwMDAgCS91c3IvbG9jYWwvbGli L2xpYnh1bC9saWJzb2Z0b2tuMy5zbwoweDAwMDAwMDA4YTM5NTYwMDAgCS91c3IvbG9jYWwv bGliL2xpYlhmdC5zby4yCjB4MDAwMDAwMDhhM2E2OTAwMCAJL3Vzci9sb2NhbC9saWIvbGli WHQuc28uNgoweDAwMDAwMDA4YTE3MDQwMDAgCS91c3IvbG9jYWwvbGliL2xpYlNNLnNvLjYK MHgwMDAwMDAwOGEzYmM5MDAwIAkvdXNyL2xvY2FsL2xpYi9saWJJQ0Uuc28uNgoweDAwMDAw MDA4YTNjZTMwMDAgCS9ob21lL3dzay8uZWNsaXBzZS9vcmcuZWNsaXBzZS5wbGF0Zm9ybV8z LjUuMF8xMjE2MzQyMDgyL2NvbmZpZ3VyYXRpb24vb3JnLmVjbGlwc2Uub3NnaS9idW5kbGVz LzE0NC8xLy5jcC9saWJzd3QteHVscnVubmVyLWd0ay0zNTU3LnNvCjB4MDAwMDAwMDgwMDUw YTAwMCAJL2xpYmV4ZWMvbGQtZWxmLnNvLjEKClZNIEFyZ3VtZW50czoKanZtX2FyZ3M6IC1Y bXMyNTZtIC1YbXgyMDQ4bSAtRG9yZy5lY2xpcHNlLmVxdWlub3gucDIucmVjb25jaWxlci5k cm9waW5zLmRpcmVjdG9yeT0vdXNyL2xvY2FsL3NoYXJlL2VjbGlwc2UtZGV2ZWwvZHJvcGlu cyAtWFg6TWF4UGVybVNpemU9MjU2bSAKamF2YV9jb21tYW5kOiAvdXNyL2xvY2FsL2xpYi9l Y2xpcHNlLWRldmVsLy9wbHVnaW5zL29yZy5lY2xpcHNlLmVxdWlub3gubGF1bmNoZXJfMS4w LjIwMS5SMzV4X3YyMDA5MDcxNS5qYXIgLW9zIGZyZWVic2QgLXdzIGd0ayAtYXJjaCB4ODZf NjQgLXNob3dzcGxhc2ggLWxhdW5jaGVyIC91c3IvbG9jYWwvbGliL2VjbGlwc2UtZGV2ZWwv ZWNsaXBzZSAtbmFtZSBFY2xpcHNlIC0tbGF1bmNoZXIubGlicmFyeSAvdXNyL2xvY2FsL2xp Yi9lY2xpcHNlLWRldmVsL3BsdWdpbnMvb3JnLmVjbGlwc2UuZXF1aW5veC5sYXVuY2hlci5n dGsuZnJlZWJzZC54ODZfNjRfMS4wLjIwMC4yMDEwMDUwNTA2MDUvZWNsaXBzZV8xMjA4LnNv IC1zdGFydHVwIC91c3IvbG9jYWwvbGliL2VjbGlwc2UtZGV2ZWwvL3BsdWdpbnMvb3JnLmVj bGlwc2UuZXF1aW5veC5sYXVuY2hlcl8xLjAuMjAxLlIzNXhfdjIwMDkwNzE1LmphciAtZXhp dGRhdGEgMTAwMTIgLXZtIC91c3IvbG9jYWwvb3BlbmpkazYvYmluL2phdmEgLXZtYXJncyAt WG1zMjU2bSAtWG14MjA0OG0gLURvcmcuZWNsaXBzZS5lcXVpbm94LnAyLnJlY29uY2lsZXIu ZHJvcGlucy5kaXJlY3Rvcnk9L3Vzci9sb2NhbC9zaGFyZS9lY2xpcHNlLWRldmVsL2Ryb3Bp bnMgLVhYOk1heFBlcm1TaXplPTI1Nm0gLWphciAvdXNyL2xvY2FsL2xpYi9lY2xpcHNlLWRl dmVsLy9wbHVnaW5zL29yZy5lY2xpcHNlLmVxdWlub3gubGF1bmNoZXJfMS4wLjIwMS5SMzV4 X3YyMDA5MDcxNS5qYXIKTGF1bmNoZXIgVHlwZTogU1VOX1NUQU5EQVJECgpFbnZpcm9ubWVu dCBWYXJpYWJsZXM6CkpBVkFfSE9NRT0vdXNyL2xvY2FsL29wZW5qZGs2ClBBVEg9L3Vzci9s b2NhbC9vcGVuamRrNi9iaW46L3NiaW46L2JpbjovdXNyL3NiaW46L3Vzci9iaW46L3Vzci9n YW1lczovdXNyL2xvY2FsL3NiaW46L3Vzci9sb2NhbC9iaW4KVVNFUk5BTUU9d3NrCkxEX0xJ QlJBUllfUEFUSD0vdXNyL2xvY2FsL29wZW5qZGs2L2pyZS9saWIvYW1kNjQvc2VydmVyOi91 c3IvbG9jYWwvb3BlbmpkazYvanJlL2xpYi9hbWQ2NDovdXNyL2xvY2FsL29wZW5qZGs2L2py ZS8uLi9saWIvYW1kNjQKU0hFTEw9L2Jpbi9jc2gKRElTUExBWT06MC4wCkhPU1RUWVBFPUZy ZWVCU0QKT1NUWVBFPUZyZWVCU0QKTUFDSFRZUEU9dW5rbm93bgoKU2lnbmFsIEhhbmRsZXJz OgpTSUdTRUdWOiBbbGlianZtLnNvKzB4NmMwMWMwXSwgc2FfbWFza1swXT0weGZmZmVmZWZm LCBzYV9mbGFncz0weDAwMDAwMDQyClNJR0JVUzogW2xpYmp2bS5zbysweDZjMDFjMF0sIHNh X21hc2tbMF09MHhmZmZlZmVmZiwgc2FfZmxhZ3M9MHgwMDAwMDA0MgpTSUdGUEU6IFNJR19J R04sIHNhX21hc2tbMF09MHgwMDAwMDAwMCwgc2FfZmxhZ3M9MHgwMDAwMDAwMgpTSUdQSVBF OiBTSUdfSUdOLCBzYV9tYXNrWzBdPTB4MDAwMDAwMDAsIHNhX2ZsYWdzPTB4MDAwMDAwMDAK U0lHWEZTWjogW2xpYmp2bS5zbysweDU4ZDAyMF0sIHNhX21hc2tbMF09MHhmZmZlZmVmZiwg c2FfZmxhZ3M9MHgwMDAwMDA0MgpTSUdJTEw6IFtsaWJqdm0uc28rMHg1OGQwMjBdLCBzYV9t YXNrWzBdPTB4ZmZmZWZlZmYsIHNhX2ZsYWdzPTB4MDAwMDAwNDIKU0lHVVNSMTogU0lHX0RG TCwgc2FfbWFza1swXT0weDAwMDAwMDAwLCBzYV9mbGFncz0weDAwMDAwMDAwClNJR1VTUjI6 IFtsaWJqdm0uc28rMHg1OGY4ZjBdLCBzYV9tYXNrWzBdPTB4MDAwMDAwMDAsIHNhX2ZsYWdz PTB4MDAwMDAwNDIKU0lHSFVQOiBbbGlianZtLnNvKzB4NThmNjkwXSwgc2FfbWFza1swXT0w eGZmZmVmZWZmLCBzYV9mbGFncz0weDAwMDAwMDQyClNJR0lOVDogW2xpYmp2bS5zbysweDU4 ZjY5MF0sIHNhX21hc2tbMF09MHhmZmZlZmVmZiwgc2FfZmxhZ3M9MHgwMDAwMDA0MgpTSUdU RVJNOiBbbGlianZtLnNvKzB4NThmNjkwXSwgc2FfbWFza1swXT0weGZmZmVmZWZmLCBzYV9m bGFncz0weDAwMDAwMDQyClNJR1FVSVQ6IFtsaWJqdm0uc28rMHg1OGY2OTBdLCBzYV9tYXNr WzBdPTB4ZmZmZWZlZmYsIHNhX2ZsYWdzPTB4MDAwMDAwNDIKCgotLS0tLS0tLS0tLS0tLS0g IFMgWSBTIFQgRSBNICAtLS0tLS0tLS0tLS0tLS0KCk9TOkJzZAp1bmFtZTpGcmVlQlNEIDgu MC1TVEFCTEUgRnJlZUJTRCA4LjAtU1RBQkxFICMxMDogTW9uIEFwciAyNiAyMjo0MDozOCBD U1QgMjAxMCAgICAgd3NrQGxwLmdkZHNuLm9yZy5jbjovdXNyL29iai91c3Ivc3JjL3N5cy9X U0sgYW1kNjQKcmxpbWl0OiBTVEFDSyA1MjQyODhrLCBDT1JFIGluZmluaXR5LCBOUFJPQyA1 NTQ3LCBOT0ZJTEUgMTEwOTUKQ1BVOnRvdGFsIDIgKDIgY29yZXMgcGVyIGNwdSwgMSB0aHJl YWRzIHBlciBjb3JlKSBmYW1pbHkgNiBtb2RlbCAxNSBzdGVwcGluZyAxMCwgY21vdiwgY3g4 LCBmeHNyLCBtbXgsIHNzZSwgc3NlMiwgc3NlMywgc3NzZTMKCk1lbW9yeTogNGsgcGFnZSwg cGh5c2ljYWwgMzU1NDc0NGsoODg4Njg2ayBmcmVlKQoKdm1faW5mbzogT3BlbkpESyA2NC1C aXQgU2VydmVyIFZNICgxNC4wLWIxNikgZm9yIGJzZC1hbWQ2NCBKUkUgKDEuNi4wLWIxNyks IGJ1aWx0IG9uIEFwciAgOCAyMDEwIDExOjQzOjA0IGJ5ICJyb290IiB3aXRoIGdjYyA0LjIu MSAyMDA3MDcxOSAgW0ZyZWVCU0RdCgp0aW1lOiBGcmkgTWF5ICA3IDEzOjAyOjI5IDIwMTAK ZWxhcHNlZCB0aW1lOiA1MCBzZWNvbmRzCgo= --------------070705000002050306020901-- From owner-freebsd-stable@FreeBSD.ORG Fri May 7 05:55:02 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A9AA21065670 for ; Fri, 7 May 2010 05:55:02 +0000 (UTC) (envelope-from fbsdq@peterk.org) Received: from poshta.pknet.net (poshta.pknet.net [216.241.167.213]) by mx1.freebsd.org (Postfix) with ESMTP id 4A69F8FC17 for ; Fri, 7 May 2010 05:55:01 +0000 (UTC) Received: (qmail 38115 invoked by uid 89); 7 May 2010 05:55:01 -0000 Received: from poshta.pknet.net (HELO pop.pknet.net) (216.241.167.213) by poshta.pknet.net with SMTP; 7 May 2010 05:55:01 -0000 Received: from 216.241.170.11 (SquirrelMail authenticated user fbsdq@peterk.org) by pop.pknet.net with HTTP; Thu, 6 May 2010 23:55:01 -0600 Message-ID: <0e6d2f091a02dcd04a6682f4c9b55490.squirrel@pop.pknet.net> Date: Thu, 6 May 2010 23:55:01 -0600 From: "Peter" To: freebsd-stable@freebsd.org User-Agent: SquirrelMail/1.4.20-RC2 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Subject: panic: spin lock held too long 8.0-STABLE r207638 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 07 May 2010 05:55:02 -0000 iH, Got a system that whenever I launch another Virtualbox instance, it will panic anywhere from 10 minutes to several days. I was able to get this system to panic constantly yesterday by trying to install Windows 2008, or after it was eventually installed, it only ran for ~45 minutes before panic. Some installs panic at around 2% done, most at ~80% and one actually completed. Trying to figure out if it's my hardware or what. I used to have a Windows XP VM running alongside, and the panics happened about once a week - eventually I got lazy and didn't start the XP VM. [less load and no swap usage, and no panics for 1.5 months until yesterday] Yesterday I tried to install Windows 2008, and in the ~6 hours I was messing around, it panicked around 8 times [after random amounts of time] panic: spin lock held too long [cpuid either 2,3, or 4 as far as I remember] 4GB of RAM AMD X4 CPU 8.0-STABLE r207638 amd64 vbox 3.1.6 mostly GENERIC kernel [sched_ule], with firewall/altq compiled in and unneccessary hardware removed from kernel config. With just one VM [FreeBSD 8-stable, 2 CPU 2GB RAM] the system runs fine for months. [it's also a file/print server] As soon as I try to get a Windows VM running on there, and it starts using some swap, anywhere from 20MB to 150MB it eventually panics [usually within an hour or so]. Any ideas ? hardware issues? Anyone successfull in running several VMs on FreeBSD -> VirtualBox ? [overloading it?] ]Peter[ From owner-freebsd-stable@FreeBSD.ORG Fri May 7 15:24:42 2010 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B2A511065670; Fri, 7 May 2010 15:24:42 +0000 (UTC) (envelope-from mclone@gmail.com) Received: from mail-pv0-f182.google.com (mail-pv0-f182.google.com [74.125.83.182]) by mx1.freebsd.org (Postfix) with ESMTP id 769368FC08; Fri, 7 May 2010 15:24:42 +0000 (UTC) Received: by pvc30 with SMTP id 30so564222pvc.13 for ; Fri, 07 May 2010 08:24:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:mime-version:received:from:date :message-id:subject:to:cc:content-type; bh=hycKukE5hovbtbYUBU0S3+QOc+b+M8CVeXB9DYoBamw=; b=rzEql7FidIJVfbWRLv6k7G5vawTmgIpd3XLkn4fFoiVve2SQ/4XVHKUA1Gy3ryqibo sh8BO3E7chyrqwvdg6C5G1psYBb5v0EmR0wX2jfTjy//G07klHZj7MErf5O5pJ1SsDtV CP6kZifua8whYqJKsqiyi/xLhmJgFzTgiKal0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:from:date:message-id:subject:to:cc:content-type; b=lGUDQG6WkCd/oDaKUs7dvn0c99jQWYg+MxoD9kBvqb+vHddfA2DpKnqJFJIXHX4Ebe 28+URSZ/E5EX+4THLU2SAIkhCuieuzfGjhTEbFF2tnfsKUHUXXgAiW5mEZrWHo+mXIxP wvXiS/7F65mwcKVnCr8G+MVAqV1ITjnCMC4DE= Received: by 10.142.56.14 with SMTP id e14mr108091wfa.37.1273244123095; Fri, 07 May 2010 07:55:23 -0700 (PDT) MIME-Version: 1.0 Received: by 10.142.101.19 with HTTP; Fri, 7 May 2010 07:55:02 -0700 (PDT) From: McLone Date: Fri, 7 May 2010 17:55:02 +0300 Message-ID: To: current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Cc: network@freebsd.org, stable@freebsd.org Subject: if_re regression on RELENG_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: Fri, 07 May 2010 15:24:42 -0000 Hell Low. When Vista finally died on my girl's notebook, she asked me to install FreeBSD on it, so no more viruses. I installed RELENG_8_0/i386, to compile fresh RELENG_8/amd64 in hopes SUJ will be availible (2gb RAM is kinda too small for ZFS). I've built custom kernel (GENERIC with unneeded things nodevice'd) and rebooted it, kldload if_re, ifcionfig, so ping started to work. I then attempted to mount_nfs, but it hung. "re0: watchdog timeout" appeared on console. So the thing is, re0 stops working after sending any packet longer than 536 bytes. I tested via ping, -S (536-8) works, but (537-8) leads to watchdog timeout. The host cannot be software rebooted in ~80% cases after it happened. Machine in question is Fujitsu-Siemens Amilo Pi 2540. The lines from RELENG_8 dmesg are: re0: port 0x3000-0x30ff mem 0xf0300000-0xf0300fff irq 19 at device 0.0 on pci5 re0: Reserved 0x1000 bytes for rid 0x18 type 3 at 0xf0300000 re0: MSI count : 2 re0: attempting to allocate 1 MSI vectors (2 supported) re0: using IRQ 256 for MSI re0: Using 1 MSI messages re0: Chip rev. 0x34000000 re0: MAC rev. 0x00000000 miibus0: on re0 re0: bpf attached re0: Ethernet address: 00:03:0d:a1:a8:19 re0: [MPSAFE] re0: [FILTER] Those lines in RELENG_8_0 are the same except IRQ 259 (i kldload if_re after boot). RELENG_8 is from 2010.05.04 i believe; had tried with sources as of 2 or 3 weeks earlier - same bug. No CFLAGS except -mtune=native (i doubt it does the weather). It doesn't matter if i kldload or just use GENERIC. How can i test further, except building fresh RELENG_8/i386? How to use a magic "DDB key" and what to input in there? p.s. I subscribed only to current@ so cc me if needed. -- wbr, |\ _,,,---,,_ dog bless ya! ` Zzz /,`.-'`' -. ;-;;,_ McLone at GMail dot com |,4- ) )-,_. ,\ ( `'-' net- and *BSD admin '---''(_/--' `-'\_) ...translit rawx! From owner-freebsd-stable@FreeBSD.ORG Fri May 7 16:27:03 2010 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 05EF6106567B for ; Fri, 7 May 2010 16:27:03 +0000 (UTC) (envelope-from christian.baer@uni-dortmund.de) Received: from dd17730.kasserver.com (dd17730.kasserver.com [85.13.138.103]) by mx1.freebsd.org (Postfix) with ESMTP id BAD848FC1B for ; Fri, 7 May 2010 16:27:02 +0000 (UTC) Received: from nermal.rz1.convenimus.net (f049055153.adsl.alicedsl.de [78.49.55.153]) by dd17730.kasserver.com (Postfix) with ESMTP id 25780186AD793 for ; Fri, 7 May 2010 18:05:59 +0200 (CEST) Received: from [192.168.100.7] (arlene.rz1.convenimus.net [192.168.100.7]) by nermal.rz1.convenimus.net (Postfix) with ESMTP id 5E30A15210 for ; Fri, 7 May 2010 18:01:27 +0200 (CEST) Message-ID: <4BE43A64.9000704@uni-dortmund.de> Date: Fri, 07 May 2010 18:05:56 +0200 From: Christian Baer User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.9) Gecko/20100317 Lightning/1.0b1 Thunderbird/3.0.4 MIME-Version: 1.0 To: stable@freebsd.org X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Subject: screwed up permissions in tree X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 07 May 2010 16:27:03 -0000 Hi there people! I guess I really screwed up the rights within my source-tree (and maybe share too). It all started pretty innocent. :-) I wanted to encrypt /usr and /var, which are both mounted on dedicated partions on this machine. There was still one unused partition, which I will call (and mount) /enctmp for the steps I took. This is how I did it: - cp -rpv /usr/* /enctmp - change fstab so that after a reboot /usr will be where /enctemp is now - reboot - geli init -b -e AES -l 256 [device] - geli attach [device] - newfs [device] - mount [device] /enctmp - cp -rpv /usr/* /enctemp - change fstab back to the old device, adding .eli - reboot I did the same steps for var. Note: I also have an own partition for /usr/obj/ (on a different drive). Now when booting, I am asked for a passwort twice and the system works fine - as far as I can tell, since I have only just set it up. What doesn't work, is installing world! :-O I went to /usr/src/, did a make buildworld and make buildkernel (both of which worked). Even make installkernel worked, just the world refuses to be installed: -------------------------------------------------------------- >>> Making hierarchy -------------------------------------------------------------- cd /usr/src; make -f Makefile.inc1 hierarchy cd /usr/src/etc; make distrib-dirs mtree -eU -f /usr/src/etc/mtree/BSD.root.dist -p / mtree -eU -f /usr/src/etc/mtree/BSD.var.dist -p /var mtree -eU -f /usr/src/etc/mtree/BSD.usr.dist -p /usr mtree -eU -f /usr/src/etc/mtree/BSD.include.dist -p /usr/include mtree -deU -f /usr/src/etc/mtree/BSD.sendmail.dist -p / cd /; rm -f /sys; ln -s usr/src/sys sys cd /usr/share/man/en.ISO8859-1; ln -sf ../man* . ln: ./man1: Operation not permitted ln: ./man1aout: Operation not permitted ln: ./man2: Operation not permitted ln: ./man3: Operation not permitted ln: ./man4: Operation not permitted ln: ./man5: Operation not permitted ln: ./man6: Operation not permitted ln: ./man7: Operation not permitted ln: ./man8: Operation not permitted ln: ./man9: Operation not permitted *** Error code 1 Stop in /usr/src/etc. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. It would seem that somewhere in this copy-orgy, some file or directory permissions (or ownership?) got messed up. Is there a way to correct this (preferably automagically)? If rebuilding /usr/src is all it takes, no problem, I have a DSL. It will take a while, but it won't kill me. :-) Is there any documentation about what the ownerships and permissions should be? Best regards from Germany, Chris From owner-freebsd-stable@FreeBSD.ORG Fri May 7 17:21:40 2010 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 664EF1065674 for ; Fri, 7 May 2010 17:21:40 +0000 (UTC) (envelope-from swhetzel@gmail.com) Received: from mail-wy0-f182.google.com (mail-wy0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id F033C8FC23 for ; Fri, 7 May 2010 17:21:39 +0000 (UTC) Received: by wyb36 with SMTP id 36so1086296wyb.13 for ; Fri, 07 May 2010 10:21:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=dz7ofkOLJdL0UFm1inqoKgNF7tiVlc86WfwXxaUrMUg=; b=pSYr/SiAoEL0p+LDVLJWfh9Lr5XZ1JIKK/+od1Z+V+AFnifzu6f0TBRQhnQn/xqk0x 0WbC1Sr7XTu+ud69y478U3AuEj9frqxVFQCkNVFU/eGb7nCxI2St27vPph9nfswOmrnx K3ORRAccL+6qU8ChT63vwo1biza+gUbdjwhoY= 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:content-transfer-encoding; b=ww4wXE6QjGkRtGr/N+kp9XzOPpi4jXvvX84yFZ5YNlzq3rYpTd2hRiaiXdflPazQXz kG+PKjJv4LP71UAvmFoIhkxMnaxW79Du7bodttTkt3mcF0LoQMws/mPupg3Y9uaYBjKF EdXVvmkuSy+LHxg11UIWK2FBz5B3HkW7GRtaI= MIME-Version: 1.0 Received: by 10.216.93.74 with SMTP id k52mr193026wef.228.1273251251393; Fri, 07 May 2010 09:54:11 -0700 (PDT) Received: by 10.216.28.3 with HTTP; Fri, 7 May 2010 09:54:11 -0700 (PDT) In-Reply-To: <4BE43A64.9000704@uni-dortmund.de> References: <4BE43A64.9000704@uni-dortmund.de> Date: Fri, 7 May 2010 11:54:11 -0500 Message-ID: From: Scot Hetzel To: Christian Baer Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: stable@freebsd.org Subject: Re: screwed up permissions in tree X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 07 May 2010 17:21:40 -0000 On Fri, May 7, 2010 at 11:05 AM, Christian Baer wrote: > Hi there people! > > I guess I really screwed up the rights within my source-tree (and maybe > share too). It all started pretty innocent. :-) > > I wanted to encrypt /usr and /var, which are both mounted on dedicated > partions on this machine. There was still one unused partition, which I > will call (and mount) /enctmp for the steps I took. This is how I did it: > > - cp -rpv /usr/* /enctmp This is where you went wrong. -r =3D -RL (see cp(1) man page). This caused cp change the symbolic links to directories. You should have used either: cp -Rpv /usr/* /enctmp or used tar: tar -cf -cf - -C /usr/ . | tar -xpf - -C destdir NOTE: tar would have preserved the hardlinks. > What doesn't work, is installing world! :-O I went to /usr/src/, did a > make buildworld and make buildkernel (both of which worked). Even make > installkernel worked, just the world refuses to be installed: > > -------------------------------------------------------------- >>>> Making hierarchy > -------------------------------------------------------------- > cd /usr/src; make -f Makefile.inc1 hierarchy > cd /usr/src/etc; =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0make distrib-dirs > mtree -eU =A0-f /usr/src/etc/mtree/BSD.root.dist -p / > mtree -eU =A0-f /usr/src/etc/mtree/BSD.var.dist -p /var > mtree -eU =A0-f /usr/src/etc/mtree/BSD.usr.dist -p /usr > mtree -eU =A0-f /usr/src/etc/mtree/BSD.include.dist =A0-p /usr/include > mtree -deU =A0-f /usr/src/etc/mtree/BSD.sendmail.dist -p / > cd /; rm -f /sys; ln -s usr/src/sys sys > cd /usr/share/man/en.ISO8859-1; ln -sf ../man* . > ln: ./man1: Operation not permitted > ln: ./man1aout: Operation not permitted > ln: ./man2: Operation not permitted > ln: ./man3: Operation not permitted > ln: ./man4: Operation not permitted > ln: ./man5: Operation not permitted > ln: ./man6: Operation not permitted > ln: ./man7: Operation not permitted > ln: ./man8: Operation not permitted > ln: ./man9: Operation not permitted The problem here is that these are now directories, instead of links. Your /usr/share/man/en.ISO8859-1 shoud look like: # ls -l /usr/share/man/en.ISO8859-1 total 20 drwxr-xr-x 2 man wheel 2 Feb 7 09:47 cat1 drwxr-xr-x 2 man wheel 2 Feb 7 09:47 cat1aout drwxr-xr-x 2 man wheel 2 Feb 7 09:47 cat2 drwxr-xr-x 2 man wheel 2 Feb 7 09:47 cat3 drwxr-xr-x 7 man wheel 7 Feb 7 09:47 cat4 drwxr-xr-x 2 man wheel 2 Feb 7 09:47 cat5 drwxr-xr-x 2 man wheel 2 Feb 7 09:47 cat6 drwxr-xr-x 2 man wheel 2 Feb 7 09:47 cat7 drwxr-xr-x 6 man wheel 6 Feb 7 09:47 cat8 drwxr-xr-x 2 man wheel 2 Feb 7 09:47 cat9 lrwxr-xr-x 1 root wheel 7 May 6 07:24 man1 -> ../man1 lrwxr-xr-x 1 root wheel 11 May 6 07:24 man1aout -> ../man1aout lrwxr-xr-x 1 root wheel 7 May 6 07:24 man2 -> ../man2 lrwxr-xr-x 1 root wheel 7 May 6 07:24 man3 -> ../man3 lrwxr-xr-x 1 root wheel 7 May 6 07:24 man4 -> ../man4 lrwxr-xr-x 1 root wheel 7 May 6 07:24 man5 -> ../man5 lrwxr-xr-x 1 root wheel 7 May 6 07:24 man6 -> ../man6 lrwxr-xr-x 1 root wheel 7 May 6 07:24 man7 -> ../man7 lrwxr-xr-x 1 root wheel 7 May 6 07:24 man8 -> ../man8 lrwxr-xr-x 1 root wheel 7 May 6 07:24 man9 -> ../man9 To fix this, just delete the man1* - man9 directories, and run make installworld. Since /usr/share/man is not needed during an installworld, the best solution to recover diskspace is to remove this directory: cd /usr/src rm -rf /usr/share/man make installworld This would let installworld recreate the man hierarchy. NOTE: There might be other locations where symbolic links were changed to directories, just remove those directories and re-run 'make installworld'. Scot From owner-freebsd-stable@FreeBSD.ORG Fri May 7 17:36:00 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 7740C1065670 for ; Fri, 7 May 2010 17:36:00 +0000 (UTC) (envelope-from mattjreimer@gmail.com) Received: from mail-yw0-f181.google.com (mail-yw0-f181.google.com [209.85.211.181]) by mx1.freebsd.org (Postfix) with ESMTP id 32A2F8FC08 for ; Fri, 7 May 2010 17:35:59 +0000 (UTC) Received: by ywh11 with SMTP id 11so771018ywh.7 for ; Fri, 07 May 2010 10:35:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=u8DAUlcSDMFZxjYJI6ZY9ECDJgSI9Y/xO7V8QftsXxs=; b=JpBXF82sCmbKpJq4Nx8Wkdj/iakZIM4eVxJvCrmTKj28M338qH770p8SJ7os0kE8Kz rq7S+xHS9cwr0mYc04rxbrsUP3YjKn65iiG/Wa+bY0k8rhH5Sp1+r3leKzk3/K02NIgo 7OomV8vNHb1aJhXT5QH/TU9YF1BwCcCf/2bNk= 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:content-transfer-encoding; b=tk+ddLegSE9RdrT1i5dZjAwb7rWle5rLi9pta3XiQjdSoTx3gpsx/y+DfEpuNOEIxG aCkDXZ2D11cNibzhmDQ22ifWyYQtf8T7+cYBjbyl402p2c/K/kATL/Ymfg15Vplvvxxn MECAGHoODX63rEI5U9Ka4zUQ5Jv0M+teHsfec= MIME-Version: 1.0 Received: by 10.150.170.2 with SMTP id s2mr2353626ybe.379.1273253747758; Fri, 07 May 2010 10:35:47 -0700 (PDT) Received: by 10.150.192.4 with HTTP; Fri, 7 May 2010 10:35:47 -0700 (PDT) In-Reply-To: <6B44BF0945694D98BC060164D404B5A9@multiplay.co.uk> References: <6B44BF0945694D98BC060164D404B5A9@multiplay.co.uk> Date: Fri, 7 May 2010 10:35:47 -0700 Message-ID: From: Matt Reimer To: Steven Hartland Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-hackers@freebsd.org, freebsd-stable@freebsd.org Subject: Re: nginx + passenger = segv in _rtld_error on restart on FreeBSD 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: Fri, 07 May 2010 17:36:00 -0000 On Tue, Dec 8, 2009 at 6:48 PM, Steven Hartland w= rote: > I'm currently testing nginx + passenger on FreeBSD 8.0 and I'm seeing a > strange > segv which seems to indicate a core library error in _rtld_error. Could t= his > be the case or is the stack just badly corrupted? > > (gdb) bt > #0 =A00x00000008005577dc in _rtld_error () from /libexec/ld-elf.so.1 > #1 =A00x0000000800557c3f in _rtld_error () from /libexec/ld-elf.so.1 > #2 =A00x0000000800557d5e in _rtld_error () from /libexec/ld-elf.so.1 > #3 =A00x000000080055851b in dladdr () from /libexec/ld-elf.so.1 > #4 =A00x00000008005585f3 in dladdr () from /libexec/ld-elf.so.1 > #5 =A00x000000080055576d in ?? () from /libexec/ld-elf.so.1 > #6 =A00x0000000000000001 in ?? () > #7 =A00x00000000004117f8 in > boost::detail::sp_counted_impl_p= ::dispose > (this=3D0x800768980) at sp_counted_impl.hpp:78 > Previous frame inner to this frame (corrupt stack?) > > =A0 Regards > =A0 Steve Steve, Did you figure this out? We're seeing something very similar with nginx + passenger + FreeBSD 8.0. Matt From owner-freebsd-stable@FreeBSD.ORG Fri May 7 18:33:58 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 1789A1065771 for ; Fri, 7 May 2010 18:33:58 +0000 (UTC) (envelope-from demelier.david@gmail.com) Received: from mail-ww0-f54.google.com (mail-ww0-f54.google.com [74.125.82.54]) by mx1.freebsd.org (Postfix) with ESMTP id 9178A8FC1B for ; Fri, 7 May 2010 18:33:57 +0000 (UTC) Received: by wwb39 with SMTP id 39so1049322wwb.13 for ; Fri, 07 May 2010 11:33:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:subject:from:to:cc :in-reply-to:references:content-type:date:message-id:mime-version :x-mailer:content-transfer-encoding; bh=c95g+U00L4Po+Xadyjc3/QFeq/jC7Ud2bcqxPbFRUd8=; b=Exv/O9bdcc4LmdueHM0DFY+a0FvP1AoqPVfMFWvrJApystvi8wFHmdxdnCOogtapsj 3Oa9Oqt9Hj1658Y2uhquunJiP+Zg4Jw4Ow88/vTlbZm+gKjflXg6O0Qphm0bj285zW2J l9BOzf0tHiaRIXRS1RljT3gRY9ucoPJdibAvE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:from:to:cc:in-reply-to:references:content-type:date :message-id:mime-version:x-mailer:content-transfer-encoding; b=pASNAQ1NfFaNz5gPXwl3B1/Gb95FPAnFZiFSjGfJzw1e7MxQlH+qyixQr9MsJAPROZ H3gtyT7ot0J9T7KbQkAEI+4nQlqCvD/J0VhlyBBO3hdRjkH9cprq54RJ8QOsneRgrTCP vFAPEYAATuhsdLcxWIXeirhOuN6ZhoM8GAJT8= Received: by 10.227.127.145 with SMTP id g17mr398465wbs.152.1273257232994; Fri, 07 May 2010 11:33:52 -0700 (PDT) Received: from [192.168.1.23] (121.21.102-84.rev.gaoland.net [84.102.21.121]) by mx.google.com with ESMTPS id k13sm1180190wed.11.2010.05.07.11.33.51 (version=SSLv3 cipher=RC4-MD5); Fri, 07 May 2010 11:33:52 -0700 (PDT) From: Demelier David To: Giovanni Trematerra In-Reply-To: References: <4DEBDE2C-C0D2-469D-AC42-DD5027926424@FreeBSD.org> <96F538BA-488A-46B3-99A0-BC324DB0F73A@FreeBSD.org> <20100505135743.GA1613@Melon.malikania.fr> <20100507120843.GA1738@Melon.malikania.fr> Content-Type: text/plain; charset="UTF-8" Date: Fri, 07 May 2010 20:33:46 +0200 Message-ID: <1273257226.1671.3.camel@malikania.fr> Mime-Version: 1.0 X-Mailer: Evolution 2.28.2 FreeBSD GNOME Team Port Content-Transfer-Encoding: 8bit Cc: freebsd-stable@freebsd.org Subject: Re: Kernel panic when unpluggin AC adaptor X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 07 May 2010 18:33:58 -0000 Le Vendredi 07 mai 2010 à 18:22 +0200, Giovanni Trematerra a écrit : > On Fri, May 7, 2010 at 2:08 PM, Demelier David wrote: > > Hi, > > I noticed that pluggin the AC adaptor when I boot without it does not > > panic. It only panic when removing it. > > > > Maybe that could help ? > > > > Good to know. The problem lies somewhere when performance state change. > In your case it happens when you remove AC adaptor. Let's hope someone on > acpi@ ml comes up with a good idea. > Okay so for the moment no change, I'll wait for someone with an idea that could solve my problem. For me because the panic only happens when changing profile from ac plugged -> ac unplugged (and not the reverse) I would think it's a cpu related acpi issue. David. From owner-freebsd-stable@FreeBSD.ORG Fri May 7 18:56:53 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A28F4106568F for ; Fri, 7 May 2010 18:56:53 +0000 (UTC) (envelope-from steinex@nognu.de) Received: from mail-ew0-f224.google.com (mail-ew0-f224.google.com [209.85.219.224]) by mx1.freebsd.org (Postfix) with ESMTP id 437198FC28 for ; Fri, 7 May 2010 18:56:52 +0000 (UTC) Received: by ewy24 with SMTP id 24so339163ewy.33 for ; Fri, 07 May 2010 11:56:43 -0700 (PDT) Received: by 10.213.46.13 with SMTP id h13mr4076320ebf.83.1273256884634; Fri, 07 May 2010 11:28:04 -0700 (PDT) Received: from haydn.nognu.de (haydn.nognu.de [81.169.170.112]) by mx.google.com with ESMTPS id 13sm1257429ewy.9.2010.05.07.11.28.03 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 07 May 2010 11:28:03 -0700 (PDT) Date: Fri, 7 May 2010 20:28:01 +0200 From: Frank Steinborn To: freebsd-stable@freebsd.org Message-ID: <20100507182801.GA46463@haydn.nognu.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable User-Agent: Mutt/1.5.20 (2009-06-14) Subject: Regression in PORTS_MODULES (make.conf)? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 07 May 2010 18:56:53 -0000 Hello, I have the following in /etc/make.conf: PORTS_MODULES=3D sysutils/fusefs-kmod \ emulators/virtualbox-ose-kmod On buildworld, it claims: env: ruby: not found=20 However, ruby is installed and in PATH. I've seen a similar issue lately but wasn't sure if it's just a problem in my configuration. Do you think this is PR-worthy? Thanks, Frank From owner-freebsd-stable@FreeBSD.ORG Fri May 7 19:26:07 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 01B4A106566C for ; Fri, 7 May 2010 19:26:07 +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 D6D148FC08 for ; Fri, 7 May 2010 19:26:06 +0000 (UTC) Received: from omta17.emeryville.ca.mail.comcast.net ([76.96.30.73]) by qmta12.emeryville.ca.mail.comcast.net with comcast id Eddn1e0051afHeLACjS75X; Fri, 07 May 2010 19:26:07 +0000 Received: from koitsu.dyndns.org ([98.248.46.159]) by omta17.emeryville.ca.mail.comcast.net with comcast id EjS61e00C3S48mS8djS76C; Fri, 07 May 2010 19:26:07 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id AED609B425; Fri, 7 May 2010 12:26:05 -0700 (PDT) Date: Fri, 7 May 2010 12:26:05 -0700 From: Jeremy Chadwick To: Demelier David Message-ID: <20100507192605.GA62650@icarus.home.lan> References: <20100505135743.GA1613@Melon.malikania.fr> <20100507120843.GA1738@Melon.malikania.fr> <1273257226.1671.3.camel@malikania.fr> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <1273257226.1671.3.camel@malikania.fr> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: Giovanni Trematerra , freebsd-stable@freebsd.org Subject: Re: Kernel panic when unpluggin AC adaptor X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 07 May 2010 19:26:07 -0000 On Fri, May 07, 2010 at 08:33:46PM +0200, Demelier David wrote: > Le Vendredi 07 mai 2010 à 18:22 +0200, Giovanni Trematerra a écrit : > > On Fri, May 7, 2010 at 2:08 PM, Demelier David wrote: > > > Hi, > > > I noticed that pluggin the AC adaptor when I boot without it does not > > > panic. It only panic when removing it. > > > > > > Maybe that could help ? > > > > > > > Good to know. The problem lies somewhere when performance state change. > > In your case it happens when you remove AC adaptor. Let's hope someone on > > acpi@ ml comes up with a good idea. > > > > Okay so for the moment no change, I'll wait for someone with an idea > that could solve my problem. For me because the panic only happens when > changing profile from ac plugged -> ac unplugged (and not the reverse) I > would think it's a cpu related acpi issue. This is one of the reasons why I asked you to provide sysctl dev.cpu output (which you did -- thanks!). There's a known situation where CPUs going into C3 (but not C1 or C2) state causes problems. In your case your CPUs only advertise up to C2, so you're unaffected by that issue. -- | 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 May 7 19:29:25 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B3417106566C for ; Fri, 7 May 2010 19:29:25 +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 9C3EC8FC0C for ; Fri, 7 May 2010 19:29:25 +0000 (UTC) Received: from omta09.emeryville.ca.mail.comcast.net ([76.96.30.20]) by qmta04.emeryville.ca.mail.comcast.net with comcast id Ecdo1e0060S2fkCA4jVSem; Fri, 07 May 2010 19:29:26 +0000 Received: from koitsu.dyndns.org ([98.248.46.159]) by omta09.emeryville.ca.mail.comcast.net with comcast id EjVR1e0073S48mS8VjVR7u; Fri, 07 May 2010 19:29:25 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 1A6F39B425; Fri, 7 May 2010 12:29:24 -0700 (PDT) Date: Fri, 7 May 2010 12:29:24 -0700 From: Jeremy Chadwick To: Frank Steinborn Message-ID: <20100507192924.GB62650@icarus.home.lan> References: <20100507182801.GA46463@haydn.nognu.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100507182801.GA46463@haydn.nognu.de> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: freebsd-stable@freebsd.org Subject: Re: Regression in PORTS_MODULES (make.conf)? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 07 May 2010 19:29:25 -0000 On Fri, May 07, 2010 at 08:28:01PM +0200, Frank Steinborn wrote: > Hello, > > I have the following in /etc/make.conf: > > PORTS_MODULES= sysutils/fusefs-kmod \ > emulators/virtualbox-ose-kmod > > On buildworld, it claims: > > env: ruby: not found > > However, ruby is installed and in PATH. I've seen a similar issue > lately but wasn't sure if it's just a problem in my configuration. > > Do you think this is PR-worthy? I'm not familiar with the above make.conf variable (I'm sure others are), but the "env" error you see is likely because the underlying sub-shell that's spawned is /bin/sh, and the default PATH for that shell probably doesn't include /usr/local/bin. I'm also unsure what ruby has to do with buildworld. (I don't see anything relevant in /usr/share/mk or /usr/src). -- | 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 May 7 19:43:02 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id C3F301065670 for ; Fri, 7 May 2010 19:43:02 +0000 (UTC) (envelope-from steinex@nognu.de) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.159]) by mx1.freebsd.org (Postfix) with ESMTP id 5B7AF8FC1C for ; Fri, 7 May 2010 19:43:02 +0000 (UTC) Received: by fg-out-1718.google.com with SMTP id 22so20019fge.13 for ; Fri, 07 May 2010 12:42:56 -0700 (PDT) Received: by 10.86.6.37 with SMTP id 37mr4679330fgf.7.1273261376623; Fri, 07 May 2010 12:42:56 -0700 (PDT) Received: from haydn.nognu.de (haydn.nognu.de [81.169.170.112]) by mx.google.com with ESMTPS id 1sm4889324fks.24.2010.05.07.12.42.55 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 07 May 2010 12:42:56 -0700 (PDT) Date: Fri, 7 May 2010 21:42:54 +0200 From: Frank Steinborn To: Jeremy Chadwick Message-ID: <20100507194254.GB46463@haydn.nognu.de> References: <20100507182801.GA46463@haydn.nognu.de> <20100507192924.GB62650@icarus.home.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable In-Reply-To: <20100507192924.GB62650@icarus.home.lan> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: freebsd-stable@freebsd.org Subject: Re: Regression in PORTS_MODULES (make.conf)? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 07 May 2010 19:43:02 -0000 Jeremy Chadwick wrote: > On Fri, May 07, 2010 at 08:28:01PM +0200, Frank Steinborn wrote: > > Hello, > >=20 > > I have the following in /etc/make.conf: > >=20 > > PORTS_MODULES=3D sysutils/fusefs-kmod \ > > emulators/virtualbox-ose-kmod > >=20 > > On buildworld, it claims: > >=20 > > env: ruby: not found=20 > >=20 > > However, ruby is installed and in PATH. I've seen a similar issue > > lately but wasn't sure if it's just a problem in my configuration. > >=20 > > Do you think this is PR-worthy? >=20 > I'm not familiar with the above make.conf variable (I'm sure others > are), but the "env" error you see is likely because the underlying > sub-shell that's spawned is /bin/sh, and the default PATH for that shell > probably doesn't include /usr/local/bin. >=20 > I'm also unsure what ruby has to do with buildworld. (I don't see > anything relevant in /usr/share/mk or /usr/src). Thanks for your reply. PORTS_MODULES is a list of ports you wish to rebuild every time the kernel is build (so it happened on 'make kernel' BTW, not buildworld - my bad). ruby has nothing to do with it, but it's needed by the sysutils/fusefs-kmod port it seems. It may be a PATH-issue but I think it should include /usr/local/bin then again, because I definitely remember it to work (but that really was years ago). Otherwise that option would be useless. Thanks, Frank From owner-freebsd-stable@FreeBSD.ORG Fri May 7 20:53:39 2010 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 254C21065673; Fri, 7 May 2010 20:53:39 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from mail-px0-f182.google.com (mail-px0-f182.google.com [209.85.212.182]) by mx1.freebsd.org (Postfix) with ESMTP id D96948FC1A; Fri, 7 May 2010 20:53:38 +0000 (UTC) Received: by pxi20 with SMTP id 20so721762pxi.13 for ; Fri, 07 May 2010 13:53:35 -0700 (PDT) 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=nymjM8aQpXCTQKpDM8kFK2X72tRZzz7ph80L9lNoxIA=; b=NqxhaSbEwkMM6Aoogr0v7fqhycxD64VElkXOrxX6ThJLgiXEzS6ERWWJN1RgSLo10N WjXVj6Ah3iwcXN9oinbN87BG3R5JhChM1Eq3S2NW5bOtLBh00eL/sYkpVdzrjmnqcrJx fYxyK5/D3+fvs22da5LFnSlDzKGnpSlFojLss= 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=sMvkKVD1e4aOrGi/jfI9bWU7Vz47916QmKLXKnWr6kY0j/REbPlZhTwPL3pSmY/iGI 8TeoqVFx5DOmPvUAUFv4BHle0918khSdte2OLSIdCiMLUOyXM6RXx2025vIeipV3jG8J TpjQyFmhksCJt2DUoztOcCKir09whb6HofKJ4= Received: by 10.142.7.13 with SMTP id 13mr385665wfg.122.1273265615096; Fri, 07 May 2010 13:53:35 -0700 (PDT) Received: from pyunyh@gmail.com ([174.35.1.224]) by mx.google.com with ESMTPS id 20sm1970927pzk.7.2010.05.07.13.53.33 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 07 May 2010 13:53:34 -0700 (PDT) Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Fri, 7 May 2010 13:53:28 -0700 From: Pyun YongHyeon Date: Fri, 7 May 2010 13:53:28 -0700 To: McLone Message-ID: <20100507205328.GH14801@michelle.cdnetworks.com> References: Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="C+ts3FVlLX8+P6JN" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Cc: network@freebsd.org, stable@freebsd.org, current@freebsd.org Subject: Re: if_re regression on RELENG_8 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: Fri, 07 May 2010 20:53:39 -0000 --C+ts3FVlLX8+P6JN Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Fri, May 07, 2010 at 05:55:02PM +0300, McLone wrote: > Hell Low. > > When Vista finally died on my girl's notebook, > she asked me to install FreeBSD on it, so no more viruses. > I installed RELENG_8_0/i386, to compile fresh RELENG_8/amd64 > in hopes SUJ will be availible (2gb RAM is kinda too small for ZFS). > > I've built custom kernel (GENERIC with unneeded things nodevice'd) > and rebooted it, kldload if_re, ifcionfig, so ping started to work. > I then attempted to mount_nfs, but it hung. > "re0: watchdog timeout" appeared on console. > > So the thing is, re0 stops working after sending any packet > longer than 536 bytes. I tested via ping, -S (536-8) works, > but (537-8) leads to watchdog timeout. The host cannot be > software rebooted in ~80% cases after it happened. > > Machine in question is Fujitsu-Siemens Amilo Pi 2540. > The lines from RELENG_8 dmesg are: > > re0: port > 0x3000-0x30ff mem 0xf0300000-0xf0300fff irq 19 at device 0.0 on pci5 > re0: Reserved 0x1000 bytes for rid 0x18 type 3 at 0xf0300000 > re0: MSI count : 2 > re0: attempting to allocate 1 MSI vectors (2 supported) > re0: using IRQ 256 for MSI > re0: Using 1 MSI messages > re0: Chip rev. 0x34000000 > re0: MAC rev. 0x00000000 > miibus0: on re0 > re0: bpf attached > re0: Ethernet address: 00:03:0d:a1:a8:19 > re0: [MPSAFE] > re0: [FILTER] > > Those lines in RELENG_8_0 are the same except IRQ 259 > (i kldload if_re after boot). > RELENG_8 is from 2010.05.04 i believe; > had tried with sources as of 2 or 3 weeks earlier - same bug. > No CFLAGS except -mtune=native (i doubt it does the weather). > It doesn't matter if i kldload or just use GENERIC. > > How can i test further, except building fresh RELENG_8/i386? > How to use a magic "DDB key" and what to input in there? > Would you try attached patch? --C+ts3FVlLX8+P6JN Content-Type: text/x-diff; charset=us-ascii Content-Disposition: attachment; filename="re.mreq.patch" Index: sys/dev/re/if_re.c =================================================================== --- sys/dev/re/if_re.c (revision 207747) +++ sys/dev/re/if_re.c (working copy) @@ -1162,9 +1162,11 @@ msic = 0; if (pci_find_extcap(dev, PCIY_EXPRESS, ®) == 0) { sc->rl_flags |= RL_FLAG_PCIE; - /* Set PCIe maximum read request size to 2048. */ - if (pci_get_max_read_req(dev) < 2048) - pci_set_max_read_req(dev, 2048); + if (devid != RT_DEVICEID_8101E) { + /* Set PCIe maximum read request size to 2048. */ + if (pci_get_max_read_req(dev) < 2048) + pci_set_max_read_req(dev, 2048); + } msic = pci_msi_count(dev); if (bootverbose) device_printf(dev, "MSI count : %d\n", msic); --C+ts3FVlLX8+P6JN-- From owner-freebsd-stable@FreeBSD.ORG Fri May 7 21:32:48 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 229471065672; Fri, 7 May 2010 21:32:48 +0000 (UTC) (envelope-from mattjreimer@gmail.com) Received: from mail-gx0-f226.google.com (mail-gx0-f226.google.com [209.85.217.226]) by mx1.freebsd.org (Postfix) with ESMTP id B71178FC0A; Fri, 7 May 2010 21:32:47 +0000 (UTC) Received: by gxk26 with SMTP id 26so953419gxk.13 for ; Fri, 07 May 2010 14:32:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=Upmt280cmtOdmd6A2MWb4WLV28RA4GtQKjR2HwaPMqE=; b=Ikea9x7SkRpxWkm61h2LCYqDPlDy4sWqhaClah6D6H2bZfyWcw2EwwazbrcErRSAkM VRyBLHvb9iedxN5vVXwhlP6mYmX1qFWf9pPnoDyHwDDF7/+0k/J6TF9jnywVmWu1s2n7 c9OaiojRwBrDCuzTGhDiZRJ9Cb/RnowhAjKjY= 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:content-transfer-encoding; b=Eq9CS1hGmoNX3jzXhYV9TF+zDiF73n7JrVKsB/o5GvnWxhc2J4UhByH8p2af1h9yYM 7MGPdlNVlpYYkmBVZMOpAB9uZj4WB+WZzbSKFdOnFTIeETNsNA75oGd68P4HfqcWURkO eEM0yEbN8HSWLlaFriAavpNGZJ9abzP5MVpSo= MIME-Version: 1.0 Received: by 10.150.61.2 with SMTP id j2mr2325499yba.360.1273267957869; Fri, 07 May 2010 14:32:37 -0700 (PDT) Received: by 10.150.192.4 with HTTP; Fri, 7 May 2010 14:32:37 -0700 (PDT) In-Reply-To: <3898B34F179B4BB7917631C532CDF95F@multiplay.co.uk> References: <6B44BF0945694D98BC060164D404B5A9@multiplay.co.uk> <20091209102122.GC43143@deviant.kiev.zoral.com.ua> <3898B34F179B4BB7917631C532CDF95F@multiplay.co.uk> Date: Fri, 7 May 2010 14:32:37 -0700 Message-ID: From: Matt Reimer To: Steven Hartland Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Kostik Belousov , freebsd-hackers@freebsd.org, freebsd-stable@freebsd.org Subject: Re: nginx + passenger = segv in _rtld_error on restart on FreeBSD8.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: Fri, 07 May 2010 21:32:48 -0000 On Wed, Dec 9, 2009 at 4:20 AM, Steven Hartland w= rote: > > ----- Original Message ----- From: "Kostik Belousov" > To: "Steven Hartland" > Cc: ; > Sent: Wednesday, December 09, 2009 10:21 AM > Subject: Re: nginx + passenger =3D segv in _rtld_error on restart on > FreeBSD8.0? > > This is the trace once world had been recompiled with:- > CFLAGS=3D-pipe > WITH_CTF=3D1 > DEBUG_FLAGS=3D-g > > > #0 =A00x0000000800c95eec in thr_kill () at thr_kill.S:3 > #1 =A00x0000000800b22e9e in _thr_send_sig (thread=3D0x800f06600, sig=3D6)= at > /usr/src/lib/libthr/thread/thr_kern.c:92 > #2 =A00x0000000800b1f878 in _raise (sig=3D6) at > /usr/src/lib/libthr/thread/thr_sig.c:187 > #3 =A00x0000000800d74003 in abort () at /usr/src/lib/libc/stdlib/abort.c:= 65 > #4 =A00x000000000043b8a7 in Client::threadMain (this=3D0x800f9cf40) at > ext/nginx/HelperServer.cpp:516 > #5 =A00x0000000000411302 in boost::_mfi::mf0::operator() > (this=3D0x7fffffa45ea8, p=3D0x800f9cf40) at mem_fn_template.hpp:49 > #6 =A00x0000000000411651 in boost::_bi::list1 >>::operator(), boost::_bi::list0> > (this=3D0x7fffffa45eb8, f=3D@0x7fffffa45ea8, a=3D@0x7fffffa45d7f) at bind= .hpp:232 > #7 =A00x0000000000411696 in boost::_bi::bind_t Client>, boost::_bi::list1 > >::operator() > (this=3D0x7fffffa45ea8) at bind_template.hpp:20 > #8 =A00x00000000004116bd in > boost::detail::function::void_function_obj_invoker0 boost::_mfi::mf0, boost::_bi::list1 >> >, void>::invoke ( > =A0 function_obj_ptr=3D@0x7fffffa45ea8) at function_template.hpp:158 > #9 =A00x000000000042e73a in boost::function0 >>::operator() (this=3D0x7fffffa45ea0) at function_template.hpp:825 > #10 0x0000000000435760 in oxt::thread::thread_main (func=3D@0x7fffffa45ea= 0, > data=3D@0x7fffffa45e90) at thread.hpp:107 > #11 0x000000000041310e in > boost::_bi::list2 std::allocator > >, > boost::_bi::value > >>::operator() >, > boost::shared_ptr), boost::_bi::list0> > (this=3D0x800f3ee80, f=3D@0x800f3ee78, a=3D@0x7fffffa45f0f) at bind.hpp:2= 89 > #12 0x0000000000413196 in boost::_bi::bind_t (*)(boost::function >, > boost::shared_ptr), > boost::_bi::list2 std::allocator > >, > boost::_bi::value > > >>::operator() (this=3D0x800f3ee78) at bind_template.hpp:20 > #13 0x00000000004131b9 in > boost::thread::thread_data (*)(boost::function >, > boost::shared_ptr), > boost::_bi::list2 std::allocator > >, > boost::_bi::value > > > >::ru= n > (this=3D0x800f3ee00) at thread.hpp:130 > #14 0x0000000000443259 in thread_proxy (param=3D0x800f3ee00) at > ext/boost/src/pthread/thread.cpp:127 > #15 0x0000000800b1badd in thread_start (curthread=3D0x800f06600) at > /usr/src/lib/libthr/thread/thr_create.c:288 > #16 0x0000000000000000 in ?? () > Cannot access memory at address 0x7fffffa46000 > Current language: =A0auto; currently asm > > It seems that in the passenger client threads it calls closeStream which > errors when > the socket close errors with ENOTCONN > =A0 =A0 =A0 virtual void closeStream() { > =A0 =A0 =A0 =A0 =A0 TRACE_POINT(); > =A0 =A0 =A0 =A0 =A0 if (fd !=3D -1) { > =A0 =A0 =A0 =A0 =A0 =A0 =A0 int ret =3D syscalls::close(fd); > =A0 =A0 =A0 =A0 =A0 =A0 =A0 fd =3D -1; > =A0 =A0 =A0 =A0 =A0 =A0 =A0 if (ret =3D=3D -1) { > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 if (errno =3D=3D EIO) { > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 throw SystemException("A writ= e operation on the > session stream failed", > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 errno); > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 } else { > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 throw SystemException("Cannot= close the session > stream", > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 errno); > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 } > =A0 =A0 =A0 =A0 =A0 =A0 =A0 } > =A0 =A0 =A0 =A0 =A0 } > =A0 =A0 =A0 } > > This causes it to call abort on the the thread which then crashes the app > with > the above stack trace, which seems really weird. Anyone got any ideas? > > =A0 Regards > =A0 steve Steve, The patch for PR 144061 works for us. http://lists.freebsd.org/pipermail/freebsd-hackers/2010-February/030741.htm= l http://www.freebsd.org/cgi/query-pr.cgi?pr=3D144061 Matt From owner-freebsd-stable@FreeBSD.ORG Fri May 7 22:54:03 2010 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A9B52106566C; Fri, 7 May 2010 22:54:03 +0000 (UTC) (envelope-from mclone@gmail.com) Received: from mail-px0-f182.google.com (mail-px0-f182.google.com [209.85.212.182]) by mx1.freebsd.org (Postfix) with ESMTP id 72A7E8FC08; Fri, 7 May 2010 22:54:03 +0000 (UTC) Received: by pxi20 with SMTP id 20so763444pxi.13 for ; Fri, 07 May 2010 15:53:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:mime-version:received:in-reply-to :references:from:date:message-id:subject:to:cc:content-type; bh=lN/n2K36sIJt7o97E3jNfcqNl2TfD5KfgGDmEF+Js+E=; b=dT8zMYbOnDu70JOkg0P0Efw/uFAhS86pNbhFheZMu2AhvVSfQi2QZ7dVCBrR569foU 1+ilTKwf+epKRaTuprBHOsW4PIrKaxlMjDS9Pc+ih59c80q7COohaTcpyLrEfgGvcU9f cAZ+umSBJ29PWa1lEnnggPlUh1kfkKzDnH4FI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; b=Y7qpV7fD9PGsoqt9mflouOhl6XtKdTz+2T5cvQhPMlv8EW/4eakYi9i8UhAsVF8rrN 7K+QyMbAMcmfbdsfzY9hLYB7L7PJwLXs7dpj9ebC+TceJn8z00WdXQKNS3/D+LT1QJe9 kPzCL/kF9fsH8alX3Og0+FW/wajA1trUKfTw0= Received: by 10.142.151.11 with SMTP id y11mr458699wfd.77.1273272834136; Fri, 07 May 2010 15:53:54 -0700 (PDT) MIME-Version: 1.0 Received: by 10.142.101.19 with HTTP; Fri, 7 May 2010 15:53:34 -0700 (PDT) In-Reply-To: <20100507205328.GH14801@michelle.cdnetworks.com> References: <20100507205328.GH14801@michelle.cdnetworks.com> From: McLone Date: Sat, 8 May 2010 01:53:34 +0300 Message-ID: To: pyunyh@gmail.com Content-Type: text/plain; charset=ISO-8859-1 Cc: stable@freebsd.org, current@freebsd.org, net@freebsd.org Subject: Re: if_re regression on RELENG_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: Fri, 07 May 2010 22:54:03 -0000 On Fri, May 7, 2010 at 11:53 PM, Pyun YongHyeon wrote: >> So the thing is, re0 stops working after sending any packet >> longer than 536 bytes. I tested via ping, -S (536-8) works, >> but (537-8) leads to watchdog timeout. The host cannot be >> software rebooted in ~80% cases after it happened. > Would you try attached patch? Indeed it helped. Thank you Pyun! You are fast as always! That's what i call "support" :-) -- wbr, |\ _,,,---,,_ dog bless ya! ` Zzz /,`.-'`' -. ;-;;,_ McLone at GMail dot com |,4- ) )-,_. ,\ ( `'-' net- and *BSD admin '---''(_/--' `-'\_) ...translit rawx! From owner-freebsd-stable@FreeBSD.ORG Fri May 7 23:06:47 2010 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id C497E106566B; Fri, 7 May 2010 23:06:47 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from mail-vw0-f54.google.com (mail-vw0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id 3E6798FC08; Fri, 7 May 2010 23:06:46 +0000 (UTC) Received: by vws17 with SMTP id 17so1026617vws.13 for ; Fri, 07 May 2010 16:06:39 -0700 (PDT) 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=wjjRvkLHXbkU6JLVqbYX08lUkTj2pZzyDHEAwMW5JFw=; b=YHTq3YhNk1eqJaYsH89gVlPppZWmqcg0Lbmpa9O+cJkB4Q4+ibzSSNzkFI7TxhY235 Nn8Pzqn52v7QODov8V1hC8OLV7qb8W+aoXWCQL11r53xe+rlcipXarnCjvubyfAxhqrS X7m6ytvahyGJF28bSQBqFJ7+BVcXanskHT8cc= 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=jn2A6+cAfd7QSGkPE8apwtNfYDSp3Em1FquD45EE2eJLDEbiIpjaicHvpMDOu4jj1J c99Tp1NFhDnuViSDL1w09PmUqsM+MNtqSpaLRhgJ22LuvlS+E6a7ZAG2fSIjdd7HwhVd 3Tx/Xnf+POiyI5uzjJVt4YJBtXlWDwf2Sv1rI= Received: by 10.220.63.78 with SMTP id a14mr520574vci.124.1273273599361; Fri, 07 May 2010 16:06:39 -0700 (PDT) Received: from pyunyh@gmail.com ([174.35.1.224]) by mx.google.com with ESMTPS id x6sm11583936vco.23.2010.05.07.16.06.37 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 07 May 2010 16:06:38 -0700 (PDT) Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Fri, 7 May 2010 16:06:31 -0700 From: Pyun YongHyeon Date: Fri, 7 May 2010 16:06:31 -0700 To: McLone Message-ID: <20100507230631.GK14801@michelle.cdnetworks.com> References: <20100507205328.GH14801@michelle.cdnetworks.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Cc: stable@freebsd.org, current@freebsd.org, net@freebsd.org Subject: Re: if_re regression on RELENG_8 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: Fri, 07 May 2010 23:06:47 -0000 On Sat, May 08, 2010 at 01:53:34AM +0300, McLone wrote: > On Fri, May 7, 2010 at 11:53 PM, Pyun YongHyeon wrote: > >> So the thing is, re0 stops working after sending any packet > >> longer than 536 bytes. I tested via ping, -S (536-8) works, > >> but (537-8) leads to watchdog timeout. The host cannot be > >> software rebooted in ~80% cases after it happened. > > Would you try attached patch? > Indeed it helped. > Thank you Pyun! You are fast as always! > That's what i call "support" :-) Fixed at r207763. Thanks for testing! From owner-freebsd-stable@FreeBSD.ORG Sat May 8 14:12:29 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 8C7141065673 for ; Sat, 8 May 2010 14:12:29 +0000 (UTC) (envelope-from rihad@mail.ru) Received: from fallback2.mail.ru (fallback2.mail.ru [94.100.176.87]) by mx1.freebsd.org (Postfix) with ESMTP id A220B8FC0C for ; Sat, 8 May 2010 14:12:28 +0000 (UTC) Received: from mx39.mail.ru (mx39.mail.ru [94.100.176.53]) by fallback2.mail.ru (mPOP.Fallback_MX) with ESMTP id F256B1C4AE1E for ; Sat, 8 May 2010 17:05:51 +0400 (MSD) Received: from [217.25.27.27] (port=17366 helo=[217.25.27.27]) by mx39.mail.ru with asmtp id 1OAjj3-0008Y7-00 for freebsd-stable@freebsd.org; Sat, 08 May 2010 17:05:49 +0400 Message-ID: <4BE561C7.70702@mail.ru> Date: Sat, 08 May 2010 18:06:15 +0500 From: rihad User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.9) Gecko/20100423 Thunderbird/3.0.4 MIME-Version: 1.0 To: freebsd-stable@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam: Not detected X-Mras: Ok Subject: Enabling watchdog X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: rihad List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 May 2010 14:12:29 -0000 Hi, I'm thinking of enabling the watchdog on our Dell PowerEdge 2950 / FreeBSD 8.0 amd64, so that it reboots the machine in case of lockups. Right now it doesn't work: # watchdog watchdog: patting the dog: Operation not supported # Looking through the kernel configuration I found two relevant settings: In /sys/conf/NOTES: # # Add software watchdog routines. # options SW_WATCHDOG and in /sys/amd64/conf/NOTES: # # Watchdog routines. # options MP_WATCHDOG Which of them should I rebuild the kernel with? BTW, the existing kernel is built with the default "options SCHED_ULE" to make good use of multiple CPUs, does watchdog work with it? Thanks. From owner-freebsd-stable@FreeBSD.ORG Sat May 8 14:26:58 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 5240D106564A for ; Sat, 8 May 2010 14:26:58 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta06.emeryville.ca.mail.comcast.net (qmta06.emeryville.ca.mail.comcast.net [76.96.30.56]) by mx1.freebsd.org (Postfix) with ESMTP id 3C5A18FC08 for ; Sat, 8 May 2010 14:26:57 +0000 (UTC) Received: from omta22.emeryville.ca.mail.comcast.net ([76.96.30.89]) by qmta06.emeryville.ca.mail.comcast.net with comcast id F1dP1e0031vN32cA62Sx09; Sat, 08 May 2010 14:26:57 +0000 Received: from koitsu.dyndns.org ([98.248.46.159]) by omta22.emeryville.ca.mail.comcast.net with comcast id F2Sw1e00S3S48mS8i2SxhZ; Sat, 08 May 2010 14:26:57 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 8F4609B425; Sat, 8 May 2010 07:26:55 -0700 (PDT) Date: Sat, 8 May 2010 07:26:55 -0700 From: Jeremy Chadwick To: rihad Message-ID: <20100508142655.GA90968@icarus.home.lan> References: <4BE561C7.70702@mail.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4BE561C7.70702@mail.ru> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: freebsd-stable@freebsd.org Subject: Re: Enabling watchdog X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 08 May 2010 14:26:58 -0000 On Sat, May 08, 2010 at 06:06:15PM +0500, rihad wrote: > Hi, I'm thinking of enabling the watchdog on our Dell PowerEdge 2950 > / FreeBSD 8.0 amd64, so that it reboots the machine in case of > lockups. > Right now it doesn't work: > > # watchdog > watchdog: patting the dog: Operation not supported > # This is almost certainly a failed WDIOCPATPAT ioctl() call, indicating you don't have support for watchdog stuff in your kernel. Once you add that, be aware you'll need to run watchdogd(8) as well. > Looking through the kernel configuration I found two relevant settings: > In /sys/conf/NOTES: > # > # Add software watchdog routines. > # > options SW_WATCHDOG > > > and in /sys/amd64/conf/NOTES: > # > # Watchdog routines. > # > options MP_WATCHDOG > > > Which of them should I rebuild the kernel with? BTW, the existing > kernel is built with the default "options SCHED_ULE" to make good use > of multiple CPUs, does watchdog work with it? I think what you want is SW_WATCHDOG, but I have no idea if this works properly or effectively on multiprocessor machines. MP_WATCHDOG may address that, but does not work with SCHED_ULE[1]. I would recommend reading the watchdog(4) and watchdogd(8) man pages. I would also recommend reading [2], since it sheds some light on how MP_WATCHDOG works. [1]: See src/sys/amd64/amd64/mp_watchdog.c, around line 32. There's an #error statement that gets hit if SCHED_ULE is used. [2]: See src/sys/amd64/amd64/mp_watchdog.c, around line 51. There's a large comment explaining what MP_WATCHDOG does. -- | 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 May 8 16:16:21 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E2203106572D for ; Sat, 8 May 2010 16:16:21 +0000 (UTC) (envelope-from bsd@nezmer.info) Received: from mail.nezmer.info (nezmer.info [97.107.142.36]) by mx1.freebsd.org (Postfix) with ESMTP id 60E3E8FC15 for ; Sat, 8 May 2010 16:16:21 +0000 (UTC) Date: Sat, 8 May 2010 19:16:15 +0300 From: Nezmer To: freebsd-stable@freebsd.org Message-ID: <20100508161615.GA5648@mail> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.20 (2009-06-14) Subject: Some C++ binaries coredumps with Bus 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: Sat, 08 May 2010 16:16:22 -0000 Hi, I'm having trouble with some C++ binaries. They coredumps with Bus error. backtraces always end up with: Cannot access memory at address 0x800000000000 An example of those binaries is pkgdata. A binary used as a part of building icu4c. I rebuilt gcc45, world and kernel with debugging symbols enabled. The weird part, no coredumps occur when kernel debugging symbols are present. But they occur when the kernel is stripped and "*.symbols" files are removed. So I think the problem lies between the kernel and world. gdb output: Core was generated by `pkgdata'. Program terminated with signal 10, Bus error. Reading symbols from ../lib/libicutu.so.44...done. Loaded symbols for ../lib/libicutu.so.44 Reading symbols from ../lib/libicuuc.so.44...done. Loaded symbols for ../lib/libicuuc.so.44 Reading symbols from /lib/libthr.so.3...done. Loaded symbols for /lib/libthr.so.3 Reading symbols from /lib/libc.so.7...done. Loaded symbols for /lib/libc.so.7 Reading symbols from ../lib/libicui18n.so.44...done. Loaded symbols for ../lib/libicui18n.so.44 Reading symbols from /lib/gcc45/libstdc++.so.6...done. Loaded symbols for /lib/gcc45/libstdc++.so.6 Reading symbols from /lib/gcc45/libgcc_s.so.1...done. Loaded symbols for /lib/gcc45/libgcc_s.so.1 Reading symbols from ../stubdata/libicudata.so.44...done. Loaded symbols for ../stubdata/libicudata.so.44 Reading symbols from /lib/libm.so.5...done. Loaded symbols for /lib/libm.so.5 Reading symbols from /libexec/ld-elf.so.1...done. Loaded symbols for /libexec/ld-elf.so.1 #0 strcpy () at fbsd8/src/8_stable-build/lib/libc/amd64/string/strcpy.S:48 48 movq %rdx,(%rdi) [New Thread 8022041c0 (LWP 100161)] (gdb) bt full #0 strcpy () at fbsd8/src/8_stable-build/lib/libc/amd64/string/strcpy.S:48 No locals. #1 0x0000000000401993 in runCommand () at pkgdata.cpp:1536 command = Cannot access memory at address 0x0 Line 1536 (pkgdata.cpp): int32_t ln=0; /* line number */ (gdb) bt #0 strcpy () at fbsd8/src/8_stable-build/lib/libc/amd64/string/strcpy.S:48 #1 0x0000000000401993 in runCommand () at pkgdata.cpp:1536 #2 0x6d742f74756f2f2e in ?? () #3 0x615f6c6c6f632f70 in ?? () #4 0x7365725f47455f72 in ?? () #5 0x74756f2f2e206f2e in ?? () #6 0x6c6f632f706d742f in ?? () #7 0x5f51495f72615f6c in ?? () . . . . #2730 0x5f676e616c2f706d in ?? () #2731 0x65725f49465f7673 in ?? () #2732 0x756f2f2e206f2e73 in ?? () Cannot access memory at address 0x800000000000 System info: AMD64 GENERIC 8-STABLE(206611) GCC 4.5(20100429) Any ideas why this is happening and why with some C++ binaries only? From owner-freebsd-stable@FreeBSD.ORG Sat May 8 16:23:17 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 26575106566C; Sat, 8 May 2010 16:23:17 +0000 (UTC) (envelope-from prvs=174407b200=killing@multiplay.co.uk) Received: from mail1.multiplay.co.uk (mail1.multiplay.co.uk [85.236.96.23]) by mx1.freebsd.org (Postfix) with ESMTP id 912458FC14; Sat, 8 May 2010 16:23:16 +0000 (UTC) X-MDAV-Processed: mail1.multiplay.co.uk, Sat, 08 May 2010 17:16:47 +0100 X-Spam-Processed: mail1.multiplay.co.uk, Sat, 08 May 2010 17:16:47 +0100 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on mail1.multiplay.co.uk X-Spam-Level: X-Spam-Status: No, score=-5.0 required=6.0 tests=USER_IN_WHITELIST shortcircuit=ham autolearn=disabled version=3.2.5 Received: from r2d2 by mail1.multiplay.co.uk (MDaemon PRO v10.0.4) with ESMTP id md50010221205.msg; Sat, 08 May 2010 17:16:47 +0100 X-Authenticated-Sender: Killing@multiplay.co.uk X-MDRemoteIP: 188.220.16.48 X-Return-Path: prvs=174407b200=killing@multiplay.co.uk X-Envelope-From: killing@multiplay.co.uk Message-ID: <729F67D8486E42A99F38592C642D74AE@multiplay.co.uk> From: "Steven Hartland" To: "Matt Reimer" References: <6B44BF0945694D98BC060164D404B5A9@multiplay.co.uk> Date: Sat, 8 May 2010 17:16:41 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5843 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 Cc: freebsd-hackers@freebsd.org, freebsd-stable@freebsd.org Subject: Re: nginx + passenger = segv in _rtld_error on restart on FreeBSD 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: Sat, 08 May 2010 16:23:17 -0000 As you may have guessed by my last reply no we didn't we had to revert to apache + passenger, but seems you've found a fix anyway. Out of interest what lead you to the close race condition PR as a potential fix? ----- Original Message ----- From: "Matt Reimer" Steve, Did you figure this out? We're seeing something very similar with nginx + passenger + FreeBSD 8.0. ================================================ This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to postmaster@multiplay.co.uk. From owner-freebsd-stable@FreeBSD.ORG Sat May 8 16:23:17 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 2D0611065670; Sat, 8 May 2010 16:23:17 +0000 (UTC) (envelope-from prvs=174407b200=killing@multiplay.co.uk) Received: from mail1.multiplay.co.uk (mail1.multiplay.co.uk [85.236.96.23]) by mx1.freebsd.org (Postfix) with ESMTP id 958408FC15; Sat, 8 May 2010 16:23:16 +0000 (UTC) X-MDAV-Processed: mail1.multiplay.co.uk, Sat, 08 May 2010 17:13:01 +0100 X-Spam-Processed: mail1.multiplay.co.uk, Sat, 08 May 2010 17:13:01 +0100 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on mail1.multiplay.co.uk X-Spam-Level: X-Spam-Status: No, score=-5.0 required=6.0 tests=USER_IN_WHITELIST shortcircuit=ham autolearn=disabled version=3.2.5 Received: from r2d2 by mail1.multiplay.co.uk (MDaemon PRO v10.0.4) with ESMTP id md50010221189.msg; Sat, 08 May 2010 17:13:00 +0100 X-Authenticated-Sender: Killing@multiplay.co.uk X-MDRemoteIP: 188.220.16.48 X-Return-Path: prvs=174407b200=killing@multiplay.co.uk X-Envelope-From: killing@multiplay.co.uk Message-ID: <4D0732ED9A714C7EA6B004E852F0D695@multiplay.co.uk> From: "Steven Hartland" To: "Matt Reimer" References: <6B44BF0945694D98BC060164D404B5A9@multiplay.co.uk><20091209102122.GC43143@deviant.kiev.zoral.com.ua><3898B34F179B4BB7917631C532CDF95F@multiplay.co.uk> Date: Sat, 8 May 2010 17:12:58 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5843 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 Cc: Kostik Belousov , freebsd-hackers@freebsd.org, freebsd-stable@freebsd.org Subject: Re: nginx + passenger = segv in _rtld_error on restart onFreeBSD8.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: Sat, 08 May 2010 16:23:17 -0000 Thanks Matt most appreciated! ----- Original Message ----- From: "Matt Reimer" Steve, The patch for PR 144061 works for us. http://lists.freebsd.org/pipermail/freebsd-hackers/2010-February/030741.html http://www.freebsd.org/cgi/query-pr.cgi?pr=144061 ================================================ This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to postmaster@multiplay.co.uk. From owner-freebsd-stable@FreeBSD.ORG Sat May 8 19:49:13 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id D483D106564A for ; Sat, 8 May 2010 19:49:13 +0000 (UTC) (envelope-from brampton@gmail.com) Received: from mail-fx0-f54.google.com (mail-fx0-f54.google.com [209.85.161.54]) by mx1.freebsd.org (Postfix) with ESMTP id 6877E8FC16 for ; Sat, 8 May 2010 19:49:13 +0000 (UTC) Received: by fxm15 with SMTP id 15so1737902fxm.13 for ; Sat, 08 May 2010 12:49:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type; bh=3uiKKyKnvHCfMYI4sjKMiMDApGjHMSft8sHEAsb4TEE=; b=ZRLpfehmLdilzXcwin1E7yWiN49h14NOyP6kHUkcIv9Rl5CRPn/qKIT14Sh0CSMhGT DGetrb45l7PoSDV3how0k7r6NulT+IXZtfSKB73BfJwhzL5oYvFPegsQJ/yIS4e93jEN sPWPS9e7I1jDKOyGdfkHGjZKTxr0IN8VyP4OQ= 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=Swbe3HM3/Ter3lOL3TFZcylDdC0m73SqKEDSMWQAvieTwVV2l92H8SC2mYesbZI/sA 3sqo1mibQ3GpirpIRE59BRQeMkTustNuWrF7Zb/I6HEIEdydEep0vwgk7Uhcx7s3VPIc 0GL0q02ZCfxmOM757zlBPsiguXel8drQSZkfc= MIME-Version: 1.0 Received: by 10.223.45.83 with SMTP id d19mr1858236faf.65.1273346657489; Sat, 08 May 2010 12:24:17 -0700 (PDT) Sender: brampton@gmail.com Received: by 10.223.126.208 with HTTP; Sat, 8 May 2010 12:24:17 -0700 (PDT) In-Reply-To: <4BE561C7.70702@mail.ru> References: <4BE561C7.70702@mail.ru> Date: Sat, 8 May 2010 20:24:17 +0100 X-Google-Sender-Auth: 2cQ6EFwzeWplckdsRywX-ahN8kU Message-ID: From: Andrew Brampton To: rihad Content-Type: text/plain; charset=UTF-8 Cc: freebsd-stable@freebsd.org Subject: Re: Enabling watchdog X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 08 May 2010 19:49:13 -0000 On Sat, May 8, 2010 at 2:06 PM, rihad wrote: > Hi, I'm thinking of enabling the watchdog on our Dell PowerEdge 2950 / > FreeBSD 8.0 amd64, so that it reboots the machine in case of lockups. > Right now it doesn't work: > I installed watchdogd on a few 8-core Dell PowerEdge 1950, which I assume are similar to the 2950s. I wrote about how to do this on my blog[1] last year. However, something in the last couple of months has broken watchdog and my machines causing them to regularly lock up. I'm unsure what has changed, and I didn't have time to investigate so I just turned it off and everything is now fine. Andrew [1] http://bramp.net/blog/freebsd-software-watchdog From owner-freebsd-stable@FreeBSD.ORG Sat May 8 22:23:38 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id AB7E51065677 for ; Sat, 8 May 2010 22:23:38 +0000 (UTC) (envelope-from jafa82@gmail.com) Received: from mail-qy0-f181.google.com (mail-qy0-f181.google.com [209.85.221.181]) by mx1.freebsd.org (Postfix) with ESMTP id 605AE8FC16 for ; Sat, 8 May 2010 22:23:38 +0000 (UTC) Received: by qyk11 with SMTP id 11so3483465qyk.13 for ; Sat, 08 May 2010 15:23:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:reply-to:to:subject:date :user-agent:references:in-reply-to:mime-version:content-type :content-transfer-encoding:message-id; bh=LTLV49L/xO/e+WXJ0eiBIuFPl+1b45uE5xX7l92zVi8=; b=Oh2s28bViN0hfyhlQ+nEH4h2SwrwLXFKlAKAfHfskWSPn1LEO9brkZ4LCsr7/MYYDE ZzrXU+UdkSSTLlHfOfie7sZKTYqVX3Pu/A9A5nCJ8mGoJpbOmcGT/mOx4LKJ6n3rQNt3 3lTKSidANin2ezh0t0Vrd0mPoaGguYsPuOqMQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:reply-to:to:subject:date:user-agent:references:in-reply-to :mime-version:content-type:content-transfer-encoding:message-id; b=RgMmUsxsXFDs+bbXWaEN7VBVff5fYWvcdLwwRqe9wMJXXgxI3lAZ5PwvNRWwPhUnzL gLI8LAooSC11Ai0Kmj7+PePxxIGqyJYi6vvCBEQZsqRJGtOzoXUT9uJ3C0WVO28CSWWE Usb4BBY5BZmKYKSgV2miil5SkVFNElq2kiTJ8= Received: by 10.229.99.143 with SMTP id u15mr1507276qcn.105.1273357402200; Sat, 08 May 2010 15:23:22 -0700 (PDT) Received: from merytaton.localnet (modemcable125.95-81-70.mc.videotron.ca [70.81.95.125]) by mx.google.com with ESMTPS id f5sm2400331qcg.8.2010.05.08.15.23.20 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sat, 08 May 2010 15:23:21 -0700 (PDT) From: Eric Damien To: freebsd-stable@freebsd.org Date: Sat, 8 May 2010 18:23:18 -0400 User-Agent: KMail/1.12.4 (FreeBSD/8.0-STABLE; KDE/4.3.5; i386; ; ) References: <201005021536.05389.jafa82@gmail.com> <20100504023457.GD7641@dmr.ath.cx> In-Reply-To: <20100504023457.GD7641@dmr.ath.cx> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201005081823.18439.jafa82@gmail.com> Subject: Re: ZFS: separate pools X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: jafa82@gmail.com List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 May 2010 22:23:38 -0000 On Monday 03 May 2010 22:34:57 Emil Mikulic wrote: > On Mon, May 03, 2010 at 10:16:57PM -0400, Charles Sprickman wrote: > > Just some random data. I know when I was reading about ZFS I did > > come across some vague notion that zfs wanted the entire drive to > > better deal with queueing, not sure if that was official Sun docs or > > some random blog though... > > ZFS on Solaris only enables write caching when it's given an entire disk. > pjd@ has stated that this does not affect FreeBSD, only Solaris. > _______________________________________________ > 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" > So, correct me if I am wrong: 1- I need to let go the slice/partitions concepts and now think in matter of pool/filesystems ? 2- And assuming "1-" is right, I have to dedicate an entire disk to a zpool ? 3- If "2-" is also true, my preoccupation now is, when I shall need to reinstall the OS, what are the steps to go through in order to preserve my data - especially the "/home" filesystem -, across the two installations ? From owner-freebsd-stable@FreeBSD.ORG Sat May 8 22:28:23 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id C1298106566C for ; Sat, 8 May 2010 22:28:23 +0000 (UTC) (envelope-from slackbie@gmail.com) Received: from mail-px0-f182.google.com (mail-px0-f182.google.com [209.85.212.182]) by mx1.freebsd.org (Postfix) with ESMTP id 9C7888FC16 for ; Sat, 8 May 2010 22:28:23 +0000 (UTC) Received: by pxi20 with SMTP id 20so1111106pxi.13 for ; Sat, 08 May 2010 15:28:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:date:message-id :subject:from:to:content-type; bh=OgETRTs6R7MYtGaIYvSXSEqiGneWJUSLW8ayYNzZ3BU=; b=L1mZHKsMdFpgAI+k5aOJEcZHkJs98oB6cUp7dbLA/U1X3oWRGUitEp3CeDGo2fQ0y9 v6kvsguxM9xeQ9s3dPF2vfGz3I9Jtj56udr/IjwLpekZywhhN8Q1VGQLEtcXNRYQm10B BlsmlN/f9lYLDep/hZp02WBgK7vKbWhlpNgog= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=uJ0dk72VnjYvEFewJZgf9JtYnwv4ra0T4ltUYbrnHYYuP5o25VLhOE1JDSuBuVVoEy 5EunGn+21gmUxPmV+6o4vW0TJBHUXM8ST4045NEKHaWm1JAWj9KKuladeQsiMBhgcr4R pWH+htOGCWnXfs/eRer2mmr7N9Ij/s3FzJnrc= MIME-Version: 1.0 Received: by 10.115.81.6 with SMTP id i6mr1495571wal.48.1273357692921; Sat, 08 May 2010 15:28:12 -0700 (PDT) Received: by 10.114.121.3 with HTTP; Sat, 8 May 2010 15:28:12 -0700 (PDT) Date: Sun, 9 May 2010 05:28:12 +0700 Message-ID: From: "~Lst" To: freebsd-stable@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Subject: vlan and openbgpd X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 08 May 2010 22:28:23 -0000 Hi, I had an experienced in FreeBSD 8.0 (not with FreeBSD 7.3), that if we removed any vlan in any interfaces it makes sessions in openbgpd with connect but never get established. The logs only said like this, ``received notification: HoldTimer expired, unknown subcode 0'' and ``socket error: Connection refused'' and ``socket error: No route to host''. When I tried to ping to the neighbor, it worked fine. I tried to restart daemon openbgpd but sessions never established, then I should to reboot our router and the session was established. Does anyone have same experienced with me ? Rgds, -- ~Lst From owner-freebsd-stable@FreeBSD.ORG Sat May 8 23:50:53 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 50CBF106567A for ; Sat, 8 May 2010 23:50:53 +0000 (UTC) (envelope-from vince@unsane.co.uk) Received: from unsane.co.uk (www.unsane.co.uk [85.233.185.162]) by mx1.freebsd.org (Postfix) with ESMTP id 8309F8FC1D for ; Sat, 8 May 2010 23:50:52 +0000 (UTC) Received: from vhoffman-macbook.local ([10.0.0.173]) (authenticated bits=0) by unsane.co.uk (8.14.4/8.14.4) with ESMTP id o48NOE6R026832 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Sun, 9 May 2010 00:24:15 +0100 (BST) (envelope-from vince@unsane.co.uk) Message-ID: <4BE5F29E.30302@unsane.co.uk> Date: Sun, 09 May 2010 00:24:14 +0100 From: Vincent Hoffman User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: FreeBSD Stable Mailing List X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: ath0 not working and getting device timeouts with recent 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: Sat, 08 May 2010 23:50:53 -0000 I'm having issues getting my wireless card working. It was working with 8.0-RELEASE I created wlan0 manually for debug ifconfig wlan0 create wlandev ath0 wlanmode station country GB wpa_supplicant -B -i wlan0 -c /etc/wpa_supplicant.conf ifconfig wlan0 10.0.0.1/25 if I then ping a known reachable IP on that network I cause a device timeout. [root@ostracod ~/wlandebug]# ping 10.0.0.32 PING 10.0.0.32 (10.0.0.32): 56 data bytes ping: sendto: Network is down ping: sendto: Network is down ^C --- 10.0.0.32 ping statistics --- 14 packets transmitted, 0 packets received, 100.0% packet loss May 8 23:13:38 ostracod kernel: wlan0: Ethernet address: 00:24:23:07:fb:5d May 8 23:13:41 ostracod kernel: wlan0: link state changed to UP May 8 23:16:15 ostracod kernel: wlan0: link state changed to DOWN May 8 23:16:20 ostracod kernel: ath0: device timeout May 8 23:16:25 ostracod kernel: wlan0: link state changed to UP Some device info Its a Zotac ION-ITX-D Atom motherboard with an "Azurewave AR5B91" wireless card. ath0@pci0:4:0:0: class=0x028000 card=0x10671a3b chip=0x002a168c rev=0x01 hdr=0x00 vendor = 'Atheros Communications Inc.' device = 'Atheros AR5B91 Wireless Network Adapter (0001)' class = network [root@ostracod ~/wlandebug]# uname -a FreeBSD ostracod.unsane.co.uk 8.0-STABLE FreeBSD 8.0-STABLE #1 r207610: Tue May 4 15:44:19 BST 2010 toor@ostracod.unsane.co.uk:/scratch/obj/usr/src/sys/OSTRACOD amd64 [root@ostracod ~/wlandebug]# more /etc/wpa_supplicant.conf ctrl_interface=/var/run/wpa_supplicant ctrl_interface_group=wheel # # home network; allow all valid ciphers network={ ssid="V_WAP" scan_ssid=1 key_mgmt=NONE wep_tx_keyidx=0 wep_key0=xxxxxxxxxxxxxxxxxxxxxxxx } I did try wpa instead of wep with the same results. I've tried wlandebug -i wlan0 debug+assoc+auth+output+power and I get May 8 23:46:50 ostracod kernel: wlan0: send probe req on channel 12 bssid ff:ff:ff:ff:ff:ff ssid "V_WAP" May 8 23:46:50 ostracod kernel: wlan0: send probe req on channel 12 bssid ff:ff:ff:ff:ff:ff ssid "" May 8 23:46:50 ostracod kernel: wlan0: received probe_resp from 94:44:52:0f:2f:c3 rssi 13 May 8 23:46:50 ostracod kernel: wlan0: received beacon from 94:44:52:0f:2f:c3 rssi 14 May 8 23:46:50 ostracod kernel: wlan0: received beacon from 94:44:52:0f:2f:c3 rssi 14 May 8 23:46:50 ostracod kernel: wlan0: [94:44:52:0f:2f:c3] station assoc via MLME May 8 23:46:50 ostracod kernel: [94:44:52:0f:2f:c3] send auth on channel 1 May 8 23:46:50 ostracod kernel: wlan0: received auth from 94:44:52:0f:2f:c3 rssi 65 May 8 23:46:50 ostracod kernel: wlan0: [94:44:52:0f:2f:c3] recv auth frame with algorithm 0 seq 2 May 8 23:46:50 ostracod kernel: [94:44:52:0f:2f:c3] send assoc_req on channel 1 May 8 23:46:50 ostracod kernel: wlan0: received assoc_resp from 94:44:52:0f:2f:c3 rssi 66 May 8 23:46:50 ostracod kernel: wlan0: [94:44:52:0f:2f:c3] assoc success at aid 3: long preamble, long slot time May 8 23:46:50 ostracod kernel: wlan0: associated with 94:44:52:0f:2f:c3 ssid "V_WAP" channel 1 start 0Mb May 8 23:46:50 ostracod kernel: wlan0: link state changed to UP May 8 23:47:42 ostracod kernel: wlan0: beacon miss, mode STA state RUN May 8 23:47:42 ostracod kernel: wlan0: send probe req on channel 1 bssid 94:44:52:0f:2f:c3 ssid "V_WAP" May 8 23:47:43 ostracod kernel: wlan0: beacon miss, mode STA state RUN May 8 23:47:43 ostracod kernel: wlan0: link state changed to DOWN May 8 23:47:43 ostracod kernel: wlan0: [94:44:52:0f:2f:c3] station assoc via MLME May 8 23:47:43 ostracod kernel: [94:44:52:0f:2f:c3] send auth on channel 1 May 8 23:47:43 ostracod kernel: wlan0: ieee80211_start: ignore queue, in AUTH state May 8 23:47:47 ostracod kernel: ath0: device timeout May 8 23:47:53 ostracod kernel: wlan0: [94:44:52:0f:2f:c3] station assoc via MLME May 8 23:47:53 ostracod kernel: [94:44:52:0f:2f:c3] send auth on channel 1 May 8 23:47:53 ostracod kernel: wlan0: received auth from 94:44:52:0f:2f:c3 rssi 67 May 8 23:47:53 ostracod kernel: wlan0: [94:44:52:0f:2f:c3] recv auth frame with algorithm 0 seq 2 May 8 23:47:53 ostracod kernel: [94:44:52:0f:2f:c3] send assoc_req on channel 1 May 8 23:47:53 ostracod kernel: wlan0: received assoc_resp from 94:44:52:0f:2f:c3 rssi 67 May 8 23:47:53 ostracod kernel: wlan0: [94:44:52:0f:2f:c3] assoc success at aid 3: long preamble, long slot time May 8 23:47:53 ostracod kernel: wlan0: associated with 94:44:52:0f:2f:c3 ssid "V_WAP" channel 1 start 0Mb May 8 23:47:53 ostracod kernel: wlan0: link state changed to UP Any suggestions welcome. Vince