From owner-freebsd-stable@FreeBSD.ORG Sun May 29 04:10:13 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9D999106566C for ; Sun, 29 May 2011 04:10:13 +0000 (UTC) (envelope-from michael@rancid.berkeley.edu) Received: from malcolm.berkeley.edu (malcolm.Berkeley.EDU [IPv6:2607:f140:ffff:ffff::239]) by mx1.freebsd.org (Postfix) with ESMTP id 85C818FC0A for ; Sun, 29 May 2011 04:10:13 +0000 (UTC) Received: from towanda.burnttofu.net ([IPv6:2001:470:1f05:17a6:219:d1ff:fe26:5246]) (authenticated bits=0) by malcolm.berkeley.edu (8.14.4/8.13.8m1) with ESMTP id p4T4ADbY013868 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for ; Sat, 28 May 2011 21:10:13 -0700 (PDT) (envelope-from michael@rancid.berkeley.edu) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.96.2 at malcolm.berkeley.edu Message-ID: <4DE1C723.2070903@rancid.berkeley.edu> Date: Sat, 28 May 2011 21:10:11 -0700 From: Michael Sinatra User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.17) Gecko/20110513 Thunderbird/3.1.10 MIME-Version: 1.0 To: freebsd-stable@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (malcolm.berkeley.edu [IPv6:2607:f140:ffff:ffff::239]); Sat, 28 May 2011 21:10:13 -0700 (PDT) Subject: ICH9 panic/instability on recent kernel X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 29 May 2011 04:10:13 -0000 Hi, I have a core-2 system with a 3ware SATA RAID controller for the main disks and the built-in Intel ICH9 4-port SATA controller that is only used for the DVDR. An 8-STABLE kernel csup'd and compiled on April 25 works fine on this system. Kernels from source csup'd this week are extremely unstable and usually panic or hang just minutes after booting. The following warning messages appear after the kernel probes the SATA controller and/or ICH9 USB controller and continue about once per 1-2 seconds until the system crashes: May 13 14:21:05 sonicyouth kernel: unknown: WARNING - ATAPI_IDENTIFY requeued due to channel reset LBA=0 Disabling the ICH9 SATA controller in the BIOS allows the system to boot and run normally. Changes were made on April 28 to allow better support for 6-port ICH9 controllers (SVN rev 221156) and I am wondering if my controller is now being incorrectly recognized. Here's the relevant kernel messages: May 13 13:52:53 sonicyouth kernel: atapci1: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0x1c4 0-0x1c4f,0x1c30-0x1c3f at device 31.2 on pci0 May 13 13:52:53 sonicyouth kernel: ata0: on atapci1 May 13 13:52:53 sonicyouth kernel: ata0: [ITHREAD] May 13 13:52:53 sonicyouth kernel: ata1: on atapci1 May 13 13:52:53 sonicyouth kernel: ata1: [ITHREAD] May 13 13:52:53 sonicyouth kernel: atapci2: port 0x1cb8-0x1cbf,0x1cac-0x1caf,0x1cb0-0x1cb7 ,0x1ca8-0x1cab,0x1c60-0x1c6f,0x1c50-0x1c5f irq 18 at device 31.5 on pci0 May 13 13:52:53 sonicyouth kernel: atapci2: [ITHREAD] May 13 13:52:53 sonicyouth kernel: ata3: on atapci2 May 13 13:52:53 sonicyouth kernel: ata3: [ITHREAD] May 13 13:52:53 sonicyouth kernel: ata4: on atapci2 May 13 13:52:53 sonicyouth kernel: ata4: [ITHREAD] If I csup the most recent kernel sources, I get the same problem. However, if, after csuping the latest kernel sources, I then fetch the version of sys/dev/ata/ata-all.c as of April 27, everything works fine. Here's the output of pciconf -l: hostb0@pci0:0:0:0: class=0x060000 card=0xd98015d9 chip=0x29e08086 rev=0x01 hdr=0x00 pcib1@pci0:0:1:0: class=0x060400 card=0xd98015d9 chip=0x29e18086 rev=0x01 hdr=0x01 pcib2@pci0:0:6:0: class=0x060400 card=0xd98015d9 chip=0x29e98086 rev=0x01 hdr=0x01 em0@pci0:0:25:0: class=0x020000 card=0x10bd15d9 chip=0x10bd8086 rev=0x02 hdr=0x00 uhci0@pci0:0:26:0: class=0x0c0300 card=0xd98015d9 chip=0x29378086 rev=0x02 hdr=0x00 uhci1@pci0:0:26:1: class=0x0c0300 card=0xd98015d9 chip=0x29388086 rev=0x02 hdr=0x00 uhci2@pci0:0:26:2: class=0x0c0300 card=0xd98015d9 chip=0x29398086 rev=0x02 hdr=0x00 ehci0@pci0:0:26:7: class=0x0c0320 card=0xd98015d9 chip=0x293c8086 rev=0x02 hdr=0x00 none0@pci0:0:27:0: class=0x040300 card=0xd98015d9 chip=0x293e8086 rev=0x02 hdr=0x00 pcib3@pci0:0:28:0: class=0x060400 card=0xd98015d9 chip=0x29408086 rev=0x02 hdr=0x01 uhci3@pci0:0:29:0: class=0x0c0300 card=0xd98015d9 chip=0x29348086 rev=0x02 hdr=0x00 uhci4@pci0:0:29:1: class=0x0c0300 card=0xd98015d9 chip=0x29358086 rev=0x02 hdr=0x00 uhci5@pci0:0:29:2: class=0x0c0300 card=0xd98015d9 chip=0x29368086 rev=0x02 hdr=0x00 ehci1@pci0:0:29:7: class=0x0c0320 card=0xd98015d9 chip=0x293a8086 rev=0x02 hdr=0x00 pcib5@pci0:0:30:0: class=0x060401 card=0xd98015d9 chip=0x244e8086 rev=0x92 hdr=0x01 isab0@pci0:0:31:0: class=0x060100 card=0xd98015d9 chip=0x29168086 rev=0x02 hdr=0x00 atapci1@pci0:0:31:2: class=0x01018a card=0xd98015d9 chip=0x29208086 rev=0x02 hdr=0x00 none1@pci0:0:31:3: class=0x0c0500 card=0xd98015d9 chip=0x29308086 rev=0x02 hdr=0x00 atapci2@pci0:0:31:5: class=0x010185 card=0xd98015d9 chip=0x29268086 rev=0x02 hdr=0x00 none2@pci0:0:31:6: class=0x118000 card=0x000015d9 chip=0x29328086 rev=0x02 hdr=0x00 vgapci0@pci0:1:0:0: class=0x030000 card=0x216619da chip=0x0e2210de rev=0xa1 hdr=0x00 none3@pci0:1:0:1: class=0x040300 card=0x216619da chip=0x0beb10de rev=0xa1 hdr=0x00 twa0@pci0:3:0:0: class=0x010400 card=0x100413c1 chip=0x100413c1 rev=0x01 hdr=0x00 pcib4@pci0:5:0:0: class=0x060400 card=0x00000000 chip=0x032c8086 rev=0x09 hdr=0x01 ioapic0@pci0:5:0:1: class=0x080020 card=0xd98015d9 chip=0x03268086 rev=0x09 hdr=0x00 fwohci0@pci0:17:3:0: class=0x0c0010 card=0xba8015d9 chip=0x8023104c rev=0x00 hdr=0x00 atapci0@pci0:17:4:0: class=0x010185 card=0x82131283 chip=0x82131283 rev=0x00 hdr=0x00 Anyone else having issues? michael From owner-freebsd-stable@FreeBSD.ORG Sun May 29 04:56:17 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D10E91065673 for ; Sun, 29 May 2011 04:56:17 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta02.emeryville.ca.mail.comcast.net (qmta02.emeryville.ca.mail.comcast.net [76.96.30.24]) by mx1.freebsd.org (Postfix) with ESMTP id B99498FC14 for ; Sun, 29 May 2011 04:56:17 +0000 (UTC) Received: from omta22.emeryville.ca.mail.comcast.net ([76.96.30.89]) by qmta02.emeryville.ca.mail.comcast.net with comcast id pGwG1g0011vN32cA2GwGwc; Sun, 29 May 2011 04:56:16 +0000 Received: from koitsu.dyndns.org ([67.180.84.87]) by omta22.emeryville.ca.mail.comcast.net with comcast id pGwB1g0051t3BNj8iGwB73; Sun, 29 May 2011 04:56:11 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id A2510102C19; Sat, 28 May 2011 21:56:15 -0700 (PDT) Date: Sat, 28 May 2011 21:56:15 -0700 From: Jeremy Chadwick To: Michael Sinatra Message-ID: <20110529045615.GA44303@icarus.home.lan> References: <4DE1C723.2070903@rancid.berkeley.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4DE1C723.2070903@rancid.berkeley.edu> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: mav@freebsd.org, freebsd-stable@freebsd.org Subject: Re: ICH9 panic/instability on recent kernel X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 29 May 2011 04:56:17 -0000 On Sat, May 28, 2011 at 09:10:11PM -0700, Michael Sinatra wrote: > I have a core-2 system with a 3ware SATA RAID controller for the > main disks and the built-in Intel ICH9 4-port SATA controller that > is only used for the DVDR. An 8-STABLE kernel csup'd and compiled > on April 25 works fine on this system. Kernels from source csup'd > this week are extremely unstable and usually panic or hang just > minutes after booting. The following warning messages appear after > the kernel probes the SATA controller and/or ICH9 USB controller and > continue about once per 1-2 seconds until the system crashes: > > May 13 14:21:05 sonicyouth kernel: unknown: WARNING - ATAPI_IDENTIFY > requeued due to channel reset LBA=0 > > Disabling the ICH9 SATA controller in the BIOS allows the system to > boot and run normally. > > Changes were made on April 28 to allow better support for 6-port > ICH9 controllers (SVN rev 221156) and I am wondering if my > controller is now being incorrectly recognized. > > Here's the relevant kernel messages: > > May 13 13:52:53 sonicyouth kernel: atapci1: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0x1c40-0x1c4f,0x1c30-0x1c3f at device 31.2 on pci0 > May 13 13:52:53 sonicyouth kernel: ata0: on atapci1 > May 13 13:52:53 sonicyouth kernel: ata0: [ITHREAD] > May 13 13:52:53 sonicyouth kernel: ata1: on atapci1 > May 13 13:52:53 sonicyouth kernel: ata1: [ITHREAD] > May 13 13:52:53 sonicyouth kernel: atapci2: controller> port 0x1cb8-0x1cbf,0x1cac-0x1caf,0x1cb0-0x1cb7,0x1ca8-0x1cab,0x1c60-0x1c6f,0x1c50-0x1c5f irq 18 at device 31.5 on pci0 > May 13 13:52:53 sonicyouth kernel: atapci2: [ITHREAD] > May 13 13:52:53 sonicyouth kernel: ata3: on atapci2 > May 13 13:52:53 sonicyouth kernel: ata3: [ITHREAD] > May 13 13:52:53 sonicyouth kernel: ata4: on atapci2 > May 13 13:52:53 sonicyouth kernel: ata4: [ITHREAD] > > If I csup the most recent kernel sources, I get the same problem. > However, if, after csuping the latest kernel sources, I then fetch > the version of sys/dev/ata/ata-all.c as of April 27, everything > works fine. Here's the output of pciconf -l: > > hostb0@pci0:0:0:0: class=0x060000 card=0xd98015d9 chip=0x29e08086 rev=0x01 hdr=0x00 > pcib1@pci0:0:1:0: class=0x060400 card=0xd98015d9 chip=0x29e18086 rev=0x01 hdr=0x01 > pcib2@pci0:0:6:0: class=0x060400 card=0xd98015d9 chip=0x29e98086 rev=0x01 hdr=0x01 > em0@pci0:0:25:0: class=0x020000 card=0x10bd15d9 chip=0x10bd8086 rev=0x02 hdr=0x00 > uhci0@pci0:0:26:0: class=0x0c0300 card=0xd98015d9 chip=0x29378086 rev=0x02 hdr=0x00 > uhci1@pci0:0:26:1: class=0x0c0300 card=0xd98015d9 chip=0x29388086 rev=0x02 hdr=0x00 > uhci2@pci0:0:26:2: class=0x0c0300 card=0xd98015d9 chip=0x29398086 rev=0x02 hdr=0x00 > ehci0@pci0:0:26:7: class=0x0c0320 card=0xd98015d9 chip=0x293c8086 rev=0x02 hdr=0x00 > none0@pci0:0:27:0: class=0x040300 card=0xd98015d9 chip=0x293e8086 rev=0x02 hdr=0x00 > pcib3@pci0:0:28:0: class=0x060400 card=0xd98015d9 chip=0x29408086 rev=0x02 hdr=0x01 > uhci3@pci0:0:29:0: class=0x0c0300 card=0xd98015d9 chip=0x29348086 rev=0x02 hdr=0x00 > uhci4@pci0:0:29:1: class=0x0c0300 card=0xd98015d9 chip=0x29358086 rev=0x02 hdr=0x00 > uhci5@pci0:0:29:2: class=0x0c0300 card=0xd98015d9 chip=0x29368086 rev=0x02 hdr=0x00 > ehci1@pci0:0:29:7: class=0x0c0320 card=0xd98015d9 chip=0x293a8086 rev=0x02 hdr=0x00 > pcib5@pci0:0:30:0: class=0x060401 card=0xd98015d9 chip=0x244e8086 rev=0x92 hdr=0x01 > isab0@pci0:0:31:0: class=0x060100 card=0xd98015d9 chip=0x29168086 rev=0x02 hdr=0x00 > atapci1@pci0:0:31:2: class=0x01018a card=0xd98015d9 chip=0x29208086 rev=0x02 hdr=0x00 > none1@pci0:0:31:3: class=0x0c0500 card=0xd98015d9 chip=0x29308086 rev=0x02 hdr=0x00 > atapci2@pci0:0:31:5: class=0x010185 card=0xd98015d9 chip=0x29268086 rev=0x02 hdr=0x00 > none2@pci0:0:31:6: class=0x118000 card=0x000015d9 chip=0x29328086 rev=0x02 hdr=0x00 > vgapci0@pci0:1:0:0: class=0x030000 card=0x216619da chip=0x0e2210de rev=0xa1 hdr=0x00 > none3@pci0:1:0:1: class=0x040300 card=0x216619da chip=0x0beb10de rev=0xa1 hdr=0x00 > twa0@pci0:3:0:0: class=0x010400 card=0x100413c1 chip=0x100413c1 rev=0x01 hdr=0x00 > pcib4@pci0:5:0:0: class=0x060400 card=0x00000000 chip=0x032c8086 rev=0x09 hdr=0x01 > ioapic0@pci0:5:0:1: class=0x080020 card=0xd98015d9 chip=0x03268086 rev=0x09 hdr=0x00 > fwohci0@pci0:17:3:0: class=0x0c0010 card=0xba8015d9 chip=0x8023104c rev=0x00 hdr=0x00 > atapci0@pci0:17:4:0: class=0x010185 card=0x82131283 chip=0x82131283 rev=0x00 hdr=0x00 This output doesn't help -- it's too terse. Please use "pciconf -lvbc" instead. > Anyone else having issues? Thank you for tracking the issue down to something between roughly April 25th and April 29th. Different revisions/models of the ICH9 offer AHCI capability. Does your system BIOS let you toggle this? If so, I would recommend enabling it then trying to use ahci.ko ("load ahci.ko" from the loader "ok" prompt, or ahci_load="yes" in /boot/loader.conf) to see if things improve. Your CD drive will then appear as a SCSI-esque CD drive (e.g. cd(4) driver instead of atapicd), so be aware. This would be a workaround for your issue, assuming it works. I've CC'd mav@ who has likely committed something that's causing this issue, but unknown at this time. Relevant cvsweb details which someone can sift through: http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/dev/ata/ -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Sun May 29 05:17:21 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 46843106566B; Sun, 29 May 2011 05:17:21 +0000 (UTC) (envelope-from michael@rancid.berkeley.edu) Received: from malcolm.berkeley.edu (malcolm.Berkeley.EDU [IPv6:2607:f140:ffff:ffff::239]) by mx1.freebsd.org (Postfix) with ESMTP id 2BC888FC12; Sun, 29 May 2011 05:17:21 +0000 (UTC) Received: from towanda.burnttofu.net ([IPv6:2001:470:1f05:17a6:219:d1ff:fe26:5246]) (authenticated bits=0) by malcolm.berkeley.edu (8.14.4/8.13.8m1) with ESMTP id p4T5HK98023836 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Sat, 28 May 2011 22:17:20 -0700 (PDT) (envelope-from michael@rancid.berkeley.edu) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.96.2 at malcolm.berkeley.edu Message-ID: <4DE1D6DF.8010904@rancid.berkeley.edu> Date: Sat, 28 May 2011 22:17:19 -0700 From: Michael Sinatra User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.17) Gecko/20110513 Thunderbird/3.1.10 MIME-Version: 1.0 To: Jeremy Chadwick References: <4DE1C723.2070903@rancid.berkeley.edu> <20110529045615.GA44303@icarus.home.lan> In-Reply-To: <20110529045615.GA44303@icarus.home.lan> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (malcolm.berkeley.edu [IPv6:2607:f140:ffff:ffff::239]); Sat, 28 May 2011 22:17:21 -0700 (PDT) Cc: mav@freebsd.org, freebsd-stable@freebsd.org Subject: Re: ICH9 panic/instability on recent kernel X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 29 May 2011 05:17:21 -0000 On 05/28/11 21:56, Jeremy Chadwick wrote: > On Sat, May 28, 2011 at 09:10:11PM -0700, Michael Sinatra wrote: >> I have a core-2 system with a 3ware SATA RAID controller for the >> main disks and the built-in Intel ICH9 4-port SATA controller that >> is only used for the DVDR. An 8-STABLE kernel csup'd and compiled >> on April 25 works fine on this system. Kernels from source csup'd >> this week are extremely unstable and usually panic or hang just >> minutes after booting. The following warning messages appear after >> the kernel probes the SATA controller and/or ICH9 USB controller and >> continue about once per 1-2 seconds until the system crashes: >> >> May 13 14:21:05 sonicyouth kernel: unknown: WARNING - ATAPI_IDENTIFY >> requeued due to channel reset LBA=0 >> >> Disabling the ICH9 SATA controller in the BIOS allows the system to >> boot and run normally. >> >> Changes were made on April 28 to allow better support for 6-port >> ICH9 controllers (SVN rev 221156) and I am wondering if my >> controller is now being incorrectly recognized. >> >> Here's the relevant kernel messages: >> >> May 13 13:52:53 sonicyouth kernel: atapci1: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0x1c40-0x1c4f,0x1c30-0x1c3f at device 31.2 on pci0 >> May 13 13:52:53 sonicyouth kernel: ata0: on atapci1 >> May 13 13:52:53 sonicyouth kernel: ata0: [ITHREAD] >> May 13 13:52:53 sonicyouth kernel: ata1: on atapci1 >> May 13 13:52:53 sonicyouth kernel: ata1: [ITHREAD] >> May 13 13:52:53 sonicyouth kernel: atapci2: controller> port 0x1cb8-0x1cbf,0x1cac-0x1caf,0x1cb0-0x1cb7,0x1ca8-0x1cab,0x1c60-0x1c6f,0x1c50-0x1c5f irq 18 at device 31.5 on pci0 >> May 13 13:52:53 sonicyouth kernel: atapci2: [ITHREAD] >> May 13 13:52:53 sonicyouth kernel: ata3: on atapci2 >> May 13 13:52:53 sonicyouth kernel: ata3: [ITHREAD] >> May 13 13:52:53 sonicyouth kernel: ata4: on atapci2 >> May 13 13:52:53 sonicyouth kernel: ata4: [ITHREAD] >> >> If I csup the most recent kernel sources, I get the same problem. >> However, if, after csuping the latest kernel sources, I then fetch >> the version of sys/dev/ata/ata-all.c as of April 27, everything >> works fine. Here's the output of pciconf -l: >> >> hostb0@pci0:0:0:0: class=0x060000 card=0xd98015d9 chip=0x29e08086 rev=0x01 hdr=0x00 >> pcib1@pci0:0:1:0: class=0x060400 card=0xd98015d9 chip=0x29e18086 rev=0x01 hdr=0x01 >> pcib2@pci0:0:6:0: class=0x060400 card=0xd98015d9 chip=0x29e98086 rev=0x01 hdr=0x01 >> em0@pci0:0:25:0: class=0x020000 card=0x10bd15d9 chip=0x10bd8086 rev=0x02 hdr=0x00 >> uhci0@pci0:0:26:0: class=0x0c0300 card=0xd98015d9 chip=0x29378086 rev=0x02 hdr=0x00 >> uhci1@pci0:0:26:1: class=0x0c0300 card=0xd98015d9 chip=0x29388086 rev=0x02 hdr=0x00 >> uhci2@pci0:0:26:2: class=0x0c0300 card=0xd98015d9 chip=0x29398086 rev=0x02 hdr=0x00 >> ehci0@pci0:0:26:7: class=0x0c0320 card=0xd98015d9 chip=0x293c8086 rev=0x02 hdr=0x00 >> none0@pci0:0:27:0: class=0x040300 card=0xd98015d9 chip=0x293e8086 rev=0x02 hdr=0x00 >> pcib3@pci0:0:28:0: class=0x060400 card=0xd98015d9 chip=0x29408086 rev=0x02 hdr=0x01 >> uhci3@pci0:0:29:0: class=0x0c0300 card=0xd98015d9 chip=0x29348086 rev=0x02 hdr=0x00 >> uhci4@pci0:0:29:1: class=0x0c0300 card=0xd98015d9 chip=0x29358086 rev=0x02 hdr=0x00 >> uhci5@pci0:0:29:2: class=0x0c0300 card=0xd98015d9 chip=0x29368086 rev=0x02 hdr=0x00 >> ehci1@pci0:0:29:7: class=0x0c0320 card=0xd98015d9 chip=0x293a8086 rev=0x02 hdr=0x00 >> pcib5@pci0:0:30:0: class=0x060401 card=0xd98015d9 chip=0x244e8086 rev=0x92 hdr=0x01 >> isab0@pci0:0:31:0: class=0x060100 card=0xd98015d9 chip=0x29168086 rev=0x02 hdr=0x00 >> atapci1@pci0:0:31:2: class=0x01018a card=0xd98015d9 chip=0x29208086 rev=0x02 hdr=0x00 >> none1@pci0:0:31:3: class=0x0c0500 card=0xd98015d9 chip=0x29308086 rev=0x02 hdr=0x00 >> atapci2@pci0:0:31:5: class=0x010185 card=0xd98015d9 chip=0x29268086 rev=0x02 hdr=0x00 >> none2@pci0:0:31:6: class=0x118000 card=0x000015d9 chip=0x29328086 rev=0x02 hdr=0x00 >> vgapci0@pci0:1:0:0: class=0x030000 card=0x216619da chip=0x0e2210de rev=0xa1 hdr=0x00 >> none3@pci0:1:0:1: class=0x040300 card=0x216619da chip=0x0beb10de rev=0xa1 hdr=0x00 >> twa0@pci0:3:0:0: class=0x010400 card=0x100413c1 chip=0x100413c1 rev=0x01 hdr=0x00 >> pcib4@pci0:5:0:0: class=0x060400 card=0x00000000 chip=0x032c8086 rev=0x09 hdr=0x01 >> ioapic0@pci0:5:0:1: class=0x080020 card=0xd98015d9 chip=0x03268086 rev=0x09 hdr=0x00 >> fwohci0@pci0:17:3:0: class=0x0c0010 card=0xba8015d9 chip=0x8023104c rev=0x00 hdr=0x00 >> atapci0@pci0:17:4:0: class=0x010185 card=0x82131283 chip=0x82131283 rev=0x00 hdr=0x00 > > This output doesn't help -- it's too terse. Please use "pciconf -lvbc" > instead. Sorry about that. Here's the output: sonicyouth# pciconf -lvbc hostb0@pci0:0:0:0: class=0x060000 card=0xd98015d9 chip=0x29e08086 rev=0x01 hdr=0x00 vendor = 'Intel Corporation' device = 'X38/X48 (Bearlake) Processor to I/O Controller' class = bridge subclass = HOST-PCI cap 09[e0] = vendor (length 12) Intel cap 0 version 1 pcib1@pci0:0:1:0: class=0x060400 card=0xd98015d9 chip=0x29e18086 rev=0x01 hdr=0x01 vendor = 'Intel Corporation' device = 'X38/X48 (Bearlake) PCIe Root Port 1' class = bridge subclass = PCI-PCI cap 0d[88] = PCI Bridge card=0xd98015d9 cap 01[80] = powerspec 3 supports D0 D3 current D0 cap 05[90] = MSI supports 1 message cap 10[a0] = PCI-Express 2 root port max data 128(128) link x16(x16) ecap 0002[100] = VC 1 max VC0 ecap 0005[140] = unknown 1 pcib2@pci0:0:6:0: class=0x060400 card=0xd98015d9 chip=0x29e98086 rev=0x01 hdr=0x01 vendor = 'Intel Corporation' device = 'X38/X48 (Bearlake) PCIe Root Port 2' class = bridge subclass = PCI-PCI cap 0d[88] = PCI Bridge card=0xd98015d9 cap 01[80] = powerspec 3 supports D0 D3 current D0 cap 05[90] = MSI supports 1 message cap 10[a0] = PCI-Express 2 root port max data 128(128) link x1(x16) ecap 0002[100] = VC 1 max VC0 ecap 0005[140] = unknown 1 em0@pci0:0:25:0: class=0x020000 card=0x10bd15d9 chip=0x10bd8086 rev=0x02 hdr=0x00 vendor = 'Intel Corporation' device = 'Intel 82566DM Gigabit Ethernet Adapter (82566DM)' class = network subclass = ethernet bar [10] = type Memory, range 32, base 0xd8600000, size 131072, enabled bar [14] = type Memory, range 32, base 0xd8627000, size 4096, enabled bar [18] = type I/O Port, range 32, base 0x1820, size 32, enabled cap 01[c8] = powerspec 2 supports D0 D3 current D0 cap 05[d0] = MSI supports 1 message, 64 bit enabled with 1 message cap 13[e0] = PCI Advanced Features: FLR TP uhci0@pci0:0:26:0: class=0x0c0300 card=0xd98015d9 chip=0x29378086 rev=0x02 hdr=0x00 vendor = 'Intel Corporation' device = '82801IB/IR/IH (ICH9 Family) USB Universal Host Controller' class = serial bus subclass = USB bar [20] = type I/O Port, range 32, base 0x1840, size 32, enabled cap 13[50] = PCI Advanced Features: FLR TP uhci1@pci0:0:26:1: class=0x0c0300 card=0xd98015d9 chip=0x29388086 rev=0x02 hdr=0x00 vendor = 'Intel Corporation' device = '82801IB/IR/IH (ICH9 Family) USB Universal Host Controller' class = serial bus subclass = USB bar [20] = type I/O Port, range 32, base 0x1860, size 32, enabled cap 13[50] = PCI Advanced Features: FLR TP uhci2@pci0:0:26:2: class=0x0c0300 card=0xd98015d9 chip=0x29398086 rev=0x02 hdr=0x00 vendor = 'Intel Corporation' device = '82801IB/IR/IH (ICH9 Family) USB Universal Host Controller' class = serial bus subclass = USB bar [20] = type I/O Port, range 32, base 0x1880, size 32, enabled cap 13[50] = PCI Advanced Features: FLR TP ehci0@pci0:0:26:7: class=0x0c0320 card=0xd98015d9 chip=0x293c8086 rev=0x02 hdr=0x00 vendor = 'Intel Corporation' device = '82801IB/IR/IH (ICH9 Family) USB2 Enhanced Host Controller' class = serial bus subclass = USB bar [10] = type Memory, range 32, base 0xd8628000, size 1024, enabled cap 01[50] = powerspec 2 supports D0 D3 current D0 cap 0a[58] = EHCI Debug Port at offset 0xa0 in map 0x14 cap 13[98] = PCI Advanced Features: FLR TP none0@pci0:0:27:0: class=0x040300 card=0xd98015d9 chip=0x293e8086 rev=0x02 hdr=0x00 vendor = 'Intel Corporation' device = '82801IB/IR/IH (ICH9 Family) HD Audio Controller' class = multimedia subclass = HDA bar [10] = type Memory, range 64, base 0xd8620000, size 16384, enabled cap 01[50] = powerspec 2 supports D0 D3 current D0 cap 05[60] = MSI supports 1 message, 64 bit cap 10[70] = PCI-Express 1 root endpoint max data 128(128) link x0(x0) ecap 0002[100] = VC 1 max VC1 ecap 0005[130] = unknown 1 pcib3@pci0:0:28:0: class=0x060400 card=0xd98015d9 chip=0x29408086 rev=0x02 hdr=0x01 vendor = 'Intel Corporation' device = '82801IB/IR/IH (ICH9 Family) PCIe Root Port 1' class = bridge subclass = PCI-PCI cap 10[40] = PCI-Express 1 root port max data 128(128) link x4(x4) cap 05[80] = MSI supports 1 message cap 0d[90] = PCI Bridge card=0xd98015d9 cap 01[a0] = powerspec 2 supports D0 D3 current D0 ecap 0002[100] = VC 1 max VC0 ecap 0005[180] = unknown 1 uhci3@pci0:0:29:0: class=0x0c0300 card=0xd98015d9 chip=0x29348086 rev=0x02 hdr=0x00 vendor = 'Intel Corporation' device = '82801IB/IR/IH (ICH9 Family) USB Universal Host Controller' class = serial bus subclass = USB bar [20] = type I/O Port, range 32, base 0x18a0, size 32, enabled cap 13[50] = PCI Advanced Features: FLR TP uhci4@pci0:0:29:1: class=0x0c0300 card=0xd98015d9 chip=0x29358086 rev=0x02 hdr=0x00 vendor = 'Intel Corporation' device = '82801IB/IR/IH (ICH9 Family) USB Universal Host Controller' class = serial bus subclass = USB bar [20] = type I/O Port, range 32, base 0x18c0, size 32, enabled cap 13[50] = PCI Advanced Features: FLR TP uhci5@pci0:0:29:2: class=0x0c0300 card=0xd98015d9 chip=0x29368086 rev=0x02 hdr=0x00 vendor = 'Intel Corporation' device = '82801IB/IR/IH (ICH9 Family) USB Universal Host Controller' class = serial bus subclass = USB bar [20] = type I/O Port, range 32, base 0x18e0, size 32, enabled cap 13[50] = PCI Advanced Features: FLR TP ehci1@pci0:0:29:7: class=0x0c0320 card=0xd98015d9 chip=0x293a8086 rev=0x02 hdr=0x00 vendor = 'Intel Corporation' device = '82801IB/IR/IH (ICH9 Family) USB2 Enhanced Host Controller' class = serial bus subclass = USB bar [10] = type Memory, range 32, base 0xd8629000, size 1024, enabled cap 01[50] = powerspec 2 supports D0 D3 current D0 cap 0a[58] = EHCI Debug Port at offset 0xa0 in map 0x14 cap 13[98] = PCI Advanced Features: FLR TP pcib5@pci0:0:30:0: class=0x060401 card=0xd98015d9 chip=0x244e8086 rev=0x92 hdr=0x01 vendor = 'Intel Corporation' device = '82801 Family (ICH2/3/4/5/6/7/8/9,63xxESB) Hub Interface to PCI Bridge' class = bridge subclass = PCI-PCI cap 0d[50] = PCI Bridge card=0xd98015d9 isab0@pci0:0:31:0: class=0x060100 card=0xd98015d9 chip=0x29168086 rev=0x02 hdr=0x00 vendor = 'Intel Corporation' device = '82801IR (ICH9R) LPC Interface Controller' class = bridge subclass = PCI-ISA cap 09[e0] = vendor (length 12) Intel cap 1 version 0 features: SATA RAID-5, 4 PCI-e x1 slots atapci1@pci0:0:31:2: class=0x01018a card=0xd98015d9 chip=0x29208086 rev=0x02 hdr=0x00 vendor = 'Intel Corporation' device = '82801IB/IR/IH (ICH9 Family) 4 port Serial ATA Storage Controller 1' class = mass storage subclass = ATA bar [10] = type I/O Port, range 32, base 0x1f0, size 8, enabled bar [14] = type I/O Port, range 32, base 0x3f4, size 1, enabled bar [18] = type I/O Port, range 32, base 0x170, size 8, enabled bar [1c] = type I/O Port, range 32, base 0x374, size 1, enabled bar [20] = type I/O Port, range 32, base 0x1c40, size 16, enabled bar [24] = type I/O Port, range 32, base 0x1c30, size 16, enabled cap 01[70] = powerspec 3 supports D0 D3 current D0 cap 13[b0] = PCI Advanced Features: FLR TP none1@pci0:0:31:3: class=0x0c0500 card=0xd98015d9 chip=0x29308086 rev=0x02 hdr=0x00 vendor = 'Intel Corporation' device = 'Intel(R) ICH9 Family SMBus Controller working fine with http://download.cnet.com/Chipset-Driver-Inte (8086)' class = serial bus subclass = SMBus bar [10] = type Memory, range 64, base 0xd862a000, size 256, enabled bar [20] = type I/O Port, range 32, base 0x1100, size 32, enabled atapci2@pci0:0:31:5: class=0x010185 card=0xd98015d9 chip=0x29268086 rev=0x02 hdr=0x00 vendor = 'Intel Corporation' device = '82801IB/IR/IH (ICH9 Family) 2 port Serial ATA Storage Controller 2' class = mass storage subclass = ATA bar [10] = type I/O Port, range 32, base 0x1cb8, size 8, enabled bar [14] = type I/O Port, range 32, base 0x1cac, size 4, enabled bar [18] = type I/O Port, range 32, base 0x1cb0, size 8, enabled bar [1c] = type I/O Port, range 32, base 0x1ca8, size 4, enabled bar [20] = type I/O Port, range 32, base 0x1c60, size 16, enabled bar [24] = type I/O Port, range 32, base 0x1c50, size 16, enabled cap 01[70] = powerspec 3 supports D0 D3 current D0 cap 13[b0] = PCI Advanced Features: FLR TP none2@pci0:0:31:6: class=0x118000 card=0x000015d9 chip=0x29328086 rev=0x02 hdr=0x00 vendor = 'Intel Corporation' device = '82801IB/IR/IH (ICH9 Family) Thermal Subsystem' class = dasp bar [10] = type Memory, range 64, base 0xd862b000, size 4096, enabled cap 01[50] = powerspec 3 supports D0 D3 current D0 vgapci0@pci0:1:0:0: class=0x030000 card=0x216619da chip=0x0e2210de rev=0xa1 hdr=0x00 vendor = 'NVIDIA Corporation' class = display subclass = VGA bar [10] = type Memory, range 32, base 0xd6000000, size 33554432, enabled bar [14] = type Prefetchable Memory, range 64, base 0xc8000000, size 134217728, enabled bar [1c] = type Prefetchable Memory, range 64, base 0xd0000000, size 67108864, enabled bar [24] = type I/O Port, range 32, base 0x2000, size 128, enabled cap 01[60] = powerspec 3 supports D0 D3 current D0 cap 05[68] = MSI supports 1 message, 64 bit cap 10[78] = PCI-Express 1 endpoint max data 128(128) link x16(x16) cap 09[b4] = vendor (length 20) ecap 0002[100] = VC 1 max VC0 ecap 0004[128] = unknown 1 ecap 000b[600] = unknown 1 none3@pci0:1:0:1: class=0x040300 card=0x216619da chip=0x0beb10de rev=0xa1 hdr=0x00 vendor = 'NVIDIA Corporation' class = multimedia subclass = HDA bar [10] = type Memory, range 32, base 0xd8000000, size 16384, enabled cap 01[60] = powerspec 3 supports D0 D3 current D0 cap 05[68] = MSI supports 1 message, 64 bit cap 10[78] = PCI-Express 1 endpoint max data 128(128) link x16(x16) twa0@pci0:3:0:0: class=0x010400 card=0x100413c1 chip=0x100413c1 rev=0x01 hdr=0x00 vendor = '3ware Inc' device = 'PCI-Express SATA2 Raid Controller (9650SE Series)' class = mass storage subclass = RAID bar [10] = type Prefetchable Memory, range 64, base 0xd4000000, size 33554432, enabled bar [18] = type Memory, range 64, base 0xd8100000, size 4096, enabled bar [20] = type I/O Port, range 32, base 0x3000, size 256, enabled cap 01[40] = powerspec 2 supports D0 D1 D2 D3 current D0 cap 05[50] = MSI supports 32 messages, 64 bit cap 10[70] = PCI-Express 1 legacy endpoint max data 128(512) link x1(x8) ecap 0001[100] = AER 1 0 fatal 1 non-fatal 1 corrected pcib4@pci0:5:0:0: class=0x060400 card=0x00000000 chip=0x032c8086 rev=0x09 hdr=0x01 vendor = 'Intel Corporation' device = 'PCI Express-to-PCI Express Bridge (6702PXH)' class = bridge subclass = PCI-PCI cap 10[44] = PCI-Express 1 PCI bridge max data 128(256) link x4(x8) cap 05[5c] = MSI supports 1 message, 64 bit cap 01[6c] = powerspec 2 supports D0 D3 current D0 cap 07[d8] = PCI-X bridge ecap 0001[100] = AER 1 0 fatal 1 non-fatal 0 corrected ecap 0004[300] = unknown 1 ioapic0@pci0:5:0:1: class=0x080020 card=0xd98015d9 chip=0x03268086 rev=0x09 hdr=0x00 vendor = 'Intel Corporation' device = '6700/6702PXH I/OxAPIC Interrupt Controller A' class = base peripheral subclass = interrupt controller bar [10] = type Memory, range 32, base 0xd8300000, size 4096, enabled cap 10[44] = PCI-Express 1 endpoint max data 256(256) link x4(x8) cap 01[6c] = powerspec 2 supports D0 D3 current D0 fwohci0@pci0:17:3:0: class=0x0c0010 card=0xba8015d9 chip=0x8023104c rev=0x00 hdr=0x00 vendor = 'Texas Instruments (TI)' device = 'IEEE1394a-2000 OHCI PHY/Link-Layer Ctrlr (TSB43AB21/A)' class = serial bus subclass = FireWire bar [10] = type Memory, range 32, base 0xd8204000, size 2048, enabled bar [14] = type Memory, range 32, base 0xd8200000, size 16384, enabled cap 01[44] = powerspec 2 supports D0 D1 D2 D3 current D0 atapci0@pci0:17:4:0: class=0x010185 card=0x82131283 chip=0x82131283 rev=0x00 hdr=0x00 vendor = 'Integrated Technology Express (ITE) Inc' device = 'IDE Controller (IT8213F)' class = mass storage subclass = ATA bar [10] = type I/O Port, range 32, base 0x4020, size 8, enabled bar [14] = type I/O Port, range 32, base 0x4014, size 4, enabled bar [18] = type I/O Port, range 32, base 0x4018, size 8, enabled bar [1c] = type I/O Port, range 32, base 0x4010, size 4, enabled bar [20] = type I/O Port, range 32, base 0x4000, size 16, enabled cap 01[80] = powerspec 2 supports D0 D3 current D0 > Thank you for tracking the issue down to something between roughly > April 25th and April 29th. It looked from SVN as if the April 28th MFCs had caused the issue, but I can't narrow it down further, other than to note that replacing ata-all.c with an older version (as of April 27 it was "$FreeBSD: src/sys/dev/ata/ata-all.c,v 1.308.2.20 2011/04/19 17:01:05 mav Exp $") allowed me to boot with SATA enabled. > Different revisions/models of the ICH9 offer AHCI capability. Does your > system BIOS let you toggle this? If so, I would recommend enabling it > then trying to use ahci.ko ("load ahci.ko" from the loader "ok" prompt, > or ahci_load="yes" in /boot/loader.conf) to see if things improve. Your > CD drive will then appear as a SCSI-esque CD drive (e.g. cd(4) driver > instead of atapicd), so be aware. This would be a workaround for your > issue, assuming it works. Right now, I am not at my workstation (I left the office a while ago), and probably won't be back until Tuesday. I'll try it then, if I don't get to it sooner. > I've CC'd mav@ who has likely committed something that's causing this > issue, but unknown at this time. Relevant cvsweb details which someone > can sift through: > > http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/dev/ata/ michael From owner-freebsd-stable@FreeBSD.ORG Sun May 29 06:54:29 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E1785106566B for ; Sun, 29 May 2011 06:54:28 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-bw0-f54.google.com (mail-bw0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id 2DDDC8FC12 for ; Sun, 29 May 2011 06:54:27 +0000 (UTC) Received: by bwz12 with SMTP id 12so3233280bwz.13 for ; Sat, 28 May 2011 23:54:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:sender:message-id:date:from:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=sA6bMsmLAERJC8p+EkyRz+dS2AYKzXEoxsrb5mtCews=; b=gsJWexboC9zC9wYeDDq9q/PNI03V5QvFzyS8kS5X/eUgWQhBULQ4zoXQdBSDf0rPVf 5Shhoz5P48B8D4qpLGKC9upeV3BZpjDJvt7OzhnNwrg8ca3bG46UMbxn5Xn6traQunAL dOWmlGkVLsgJV46oGQqcXEIMTujzqpAC07jtI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=cmCeNNtG3SZ2a+HK+qQ1nCEIly7mIM3xZh4UuomiaHgqXlDu+3mGRA39ZEa87G5+oL 95W/9ZAq23W+myA5bTmUSCLE+4wS6oCpA/gtzGMy8bN/UyagGbwvsH0F2sQv4PBmNpRt vd7dF54RWKnGUc0dVxaug1ErplJLz3Cnvw7TE= Received: by 10.204.6.219 with SMTP id a27mr3207094bka.171.1306652066856; Sat, 28 May 2011 23:54:26 -0700 (PDT) Received: from mavbook.mavhome.dp.ua ([91.198.175.1]) by mx.google.com with ESMTPS id k10sm2482513bkq.10.2011.05.28.23.54.25 (version=SSLv3 cipher=OTHER); Sat, 28 May 2011 23:54:25 -0700 (PDT) Sender: Alexander Motin Message-ID: <4DE1ED9E.9070303@FreeBSD.org> Date: Sun, 29 May 2011 09:54:22 +0300 From: Alexander Motin User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.15) Gecko/20110310 Thunderbird/3.1.9 MIME-Version: 1.0 To: Michael Sinatra References: <4DE1C723.2070903@rancid.berkeley.edu> <20110529045615.GA44303@icarus.home.lan> In-Reply-To: <20110529045615.GA44303@icarus.home.lan> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org, Jeremy Chadwick Subject: Re: ICH9 panic/instability on recent kernel X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 29 May 2011 06:54:29 -0000 On 29.05.2011 07:56, Jeremy Chadwick wrote: > On Sat, May 28, 2011 at 09:10:11PM -0700, Michael Sinatra wrote: >> I have a core-2 system with a 3ware SATA RAID controller for the >> main disks and the built-in Intel ICH9 4-port SATA controller that >> is only used for the DVDR. An 8-STABLE kernel csup'd and compiled >> on April 25 works fine on this system. Kernels from source csup'd >> this week are extremely unstable and usually panic or hang just >> minutes after booting. The following warning messages appear after >> the kernel probes the SATA controller and/or ICH9 USB controller and >> continue about once per 1-2 seconds until the system crashes: >> >> May 13 14:21:05 sonicyouth kernel: unknown: WARNING - ATAPI_IDENTIFY >> requeued due to channel reset LBA=0 >> >> Disabling the ICH9 SATA controller in the BIOS allows the system to >> boot and run normally. >> >> Changes were made on April 28 to allow better support for 6-port >> ICH9 controllers (SVN rev 221156) and I am wondering if my >> controller is now being incorrectly recognized. >> >> Here's the relevant kernel messages: >> >> May 13 13:52:53 sonicyouth kernel: atapci1: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0x1c40-0x1c4f,0x1c30-0x1c3f at device 31.2 on pci0 >> May 13 13:52:53 sonicyouth kernel: ata0: on atapci1 >> May 13 13:52:53 sonicyouth kernel: ata0: [ITHREAD] >> May 13 13:52:53 sonicyouth kernel: ata1: on atapci1 >> May 13 13:52:53 sonicyouth kernel: ata1: [ITHREAD] >> May 13 13:52:53 sonicyouth kernel: atapci2: controller> port 0x1cb8-0x1cbf,0x1cac-0x1caf,0x1cb0-0x1cb7,0x1ca8-0x1cab,0x1c60-0x1c6f,0x1c50-0x1c5f irq 18 at device 31.5 on pci0 >> May 13 13:52:53 sonicyouth kernel: atapci2: [ITHREAD] >> May 13 13:52:53 sonicyouth kernel: ata3: on atapci2 >> May 13 13:52:53 sonicyouth kernel: ata3: [ITHREAD] >> May 13 13:52:53 sonicyouth kernel: ata4: on atapci2 >> May 13 13:52:53 sonicyouth kernel: ata4: [ITHREAD] >> >> If I csup the most recent kernel sources, I get the same problem. >> However, if, after csuping the latest kernel sources, I then fetch >> the version of sys/dev/ata/ata-all.c as of April 27, everything >> works fine. Here's the output of pciconf -l: The only change in 8-STABLE ata-all.c since April 27 was the SVN rev 221155. But I don't see how can it cause problems. I would really like to see full _verbose_ demsg output to better understand what is going on there. If it even panics, I need to see how exactly. -- Alexander Motin From owner-freebsd-stable@FreeBSD.ORG Sun May 29 10:14:09 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B0644106566C for ; Sun, 29 May 2011 10:14:09 +0000 (UTC) (envelope-from daniel@digsys.bg) Received: from smtp-sofia.digsys.bg (smtp-sofia.digsys.bg [193.68.3.230]) by mx1.freebsd.org (Postfix) with ESMTP id 242128FC12 for ; Sun, 29 May 2011 10:14:08 +0000 (UTC) Received: from [193.68.136.252] (digsys252-136.pip.digsys.bg [193.68.136.252]) (authenticated bits=0) by smtp-sofia.digsys.bg (8.14.4/8.14.4) with ESMTP id p4TADusa036328 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Sun, 29 May 2011 13:14:02 +0300 (EEST) (envelope-from daniel@digsys.bg) Message-ID: <4DE21C64.8060107@digsys.bg> Date: Sun, 29 May 2011 13:13:56 +0300 From: Daniel Kalchev User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-GB; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: freebsd-stable@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: HAST instability X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 29 May 2011 10:14:09 -0000 I am trying to get a basic HAST setup working on 8-stable (as of today). Hardware is two supermicro blades, each with 2x Xeon E5620 processors, 48GB RAM, integrated LSI2008 controller, two 600GB SAS2 Toshiba drives, two Intel gigabit interfaces and two Intel 10Gbit interfaces. On each of the drives there is an GPT partition intended to be used by HAST. Each host thus has two HAST resources, data0 and data1 respectively. HAST is run over the 10Gbit interfaces, connected via the blade chasis 10Gbit switch. /etc/hast.conf is resource data0 { on b1a { local /dev/gpt/data0 remote 10.2.101.12 } on b1b { local /dev/gpt/data0 remote 10.2.101.11 } } resource data1 { on b1a { local /dev/gpt/data1 remote 10.2.101.12 } on b1b { local /dev/gpt/data1 remote 10.2.101.11 } } On top of data0 and data1 I run ZFS mirror, although this doesn't seem to be relevant here. What I am observing is very jumpy performance, both nodes often disconnect with primary: May 29 13:06:33 b1b hastd[2372]: [data0] (primary) Unable to receive reply header: Socket is not connected. May 29 13:06:33 b1b hastd[2372]: [data0] (primary) Unable to send request (Broken pipe): WRITE(60470853632, 131072). May 29 13:06:33 b1b hastd[2372]: [data0] (primary) Disconnected from 10.2.101.11. May 29 13:06:33 b1b hastd[2372]: [data0] (primary) Unable to write synchronization data: Socket is not connected. on secondary: May 29 03:03:14 b1a hastd[28357]: [data1] (secondary) Unable to receive request header: RPC version wrong. May 29 03:03:19 b1a hastd[11659]: [data1] (secondary) Worker process exited ungracefully (pid=28357, exitcode=75). May 29 03:05:31 b1a hastd[35535]: [data0] (secondary) Unable to receive request header: RPC version wrong. May 29 03:05:36 b1a hastd[11659]: [data0] (secondary) Worker process exited ungracefully (pid=35535, exitcode=75). When it works, replication rate observed with 'systat -if' is over 140MB/sec (perhaps limited by drives write troughput) The only reference to this error messages I found in http://lists.freebsd.org/pipermail/freebsd-stable/2010-November/059817.html, and that thread indicated the fix was commited. About the only tuning these machines have is to set kern.ipc.nmbclusters=51200, because with the default values 10Gbit interfaces would not work and anyway the system would run out of mbufs. Has anyone observed something similar? Any ideas how to fix it? Daniel From owner-freebsd-stable@FreeBSD.ORG Mon May 30 09:25:22 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CB6BD106567A; Mon, 30 May 2011 09:25:22 +0000 (UTC) (envelope-from willy@Offermans.Rompen.nl) Received: from cpsmtpb-ews01.kpnxchange.com (cpsmtpb-ews01.kpnxchange.com [213.75.39.4]) by mx1.freebsd.org (Postfix) with ESMTP id 4D0CF8FC1E; Mon, 30 May 2011 09:25:21 +0000 (UTC) Received: from cpbrm-ews17.kpnxchange.com ([10.94.84.148]) by cpsmtpb-ews01.kpnxchange.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 30 May 2011 11:25:20 +0200 Received: from CPSMTPM-CMT108.kpnxchange.com ([195.121.3.24]) by cpbrm-ews17.kpnxchange.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 30 May 2011 11:25:19 +0200 Received: from koko.offrom.nl ([77.170.60.162]) by CPSMTPM-CMT108.kpnxchange.com with Microsoft SMTPSVC(7.0.6002.18264); Mon, 30 May 2011 11:25:18 +0200 Received: from squid.home.itmc.RWTH-Aachen.DE (squid.vpn.offrom.nl [10.168.0.72]) by koko.offrom.nl (8.14.3/8.14.3) with ESMTP id p4U9PFb4051245; Mon, 30 May 2011 11:25:15 +0200 (CEST) (envelope-from willy@vpn.offrom.nl) Received: from willy by squid.home.itmc.RWTH-Aachen.DE with local (Exim 4.72) (envelope-from ) id 1QQyio-0001OB-K1; Mon, 30 May 2011 11:25:14 +0200 Date: Mon, 30 May 2011 11:25:14 +0200 From: Willy Offermans To: John Baldwin Message-ID: <20110530092514.GB4558@vpn.offrom.nl> References: <20110521092037.GB3271@vpn.offrom.nl> <201105270805.56457.jhb@freebsd.org> <20110527143802.GA5352@vpn.offrom.nl> <201105271043.34268.jhb@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201105271043.34268.jhb@freebsd.org> User-Agent: Mutt/1.5.20 (2009-06-14) X-OriginalArrivalTime: 30 May 2011 09:25:18.0941 (UTC) FILETIME=[7E0528D0:01CC1EAB] X-RcptDomain: freebsd.org Cc: Marcel Moolenaar , freebsd-stable@freebsd.org, freebsd-hardware@freebsd.org Subject: Re: modem support MT9234ZPX-PCIE-NV X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Willy@Offermans.Rompen.nl List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 May 2011 09:25:22 -0000 Hello John and FreeBSD friends, On Fri, May 27, 2011 at 10:43:34AM -0400, John Baldwin wrote: > On Friday, May 27, 2011 10:38:02 am Willy Offermans wrote: > > Dear John and FreeBSD friends, > > > > On Fri, May 27, 2011 at 08:05:56AM -0400, John Baldwin wrote: > > > On Thursday, May 26, 2011 4:58:37 pm Mike Tancsa wrote: > > > > On 5/26/2011 4:12 PM, John Baldwin wrote: > > > > > > > > > > Hmm, can you get 'pciconf -lb' output? > > > > > > > > > > Hmm, wow, I wonder how uart(4) works at all. It tries to reuse it's softc > > > > > structure in uart_bus_attach() that was setup in uart_bus_probe(). Since > > > it > > > > > doesn't return 0 from its probe routine, that is forbidden. I guess it > > > > > accidentally works because of the hack where we call DEVICE_PROBE() again > > > > > to make sure the device description is correct. > > > > > > > > > > > > I think this is a similar card. Had it laying about for a while and > > > > popped it in. cu -l to it, attaches, but I am not able to interact with it. > > > > > > > > none3@pci0:5:0:0: class=0x070002 card=0x20282205 chip=0x015213a8 > > > > rev=0x02 hdr=0x00 > > > > vendor = 'Exar Corp.' > > > > device = 'XR17C/D152 Dual PCI UART' > > > > class = simple comms > > > > subclass = UART > > > > bar [10] = type Memory, range 32, base 0xe8950000, size 1024, enabled > > > > > > > > > > > > NetBSD supposedly has support for this card > > > > > > Oh, hmm, looks like the clock has an unusual multiplier. Does it work if you > > > use 'cu -l -s 1200' to talk at 9600 for example? (In general use speed / 8 > > > as the speed to '-s'.) > > > > > > Also, is your card a modem or a dual-port card? > > > > > > -- > > > John Baldwin > > > > It is a modem. > > > > As suggested: > > > > kosmos# cu -l /dev/cuau0 -s 1200 > > Stale lock on cuau0 PID=3642... overriding. > > Connected > > at&F > > OK > > atdt0045******* > > NO DIALTONE > > Ok, try this updated patch. After this you should be able to use the correct > speed: > > Index: uart_bus_pci.c > =================================================================== > --- uart_bus_pci.c (revision 222285) > +++ uart_bus_pci.c (working copy) > @@ -110,6 +110,8 @@ static struct pci_id pci_ns8250_ids[] = { > { 0x1415, 0x950b, 0xffff, 0, "Oxford Semiconductor OXCB950 Cardbus 16950 UART", > 0x10, 16384000 }, > { 0x151f, 0x0000, 0xffff, 0, "TOPIC Semiconductor TP560 56k modem", 0x10 }, > +{ 0x13a8, 0x0152, 0x2205, 0x2026, "MultiTech MultiModem ZPX", 0x10, > + 8 * DEFAULT_RCLK }, > { 0x9710, 0x9820, 0x1000, 1, "NetMos NM9820 Serial Port", 0x10 }, > { 0x9710, 0x9835, 0x1000, 1, "NetMos NM9835 Serial Port", 0x10 }, > { 0x9710, 0x9865, 0xa000, 0x1000, "NetMos NM9865 Serial Port", 0x10 }, > > -- > John Baldwin Hello John, After inserting the magic line into uart_bus_pci.c, things start to be really good. Minicom is now able to communicate with the device in a proper way. Hereafter you can see some response from the modem. AT S7=45 S0=0 L1 V1 X4 &c1 E1 Q0 OK at OK ati Agere OCM V.92 MT9234ZPX-PCIE Internal Data/Fax/Voice Modem Version 1.02d OK at&F OK atdt0,0455444944 NO DIALTONE Of course there is no dialtone, since the telephone line is not connected yet. I will ask the people on the remote site to connect the line as soon as possible. The status of HylaFAX is also as expected: kosmos# faxstat HylaFAX scheduler on localhost: Running Modem cuau0 (+31455667077): Running and idle As soon as the line is established and as soon as I have established a proper setup with HylaFAX and performed some tests, I will report about the results again. I would like to thank you for your support so far. It was of great help and without it I would certainly not have succeed. However, since it does not seem to be so difficult, it would be wise to put the setup into http://www.freebsd.org/doc/handbook/serial.html. Other users would benefit from it. The structure you have provided in your magic line would also need some explanation. The data concerns the description of the chip and the card I guess and can be gained by `pciconf -lv` uart0@pci0:6:0:0: class=0x070002 card=0x20262205 chip=0x015213a8 rev=0x02 hdr=0x00 vendor = 'Exar Corp.' device = 'XR17C/D152 Dual PCI UART' class = simple comms subclass = UART A more detailed explanation would not harm. The data 0x10 and 8 * DEFAULT_RCLK are still totally miraculous to me. -- Met vriendelijke groeten, With kind regards, Mit freundlichen Gruessen, Willy ************************************* W.K. Offermans Home: +31 45 544 49 44 Mobile: +31 681 15 87 68 e-mail: Willy@Offermans.Rompen.nl From owner-freebsd-stable@FreeBSD.ORG Mon May 30 09:35:50 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0C423106566B for ; Mon, 30 May 2011 09:35:50 +0000 (UTC) (envelope-from O.Seibert@cs.ru.nl) Received: from kookpunt.science.ru.nl (kookpunt.science.ru.nl [131.174.30.61]) by mx1.freebsd.org (Postfix) with ESMTP id 7AC7A8FC17 for ; Mon, 30 May 2011 09:35:48 +0000 (UTC) Received: from twoquid.cs.ru.nl (twoquid.cs.ru.nl [131.174.142.38]) by kookpunt.science.ru.nl (8.13.7/5.31) with ESMTP id p4U9Zkmb008698; Mon, 30 May 2011 11:35:46 +0200 (MEST) Received: by twoquid.cs.ru.nl (Postfix, from userid 4100) id C9E132E03C; Mon, 30 May 2011 11:35:46 +0200 (CEST) Date: Mon, 30 May 2011 11:35:46 +0200 From: Olaf Seibert To: freebsd-stable@freebsd.org Message-ID: <20110530093546.GX6733@twoquid.cs.ru.nl> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.19 (2009-01-05) X-Spam-Score: -1.799 () ALL_TRUSTED,BAYES_50 X-Scanned-By: MIMEDefang 2.63 on 131.174.30.61 Subject: ZFS I/O errors X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 30 May 2011 09:35:50 -0000 "My" FreeBSD system somehow rebooted itself last friday in the early hours in the morning, and since then /var/log/messages is full with messages like these: May 30 10:38:28 fourquid root: ZFS: zpool I/O failure, zpool=tank error=86 May 30 10:38:38 fourquid root: ZFS: checksum mismatch, zpool=tank path=/dev/da3 offset=278593630720 size=7680 May 30 10:38:38 fourquid root: ZFS: checksum mismatch, zpool=tank path=/dev/da4 offset=278593630720 size=7680 May 30 10:38:38 fourquid root: ZFS: checksum mismatch, zpool=tank path=/dev/da5 offset=278593630720 size=7680 May 30 10:38:38 fourquid root: ZFS: checksum mismatch, zpool=tank path=/dev/da0 offset=278593631232 size=7680 May 30 10:38:38 fourquid root: ZFS: checksum mismatch, zpool=tank path=/dev/da1 offset=278593631232 size=7680 May 30 10:38:38 fourquid root: ZFS: checksum mismatch, zpool=tank path=/dev/da2 offset=278593631232 size=7680 May 30 10:38:38 fourquid root: ZFS: checksum mismatch, zpool=tank path=/dev/da3 offset=278593630720 size=7680 May 30 10:38:38 fourquid root: ZFS: checksum mismatch, zpool=tank path=/dev/da4 offset=278593630720 size=7680 May 30 10:38:38 fourquid root: ZFS: checksum mismatch, zpool=tank path=/dev/da5 offset=278593630720 size=7680 May 30 10:38:38 fourquid root: ZFS: checksum mismatch, zpool=tank path=/dev/da0 offset=278593631232 size=7680 May 30 10:38:38 fourquid root: ZFS: checksum mismatch, zpool=tank path=/dev/da1 offset=278593631232 size=7680 May 30 10:38:38 fourquid root: ZFS: checksum mismatch, zpool=tank path=/dev/da2 offset=278593631232 size=7680 i.e. errors op all disks that make up the pool. There appear to be more than just the two offsets as mentioned in this block of messages but so far it seems the number of them is limited. Seemingly they stopped around the time I logged in. I started a scrub, just in case. zpool status -v says this: fourquid.1:~$ sudo zpool status -v pool: tank state: ONLINE status: One or more devices has experienced an error resulting in data corruption. Applications may be affected. action: Restore the file in question if possible. Otherwise restore the entire pool from backup. see: http://www.sun.com/msg/ZFS-8000-8A scrub: scrub in progress for 0h23m, 4.70% done, 7h49m to go config: NAME STATE READ WRITE CKSUM tank ONLINE 0 0 6.15K raidz2 ONLINE 0 0 24.5K 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 errors: Permanent errors have been detected in the following files: tank/vol-fourquid-1:<0x0> tank/vol-fourquid-1:<0xc8190da> How do I identify which files it is listing here? -Olaf. -- Pipe rene = new PipePicture(); assert(Not rene.GetType().Equals(Pipe)); From owner-freebsd-stable@FreeBSD.ORG Mon May 30 10:10:54 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B6C5B1065670 for ; Mon, 30 May 2011 10:10:54 +0000 (UTC) (envelope-from O.Seibert@cs.ru.nl) Received: from kookpunt.science.ru.nl (kookpunt.science.ru.nl [131.174.30.61]) by mx1.freebsd.org (Postfix) with ESMTP id 488DC8FC1D for ; Mon, 30 May 2011 10:10:53 +0000 (UTC) Received: from twoquid.cs.ru.nl (twoquid.cs.ru.nl [131.174.142.38]) by kookpunt.science.ru.nl (8.13.7/5.31) with ESMTP id p4UAApTj009587; Mon, 30 May 2011 12:10:51 +0200 (MEST) Received: by twoquid.cs.ru.nl (Postfix, from userid 4100) id 853352E03C; Mon, 30 May 2011 12:10:51 +0200 (CEST) Date: Mon, 30 May 2011 12:10:51 +0200 From: Olaf Seibert To: freebsd-stable@freebsd.org Message-ID: <20110530101051.GA49825@twoquid.cs.ru.nl> References: <20110530093546.GX6733@twoquid.cs.ru.nl> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20110530093546.GX6733@twoquid.cs.ru.nl> User-Agent: Mutt/1.5.19 (2009-01-05) X-Spam-Score: -1.799 () ALL_TRUSTED,BAYES_50 X-Scanned-By: MIMEDefang 2.63 on 131.174.30.61 Subject: Re: ZFS I/O errors X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 30 May 2011 10:10:54 -0000 On Mon 30 May 2011 at 11:35:46 +0200, Olaf Seibert wrote: > How do I identify which files it is listing here? The nighly 'find' has found the files for me. It is actually a bunch of directories, that were likely in use when the crash occurred. They give an "interesting" error when you try to ls them: find: /tank/vol-fourquid-1/evadh/CLEF-IP11/PARSED_CORPUS/EP/000000/45/97: Illegal byte sequence The file system is compressed, that may be the reason it can identify "illegal byte sequence"s. It isn't even possible to rm -r the directories, or even to mv them... (fortunately the standard trick works: move the parent directory instead, create a new one in its old place, and move the old, good, contents back). but now I seem to be left with some directories (elsewhere) that I still can't remove... > -Olaf. > -- > Pipe rene = new PipePicture(); assert(Not rene.GetType().Equals(Pipe)); From owner-freebsd-stable@FreeBSD.ORG Mon May 30 10:33:51 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 87CE0106564A for ; Mon, 30 May 2011 10:33:51 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta08.emeryville.ca.mail.comcast.net (qmta08.emeryville.ca.mail.comcast.net [76.96.30.80]) by mx1.freebsd.org (Postfix) with ESMTP id 70C4C8FC08 for ; Mon, 30 May 2011 10:33:51 +0000 (UTC) Received: from omta21.emeryville.ca.mail.comcast.net ([76.96.30.88]) by qmta08.emeryville.ca.mail.comcast.net with comcast id pmZ51g0041u4NiLA8mZqud; Mon, 30 May 2011 10:33:50 +0000 Received: from koitsu.dyndns.org ([67.180.84.87]) by omta21.emeryville.ca.mail.comcast.net with comcast id pmZq1g0041t3BNj8hmZqUt; Mon, 30 May 2011 10:33:51 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 5BA7A102C19; Mon, 30 May 2011 03:33:49 -0700 (PDT) Date: Mon, 30 May 2011 03:33:49 -0700 From: Jeremy Chadwick To: Olaf Seibert Message-ID: <20110530103349.GA73825@icarus.home.lan> References: <20110530093546.GX6733@twoquid.cs.ru.nl> <20110530101051.GA49825@twoquid.cs.ru.nl> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20110530101051.GA49825@twoquid.cs.ru.nl> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-stable@freebsd.org Subject: Re: ZFS I/O errors X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 30 May 2011 10:33:51 -0000 On Mon, May 30, 2011 at 12:10:51PM +0200, Olaf Seibert wrote: > On Mon 30 May 2011 at 11:35:46 +0200, Olaf Seibert wrote: > > How do I identify which files it is listing here? On Solaris anyway, "zpool status -v" is supposed to show this. Occasionally it shows something like <0xXX>:, rather than a path/filename, and on FreeBSD it appears to behave the same. Per your own output: tank/vol-fourquid-1:<0x0> tank/vol-fourquid-1:<0xc8190da> I'm not sure why this didn't actually map to a filename on the system however. I've never quite understood what the hexadecimal values shown represent (I have ideas but it'd be useful to know what they meant). > The nighly 'find' has found the files for me. It is actually a bunch of > directories, that were likely in use when the crash occurred. > > They give an "interesting" error when you try to ls them: > > find: /tank/vol-fourquid-1/evadh/CLEF-IP11/PARSED_CORPUS/EP/000000/45/97: Illegal byte sequence Yes, and this is what error 86 was in the very first line of your kernel output: May 30 10:38:28 fourquid root: ZFS: zpool I/O failure, zpool=tank error=86 $ perror 86 Illegal byte sequence > The file system is compressed, that may be the reason it can identify > "illegal byte sequence"s. > > It isn't even possible to rm -r the directories, or even to mv them... > > (fortunately the standard trick works: move the parent directory > instead, create a new one in its old place, and move the old, good, > contents back). > > but now I seem to be left with some directories (elsewhere) that I still > can't remove... I sincerely hope your "zpool scrub" addresses these problems. Otherwise I hope you have backup and can recreate the pool (zpool destroy, etc.). Try running without compression and see if that improves things. It's important to note that the I/O errors shown happened on "random disks" (meaning more than just one device). What you didn't disclose is what the disks are attached to. "camcontrol devlist -v" would have been a good start, followed by any details of controller/driver/etc. you're using. Possibly it's an underlying (silent) storage driver bug. Finally, and leaving the most important point for last: you didn't state what FreeBSD version you're using, and ceased to provide uname -a output (to see kernel build date, etc.). It matters greatly. -- | 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 30 11:09:50 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7EC781065680 for ; Mon, 30 May 2011 11:09:50 +0000 (UTC) (envelope-from O.Seibert@cs.ru.nl) Received: from kookpunt.science.ru.nl (kookpunt.science.ru.nl [131.174.30.61]) by mx1.freebsd.org (Postfix) with ESMTP id 211A58FC19 for ; Mon, 30 May 2011 11:09:49 +0000 (UTC) Received: from twoquid.cs.ru.nl (twoquid.cs.ru.nl [131.174.142.38]) by kookpunt.science.ru.nl (8.13.7/5.31) with ESMTP id p4UB9kg6010961; Mon, 30 May 2011 13:09:46 +0200 (MEST) Received: by twoquid.cs.ru.nl (Postfix, from userid 4100) id EA4D02E03C; Mon, 30 May 2011 13:09:46 +0200 (CEST) Date: Mon, 30 May 2011 13:09:46 +0200 From: Olaf Seibert To: Jeremy Chadwick Message-ID: <20110530110946.GC6733@twoquid.cs.ru.nl> References: <20110530093546.GX6733@twoquid.cs.ru.nl> <20110530101051.GA49825@twoquid.cs.ru.nl> <20110530103349.GA73825@icarus.home.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20110530103349.GA73825@icarus.home.lan> User-Agent: Mutt/1.5.19 (2009-01-05) X-Spam-Score: -1.799 () ALL_TRUSTED,BAYES_50 X-Scanned-By: MIMEDefang 2.63 on 131.174.30.61 Cc: freebsd-stable@freebsd.org, Olaf Seibert Subject: Re: ZFS I/O errors X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 30 May 2011 11:09:50 -0000 On Mon 30 May 2011 at 03:33:49 -0700, Jeremy Chadwick wrote: > On Mon, May 30, 2011 at 12:10:51PM +0200, Olaf Seibert wrote: > I'm not sure why this didn't actually map to a filename on the system > however. I've never quite understood what the hexadecimal values shown > represent (I have ideas but it'd be useful to know what they meant). The scrub is starting to add some filenames to the list. So far they are two filenames in snapshots (where current versions of the file have been modified since then). > Try running without compression and see if that improves things. That sounds like a good idea. My theory so far is that it ran out of memory while compressing, with incorrect compressed data written to the disk. > It's important to note that the I/O errors shown happened on "random > disks" (meaning more than just one device). What you didn't disclose is > what the disks are attached to. "camcontrol devlist -v" would have been > a good start, followed by any details of controller/driver/etc. you're > using. Possibly it's an underlying (silent) storage driver bug. They are connected to an Areca host adapter: arcmsr0: mem 0xfebff000-0xfebfffff,0xfdc00000-0xfdffffff irq 17 at device 14.0 on pci7 ARECA RAID ADAPTER0: Driver Version 1.20.00.19 2010-11-11 ARECA RAID ADAPTER0: FIRMWARE VERSION V1.46 2008-08-06 arcmsr0: [ITHREAD] da0 at arcmsr0 bus 0 scbus0 target 0 lun 0 da1 at arcmsr0 bus 0 scbus0 target 0 lun 1 da2 at arcmsr0 bus 0 scbus0 target 0 lun 2 da3 at arcmsr0 bus 0 scbus0 target 0 lun 3 da4 at arcmsr0 bus 0 scbus0 target 0 lun 4 da5 at arcmsr0 bus 0 scbus0 target 0 lun 5 pass6 at arcmsr0 bus 0 scbus0 target 16 lun 0 camcontrol devlist -v: scbus0 on arcmsr0 bus 0: at scbus0 target 0 lun 0 (pass0,da0) at scbus0 target 0 lun 1 (pass1,da1) at scbus0 target 0 lun 2 (pass2,da2) at scbus0 target 0 lun 3 (pass3,da3) at scbus0 target 0 lun 4 (pass4,da4) at scbus0 target 0 lun 5 (pass5,da5) at scbus0 target 16 lun 0 (pass6) <> at scbus0 target -1 lun -1 () scbus-1 on xpt0 bus 0: <> at scbus-1 target -1 lun -1 (xpt0) > Finally, and leaving the most important point for last: you didn't state > what FreeBSD version you're using, and ceased to provide uname -a output > (to see kernel build date, etc.). It matters greatly. Sorry. Here is it: FreeBSD fourquid.cs.ru.nl 8.2-RELEASE FreeBSD 8.2-RELEASE #3: Tue Apr 19 13:02:11 CEST 2011 root@fourquid.cs.ru.nl:/usr/obj/usr/src/sys/FOURQUID amd64 The kernel is built from unmodified 8.2-RELEASE sources, but I adapted the configuration a bit to throw out irrelevant hardware support (this does make a small difference): -r-xr-xr-x 1 root wheel 12612347 Apr 19 12:27 /boot/GENERIC/kernel* -r-xr-xr-x 1 root wheel 7031915 Apr 19 13:02 /boot/kernel/kernel* The real original reason to make a custom kernel was to add the SCSI passthrough device (needed by smartctl) , but istr that that is included in GENERIC now. Thanks so far, -Olaf. -- Pipe rene = new PipePicture(); assert(Not rene.GetType().Equals(Pipe)); From owner-freebsd-stable@FreeBSD.ORG Mon May 30 11:41:09 2011 Return-Path: Delivered-To: stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 86B011065672; Mon, 30 May 2011 11:41:09 +0000 (UTC) (envelope-from borjam@sarenet.es) Received: from proxypop02.sare.net (proxypop02.sare.net [194.30.18.43]) by mx1.freebsd.org (Postfix) with ESMTP id 42C208FC15; Mon, 30 May 2011 11:41:08 +0000 (UTC) Received: from [172.16.1.55] (izaro.sarenet.es [192.148.167.11]) by proxypop02.sare.net (Postfix) with ESMTPSA id EDB09124E467; Mon, 30 May 2011 13:41:43 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Borja Marcos In-Reply-To: <1305876839.13971.5.camel@pow> Date: Mon, 30 May 2011 13:41:03 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <867340A1-B7F4-452C-BB7E-93CAF7E4ABA8@sarenet.es> References: <20110517073029.GA44359@icarus.home.lan> <4DD25264.8040305@FreeBSD.org> <20110517112952.GA48610@icarus.home.lan> <1305876839.13971.5.camel@pow> To: luke@hybrid-logic.co.uk X-Mailer: Apple Mail (2.1084) Cc: Charles Sprickman , stable@FreeBSD.org, Jeremy Chadwick , Andriy Gapon Subject: Re: 8.1R possible zfs snapshot livelock? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 30 May 2011 11:41:09 -0000 On May 20, 2011, at 9:33 AM, Luke Marsden wrote: >> If you wish to reproduce it, try creating a dataset for /usr/obj, >> running make buildworld on it, replicating at, say, 30 or 60 second >> intervals, and keep several scripts (or rsync) reading the target >> dataset files and just copying them to another place in the usual, >> "classic" way. (example: tar cf - . | ( cd /destination && tar xf -) >>=20 >=20 > Is there a PR for this? I'd like to see it addressed, since read-only > I/O on a dataset which is being updated by `zfs recv` is an important > part of what we plan to do with ZFS on FreeBSD. Hello, Sorry for the delay to anwer. I think I added some information about = this issue to a related PR but I'm unable to find it right now. I had a discussion about this issue as well, you can read the relevant = threads here: http://osdir.com/ml/freebsd-fs/2010-03/msg00062.html http://kerneltrap.org/mailarchive/freebsd-fs/2009/10/31/6535463/thread In hindsight, however, unless you are working in very clearly defined = conditions, it doesn't make much sense to keep even reading activity on = the target dataset. What happens if you keep a file open for reading while the "zfs recv" = operation is done? What happens if you are traversing a directory, which = means that you keep the directory open, and the destination dataset is = "replaced" by a new one by a recv? For read-only operations I would rely on clones instead.=20 Borja. From owner-freebsd-stable@FreeBSD.ORG Mon May 30 14:43:16 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 04194106566C for ; Mon, 30 May 2011 14:43:16 +0000 (UTC) (envelope-from daniel@digsys.bg) Received: from smtp-sofia.digsys.bg (smtp-sofia.digsys.bg [193.68.3.230]) by mx1.freebsd.org (Postfix) with ESMTP id 878E48FC18 for ; Mon, 30 May 2011 14:43:15 +0000 (UTC) Received: from dcave.digsys.bg (dcave.digsys.bg [192.92.129.5]) (authenticated bits=0) by smtp-sofia.digsys.bg (8.14.4/8.14.4) with ESMTP id p4UEh48A050347 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Mon, 30 May 2011 17:43:09 +0300 (EEST) (envelope-from daniel@digsys.bg) Message-ID: <4DE3ACF8.4070809@digsys.bg> Date: Mon, 30 May 2011 17:43:04 +0300 From: Daniel Kalchev User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.17) Gecko/20110519 Thunderbird/3.1.10 MIME-Version: 1.0 To: freebsd-stable@freebsd.org References: <4DE21C64.8060107@digsys.bg> In-Reply-To: <4DE21C64.8060107@digsys.bg> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: HAST instability X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 30 May 2011 14:43:16 -0000 Some further investigation: The HAST nodes do not disconnect when checksum is enabled (either crc32 or sha256). One strange thing is that there is never established TCP connection between both nodes: tcp4 0 0 10.2.101.11.48939 10.2.101.12.8457 FIN_WAIT_2 tcp4 0 1288 10.2.101.11.57008 10.2.101.12.8457 CLOSE_WAIT tcp4 0 0 10.2.101.11.46346 10.2.101.12.8457 FIN_WAIT_2 tcp4 0 90648 10.2.101.11.13916 10.2.101.12.8457 CLOSE_WAIT tcp4 0 0 10.2.101.11.8457 *.* LISTEN When using sha256 one CPU core is 100% utilized by each hastd process, while 70-80MB/sec per HAST resource is being transferred (total of up to 140 MB/sec traffic for both); When using crc32 each CPU core is at 22% utilization; When using none as checksum, CPU usage is under 10% Eventually after many hours, got corrupted communication: May 30 17:32:35 b1b hastd[9827]: [data0] (secondary) Hash mismatch. May 30 17:32:35 b1b hastd[9827]: [data0] (secondary) Unable to receive request data: No such file or directory. May 30 17:32:38 b1b hastd[9397]: [data0] (secondary) Worker process exited ungracefully (pid=9827, exitcode=75). and May 30 17:32:27 b1a hastd[1837]: [data0] (primary) Unable to receive reply header: Operation timed out. May 30 17:32:30 b1a hastd[1837]: [data0] (primary) Disconnected from 10.2.101.12. May 30 17:32:30 b1a hastd[1837]: [data0] (primary) Unable to send request (Broken pipe): WRITE(99128470016, 131072). Daniel From owner-freebsd-stable@FreeBSD.ORG Mon May 30 17:19:20 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 622E1106566B for ; Mon, 30 May 2011 17:19:20 +0000 (UTC) (envelope-from dan@dan.emsphone.com) Received: from email2.allantgroup.com (email2.emsphone.com [199.67.51.116]) by mx1.freebsd.org (Postfix) with ESMTP id 0E3B48FC0C for ; Mon, 30 May 2011 17:19:19 +0000 (UTC) Received: from dan.emsphone.com (dan.emsphone.com [199.67.51.101]) by email2.allantgroup.com (8.14.4/8.14.4) with ESMTP id p4UHJB3u012171 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 30 May 2011 12:19:11 -0500 (CDT) (envelope-from dan@dan.emsphone.com) Received: from dan.emsphone.com (smmsp@localhost [127.0.0.1]) by dan.emsphone.com (8.14.5/8.14.4) with ESMTP id p4UHJAH7005026 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 30 May 2011 12:19:10 -0500 (CDT) (envelope-from dan@dan.emsphone.com) Received: (from dan@localhost) by dan.emsphone.com (8.14.5/8.14.5/Submit) id p4UHJABN005025; Mon, 30 May 2011 12:19:10 -0500 (CDT) (envelope-from dan) Date: Mon, 30 May 2011 12:19:10 -0500 From: Dan Nelson To: Olaf Seibert Message-ID: <20110530171909.GE6688@dan.emsphone.com> References: <20110530093546.GX6733@twoquid.cs.ru.nl> <20110530101051.GA49825@twoquid.cs.ru.nl> <20110530103349.GA73825@icarus.home.lan> <20110530110946.GC6733@twoquid.cs.ru.nl> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20110530110946.GC6733@twoquid.cs.ru.nl> X-OS: FreeBSD 8.2-STABLE User-Agent: Mutt/1.5.21 (2010-09-15) X-Virus-Scanned: clamav-milter 0.97 at email2.allantgroup.com X-Virus-Status: Clean X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.6 (email2.allantgroup.com [199.67.51.78]); Mon, 30 May 2011 12:19:11 -0500 (CDT) X-Scanned-By: MIMEDefang 2.68 on 199.67.51.78 Cc: freebsd-stable@freebsd.org, Jeremy Chadwick Subject: Re: ZFS I/O errors X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 30 May 2011 17:19:20 -0000 In the last episode (May 30), Olaf Seibert said: > On Mon 30 May 2011 at 03:33:49 -0700, Jeremy Chadwick wrote: > > On Mon, May 30, 2011 at 12:10:51PM +0200, Olaf Seibert wrote: > > I'm not sure why this didn't actually map to a filename on the system > > however. I've never quite understood what the hexadecimal values shown > > represent (I have ideas but it'd be useful to know what they meant). > > The scrub is starting to add some filenames to the list. So far they are > two filenames in snapshots (where current versions of the file have been > modified since then). > > > Try running without compression and see if that improves things. > > That sounds like a good idea. > > My theory so far is that it ran out of memory while compressing, with > incorrect compressed data written to the disk. The ZFS compression code will panic if it can't allocate the buffer needed to store the compressed data, so that's unlikely to be your problem. The only time I have seen an "illegal byte sequence" error was when trying to copy raw disk images containing ZFS pools to different disks, and the destination disk was a different size than the original. I wasn't even able to import the pool in that case, though. The zfs IO code overloads the EILSEQ error code and uses it as a "checksum error" code. Returning that error for the same block on all disks is definitely weird. Could you have run a partitioning tool, or some other program that would have done direct writes to all of your component disks? Your scrub is also a bit worrying - 24k checksum errors definitely shouldn't occur during normal usage. -- Dan Nelson dnelson@allantgroup.com From owner-freebsd-stable@FreeBSD.ORG Mon May 30 18:42:28 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2B67A1065670 for ; Mon, 30 May 2011 18:42:28 +0000 (UTC) (envelope-from to.my.trociny@gmail.com) Received: from mail-bw0-f54.google.com (mail-bw0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id A38BB8FC08 for ; Mon, 30 May 2011 18:42:27 +0000 (UTC) Received: by bwz12 with SMTP id 12so4552186bwz.13 for ; Mon, 30 May 2011 11:42:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:from:to:cc:subject:references:x-comment-to :sender:date:in-reply-to:message-id:user-agent:mime-version :content-type; bh=0SYRbKvxFRShHFo0EyETiaTVI55dFZMeOIVpDlPCJ8M=; b=n8WuDXcvFPTXm5/7vBQk5STqm913emV5n9CCnEDoevF3cQQT+Zuh2Mx6x+n62UZOXR 4TwfIOVaLIspDJs1GH6n/HL8hTCGy/9ujmbCRStN3BwgFB4+E5nlu/afUUCpd9+yTUxT ZuXeUph2H68Zr4g96SKJjkFYZrKBwGAZsMKDU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:cc:subject:references:x-comment-to:sender:date:in-reply-to :message-id:user-agent:mime-version:content-type; b=D66K9UMuQBc0qM1YpoqfMfEMXI2ndV6Rs4KOTjCcwaJuGRuZ51GEJx2Jx3PsLgevW6 pQfSCXhyAlNQGCLLPNO2WWDbHKuhr8pXOCgoIKcUwtsID+9TAEqUnycxd/j/6sh6igjV Acy34YpWMhQX4lKdWxMrHcvqfDaSHJJdkrWqk= Received: by 10.204.232.4 with SMTP id js4mr4503881bkb.47.1306780946494; Mon, 30 May 2011 11:42:26 -0700 (PDT) Received: from localhost ([95.69.172.154]) by mx.google.com with ESMTPS id af13sm3618392bkc.7.2011.05.30.11.42.24 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 30 May 2011 11:42:25 -0700 (PDT) From: Mikolaj Golub To: Daniel Kalchev References: <4DE21C64.8060107@digsys.bg> <4DE3ACF8.4070809@digsys.bg> X-Comment-To: Daniel Kalchev Sender: Mikolaj Golub Date: Mon, 30 May 2011 21:42:22 +0300 In-Reply-To: <4DE3ACF8.4070809@digsys.bg> (Daniel Kalchev's message of "Mon, 30 May 2011 17:43:04 +0300") Message-ID: <86d3j02fox.fsf@kopusha.home.net> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.2 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: freebsd-stable@freebsd.org Subject: Re: HAST instability X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 30 May 2011 18:42:28 -0000 On Mon, 30 May 2011 17:43:04 +0300 Daniel Kalchev wrote: DK> Some further investigation: DK> The HAST nodes do not disconnect when checksum is enabled (either DK> crc32 or sha256). DK> One strange thing is that there is never established TCP connection DK> between both nodes: DK> tcp4 0 0 10.2.101.11.48939 10.2.101.12.8457 FIN_WAIT_2 DK> tcp4 0 1288 10.2.101.11.57008 10.2.101.12.8457 CLOSE_WAIT DK> tcp4 0 0 10.2.101.11.46346 10.2.101.12.8457 FIN_WAIT_2 DK> tcp4 0 90648 10.2.101.11.13916 10.2.101.12.8457 CLOSE_WAIT DK> tcp4 0 0 10.2.101.11.8457 *.* LISTEN It is normal. hastd uses the connections only in one direction so it calls shutdown to close unused directions. DK> When using sha256 one CPU core is 100% utilized by each hastd process, DK> while 70-80MB/sec per HAST resource is being transferred (total of up DK> to 140 MB/sec traffic for both); DK> When using crc32 each CPU core is at 22% utilization; DK> When using none as checksum, CPU usage is under 10% I suppose when checksum is enabled the bottleneck is cpu, the triffic rate is lower and the problem is not triggered. DK> Eventually after many hours, got corrupted communication: DK> May 30 17:32:35 b1b hastd[9827]: [data0] (secondary) Hash mismatch. "Hash mismatch" message suggests that actually you were using checksum then, weren't you? DK> May 30 17:32:35 b1b hastd[9827]: [data0] (secondary) Unable to receive DK> request data: No such file or directory. DK> May 30 17:32:38 b1b hastd[9397]: [data0] (secondary) Worker process DK> exited ungracefully (pid=9827, exitcode=75). DK> and DK> May 30 17:32:27 b1a hastd[1837]: [data0] (primary) Unable to receive DK> reply header: Operation timed out. DK> May 30 17:32:30 b1a hastd[1837]: [data0] (primary) Disconnected from DK> 10.2.101.12. DK> May 30 17:32:30 b1a hastd[1837]: [data0] (primary) Unable to send DK> request (Broken pipe): WRITE(99128470016, 131072). It looks a little different than in your fist message. Do you have clock in sync on both nodes? I would like to look at full logs for some rather large period, with several cases, from both primary and secondary (and be sure about synchronized time). Also, it might worth checking that there is no network packet corruption (some strange things in netstat -di, netstat -s, may be copying large files via net and comparing checksums). -- Mikolaj Golub From owner-freebsd-stable@FreeBSD.ORG Mon May 30 18:54:21 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id ED8241065672 for ; Mon, 30 May 2011 18:54:21 +0000 (UTC) (envelope-from to.my.trociny@gmail.com) Received: from mail-bw0-f54.google.com (mail-bw0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id 6D7A98FC1B for ; Mon, 30 May 2011 18:54:21 +0000 (UTC) Received: by bwz12 with SMTP id 12so4560524bwz.13 for ; Mon, 30 May 2011 11:54:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:from:to:cc:subject:references:x-comment-to :sender:date:in-reply-to:message-id:user-agent:mime-version :content-type; bh=1SW+SxbhsCWIDmKd8ps+nqY5cM/XeLgWPAyLCrKVtLE=; b=xgrZABe6YM//uvR2pBHk0wXb0btD/dEri3N7HK5Nn8hwqlXgPpzctgaUAkbJTxMRLh KPnJfn1yWf5XcJ50oPNJxQgWfVH/0aKsmSfaDgLKFRwbi5WwI0XSpV/U+XBw+/01qQbt 4Ij6GBRazpVCe8gxpMTkV6k9fkJRA0fMVzxV4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:cc:subject:references:x-comment-to:sender:date:in-reply-to :message-id:user-agent:mime-version:content-type; b=DzIMpjROx1eAE5PJ4gGVhGz4euNQkhsgYkks1SfpA2rGqmvjWER60JRUgkAJ+5J4G5 BWb14DHKtn5lOAtiNlG8GVCnfP2UJ3/GCR+pZfUemEsparFsyF9rNpHDr8Ol2HO6b09x 2QzL4h6qR2eGJgoba2zXPFQnpCSiefoh52qBM= Received: by 10.204.152.5 with SMTP id e5mr444457bkw.138.1306781660135; Mon, 30 May 2011 11:54:20 -0700 (PDT) Received: from localhost ([95.69.172.154]) by mx.google.com with ESMTPS id af13sm3627228bkc.19.2011.05.30.11.54.18 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 30 May 2011 11:54:19 -0700 (PDT) From: Mikolaj Golub To: Daniel Kalchev References: <4DE21C64.8060107@digsys.bg> <4DE3ACF8.4070809@digsys.bg> X-Comment-To: Daniel Kalchev Sender: Mikolaj Golub Date: Mon, 30 May 2011 21:54:16 +0300 In-Reply-To: <4DE3ACF8.4070809@digsys.bg> (Daniel Kalchev's message of "Mon, 30 May 2011 17:43:04 +0300") Message-ID: <868vto2f53.fsf@kopusha.home.net> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.2 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: freebsd-stable@freebsd.org Subject: Re: HAST instability X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 30 May 2011 18:54:22 -0000 On Mon, 30 May 2011 17:43:04 +0300 Daniel Kalchev wrote: DK> tcp4 0 0 10.2.101.11.48939 10.2.101.12.8457 FIN_WAIT_2 DK> tcp4 0 1288 10.2.101.11.57008 10.2.101.12.8457 CLOSE_WAIT DK> tcp4 0 0 10.2.101.11.46346 10.2.101.12.8457 FIN_WAIT_2 DK> tcp4 0 90648 10.2.101.11.13916 10.2.101.12.8457 CLOSE_WAIT DK> tcp4 0 0 10.2.101.11.8457 *.* LISTEN Also, it might be useful to see if you normally have full receive buffers like above or only when the issue is observed, running netstat in loop, something like below: while sleep 5; do t=`date '+%F %H:%M:%S'`; netstat -na | grep 8457 | while read l; do echo "$t $l"; done; done > /tmp/netstat.log -- Mikolaj Golub From owner-freebsd-stable@FreeBSD.ORG Mon May 30 19:13:30 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 79889106566C for ; Mon, 30 May 2011 19:13:30 +0000 (UTC) (envelope-from prvs=1131b31f60=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 EF6028FC08 for ; Mon, 30 May 2011 19:13:29 +0000 (UTC) X-MDAV-Processed: mail1.multiplay.co.uk, Mon, 30 May 2011 20:02:14 +0100 X-Spam-Processed: mail1.multiplay.co.uk, Mon, 30 May 2011 20:02:14 +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 ([188.220.16.49]) by mail1.multiplay.co.uk (mail1.multiplay.co.uk [85.236.96.23]) (MDaemon PRO v10.0.4) with ESMTP id md50013420052.msg for ; Mon, 30 May 2011 20:02:13 +0100 X-MDRemoteIP: 188.220.16.49 X-Return-Path: prvs=1131b31f60=killing@multiplay.co.uk X-Envelope-From: killing@multiplay.co.uk X-MDaemon-Deliver-To: freebsd-stable@freebsd.org Message-ID: From: "Steven Hartland" To: "Dan Nelson" , "Olaf Seibert" References: <20110530093546.GX6733@twoquid.cs.ru.nl><20110530101051.GA49825@twoquid.cs.ru.nl><20110530103349.GA73825@icarus.home.lan><20110530110946.GC6733@twoquid.cs.ru.nl> <20110530171909.GE6688@dan.emsphone.com> Date: Mon, 30 May 2011 20:02:45 +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.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6090 Cc: freebsd-stable@freebsd.org, Jeremy Chadwick Subject: Re: ZFS I/O errors X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 30 May 2011 19:13:30 -0000 ----- Original Message ----- From: "Dan Nelson" > The zfs IO code overloads the EILSEQ error code and uses it as a "checksum > error" code. Returning that error for the same block on all disks is > definitely weird. Could you have run a partitioning tool, or some other > program that would have done direct writes to all of your component disks? > > Your scrub is also a bit worrying - 24k checksum errors definitely shouldn't > occur during normal usage. Its not on a 48bit boundary or something similar is it i.e. indicating some sort of driver / disk firmware interaction issue? Regards Steve ================================================ This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to postmaster@multiplay.co.uk. From owner-freebsd-stable@FreeBSD.ORG Tue May 31 09:14:14 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2FF4F106566C for ; Tue, 31 May 2011 09:14:14 +0000 (UTC) (envelope-from mickael.maillot@gmail.com) Received: from mail-qy0-f175.google.com (mail-qy0-f175.google.com [209.85.216.175]) by mx1.freebsd.org (Postfix) with ESMTP id DA98F8FC17 for ; Tue, 31 May 2011 09:14:13 +0000 (UTC) Received: by qyk35 with SMTP id 35so1303972qyk.13 for ; Tue, 31 May 2011 02:14:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=DRFCiPeTOygpCGXQBhre40WfpjgGJECEuXR2YrPjwUQ=; b=RXun0udUUElgOzmDEVgbaAny0IVpuWDvN+avxU+Kw9F0Wch95ABOaGchtte2AQabY9 58s4J8ZQ58hrJEcNaljBvmKhcZ8BNWeh1N/Ix6kjTkbN5iadI2gQoNgn3ndRsb01P8ln A7lBtp8VwMShoL7WzxETQUclhbVVECDRsJoqM= 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=bdcXv/gQvCFLYWCauywRYEvbzoYWfV2rpBirGTlL3fKb0g/rXUFqFgIdGv1lG6FeY6 rfq52gCWIfIIbu98UWWwXmjNKUjfuaRDduarYVW/ocedE3CWXVEjj+QfV5GKoY4oVDtm lnFtzerOMjUROzMZXUn3mHG7aslzg+2F1kfZI= MIME-Version: 1.0 Received: by 10.229.22.138 with SMTP id n10mr4060359qcb.175.1306833253048; Tue, 31 May 2011 02:14:13 -0700 (PDT) Received: by 10.229.237.209 with HTTP; Tue, 31 May 2011 02:14:13 -0700 (PDT) In-Reply-To: <20110530093546.GX6733@twoquid.cs.ru.nl> References: <20110530093546.GX6733@twoquid.cs.ru.nl> Date: Tue, 31 May 2011 11:14:13 +0200 Message-ID: From: =?ISO-8859-1?Q?Micka=EBl_Maillot?= To: Olaf Seibert Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-stable@freebsd.org Subject: Re: ZFS I/O errors X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 31 May 2011 09:14:14 -0000 Hi, 2011/5/30 Olaf Seibert > "My" FreeBSD system somehow rebooted itself last friday in the early > hours in the morning, and since then /var/log/messages is full with > messages like these: > > May 30 10:38:28 fourquid root: ZFS: zpool I/O failure, zpool=tank error=86 > May 30 10:38:38 fourquid root: ZFS: checksum mismatch, zpool=tank > path=/dev/da3 offset=278593630720 size=7680 > May 30 10:38:38 fourquid root: ZFS: checksum mismatch, zpool=tank > path=/dev/da4 offset=278593630720 size=7680 > May 30 10:38:38 fourquid root: ZFS: checksum mismatch, zpool=tank > path=/dev/da5 offset=278593630720 size=7680 > May 30 10:38:38 fourquid root: ZFS: checksum mismatch, zpool=tank > path=/dev/da0 offset=278593631232 size=7680 > May 30 10:38:38 fourquid root: ZFS: checksum mismatch, zpool=tank > path=/dev/da1 offset=278593631232 size=7680 > May 30 10:38:38 fourquid root: ZFS: checksum mismatch, zpool=tank > path=/dev/da2 offset=278593631232 size=7680 > May 30 10:38:38 fourquid root: ZFS: checksum mismatch, zpool=tank > path=/dev/da3 offset=278593630720 size=7680 > May 30 10:38:38 fourquid root: ZFS: checksum mismatch, zpool=tank > path=/dev/da4 offset=278593630720 size=7680 > May 30 10:38:38 fourquid root: ZFS: checksum mismatch, zpool=tank > path=/dev/da5 offset=278593630720 size=7680 > May 30 10:38:38 fourquid root: ZFS: checksum mismatch, zpool=tank > path=/dev/da0 offset=278593631232 size=7680 > May 30 10:38:38 fourquid root: ZFS: checksum mismatch, zpool=tank > path=/dev/da1 offset=278593631232 size=7680 > May 30 10:38:38 fourquid root: ZFS: checksum mismatch, zpool=tank > path=/dev/da2 offset=278593631232 size=7680 > > looks like memory errors to me, check your RAM with memtest. Mickael From owner-freebsd-stable@FreeBSD.ORG Tue May 31 09:26:02 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 61EDA106564A for ; Tue, 31 May 2011 09:26:02 +0000 (UTC) (envelope-from O.Seibert@cs.ru.nl) Received: from kookpunt.science.ru.nl (kookpunt.science.ru.nl [131.174.30.61]) by mx1.freebsd.org (Postfix) with ESMTP id F39A88FC15 for ; Tue, 31 May 2011 09:26:01 +0000 (UTC) Received: from twoquid.cs.ru.nl (twoquid.cs.ru.nl [131.174.142.38]) by kookpunt.science.ru.nl (8.13.7/5.31) with ESMTP id p4V9PuSt016493; Tue, 31 May 2011 11:25:56 +0200 (MEST) Received: by twoquid.cs.ru.nl (Postfix, from userid 4100) id AB0252E058; Tue, 31 May 2011 11:25:56 +0200 (CEST) Date: Tue, 31 May 2011 11:25:56 +0200 From: Olaf Seibert To: Dan Nelson Message-ID: <20110531092556.GD6733@twoquid.cs.ru.nl> References: <20110530093546.GX6733@twoquid.cs.ru.nl> <20110530101051.GA49825@twoquid.cs.ru.nl> <20110530103349.GA73825@icarus.home.lan> <20110530110946.GC6733@twoquid.cs.ru.nl> <20110530171909.GE6688@dan.emsphone.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20110530171909.GE6688@dan.emsphone.com> User-Agent: Mutt/1.5.19 (2009-01-05) X-Spam-Score: -1.799 () ALL_TRUSTED,BAYES_50 X-Scanned-By: MIMEDefang 2.63 on 131.174.30.61 Cc: freebsd-stable@freebsd.org, Olaf Seibert , Jeremy Chadwick Subject: Re: ZFS I/O errors X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 31 May 2011 09:26:02 -0000 On Mon 30 May 2011 at 12:19:10 -0500, Dan Nelson wrote: > The ZFS compression code will panic if it can't allocate the buffer needed > to store the compressed data, so that's unlikely to be your problem. The > only time I have seen an "illegal byte sequence" error was when trying to > copy raw disk images containing ZFS pools to different disks, and the > destination disk was a different size than the original. I wasn't even able > to import the pool in that case, though. Yet somehow some incorrect data got written, it seems. That never happened before, fortunately, even though we had crashes before that seemed to be related to ZFS running out of memory. > The zfs IO code overloads the EILSEQ error code and uses it as a "checksum > error" code. Returning that error for the same block on all disks is > definitely weird. Could you have run a partitioning tool, or some other > program that would have done direct writes to all of your component disks? I hope I would remember doing that if I did! > Your scrub is also a bit worrying - 24k checksum errors definitely shouldn't > occur during normal usage. It turns out that the errors are easy to provoke: they happen every time I do an ls of of the affected directories. There were processes running that were likely to be trying to write to the same directories (the file system is exported over NFS), so in that case it is easy to imagine that the numbers rack up quickly. I moved those directories to the side, for the moment, but I haven't been able to delete them yet. The data is a bit bigger than we're able to backup so "just restoring a backup" isn't an easy thing to do. Possibly I could make a new filesystem in the same pool, if that would do the trick; it isn't more than 50% full but the affected one is the biggest filesystem in it. The end result of the scrub is as follows: pool: tank state: ONLINE status: One or more devices has experienced an error resulting in data corruption. Applications may be affected. action: Restore the file in question if possible. Otherwise restore the entire pool from backup. see: http://www.sun.com/msg/ZFS-8000-8A scrub: scrub completed after 12h56m with 3 errors on Mon May 30 23:56:47 2011 config: NAME STATE READ WRITE CKSUM tank ONLINE 0 0 6.38K raidz2 ONLINE 0 0 25.4K 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 errors: Permanent errors have been detected in the following files: tank/vol-fourquid-1:<0x0> tank/vol-fourquid-1@saturday:<0x0> /tank/vol-fourquid-1/.zfs/snapshot/saturday/backups/dumps/dump_usr_friday.dump /tank/vol-fourquid-1/.zfs/snapshot/saturday/sverberne/CLEF-IP11/parts_abs+desc /tank/vol-fourquid-1/.zfs/snapshot/sunday/sverberne/CLEF-IP11/parts_abs+desc /tank/vol-fourquid-1/.zfs/snapshot/monday/sverberne/CLEF-IP11/parts_abs+desc -Olaf. -- Pipe rene = new PipePicture(); assert(Not rene.GetType().Equals(Pipe)); From owner-freebsd-stable@FreeBSD.ORG Tue May 31 09:47:25 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EEC4E1065672 for ; Tue, 31 May 2011 09:47:25 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta01.westchester.pa.mail.comcast.net (qmta01.westchester.pa.mail.comcast.net [76.96.62.16]) by mx1.freebsd.org (Postfix) with ESMTP id 99D978FC0C for ; Tue, 31 May 2011 09:47:25 +0000 (UTC) Received: from omta22.westchester.pa.mail.comcast.net ([76.96.62.73]) by qmta01.westchester.pa.mail.comcast.net with comcast id q9mS1g0041ap0As519nRxV; Tue, 31 May 2011 09:47:25 +0000 Received: from koitsu.dyndns.org ([67.180.84.87]) by omta22.westchester.pa.mail.comcast.net with comcast id q9nQ1g0061t3BNj3i9nQR8; Tue, 31 May 2011 09:47:25 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id A8F36102C19; Tue, 31 May 2011 02:47:22 -0700 (PDT) Date: Tue, 31 May 2011 02:47:22 -0700 From: Jeremy Chadwick To: Olaf Seibert Message-ID: <20110531094722.GA96712@icarus.home.lan> References: <20110530093546.GX6733@twoquid.cs.ru.nl> <20110530101051.GA49825@twoquid.cs.ru.nl> <20110530103349.GA73825@icarus.home.lan> <20110530110946.GC6733@twoquid.cs.ru.nl> <20110530171909.GE6688@dan.emsphone.com> <20110531092556.GD6733@twoquid.cs.ru.nl> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20110531092556.GD6733@twoquid.cs.ru.nl> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-stable@freebsd.org, Dan Nelson Subject: Re: ZFS I/O errors X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 31 May 2011 09:47:26 -0000 On Tue, May 31, 2011 at 11:25:56AM +0200, Olaf Seibert wrote: > On Mon 30 May 2011 at 12:19:10 -0500, Dan Nelson wrote: > > The ZFS compression code will panic if it can't allocate the buffer needed > > to store the compressed data, so that's unlikely to be your problem. The > > only time I have seen an "illegal byte sequence" error was when trying to > > copy raw disk images containing ZFS pools to different disks, and the > > destination disk was a different size than the original. I wasn't even able > > to import the pool in that case, though. > > Yet somehow some incorrect data got written, it seems. That never > happened before, fortunately, even though we had crashes before that > seemed to be related to ZFS running out of memory. > > > The zfs IO code overloads the EILSEQ error code and uses it as a "checksum > > error" code. Returning that error for the same block on all disks is > > definitely weird. Could you have run a partitioning tool, or some other > > program that would have done direct writes to all of your component disks? > > I hope I would remember doing that if I did! > > > Your scrub is also a bit worrying - 24k checksum errors definitely shouldn't > > occur during normal usage. > > It turns out that the errors are easy to provoke: they happen every time > I do an ls of of the affected directories. There were processes running > that were likely to be trying to write to the same directories (the file > system is exported over NFS), so in that case it is easy to imagine that > the numbers rack up quickly. > > I moved those directories to the side, for the moment, but I haven't > been able to delete them yet. The data is a bit bigger than we're able > to backup so "just restoring a backup" isn't an easy thing to do. > Possibly I could make a new filesystem in the same pool, if that would > do the trick; it isn't more than 50% full but the affected one is the > biggest filesystem in it. > > The end result of the scrub is as follows: > > pool: tank > state: ONLINE > status: One or more devices has experienced an error resulting in data > corruption. Applications may be affected. > action: Restore the file in question if possible. Otherwise restore the > entire pool from backup. > see: http://www.sun.com/msg/ZFS-8000-8A > scrub: scrub completed after 12h56m with 3 errors on Mon May 30 23:56:47 2011 > config: > > NAME STATE READ WRITE CKSUM > tank ONLINE 0 0 6.38K > raidz2 ONLINE 0 0 25.4K > 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 > > errors: Permanent errors have been detected in the following files: > > tank/vol-fourquid-1:<0x0> > tank/vol-fourquid-1@saturday:<0x0> > /tank/vol-fourquid-1/.zfs/snapshot/saturday/backups/dumps/dump_usr_friday.dump > /tank/vol-fourquid-1/.zfs/snapshot/saturday/sverberne/CLEF-IP11/parts_abs+desc > /tank/vol-fourquid-1/.zfs/snapshot/sunday/sverberne/CLEF-IP11/parts_abs+desc > /tank/vol-fourquid-1/.zfs/snapshot/monday/sverberne/CLEF-IP11/parts_abs+desc Mickael Maillot responded to this thread, pointing that situations like this could be caused by bad RAM. I admit that's a possibility; with ZFS in use the most likely memory-utilising piece (meaning volume-wise) of the system would be the ZFS ARC. I don't know if you'd necessarily see things like sig11's on random daemons, etc. (it often depends on where within the addressing range the bad DRAM chip would be associated). Can you rule out bad RAM by letting something like memtest86+ run for 12-24 hours? It's not a 100% infallible utility, but usually for simple things, it will detect/report errors within the first 15-30 minutes. Please keep in mind that even if you have ECC RAM, testing with memtest86+ would be worthwhile. Single-bit errors are correctable by ECC, while multi-bit aren't (but are detectable). "ChipKill" (see Wikipedia please) might work around this problem, but I've never personally used it (never seen it on any Intel systems I've used, only AMD systems). Finally, depending on what CPU model you have, northbridge problems (older systems) or on-die MCH (newer CPUs, e.g. Core iX and recent Xeon) problems could manifest themselves like this. However, in those situations I'd imagine you'd be seeing a lot of other oddities on the system and not limited to just ZFS. Newer systems which support MCA (again see Wikipedia; Machine Check Architecture) would/show throw MCEs which FreeBSD 8.x should absolutely notice/report (you'd see a lot of nastigrams on the console). I think that about does it for my ideas/blabbing on that topic. -- | 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 31 11:36:15 2011 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 89C9E1065677 for ; Tue, 31 May 2011 11:36:15 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id DAA1A8FC1A for ; Tue, 31 May 2011 11:36:14 +0000 (UTC) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id OAA08380; Tue, 31 May 2011 14:36:09 +0300 (EEST) (envelope-from avg@FreeBSD.org) Message-ID: <4DE4D2A8.7050006@FreeBSD.org> Date: Tue, 31 May 2011 14:36:08 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.17) Gecko/20110504 Lightning/1.0b2 Thunderbird/3.1.10 MIME-Version: 1.0 To: Arnaud Houdelette References: <63454684d7d46c2ef76cfcc979500612@tzim.net> <4DDF8E02.4060108@FreeBSD.org> In-Reply-To: X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-stable@FreeBSD.org Subject: Re: zfs-root and "safe" atomic updates X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 31 May 2011 11:36:15 -0000 on 27/05/2011 17:16 Arnaud Houdelette said the following: > On Fri, 27 May 2011 14:41:54 +0300, Andriy Gapon wrote: >> I am not aware of any plans to implement nextboot for zfs as it would >> require at >> least some write support for zpool and there is none (for boot code) >> at the moment. >> > > Could'nt the loader use a bit flag in the loader sector ? First, strictly speaking, the loader is an executable on a filesystem, there is no "loader sector". If we consider the earlier boot stages, various incarnations of boot2 like gptzfsboot or non-MBR part of zfsboot, then it gets interesting for multi-disk configurations. FreeBSD has its view of disks, but BIOS (which is used for disk access during boot) has its own different view of disks. So it's hard (or impossible) to do an auto-magic thing here. One option could be to force a user to use its superior knowledge of a system to explicitly specify which disk and which boot block should be used for nextboot-ish purposes. That, of course, would be prone to footshooting because of the human nature. For example, one could specify a wrong disk, boot, see that nothing changed, realize the mistake, specify correct disk, never clean out nextboot-ish data on the wrong disk, change boot order months later and get badly hurt. But it could also be argued that that approach would be better than nothing, which is the case for ZFS at the moment. > Nextboot (or something equivalent) missing is the sole thing keeping me from > removing ufs boot partition for remote servers. > >>> What do you think ? How do you address the problem ? >> >> I have some patches that allow to boot a different loader or a kernel from a >> different (non-bootfs) ZFS dataset: >> http://lists.freebsd.org/pipermail/freebsd-fs/2010-July/008976.html >> But that still requires access to zfs boot and/or loader command interface. > > Interesting though. Thanks. > Does the mentionned patch still works with latest 8-stable loader ? I've rebased the patch to the latest head: http://people.freebsd.org/~avg/zfsboot.diff > And do you still have to change vfs.root.mountfrom once currdev set ? That should already be included into the patch. -- Andriy Gapon From owner-freebsd-stable@FreeBSD.ORG Tue May 31 12:51:18 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B4ECE1065674; Tue, 31 May 2011 12:51:18 +0000 (UTC) (envelope-from daniel@digsys.bg) Received: from smtp-sofia.digsys.bg (smtp-sofia.digsys.bg [193.68.3.230]) by mx1.freebsd.org (Postfix) with ESMTP id 4325B8FC1A; Tue, 31 May 2011 12:51:17 +0000 (UTC) Received: from dcave.digsys.bg (dcave.digsys.bg [192.92.129.5]) (authenticated bits=0) by smtp-sofia.digsys.bg (8.14.4/8.14.4) with ESMTP id p4VCp7tJ055389 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Tue, 31 May 2011 15:51:13 +0300 (EEST) (envelope-from daniel@digsys.bg) Message-ID: <4DE4E43B.7030302@digsys.bg> Date: Tue, 31 May 2011 15:51:07 +0300 From: Daniel Kalchev User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.17) Gecko/20110519 Thunderbird/3.1.10 MIME-Version: 1.0 To: Mikolaj Golub References: <4DE21C64.8060107@digsys.bg> <4DE3ACF8.4070809@digsys.bg> <86d3j02fox.fsf@kopusha.home.net> In-Reply-To: <86d3j02fox.fsf@kopusha.home.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org Subject: Re: HAST instability X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 31 May 2011 12:51:18 -0000 On 30.05.11 21:42, Mikolaj Golub wrote: > DK> One strange thing is that there is never established TCP connection > DK> between both nodes: > > DK> tcp4 0 0 10.2.101.11.48939 10.2.101.12.8457 FIN_WAIT_2 > DK> tcp4 0 1288 10.2.101.11.57008 10.2.101.12.8457 CLOSE_WAIT > DK> tcp4 0 0 10.2.101.11.46346 10.2.101.12.8457 FIN_WAIT_2 > DK> tcp4 0 90648 10.2.101.11.13916 10.2.101.12.8457 CLOSE_WAIT > DK> tcp4 0 0 10.2.101.11.8457 *.* LISTEN > > It is normal. hastd uses the connections only in one direction so it calls > shutdown to close unused directions. So the TCP connections are all too short-lived that I can never see a single one in ESTABLISHED state? 10Gbit Ethernet is indeed fast, so this might well be possible... > I suppose when checksum is enabled the bottleneck is cpu, the triffic rate is lower and the problem is not triggered. I was thinking something like this. My later tests seems to suggest that when the network transfer rate is mugh higher than disk transfer rate this gets triggered. > "Hash mismatch" message suggests that actually you were using checksum then, > weren't you? Yes, this occurs only when checksums are enabled. Happens with both crc32 and sha256. > I would like to look at full logs for some rather large period, with several > cases, from both primary and secondary (and be sure about synchronized time). I have made sure clocks are synchronized and am currently running on a freshly rebooted nodes (with two additional SATA drives at each node) -- so far some interesting findings, like I get hash errors and disconnects much more frequent now. Will post when an bonnie++ run on the ZFS filesystem on top of the HAST resources finishes. > Also, it might worth checking that there is no network packet corruption (some strange things in netstat -di, netstat -s, may be copying large files via net and comparing checksums). > I will post these as well, however so far no indication of any network problems was seen, no interface errors etc. Might be also the ix driver is not reporting such, of course. One additional note: while playing with this setup, I tried to simulate local disk going away in the hope HAST will switch to using the remote disk. Instead of asking someone at the site to pull out the drive, I just issued on the primary hastctl role init data0 which resulted in kernel panic. Unfortunately, there was no sufficient dump space for 48GB. I will re-run this again with more drives for the crash dump. Anything you want me to look for in particular? (kernels have no KDB compiled in yet) Daniel From owner-freebsd-stable@FreeBSD.ORG Tue May 31 13:16:21 2011 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DD074106566B for ; Tue, 31 May 2011 13:16:20 +0000 (UTC) (envelope-from matt.thyer@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 76C068FC0A for ; Tue, 31 May 2011 13:16:20 +0000 (UTC) Received: by wyf23 with SMTP id 23so4460514wyf.13 for ; Tue, 31 May 2011 06:16:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:date:message-id:subject:from:to :content-type; bh=eDJeDjR6xWdE0v7pcp2ubHz/J4SeYxMob/VqUHAPwJ4=; b=hTXgDLTuhvZ90+ilBdxT7UFC65PBepyKyvk2LpPW1CS3PlGX07dO7zaEruAeEZdB7w yvV9eUV0pnaBPgxO5ObGs9RSP2TpomGy59weWrX8GB3a+VIvLyZ9fNnRMZ9ZWkv89QFv 8QQd8CnpnEf3IGiK4DMqCp93ky1M/leldr71c= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=ImRhfJyHMG37JJf+GqSjgfauosLFOgDS9/+E8WSQ7Y6xWdx+1yqLIRkt8gFe3qxXTS DVRh/1TLHYkEwaFvJxjTusw/9TyYm2jjCqcyp4ojtOEcGPfAwgqrpn8U5ybmKUSA5MEP kF0O4cZO6pMEI4dh9+fT9qE5c4GoPg7MsYOYk= MIME-Version: 1.0 Received: by 10.216.220.150 with SMTP id o22mr5986626wep.59.1306846131450; Tue, 31 May 2011 05:48:51 -0700 (PDT) Received: by 10.216.54.67 with HTTP; Tue, 31 May 2011 05:48:51 -0700 (PDT) Date: Tue, 31 May 2011 22:18:51 +0930 Message-ID: From: Matt Thyer To: stable@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Subject: PCIe SATA HBA for ZFS on -STABLE X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 May 2011 13:16:21 -0000 I'm not on the -STABLE list so please reply to me. I'm using an Intel Core i3-530 on a Gigabyte H55M-D2H motherboard with 8 x 2TB drives & 2 x 1TB drives. The plan is to have the 1 TB drives in a zmirror and the 8 in a raidz2. Now the Intel chipset has only 6 on board SATA II ports so ideally I'm looking for a non RAID SATA II HBA to give me 6 extra ports (4 min). Why 6 extra ? Well the case I'm using has 2 x eSATA ports so 6 would be ideal, 5 OK, and 4 the minimum I need to do the job. So... What do people recommend for 8-STABLE as a PCIe SATA II HBA for someone using ZFS ? Not wanting to break the bank. Not interested in SATA III 6GB at this time... though it could be useful if I add an SSD for... (is it ZIL ?). Can this be added at any time ? The main issue is I need at least 10 ports total for all existing drives... ZIL would require 11 so ideally we are talking a 6 port HBA. From owner-freebsd-stable@FreeBSD.ORG Tue May 31 13:40:04 2011 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B8669106566C for ; Tue, 31 May 2011 13:40:04 +0000 (UTC) (envelope-from prvs=11320824c3=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 3B4808FC12 for ; Tue, 31 May 2011 13:40:04 +0000 (UTC) X-MDAV-Processed: mail1.multiplay.co.uk, Tue, 31 May 2011 14:28:10 +0100 X-Spam-Processed: mail1.multiplay.co.uk, Tue, 31 May 2011 14:28:10 +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 ([188.220.16.49]) by mail1.multiplay.co.uk (mail1.multiplay.co.uk [85.236.96.23]) (MDaemon PRO v10.0.4) with ESMTP id md50013429315.msg for ; Tue, 31 May 2011 14:28:10 +0100 X-MDRemoteIP: 188.220.16.49 X-Return-Path: prvs=11320824c3=killing@multiplay.co.uk X-Envelope-From: killing@multiplay.co.uk X-MDaemon-Deliver-To: stable@freebsd.org Message-ID: From: "Steven Hartland" To: "Matt Thyer" , References: Date: Tue, 31 May 2011 14:28:18 +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.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6090 Cc: Subject: Re: PCIe SATA HBA for ZFS on -STABLE X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 May 2011 13:40:04 -0000 Areca's work well. The ARC-1220 (8 ports) should do you, not the cheapest but good support and performance. Regards Steve ----- Original Message ----- From: "Matt Thyer" To: Sent: Tuesday, May 31, 2011 1:48 PM Subject: PCIe SATA HBA for ZFS on -STABLE > I'm not on the -STABLE list so please reply to me. > > I'm using an Intel Core i3-530 on a Gigabyte H55M-D2H motherboard with 8 x > 2TB drives & 2 x 1TB drives. > The plan is to have the 1 TB drives in a zmirror and the 8 in a raidz2. > > Now the Intel chipset has only 6 on board SATA II ports so ideally I'm > looking for a non RAID SATA II HBA to give me 6 extra ports (4 min). > Why 6 extra ? > Well the case I'm using has 2 x eSATA ports so 6 would be ideal, 5 OK, and 4 > the minimum I need to do the job. > > So... > > What do people recommend for 8-STABLE as a PCIe SATA II HBA for someone > using ZFS ? > > Not wanting to break the bank. > Not interested in SATA III 6GB at this time... though it could be useful if > I add an SSD for... (is it ZIL ?). > Can this be added at any time ? > > The main issue is I need at least 10 ports total for all existing drives... > ZIL would require 11 so ideally we are talking a 6 port HBA. > _______________________________________________ > 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" > ================================================ 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 Tue May 31 14:09:05 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 722F01065672 for ; Tue, 31 May 2011 14:09:05 +0000 (UTC) (envelope-from to.my.trociny@gmail.com) Received: from mail-fx0-f54.google.com (mail-fx0-f54.google.com [209.85.161.54]) by mx1.freebsd.org (Postfix) with ESMTP id 007468FC17 for ; Tue, 31 May 2011 14:09:04 +0000 (UTC) Received: by fxm11 with SMTP id 11so4352854fxm.13 for ; Tue, 31 May 2011 07:09:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:from:to:cc:subject:organization:references :sender:date:in-reply-to:message-id:user-agent:mime-version :content-type; bh=SiiteZIpiqWyMfHASvHC0qP1gyZDuCWdmeh/1CyV8oo=; b=VPgYj8yOnYhQBPYrAbv3WzesVo4jwJfY9Nr2P6EMw/sCNljielBtEe0G34zxslyIJd kX1xsXq225vrA3Y54/eThAEhfUCG2/RVQmDH7Yk+WPjKeleUi3dDxpYwC1Uj9W11W/zl 0Lk16A+p3AFkXihV/icaVQ6X74q86nGMHunog= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:cc:subject:organization:references:sender:date:in-reply-to :message-id:user-agent:mime-version:content-type; b=JxZeNvIPJ2iAhRIsZF+zZZ826JKF/LVw3dNICz8jGnbSBLncM7BkAxMKFwlKixDGon cbIs6voZoqHa+HlPKNwlNvWKwzE8hkOsJQ9WAcoMvweogzjtnV2kqwUJJcA1SH80vd5E plnZ0jj6DFRfZ3Bh0E6DD6finPRjrTmZLQejI= Received: by 10.223.16.136 with SMTP id o8mr1172534faa.21.1306850943773; Tue, 31 May 2011 07:09:03 -0700 (PDT) Received: from localhost ([94.27.39.186]) by mx.google.com with ESMTPS id q14sm53544faa.3.2011.05.31.07.09.01 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 31 May 2011 07:09:02 -0700 (PDT) From: Mikolaj Golub To: Daniel Kalchev Organization: TOA Ukraine References: <4DE21C64.8060107@digsys.bg> <4DE3ACF8.4070809@digsys.bg> <86d3j02fox.fsf@kopusha.home.net> <4DE4E43B.7030302@digsys.bg> Sender: Mikolaj Golub Date: Tue, 31 May 2011 17:08:59 +0300 In-Reply-To: <4DE4E43B.7030302@digsys.bg> (Daniel Kalchev's message of "Tue, 31 May 2011 15:51:07 +0300") Message-ID: <86zkm3t11g.fsf@in138.ua3> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.2 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: freebsd-stable@freebsd.org Subject: Re: HAST instability X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 31 May 2011 14:09:05 -0000 On Tue, 31 May 2011 15:51:07 +0300 Daniel Kalchev wrote: DK> On 30.05.11 21:42, Mikolaj Golub wrote: >> DK> One strange thing is that there is never established TCP connection >> DK> between both nodes: >> >> DK> tcp4 0 0 10.2.101.11.48939 10.2.101.12.8457 FIN_WAIT_2 >> DK> tcp4 0 1288 10.2.101.11.57008 10.2.101.12.8457 CLOSE_WAIT >> DK> tcp4 0 0 10.2.101.11.46346 10.2.101.12.8457 FIN_WAIT_2 >> DK> tcp4 0 90648 10.2.101.11.13916 10.2.101.12.8457 CLOSE_WAIT >> DK> tcp4 0 0 10.2.101.11.8457 *.* LISTEN >> >> It is normal. hastd uses the connections only in one direction so it calls >> shutdown to close unused directions. DK> So the TCP connections are all too short-lived that I can never see a DK> single one in ESTABLISHED state? 10Gbit Ethernet is indeed fast, so DK> this might well be possible... No the connections are persistent, just only one (unused) direction of communication is closed. See shutdown(2) for further info. >> I would like to look at full logs for some rather large period, with several >> cases, from both primary and secondary (and be sure about synchronized time). DK> I have made sure clocks are synchronized and am currently running on a freshly rebooted nodes (with two additional SATA drives at each node) -- DK> so far some interesting findings, like I get hash errors and DK> disconnects much more frequent now. Will post when an bonnie++ run on DK> the ZFS filesystem on top of the HAST resources finishes. As I wrote privately, it would be nice to see both netstat and hast logs (from both nodes) for the same rather long period, when several cases occured. It would be good to place them somewere on web so other guys could access them too, as I will be offline for 7-10 days and will not be able to help you until I am back. DK> One additional note: while playing with this setup, I tried to DK> simulate local disk going away in the hope HAST will switch to using DK> the remote disk. Instead of asking someone at the site to pull out the DK> drive, I just issued on the primary DK> hastctl role init data0 DK> which resulted in kernel panic. Unfortunately, there was no sufficient DK> dump space for 48GB. I will re-run this again with more drives for the DK> crash dump. Anything you want me to look for in particular? (kernels DK> have no KDB compiled in yet) Well, removing physical disk (device /dev/gpt/data0 consumed by hastd dissapears) and switching a resource to init role (devive /dev/hast/data0 consumed by FS dissapears) are two different things. Sure you should not normally change the resource role (destroy hast device) before unmounting (exporting) FS. -- Mikolaj Golub From owner-freebsd-stable@FreeBSD.ORG Tue May 31 14:54:19 2011 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7A664106564A for ; Tue, 31 May 2011 14:54:19 +0000 (UTC) (envelope-from fjwcash@gmail.com) Received: from mail-yi0-f54.google.com (mail-yi0-f54.google.com [209.85.218.54]) by mx1.freebsd.org (Postfix) with ESMTP id 3671C8FC15 for ; Tue, 31 May 2011 14:54:18 +0000 (UTC) Received: by yie12 with SMTP id 12so2669053yie.13 for ; Tue, 31 May 2011 07:54:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=+NYNxzhAUj55XSPUFQ2vxEpIRhE9237WoVcFSgMhfZE=; b=QBy8G5gbes2qmI6597FMfnvGOdipbKsEbochBm9H7ZQ15l23k/+FimPAKcIne2XVaG RJL4qiivr9cH1SFaJNaMNioVISg1TxTseu4VuXWOVeG6w4+4+JD1SYLAjA06fnXsTEIC wfkJUGdeEcfZAkQIkyU3pcE9bxOE3MDB9TMXw= 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=iXwKhewgkgwKa7BQjuXM6avrCkXHYX4MZRkBI5ALYsBKVf5qNtRg79R9JACDbCeQ1B eacrzCm0WH0QWUemo6xS9U+GzRbXvP5uxF0RzQcKDM8Q3XuxAZh9auYB3va6tIWVjMx3 oTzfUiUA+UZ9JiI9NJN59Zbqxyo3NkZAsj7kw= MIME-Version: 1.0 Received: by 10.91.153.7 with SMTP id f7mr5025076ago.36.1306852263577; Tue, 31 May 2011 07:31:03 -0700 (PDT) Received: by 10.91.161.17 with HTTP; Tue, 31 May 2011 07:31:03 -0700 (PDT) In-Reply-To: References: Date: Tue, 31 May 2011 07:31:03 -0700 Message-ID: From: Freddie Cash To: Matt Thyer Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: stable@freebsd.org Subject: Re: PCIe SATA HBA for ZFS on -STABLE X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 May 2011 14:54:19 -0000 On Tue, May 31, 2011 at 5:48 AM, Matt Thyer wrote: > What do people recommend for 8-STABLE as a PCIe SATA II HBA for someone > using ZFS ? > > Not wanting to break the bank. > Not interested in SATA III 6GB at this time... though it could be useful if > I add an SSD for... (is it ZIL ?). > Can this be added at any time ? > > The main issue is I need at least 10 ports total for all existing drives... > ZIL would require 11 so ideally we are talking a 6 port HBA. > SuperMicro AOC-USAS2-L8i works exceptionally well. These are 8-port HBAs using the LSI1068 chipset, supported by the mpt(4) driver. Support 3 Gpbs SATA/SAS, using multi-lane cables (2 connectors on the card, each connector supports 4 SATA ports), hot-plug, hot-swap. These are UIO cards, so the bracket that comes with it doesn't work with normal cases (the bracket is on the wrong side of the card; they're made for SuperMicro's UIO-based motherboards). However, these are normal PCIe cards and work in any PCIe slot. You either have to remove the bracket, or you can purchase separate brackets online. These cards are recommended on the zfs-discuss mailing list. They are only ~$120 CDN at places like cdw.ca and newegg.ca. -- Freddie Cash fjwcash@gmail.com From owner-freebsd-stable@FreeBSD.ORG Tue May 31 15:01:31 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9F3321065770; Tue, 31 May 2011 15:01:31 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 06DB68FC14; Tue, 31 May 2011 15:01:31 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 9365A46B42; Tue, 31 May 2011 11:01:30 -0400 (EDT) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 1E9558A01F; Tue, 31 May 2011 11:01:30 -0400 (EDT) From: John Baldwin To: Willy@offermans.rompen.nl Date: Tue, 31 May 2011 11:01:23 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110325; KDE/4.5.5; amd64; ; ) References: <20110521092037.GB3271@vpn.offrom.nl> <201105271043.34268.jhb@freebsd.org> <20110530092514.GB4558@vpn.offrom.nl> In-Reply-To: <20110530092514.GB4558@vpn.offrom.nl> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201105311101.23905.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (bigwig.baldwin.cx); Tue, 31 May 2011 11:01:30 -0400 (EDT) Cc: freebsd-hardware@freebsd.org, Marcel Moolenaar , freebsd-stable@freebsd.org Subject: Re: modem support MT9234ZPX-PCIE-NV X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 31 May 2011 15:01:31 -0000 On Monday, May 30, 2011 5:25:14 am Willy Offermans wrote: > Hello John and FreeBSD friends, > > On Fri, May 27, 2011 at 10:43:34AM -0400, John Baldwin wrote: > > On Friday, May 27, 2011 10:38:02 am Willy Offermans wrote: > > > Dear John and FreeBSD friends, > > > > > > On Fri, May 27, 2011 at 08:05:56AM -0400, John Baldwin wrote: > > > > On Thursday, May 26, 2011 4:58:37 pm Mike Tancsa wrote: > > > > > On 5/26/2011 4:12 PM, John Baldwin wrote: > > > > > > > > > > > > Hmm, can you get 'pciconf -lb' output? > > > > > > > > > > > > Hmm, wow, I wonder how uart(4) works at all. It tries to reuse it's softc > > > > > > structure in uart_bus_attach() that was setup in uart_bus_probe(). Since > > > > it > > > > > > doesn't return 0 from its probe routine, that is forbidden. I guess it > > > > > > accidentally works because of the hack where we call DEVICE_PROBE() again > > > > > > to make sure the device description is correct. > > > > > > > > > > > > > > > I think this is a similar card. Had it laying about for a while and > > > > > popped it in. cu -l to it, attaches, but I am not able to interact with it. > > > > > > > > > > none3@pci0:5:0:0: class=0x070002 card=0x20282205 chip=0x015213a8 > > > > > rev=0x02 hdr=0x00 > > > > > vendor = 'Exar Corp.' > > > > > device = 'XR17C/D152 Dual PCI UART' > > > > > class = simple comms > > > > > subclass = UART > > > > > bar [10] = type Memory, range 32, base 0xe8950000, size 1024, enabled > > > > > > > > > > > > > > > NetBSD supposedly has support for this card > > > > > > > > Oh, hmm, looks like the clock has an unusual multiplier. Does it work if you > > > > use 'cu -l -s 1200' to talk at 9600 for example? (In general use speed / 8 > > > > as the speed to '-s'.) > > > > > > > > Also, is your card a modem or a dual-port card? > > > > > > > > -- > > > > John Baldwin > > > > > > It is a modem. > > > > > > As suggested: > > > > > > kosmos# cu -l /dev/cuau0 -s 1200 > > > Stale lock on cuau0 PID=3642... overriding. > > > Connected > > > at&F > > > OK > > > atdt0045******* > > > NO DIALTONE > > > > Ok, try this updated patch. After this you should be able to use the correct > > speed: > > > > Index: uart_bus_pci.c > > =================================================================== > > --- uart_bus_pci.c (revision 222285) > > +++ uart_bus_pci.c (working copy) > > @@ -110,6 +110,8 @@ static struct pci_id pci_ns8250_ids[] = { > > { 0x1415, 0x950b, 0xffff, 0, "Oxford Semiconductor OXCB950 Cardbus 16950 UART", > > 0x10, 16384000 }, > > { 0x151f, 0x0000, 0xffff, 0, "TOPIC Semiconductor TP560 56k modem", 0x10 }, > > +{ 0x13a8, 0x0152, 0x2205, 0x2026, "MultiTech MultiModem ZPX", 0x10, > > + 8 * DEFAULT_RCLK }, > > { 0x9710, 0x9820, 0x1000, 1, "NetMos NM9820 Serial Port", 0x10 }, > > { 0x9710, 0x9835, 0x1000, 1, "NetMos NM9835 Serial Port", 0x10 }, > > { 0x9710, 0x9865, 0xa000, 0x1000, "NetMos NM9865 Serial Port", 0x10 }, > > > > -- > > John Baldwin > > The structure you have provided in your magic line would also need > some explanation. The data concerns the description of the chip and the > card I guess and can be gained by `pciconf -lv` > > uart0@pci0:6:0:0: class=0x070002 card=0x20262205 chip=0x015213a8 rev=0x02 hdr=0x00 > vendor = 'Exar Corp.' > device = 'XR17C/D152 Dual PCI UART' > class = simple comms > subclass = UART > > > A more detailed explanation would not harm. The data 0x10 and > 8 * DEFAULT_RCLK are still totally miraculous to me. 0x10 is the resource id for the first PCI BAR (rids for PCI device resources use the offset in PCI config space of the associated BAR). It would perhaps be more obvious if uart(4) and puc(4) used PCIR_BAR(0) rather than 0x10. Bumping the clock by a multiple of 8 was based on looking at the change in NetBSD that Mike Tancsa pointed to and that you verified by noting that 'cu -s 1200' connected at 9600 (9600 / 1200 == 8). One question though, would you be able to test the patch for puc(4) that I sent to Mike Tancsa to see if your modem works with puc(4)? The puc(4) patch is more general and if it works fine for your modem I'd rather just commit that. -- John Baldwin From owner-freebsd-stable@FreeBSD.ORG Tue May 31 15:09:11 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D67121065674; Tue, 31 May 2011 15:09:11 +0000 (UTC) (envelope-from daniel@digsys.bg) Received: from smtp-sofia.digsys.bg (smtp-sofia.digsys.bg [193.68.3.230]) by mx1.freebsd.org (Postfix) with ESMTP id 5DBEC8FC1B; Tue, 31 May 2011 15:09:11 +0000 (UTC) Received: from dcave.digsys.bg (dcave.digsys.bg [192.92.129.5]) (authenticated bits=0) by smtp-sofia.digsys.bg (8.14.4/8.14.4) with ESMTP id p4VF8xhb056081 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Tue, 31 May 2011 18:09:04 +0300 (EEST) (envelope-from daniel@digsys.bg) Message-ID: <4DE5048B.3080206@digsys.bg> Date: Tue, 31 May 2011 18:08:59 +0300 From: Daniel Kalchev User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.17) Gecko/20110519 Thunderbird/3.1.10 MIME-Version: 1.0 To: Mikolaj Golub References: <4DE21C64.8060107@digsys.bg> <4DE3ACF8.4070809@digsys.bg> <86d3j02fox.fsf@kopusha.home.net> <4DE4E43B.7030302@digsys.bg> <86zkm3t11g.fsf@in138.ua3> In-Reply-To: <86zkm3t11g.fsf@in138.ua3> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org Subject: Re: HAST instability X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 31 May 2011 15:09:12 -0000 On 31.05.11 17:08, Mikolaj Golub wrote: > As I wrote privately, it would be nice to see both netstat and hast logs (from both nodes) for the same rather long period, when several cases occured. It would be good to place them somewere on web so other guys could access them too, as I will be offline for 7-10 days and will not be able to help you until I am back. The test finished running for almost three hours, and so here is the collected data: (for the duration of test, on the secondary node) systat -if /0 /1 /2 /3 /4 /5 /6 /7 /8 /9 /10 Load Average Interface Traffic Peak Total lo0 in 0.000 KB/s 0.000 KB/s 1.126 KB out 0.000 KB/s 0.000 KB/s 1.126 KB ix1 in 0.003 KB/s 230.590 MB/s 614.688 GB out 0.054 KB/s 7.425 MB/s 19.910 GB igb0 in 0.025 KB/s 3.636 KB/s 566.897 KB out 0.072 KB/s 4.296 KB/s 1.091 MB The primary node is b1a, the secondary node is b1b. kernel (built just after csup update): FreeBSD b1a 8.2-STABLE FreeBSD 8.2-STABLE #1: Mon May 30 14:17:50 EEST 2011 root@b1a:/usr/obj/usr/src/sys/GENERIC amd64 from primary messages: http://news.digsys.bg/~admin/hast/test31may/b1a-messages netstat -in: http://news.digsys.bg/~admin/hast/test31may/b1a-netstat -in netstat-s: http://news.digsys.bg/~admin/hast/test31may/b1a-netstat-s from secondary messages: http://news.digsys.bg/~admin/hast/test31may/b1b-messages netstat -in: http://news.digsys.bg/~admin/hast/test31may/b1b-netstat -in netstat-s: http://news.digsys.bg/~admin/hast/test31may/b1b-netstat-s > DK> One additional note: while playing with this setup, I tried to > DK> simulate local disk going away in the hope HAST will switch to using > DK> the remote disk. Instead of asking someone at the site to pull out the > DK> drive, I just issued on the primary > > DK> hastctl role init data0 > > DK> which resulted in kernel panic. Unfortunately, there was no sufficient > DK> dump space for 48GB. I will re-run this again with more drives for the > DK> crash dump. Anything you want me to look for in particular? (kernels > DK> have no KDB compiled in yet) > > Well, removing physical disk (device /dev/gpt/data0 consumed by hastd > dissapears) and switching a resource to init role (devive /dev/hast/data0 > consumed by FS dissapears) are two different things. Sure you should not > normally change the resource role (destroy hast device) before unmounting > (exporting) FS. Then how do I proceed with a failed drive? Or a flaky drive that is still visible to the OS, that I want to remove from HAST and replace with a different one? How do I ask HAST to switch I/O to the secondary? Is there other way to get a drive out of HAST? In any case, even if this is not allowed operation, it should not panic. I am now going to reboot and run the same tests without checksums. Daniel From owner-freebsd-stable@FreeBSD.ORG Tue May 31 19:09:55 2011 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AFB7D106566C for ; Tue, 31 May 2011 19:09:55 +0000 (UTC) (envelope-from artemb@gmail.com) Received: from mail-gx0-f182.google.com (mail-gx0-f182.google.com [209.85.161.182]) by mx1.freebsd.org (Postfix) with ESMTP id 68B748FC13 for ; Tue, 31 May 2011 19:09:55 +0000 (UTC) Received: by gxk28 with SMTP id 28so2822717gxk.13 for ; Tue, 31 May 2011 12:09:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=lmdi3CnWfRIsgw14p7eZ/jl5SVBTSieQ0oMrRHlbOjQ=; b=Gse/5ir2UQLrNTRbCsNEaABhrDfl6ZG9Txq7iEIOmxmPefnDCGNHjuvyMspb7YrCP+ 1HgRU8pj37mOnIa5Fab2UBLZPLuWSopwdSu5jjCvTHtTips8fJdCrOE2pkrG1zxoNpuH LftzMb5ZPk2U0SVNZrqv9yTuWdDWUrkDMfgVo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=UY4pY94nu/45j5t6kcTBn94vCQ+sN6LhiP66l6a5yfsRqOnVyFVnZEaCcDIKjZ2x25 PlfcJEYiGog4V5F3ZnPZw1t6vVa1w22mC7zAxOOnr7y51OXsMqdJEWyu25EIalc9ExxR JcCINRnm2sLBC5A1SHL2GHawDe1ebT9Ltl8vM= MIME-Version: 1.0 Received: by 10.236.138.161 with SMTP id a21mr2423937yhj.49.1306868994592; Tue, 31 May 2011 12:09:54 -0700 (PDT) Sender: artemb@gmail.com Received: by 10.236.208.70 with HTTP; Tue, 31 May 2011 12:09:54 -0700 (PDT) In-Reply-To: References: Date: Tue, 31 May 2011 12:09:54 -0700 X-Google-Sender-Auth: k8O70fgoIi2IJvaAFkynw7I8uuA Message-ID: From: Artem Belevich To: Freddie Cash Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: stable@freebsd.org, Matt Thyer Subject: Re: PCIe SATA HBA for ZFS on -STABLE X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 May 2011 19:09:55 -0000 On Tue, May 31, 2011 at 7:31 AM, Freddie Cash wrote: > On Tue, May 31, 2011 at 5:48 AM, Matt Thyer wrote: > >> What do people recommend for 8-STABLE as a PCIe SATA II HBA for someone >> using ZFS ? >> >> Not wanting to break the bank. >> Not interested in SATA III 6GB at this time... though it could be useful= if >> I add an SSD for... (is it ZIL ?). >> Can this be added at any time ? >> >> The main issue is I need at least 10 ports total for all existing drives= ... >> ZIL would require 11 so ideally we are talking a 6 port HBA. >> > > SuperMicro AOC-USAS2-L8i works exceptionally well. =A0These are 8-port HB= As > using the LSI1068 chipset, supported by the mpt(4) driver. =A0Support 3 G= pbs > SATA/SAS, using multi-lane cables (2 connectors on the card, each connect= or > supports 4 SATA ports), hot-plug, hot-swap. > > These are UIO cards, so the bracket that comes with it doesn't work with > normal cases (the bracket is on the wrong side of the card; they're made = for > SuperMicro's UIO-based motherboards). =A0However, these are normal PCIe c= ards > and work in any PCIe slot. =A0You either have to remove the bracket, or y= ou > can purchase separate brackets online. > > These cards are recommended on the zfs-discuss mailing list. =A0They are = only > ~$120 CDN at places like cdw.ca and newegg.ca. +1 for LSI1068(e) controller + mpt driver. It's cheap and it works. Those LSI controllers are often hiding behind other brands. SuperMicro mentioned above is one. Intel would be another -- search for Intel SASUC8I. Tyan also sells one as TYAN P3208SR. LSI-branded controllers tend to be a bit more expensive than rebranded ones, though functionality is the same and you can often cross-flash firmware. Keep in mind that HBAs based on LSI1068(e) can't handle hard drives larger than 2TB and will truncate larger drive capacity to 2TB. As for the SSD, you may want to hook them up to on-board SATA ports. In my not-very scientific benchmark Intel's X25-M SSD connected to on-board SATA port on ICH10 was able to deliver ~20% more reads/sec than the same SSD connected to LSI1068 based controller. --Artem From owner-freebsd-stable@FreeBSD.ORG Tue May 31 20:11:24 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C4660106566B for ; Tue, 31 May 2011 20:11:24 +0000 (UTC) (envelope-from anonymous@es11.webex.net) Received: from es11.webex.net (es11.webex.net [209.250.82.29]) by mx1.freebsd.org (Postfix) with SMTP id 3540E8FC14 for ; Tue, 31 May 2011 20:11:23 +0000 (UTC) Received: (qmail 61435 invoked by uid 107); 31 May 2011 19:43:51 -0000 Date: 31 May 2011 19:43:51 -0000 Message-ID: <20110531194351.61434.qmail@es11.webex.net> To: "Friend" From: "Catherine Jackson" MIME-Version: 1.0 X-Mailer: Zen Cart Mailer Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Subject: Your friend Catherine Jackson has recommended this great product from Street Cat Jewelry X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 31 May 2011 20:11:24 -0000 Hi Friend! Your friend, Catherine Jackson, thought that you would be interested in Cotswolds, England NC13 from Street Cat Jewelry. Catherine Jackson sent a note saying: Hello Friend, Your Wealth Miners Source Capital! You Can Earn While You Sleep!!! How Could You Imagine To Send Your Ads To More Than 900 Million Everyday Just a Few Click of Your Mouse Hurry This Limited Hot Business in 2011 First Come First Serve... Congratulations: Get Your Waiting $800 Hot Commissions Now!!! It's So Simple That Even A Ten Year Old Could Learn This In Under 1 Hour!"It Doesn't Matter Where In The World You Are If You Have An Internet Connection & A PC You Can Earn The $800 For Just A Few Minutes Of Clicking A Mouse " Imagine waking up at 10am in the morning, having a quick look at your PC and finding the exact information you need to collect a quick $300 by lunchtime. You could take the afternoon off, play some golf, go shopping or spend some quality time with the family. Then do the same thing again in the evening, What a wonderful concept and you could be doing it today. Even during the boom years in any economy it's not possible to find a form of free income, BUT THIS IS EXACTLY THAT! and it will make you free money for the rest of your life. It's Easy To Make Money Everyday Even If You're Starting From Scratch With Zero Knowledge, Experience Or Budget!I'll Show You Exactly How. We've Start putting New 32 Members in YOUR TEAM for the May 24 to 31/2011 weekly commission cycle...and GROWING everyday earn by $100 up to $200 or more. IMPORTANT:Advance Don't delay on May 31/2011,is the Cut-Off day to lock in your position then faster you act the higher commission you will earn!!! Go Here To Secure not less than $800 commission Now and it still growing as many people joining under you. if you secure your position right away:The $800 Commission will Arrive Through your Paypal or Credit Card on July/20/2011...Hurry this limited time, only 8 Positions are available Now. Once you enter a valid credit card number or paypal, after procces, you will be able to earn $800 in less than 2 hours a day.I will show you how we do that and then I will help you through the process so that YOU SUCCEED! And Enjoy!!! You can claim your $800 USD money in any ATM when your membership process are valid. Click Below!!!And Join Right Now.. https://www.plimus.com/jsp/redirect.jsp?contractId=2757066&referrer=freeincome ____ You Can See This Snapshots? Those Person is Proven Earn After Join _____ TYPE DATE & TIME ------- NEW MEMBERS ------------ COUNTRY P --- MAY. 30 @ 2:38 AM-- Jenny Lopez------------- United States P --- MAY. 30 @ 2:53 AM-- Andy William ----------- United Kingdom P --- MAY. 30 @ 2:56 AM-- Jeffrey Jacobs---------- Germany M --- MAY. 30 @ 4:19 AM-- Mayeth Thompson--------- Singapore P --- MAY. 30 @ 4:28 AM-- Chandrena White--------- Italy P --- MAY. 29 @ 2:38 AM-- Jinky Buffer------------ United States P --- MAY. 29 @ 2:53 AM-- Ailaine Smith ---------- United Kingdom P --- MAY. 29 @ 2:56 AM-- Mandene Jonhson--------- Germany M --- MAY. 29 @ 4:19 AM-- Cristian Gatmaitan------ Singapore P --- MAY. 29 @ 4:28 AM-- Jhon Carmalon----------- Italy M --- MAY. 28 @ 6:01 AM-- lalaine Anderson-------- Australia P --- MAY. 28 @ 7:11 AM-- Rebecca Underwood------- Hungary P --- MAY. 28 @ 7:39 AM-- Jericho Jackson--------- Canada P --- MAY. 27 @ 9:42 AM-- Thomas Silva ----------- Sri Lanka M --- MAY. 27 @ 9:58 PM-- Grace Taylor------------ United States P --- MAY. 27 @ 10:21 PM-- Gina Henry-------------- New Zealand P --- MAY. 27 @ 11:24 PM-- Mohammed Ahmen --------- Romania M --- MAY. 26 @ 11:33 PM-- Tracey Duncan----------- Puerto Rico P --- MAY. 26 @ 11:41 PM-- Jane Stawrt------------- United States P --- MAY. 26 @ 11:47 PM-- Janice Youngstown------- Taiwan P --- MAY. 26 @ 11:53 PM-- Shirley Ong------------- China P --- MAY. 25 @ 1:45 AM-- Ryann Lambert ---------- Europe M --- MAY. 25 @ 12:34 AM-- Nick Gauci ------------- Calefornia M --- MAY. 25 @ 10:24 AM-- Don Riley -------------- Netherland P --- MAY. 24 @ 10:30 AM-- Lorne Whittaker -------- Swetzerland P --- MAY. 24 @ 02:14 AM-- Ashwani Vohra ---------- Brazil M --- MAY. 24 @ 2:34 AM-- Kevin Hunt ------------- United States P --- MAY. 24 @ 1:54 AM-- Charles Brown----------- United States Therefore, you have a GUARANTEED $800 CommissionS every month from now on! Earn $25Per Process!Each $25 x 32 = $800 Commission will be yours... Be Sure to Copy the link below & Paste into your browser and press enter: To Secure your $800 commission! You will access your $800 in any ATM when you Join early our weekly cycle. Click Below!!!And Join Right Now.. https://www.plimus.com/jsp/redirect.jsp?contractId=2757066&referrer=freeincome After your simple payment of $25 and you could have earn $800 Remember No one Can give you this kind of commissions in every 20th of the month. Today is $800 Commission in each Member Who start Today before cut-off.... You must UPGRADE right away or before others do.... Business Manager Success, Catherine Jackson MAIN OFFICE, USA, UK, Australia, Asia, Europe ---------------------------------------------------------------------------------------- To view the product, click on the link below or copy and paste the link into your web browser: http://www.streetcatjewelry.com/index.php?main_page=product_info&products_id=701 Regards, Street Cat Jewelry http://www.streetcatjewelry.com/ ----- IMPORTANT: For your protection and to prevent malicious use, all emails sent via this web site are logged and the contents recorded and available to the store owner. If you feel that you have received this email in error, please send an email to sales@streetcatjewelry.com From owner-freebsd-stable@FreeBSD.ORG Tue May 31 20:23:22 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2853D106566C; Tue, 31 May 2011 20:23:22 +0000 (UTC) (envelope-from michael@rancid.berkeley.edu) Received: from rancid.net.berkeley.edu (rancid.Net.Berkeley.EDU [IPv6:2607:f140:ffff:ffff::242]) by mx1.freebsd.org (Postfix) with ESMTP id 04ADA8FC1F; Tue, 31 May 2011 20:23:22 +0000 (UTC) Received: from rancid.net.berkeley.edu (rancid.Berkeley.EDU [128.32.206.242]) by rancid.net.berkeley.edu (8.14.4/8.14.4) with ESMTP id p4VKNL7q096314; Tue, 31 May 2011 13:23:21 -0700 (PDT) (envelope-from michael@rancid.berkeley.edu) Received: from localhost (michael@localhost) by rancid.net.berkeley.edu (8.14.4/8.13.1/Submit) with ESMTP id p4VKNLYB096311; Tue, 31 May 2011 13:23:21 -0700 (PDT) (envelope-from michael@rancid.berkeley.edu) X-Authentication-Warning: rancid.net.berkeley.edu: michael owned process doing -bs Date: Tue, 31 May 2011 13:23:21 -0700 (PDT) From: Michael Sinatra X-X-Sender: michael@rancid.net.berkeley.edu To: Alexander Motin In-Reply-To: <4DE1ED9E.9070303@FreeBSD.org> Message-ID: References: <4DE1C723.2070903@rancid.berkeley.edu> <20110529045615.GA44303@icarus.home.lan> <4DE1ED9E.9070303@FreeBSD.org> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: clamav-milter 0.97 at rancid.net.berkeley.edu X-Virus-Status: Clean X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (rancid.net.berkeley.edu [128.32.206.242]); Tue, 31 May 2011 13:23:21 -0700 (PDT) Cc: freebsd-stable@freebsd.org, Jeremy Chadwick Subject: Re: ICH9 panic/instability on recent kernel X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 31 May 2011 20:23:22 -0000 On Sun, 29 May 2011, Alexander Motin wrote: >>> If I csup the most recent kernel sources, I get the same problem. >>> However, if, after csuping the latest kernel sources, I then fetch >>> the version of sys/dev/ata/ata-all.c as of April 27, everything >>> works fine. Here's the output of pciconf -l: > > The only change in 8-STABLE ata-all.c since April 27 was the SVN rev 221155. > But I don't see how can it cause problems. I would really like to see full > _verbose_ demsg output to better understand what is going on there. If it > even panics, I need to see how exactly. I agree that it makes little sense on the surface. I did follow Jeremy's advice and enable AHCI in the BIOS. Even without loding the ACHI module at boot, that still solved the problem. (I also did load AHCI and it worked fine, which the DVD being recognized as a scsi/atapi-style cd0.) I'll turn of AHCI again and try to get a serial port hooked up so that I can do a boot -v and generate the panic (usually a little bit of disk activity will cause a panic). I'll send that in a separate email to you directly. thanks, michael From owner-freebsd-stable@FreeBSD.ORG Wed Jun 1 01:42:26 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 67DCC106564A for ; Wed, 1 Jun 2011 01:42:26 +0000 (UTC) (envelope-from lichray@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 EFAD88FC0C for ; Wed, 1 Jun 2011 01:42:25 +0000 (UTC) Received: by fxm11 with SMTP id 11so4880624fxm.13 for ; Tue, 31 May 2011 18:42:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:date:message-id:subject:from:to :content-type; bh=2jCoUT9qtZ0RBrWhbsRhSP4e4G77B0leLh3EAAq5nJ4=; b=jB9K9oNbhJRytR6N97XqLyBLvj70QWwdzzycMzMlUbNNSs3uAJ1yLDtnltIdfmUAq5 mZInQllKpQkz61HUQClOC6Oa42nh6bD2DV3671Jj52qcaEGCmHvatm6gMz/MVwJUjKBg ED441/goEBrGZwOfjIEg+lokuU0Vn17DAQByw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=Du0vCwoigMLS7wthF1d+tg6ddQl4ghlOBTjJ5+6fjueZblC/XiK3EfUSzNjYGNOHXR 6BsL+15Nx6kdLcbGyM/+75sWzb0IR498/8GcLgU65glkjuq9veeP+ck1DTEwZtxXmEvv KCkLPY2KB1npYzbbf5h+Sp9TYs0jZDIj7EaN0= MIME-Version: 1.0 Received: by 10.223.53.85 with SMTP id l21mr2209472fag.26.1306890935922; Tue, 31 May 2011 18:15:35 -0700 (PDT) Received: by 10.223.72.13 with HTTP; Tue, 31 May 2011 18:15:35 -0700 (PDT) Date: Tue, 31 May 2011 20:15:35 -0500 Message-ID: From: Zhihao Yuan To: FreeBSD-STABLE Mailing List Content-Type: text/plain; charset=UTF-8 Subject: [ZFSv28]gtpzfsboot fails to boot ZFSv28 0511 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 01 Jun 2011 01:42:26 -0000 Hi, I met this problem, which is serious. I need some help to recovered the system, after that I'll show the photos about the error screen. I used the ZFSv28 patch maintained by mm@ before, and I have a backuped working kernel. I need a LiveCD/memstick to boot the system and recover it. But after I burned the 9.0-current image to memstick, I found that it keeps giving me kernel panic when booting! How can I find a LiveFS with ZFSv28 support? Thanks. -- Zhihao Yuan, nickname lichray The best way to predict the future is to invent it. ___________________________________________________ 4BSD -- http://4bsd.biz/ From owner-freebsd-stable@FreeBSD.ORG Wed Jun 1 01:49:40 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CFD821065673 for ; Wed, 1 Jun 2011 01:49: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 B7B398FC16 for ; Wed, 1 Jun 2011 01:49:40 +0000 (UTC) Received: from omta18.emeryville.ca.mail.comcast.net ([76.96.30.74]) by qmta11.emeryville.ca.mail.comcast.net with comcast id qRQo1g0051bwxycABRpfod; Wed, 01 Jun 2011 01:49:39 +0000 Received: from koitsu.dyndns.org ([67.180.84.87]) by omta18.emeryville.ca.mail.comcast.net with comcast id qRpa1g0091t3BNj8eRpbhb; Wed, 01 Jun 2011 01:49:35 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 0FD34102C19; Tue, 31 May 2011 18:49:33 -0700 (PDT) Date: Tue, 31 May 2011 18:49:33 -0700 From: Jeremy Chadwick To: Zhihao Yuan Message-ID: <20110601014933.GA12940@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.21 (2010-09-15) Cc: FreeBSD-STABLE Mailing List Subject: Re: [ZFSv28]gtpzfsboot fails to boot ZFSv28 0511 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 01 Jun 2011 01:49:40 -0000 On Tue, May 31, 2011 at 08:15:35PM -0500, Zhihao Yuan wrote: > I met this problem, which is serious. I need some help to recovered > the system, after that I'll show the photos about the error screen. > > I used the ZFSv28 patch maintained by mm@ before, and I have a > backuped working kernel. I need a LiveCD/memstick to boot the system > and recover it. But after I burned the 9.0-current image to memstick, > I found that it keeps giving me kernel panic when booting! How can I > find a LiveFS with ZFSv28 support? Thanks. The closest thing I can think of is this: http://mfsbsd.vx.sk/ Except: 1) The ISOs there don't claim to be "LiveFS"; I don't know if they are. 2) There's no memory stick image available, only ISOs, 3) They're 8.2-RELEASE with ZFSv28 patches, not 9.0-CURRENT. I don't know the implications of this. Best to ask mm@. -- | 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 Jun 1 05:59:28 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E5047106567A for ; Wed, 1 Jun 2011 05:59:28 +0000 (UTC) (envelope-from daniel@digsys.bg) Received: from smtp-sofia.digsys.bg (smtp-sofia.digsys.bg [193.68.3.230]) by mx1.freebsd.org (Postfix) with ESMTP id 740318FC15 for ; Wed, 1 Jun 2011 05:59:28 +0000 (UTC) Received: from dcave.digsys.bg (dcave.digsys.bg [192.92.129.5]) (authenticated bits=0) by smtp-sofia.digsys.bg (8.14.4/8.14.4) with ESMTP id p515xIHP061446 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Wed, 1 Jun 2011 08:59:23 +0300 (EEST) (envelope-from daniel@digsys.bg) Message-ID: <4DE5D535.20804@digsys.bg> Date: Wed, 01 Jun 2011 08:59:17 +0300 From: Daniel Kalchev User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.17) Gecko/20110519 Thunderbird/3.1.10 MIME-Version: 1.0 To: freebsd-stable@freebsd.org References: <4DE21C64.8060107@digsys.bg> <4DE3ACF8.4070809@digsys.bg> <86d3j02fox.fsf@kopusha.home.net> <4DE4E43B.7030302@digsys.bg> <86zkm3t11g.fsf@in138.ua3> <4DE5048B.3080206@digsys.bg> In-Reply-To: <4DE5048B.3080206@digsys.bg> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: HAST instability X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 01 Jun 2011 05:59:29 -0000 Here goes the second run, wihtout checksums. systat -if /0 /1 /2 /3 /4 /5 /6 /7 /8 /9 /10 Load Average Interface Traffic Peak Total lo0 in 0.000 KB/s 71.666 KB/s 361.825 KB out 0.000 KB/s 71.666 KB/s 361.825 KB ix1 in 0.021 KB/s 816.608 MB/s 625.751 GB out 0.016 KB/s 7.384 MB/s 23.032 GB igb0 in 0.025 KB/s 1.507 KB/s 11.547 MB out 0.069 KB/s 1.765 KB/s 17.140 MB This time it managed to achieve 800MB/s wow! Anyway, no idea when this happened, as during my observation, it didn't manage to push much data, due to frequent disconnects. Typical "good" rate was lower than with checksums, like just over 100MB/s. from primary messages: http://news.digsys.bg/~admin/hast/test31may-2/b1a-messages netstat -in: http://news.digsys.bg/~admin/hast/test31may-2/b1a-netstat-in netstat-s: http://news.digsys.bg/~admin/hast/test31may-2/b1a-netstat-s from secondary messages: http://news.digsys.bg/~admin/hast/test31may-2/b1b-messages netstat -in: http://news.digsys.bg/~admin/hast/test31may-2/b1b-netstat-in netstat-s: http://news.digsys.bg/~admin/hast/test31may-2/b1b-netstat-s Daniel From owner-freebsd-stable@FreeBSD.ORG Wed Jun 1 07:03:39 2011 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 358561065673 for ; Wed, 1 Jun 2011 07:03:39 +0000 (UTC) (envelope-from tj@tjvarghese.com) Received: from mail-bw0-f54.google.com (mail-bw0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id C06F18FC0C for ; Wed, 1 Jun 2011 07:03:36 +0000 (UTC) Received: by bwz12 with SMTP id 12so6364778bwz.13 for ; Wed, 01 Jun 2011 00:03:36 -0700 (PDT) MIME-Version: 1.0 Received: by 10.204.31.226 with SMTP id z34mr6538529bkc.160.1306910095742; Tue, 31 May 2011 23:34:55 -0700 (PDT) Received: by 10.204.40.202 with HTTP; Tue, 31 May 2011 23:34:55 -0700 (PDT) In-Reply-To: References: Date: Wed, 1 Jun 2011 14:34:55 +0800 Message-ID: From: TJ Varghese To: Freddie Cash Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: stable@freebsd.org, Matt Thyer Subject: Re: PCIe SATA HBA for ZFS on -STABLE X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jun 2011 07:03:39 -0000 On Tue, May 31, 2011 at 10:31 PM, Freddie Cash wrote: > On Tue, May 31, 2011 at 5:48 AM, Matt Thyer wrote: > > > What do people recommend for 8-STABLE as a PCIe SATA II HBA for someone > > using ZFS ? > > > > Not wanting to break the bank. > > Not interested in SATA III 6GB at this time... though it could be useful > if > > I add an SSD for... (is it ZIL ?). > > Can this be added at any time ? > > > > The main issue is I need at least 10 ports total for all existing > drives... > > ZIL would require 11 so ideally we are talking a 6 port HBA. > > > > SuperMicro AOC-USAS2-L8i works exceptionally well. These are 8-port HBAs > using the LSI1068 chipset, supported by the mpt(4) driver. Support 3 Gpbs > SATA/SAS, using multi-lane cables (2 connectors on the card, each connector > supports 4 SATA ports), hot-plug, hot-swap. > > The USAS2 (6Gbps) is supported by the mps driver (on -CURRENT, not sure if it's in 8-STABLE yet). Perhaps you're referring to the earlier USAS which does 3Gbps and is supported by the mpt driver. -- TJ From owner-freebsd-stable@FreeBSD.ORG Wed Jun 1 07:39:52 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9D7F5106566B for ; Wed, 1 Jun 2011 07:39:52 +0000 (UTC) (envelope-from tzim@tzim.net) Received: from orlith.tzim.net (unknown [IPv6:2001:41d0:2:1d32:21c:c0ff:fe82:92c6]) by mx1.freebsd.org (Postfix) with ESMTP id 39D578FC12 for ; Wed, 1 Jun 2011 07:39:52 +0000 (UTC) Received: from localhost ([127.0.0.1] helo=secure.tzim.net) by orlith.tzim.net with esmtp (Exim 4.76 (FreeBSD)) (envelope-from ) id 1QRg1v-0008X6-1x for freebsd-stable@freebsd.org; Wed, 01 Jun 2011 09:39:51 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Date: Wed, 01 Jun 2011 09:39:50 +0200 From: Arnaud Houdelette To: In-Reply-To: <4DE4D2A8.7050006@FreeBSD.org> References: <63454684d7d46c2ef76cfcc979500612@tzim.net> <4DDF8E02.4060108@FreeBSD.org> <4DE4D2A8.7050006@FreeBSD.org> Message-ID: <04039d080a0dfa9f679644e6aae42b55@tzim.net> X-Sender: tzim@tzim.net User-Agent: RoundCube Webmail/0.5.2 Subject: Re: zfs-root and "safe" atomic updates X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 01 Jun 2011 07:39:52 -0000 On Tue, 31 May 2011 14:36:08 +0300, Andriy Gapon wrote: > First, strictly speaking, the loader is an executable on a > filesystem, there is no > "loader sector". If we consider the earlier boot stages, various > incarnations of > boot2 like gptzfsboot or non-MBR part of zfsboot, then it gets > interesting for > multi-disk configurations. FreeBSD has its view of disks, but BIOS > (which is used > for disk access during boot) has its own different view of disks. So > it's hard > (or impossible) to do an auto-magic thing here. One option could be > to force a > user to use its superior knowledge of a system to explicitly specify > which disk > and which boot block should be used for nextboot-ish purposes. > That, of course, would be prone to footshooting because of the human > nature. For > example, one could specify a wrong disk, boot, see that nothing > changed, realize > the mistake, specify correct disk, never clean out nextboot-ish data > on the wrong > disk, change boot order months later and get badly hurt. But it > could also be > argued that that approach would be better than nothing, which is the > case for ZFS > at the moment. > I didn't though of those footshooting scenarios, but it makes sense. I hope we'll somehow end with a proper solution. (...) > I've rebased the patch to the latest head: > http://people.freebsd.org/~avg/zfsboot.diff > >> And do you still have to change vfs.root.mountfrom once currdev set >> ? > > That should already be included into the patch. Ok. It seems the patch won't apply to 8-stable. How should I proceed to adapt it to 8-stable (if this is possible ?). Or maybe I should juste use HEAD loader ? Thanks again. Arnaud Houdelette From owner-freebsd-stable@FreeBSD.ORG Wed Jun 1 08:07:10 2011 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 38AAC1065687 for ; Wed, 1 Jun 2011 08:07:10 +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 D75678FC15 for ; Wed, 1 Jun 2011 08:07:09 +0000 (UTC) Received: from omta18.westchester.pa.mail.comcast.net ([76.96.62.90]) by qmta13.westchester.pa.mail.comcast.net with comcast id qY791g0091wpRvQ5DY7AyW; Wed, 01 Jun 2011 08:07:10 +0000 Received: from koitsu.dyndns.org ([67.180.84.87]) by omta18.westchester.pa.mail.comcast.net with comcast id qY781g0081t3BNj3eY78t5; Wed, 01 Jun 2011 08:07:09 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id DC7AA102C19; Wed, 1 Jun 2011 01:07:06 -0700 (PDT) Date: Wed, 1 Jun 2011 01:07:06 -0700 From: Jeremy Chadwick To: TJ Varghese Message-ID: <20110601080706.GA18521@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.21 (2010-09-15) Cc: stable@freebsd.org, Matt Thyer Subject: Re: PCIe SATA HBA for ZFS on -STABLE X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jun 2011 08:07:10 -0000 On Wed, Jun 01, 2011 at 02:34:55PM +0800, TJ Varghese wrote: > On Tue, May 31, 2011 at 10:31 PM, Freddie Cash wrote: > > > On Tue, May 31, 2011 at 5:48 AM, Matt Thyer wrote: > > > > > What do people recommend for 8-STABLE as a PCIe SATA II HBA for someone > > > using ZFS ? > > > > > > Not wanting to break the bank. > > > Not interested in SATA III 6GB at this time... though it could be useful > > if > > > I add an SSD for... (is it ZIL ?). > > > Can this be added at any time ? > > > > > > The main issue is I need at least 10 ports total for all existing > > drives... > > > ZIL would require 11 so ideally we are talking a 6 port HBA. > > > > > > > SuperMicro AOC-USAS2-L8i works exceptionally well. These are 8-port HBAs > > using the LSI1068 chipset, supported by the mpt(4) driver. Support 3 Gpbs > > SATA/SAS, using multi-lane cables (2 connectors on the card, each connector > > supports 4 SATA ports), hot-plug, hot-swap. > > > > > The USAS2 (6Gbps) is supported by the mps driver (on -CURRENT, not sure if > it's in 8-STABLE yet). Perhaps you're referring to the earlier USAS which > does 3Gbps and is supported by the mpt driver. Folks considering use of mps(4), which was committed to RELENG_8 roughly around 2011/02/18 (thus is not in 8.2-RELEASE), should read the below threads just in case. Always good to be educated. Of course, the mailing lists are usually filled with complaints rather than success stories, so the tone of my mail here will therefore sound negative; I don't mean it that way, I just ask that people "be aware". * 2011/04/29 -- mps driver instability under stable/8 http://lists.freebsd.org/pipermail/freebsd-stable/2011-April/thread.html#62507 http://lists.freebsd.org/pipermail/freebsd-stable/2011-May/thread.html#62518 * 2011/04/27 -- MPS driver: force bus rescan after remove SAS cable http://lists.freebsd.org/pipermail/freebsd-stable/2011-April/thread.html#62438 http://lists.freebsd.org/pipermail/freebsd-stable/2011-April/thread.html#62443 * 2011/03/10 -- LSI SAS2008 performance with mps(4) driver http://lists.freebsd.org/pipermail/freebsd-stable/2011-March/thread.html#61862 To the OP (Matt Thyer): Sadly I don't have a recommendation for you, since you effectively want a 6-port SATA300 controller that's reliable, you're almost certainly going to be paying Big Bucks(tm) given the number of ports and your requirement that it be PCIe-based. You state quite boldly "not wanting to break the bank", but what you're asking for almost certainly WILL break the bank. For example, an "affordable" controller might be one driven by Silicon Image's SiI3124 chip -- four (4) SATA300 ports, but it's only hooked to PCI or PCI-X, not PCIe, which means you're susceptible to a much more severe bus bottleneck than with PCIe: http://www.siliconimage.com/products/family.aspx?id=3 FreeBSD does have support for many Silicon Image chips via the siis(4) driver, and support is quite good since SI provides mav@ with technical documentation and support. I commend SI for that; it's good to see companies supporting developers, regardless of OS. I tend to avoid consumer-grade Marvell and JMicron SATA chipsets like the plague, however. That's based on my experiences with them under Windows, where I would expect (truly) the drivers to be rock solid given the marketing demographic of the chips in question. Be aware that SATA port multipliers (if someone recommends them to you as a way of providing expansion) will also limit your I/O bottleneck, especially when multiple drives are used over a single multiplier port. E.g. 4 drives operating at 100MByte/sec (common read speed with consumer-grade Caviar Black drives!) will saturate a SATA300 connection easily. One port per drive solves this dilemma of course, putting the focus back on the PCI/PCI-X/PCIe bus as a bottleneck. Anyway, you need to ask yourself what your requirements really are, or what sort of monetary limitations you have, then make a decision based on that. Remember: a good, solid controller will probably be a one-time purchase. But also think about the future and if in 2-3 years you want to go about buying another controller (likely costing more than whatever it is you buy now). Good luck, and please let us know what controller you *do* end up going with and your experience with it! Positives are as important as negatives. -- | 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 Jun 1 08:16:17 2011 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BAD8C106564A for ; Wed, 1 Jun 2011 08:16:17 +0000 (UTC) (envelope-from tzim@tzim.net) Received: from orlith.tzim.net (unknown [IPv6:2001:41d0:2:1d32:21c:c0ff:fe82:92c6]) by mx1.freebsd.org (Postfix) with ESMTP id 8512E8FC0A for ; Wed, 1 Jun 2011 08:16:17 +0000 (UTC) Received: from localhost ([127.0.0.1] helo=secure.tzim.net) by orlith.tzim.net with esmtp (Exim 4.76 (FreeBSD)) (envelope-from ) id 1QRgbA-000ABZ-P6 for stable@freebsd.org; Wed, 01 Jun 2011 10:16:16 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Date: Wed, 01 Jun 2011 10:16:16 +0200 From: Arnaud Houdelette To: Message-ID: X-Sender: tzim@tzim.net User-Agent: RoundCube Webmail/0.5.2 Cc: Subject: gptzfsboot serial support X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 01 Jun 2011 08:16:17 -0000 Hi. I know that there is 2 versions of boot0 : With and Without serial support. Is it the same with gptzfsboot ? How to build gptzfsboot with serial support, setting serial speed at 19200 baud ? Thanks Arnaud Houdelette From owner-freebsd-stable@FreeBSD.ORG Wed Jun 1 08:22:39 2011 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5F055106566B for ; Wed, 1 Jun 2011 08:22:39 +0000 (UTC) (envelope-from Holger.Kipp@alogis.com) Received: from alogis.com (firewall.solit-ag.de [212.184.102.1]) by mx1.freebsd.org (Postfix) with ESMTP id D35408FC12 for ; Wed, 1 Jun 2011 08:22:38 +0000 (UTC) Received: from msx3.exchange.alogis.com (exchange.alogis.com [10.1.1.6]) by alogis.com (8.13.4/8.13.1) with ESMTP id p518MbPO020004 for ; Wed, 1 Jun 2011 10:22:37 +0200 (CEST) (envelope-from Holger.Kipp@alogis.com) Received: from MSX3.exchange.alogis.com ([fe80::c8ed:428a:a157:b61]) by msx3.exchange.alogis.com ([fe80::c8ed:428a:a157:b61%13]) with mapi id 14.01.0255.000; Wed, 1 Jun 2011 10:23:20 +0200 From: Holger Kipp To: "stable@freebsd.org" Thread-Topic: 8-STABLE won't boot with ZFSv28 Thread-Index: AcwgMDZpIyhysR9GQjKr1bi0oNTyxw== Date: Wed, 1 Jun 2011 08:23:19 +0000 Message-ID: <814C9E9472FDCC40AAC3FC95A2D67E3B0BD88C69@msx3.exchange.alogis.com> Accept-Language: en-GB, de-DE, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [212.184.101.130] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Subject: 8-STABLE won't boot with ZFSv28 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 01 Jun 2011 08:22:39 -0000 Hi all, I have a very irritating problem with 8-STABLE and ZFSv28 I upgraded to 8-STABLE as of yesterday (31.05.2011), downloaded stable-8-zfsv28-20110521.patch.xz and applied the patch using cd /usr/src patch -E -p0 < /path/to/patchfile make buildworld make buildkernel KERNCONF=3Dfoo make installkernel KERNCONF=3Dfoo make installworld mergemaster which all went smoothly. After reboot, I only got unknown: WARNING - ATAPI_IDENTITFY requeued due to channel reset LBA=3D0 all the time, and then after an hour or so (wasn't on site), system gave Fatal trap 12: page fault while in kernel mode cupid - 0; apic id =3D 00 fault virtual address =3D 0x8 fault code =3D supervisor read data, page not present instruction pointer =3D 0x20:0xffffffff80252301 stack poiner =3D 0x28:0xffffff80000a7ac0 frame pointer =3D 0x28:0xffffff80000a7b00 code segment =3D base 0x0, limit 0xfffff, type 0x1b =3D DPL 0, pres1, long 1, de= f32 0, gran 1 processor eflags =3D interrupt enabled, resume, IOPL =3D 0 current process =3D 0 (thread taskq)trap number =3D= 12 panic: page fault cpuid =3D 0 Uptime: 1h0m13s Cannot dump. Device not defined or unavailable. Automatic reboot in 15 seconds - press a key on the console to abort Needless to say the system did not reboot. Had to powercycle. Then always got the unknown: WARNING - ATAPI_IDENTITFY requeued due to channel reset LBA=3D0 error about once per second. Have now used a fixit-disk to change back to the old kernel: FreeBSD 8.2-STABLE #12: Mon Apr 18 12:48:56 CEST 2011 and rebootet. Now zfs claims to be v28, current storage pool is at 15.I'd love to try ZFSv28, but with the old kernel I don't think this is a good idea - but with the new kernel it seems I can't even boot properly. Any suggestions as to how to proceed? Best regards, Holger -- Holger Kipp Diplom-Mathematiker Senior Consultant Tel. : +49 30 436 58 114 Fax. : +49 30 436 58 214 Mobil: +49 178 36 58 114 Email: holger.kipp@alogis.com alogis AG Alt-Moabit 90b D-10559 Berlin web : http://www.alogis.com ---------------------------------------------------------- alogis AG Sitz/Registergericht: Berlin/AG Charlottenburg, HRB 71484 Vorstand: Arne Friedrichs, Joern Samuelson Aufsichtsratsvorsitzender: Reinhard Mielke From owner-freebsd-stable@FreeBSD.ORG Wed Jun 1 08:39:36 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 86D08106566B for ; Wed, 1 Jun 2011 08:39:36 +0000 (UTC) (envelope-from daniel@digsys.bg) Received: from smtp-sofia.digsys.bg (smtp-sofia.digsys.bg [193.68.3.230]) by mx1.freebsd.org (Postfix) with ESMTP id 122EB8FC1D for ; Wed, 1 Jun 2011 08:39:35 +0000 (UTC) Received: from dcave.digsys.bg (dcave.digsys.bg [192.92.129.5]) (authenticated bits=0) by smtp-sofia.digsys.bg (8.14.4/8.14.4) with ESMTP id p518dQIZ065136 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Wed, 1 Jun 2011 11:39:32 +0300 (EEST) (envelope-from daniel@digsys.bg) Message-ID: <4DE5FABE.20905@digsys.bg> Date: Wed, 01 Jun 2011 11:39:26 +0300 From: Daniel Kalchev User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.17) Gecko/20110519 Thunderbird/3.1.10 MIME-Version: 1.0 To: freebsd-stable@freebsd.org References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: PCIe SATA HBA for ZFS on -STABLE X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jun 2011 08:39:36 -0000 On 01.06.11 09:34, TJ Varghese wrote: > >> SuperMicro AOC-USAS2-L8i works exceptionally well. These are 8-port HBAs >> using the LSI1068 chipset, supported by the mpt(4) driver. Support 3 Gpbs >> SATA/SAS, using multi-lane cables (2 connectors on the card, each connector >> supports 4 SATA ports), hot-plug, hot-swap. > The USAS2 (6Gbps) is supported by the mps driver (on -CURRENT, not sure if > it's in 8-STABLE yet). Perhaps you're referring to the earlier USAS which > does 3Gbps and is supported by the mpt driver. > One should also bear in mind, that the 1068e based controllers (AOC-USAS-L8i) apparently have 2TB drive size limitation, therefore cannot be used with current 3TB (and who knows what capacities by the end of the year) drives. Otherwise, this is an well supported, high performance, stable and relatively cheap HBA to consider. The SAS2 (LSI 2008 based) HBAs are also good, despite some firmware issues (mostly are related to use with SAS expanders) and do not have obvious limitations yet. These might be just a bit more expensive, but my Supermicro supplier advised delivery times for the older SAS (3Gbps) versions would be much longer. Daniel From owner-freebsd-stable@FreeBSD.ORG Wed Jun 1 08:50:46 2011 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 518F3106566B for ; Wed, 1 Jun 2011 08:50:46 +0000 (UTC) (envelope-from laa@cemu.ru) Received: from m.cemu.ru (m.cemu.ru [194.186.216.68]) by mx1.freebsd.org (Postfix) with ESMTP id 067058FC1C for ; Wed, 1 Jun 2011 08:50:45 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=laa.zp.ua; s=dkim; h=Sender:In-Reply-To:Content-Type:Mime-Version:References:Message-ID:Subject:Cc:To:From:Date; bh=PUXiUROvAYIKsJTFUgmCHdav0JbHRrOFY3D1kvdP8rI=; b=bePiaCgmqVWgi5WJRcxeiHgEPCYeCXpZNbbFd5ljCkIUWxiCUJACVguLt25QIj0C1ayKiaFOgZeYRlELOC8uYhV8iUQSxNhqn0IS9ypTENxBezDjSDmF211bFoYTozgKfjErFgxYdj+MMiYL9mtpk3jdcQnVHE+Ll3Jl8aPYpvc=; Received: by m.cemu.ru with local (Exim) (envelope-from ) id 1QRgpc-000KJh-Jb; Wed, 01 Jun 2011 12:31:12 +0400 Date: Wed, 1 Jun 2011 12:31:12 +0400 From: Lystopad Olexandr To: Holger Kipp Message-ID: <20110601083112.GG74833@laa.zp.ua> References: <814C9E9472FDCC40AAC3FC95A2D67E3B0BD88C69@msx3.exchange.alogis.com> Mime-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <814C9E9472FDCC40AAC3FC95A2D67E3B0BD88C69@msx3.exchange.alogis.com> User-Agent: Mutt/1.4.2.3i Sender: laa Cc: "stable@freebsd.org" Subject: Re: 8-STABLE won't boot with ZFSv28 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 01 Jun 2011 08:50:46 -0000 Hello, Holger Kipp! On Wed, Jun 01, 2011 at 08:23:19AM +0000 Holger.Kipp@alogis.com wrote about "8-STABLE won't boot with ZFSv28": > Hi all, > I have a very irritating problem with 8-STABLE and ZFSv28 > > I upgraded to 8-STABLE as of yesterday (31.05.2011), > downloaded stable-8-zfsv28-20110521.patch.xz > and applied the patch using > > cd /usr/src > patch -E -p0 < /path/to/patchfile > make buildworld > make buildkernel KERNCONF=foo > make installkernel KERNCONF=foo > make installworld > mergemaster Looks like you forgot to update your bootcode. gpart bootcode .... > which all went smoothly. > > After reboot, I only got > unknown: WARNING - ATAPI_IDENTITFY requeued due to channel reset LBA=0 > all the time, and then after an hour or so (wasn't on site), > system gave > Fatal trap 12: page fault while in kernel mode > cupid - 0; apic id = 00 > fault virtual address = 0x8 > fault code = supervisor read data, page not present > instruction pointer = 0x20:0xffffffff80252301 > stack poiner = 0x28:0xffffff80000a7ac0 > frame pointer = 0x28:0xffffff80000a7b00 > code segment = base 0x0, limit 0xfffff, type 0x1b > = DPL 0, pres1, long 1, def32 0, gran 1 > processor eflags = interrupt enabled, resume, IOPL = 0 > current process = 0 (thread taskq)trap number = 12 > panic: page fault > cpuid = 0 > Uptime: 1h0m13s > Cannot dump. Device not defined or unavailable. > Automatic reboot in 15 seconds - press a key on the console to abort > > > Needless to say the system did not reboot. Had to powercycle. > > Then always got the > unknown: WARNING - ATAPI_IDENTITFY requeued due to channel reset LBA=0 > error about once per second. > > Have now used a fixit-disk to change back to the old kernel: > FreeBSD 8.2-STABLE #12: Mon Apr 18 12:48:56 CEST 2011 > and rebootet. > Now zfs claims to be v28, current storage pool is at 15.I'd love to > try ZFSv28, but with the old kernel I don't think > this is a good idea - but with the new kernel it seems I can't > even boot properly. > Any suggestions as to how to proceed? -- Lystopad Olexandr From owner-freebsd-stable@FreeBSD.ORG Wed Jun 1 08:54:57 2011 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4CA931065676 for ; Wed, 1 Jun 2011 08:54:57 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta05.westchester.pa.mail.comcast.net (qmta05.westchester.pa.mail.comcast.net [76.96.62.48]) by mx1.freebsd.org (Postfix) with ESMTP id EC63E8FC12 for ; Wed, 1 Jun 2011 08:54:56 +0000 (UTC) Received: from omta22.westchester.pa.mail.comcast.net ([76.96.62.73]) by qmta05.westchester.pa.mail.comcast.net with comcast id qYs41g0011ap0As55Yuxak; Wed, 01 Jun 2011 08:54:57 +0000 Received: from koitsu.dyndns.org ([67.180.84.87]) by omta22.westchester.pa.mail.comcast.net with comcast id qYuv1g00F1t3BNj3iYuvyj; Wed, 01 Jun 2011 08:54:56 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 1CE5F102C19; Wed, 1 Jun 2011 01:54:54 -0700 (PDT) Date: Wed, 1 Jun 2011 01:54:54 -0700 From: Jeremy Chadwick To: Holger Kipp Message-ID: <20110601085454.GA19434@icarus.home.lan> References: <814C9E9472FDCC40AAC3FC95A2D67E3B0BD88C69@msx3.exchange.alogis.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <814C9E9472FDCC40AAC3FC95A2D67E3B0BD88C69@msx3.exchange.alogis.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "stable@freebsd.org" , mav@freebsd.org Subject: Re: 8-STABLE won't boot with ZFSv28 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 01 Jun 2011 08:54:57 -0000 On Wed, Jun 01, 2011 at 08:23:19AM +0000, Holger Kipp wrote: > I have a very irritating problem with 8-STABLE and ZFSv28 > > I upgraded to 8-STABLE as of yesterday (31.05.2011), > downloaded stable-8-zfsv28-20110521.patch.xz > and applied the patch using > > cd /usr/src > patch -E -p0 < /path/to/patchfile > make buildworld > make buildkernel KERNCONF=foo > make installkernel KERNCONF=foo > make installworld > mergemaster > > which all went smoothly. > > After reboot, I only got > unknown: WARNING - ATAPI_IDENTITFY requeued due to channel reset LBA=0 > all the time, and then after an hour or so (wasn't on site), > system gave > Fatal trap 12: page fault while in kernel mode > cupid - 0; apic id = 00 > fault virtual address = 0x8 > fault code = supervisor read data, page not present > instruction pointer = 0x20:0xffffffff80252301 > stack poiner = 0x28:0xffffff80000a7ac0 > frame pointer = 0x28:0xffffff80000a7b00 > code segment = base 0x0, limit 0xfffff, type 0x1b > = DPL 0, pres1, long 1, def32 0, gran 1 > processor eflags = interrupt enabled, resume, IOPL = 0 > current process = 0 (thread taskq)trap number = 12 > panic: page fault > cpuid = 0 > Uptime: 1h0m13s > Cannot dump. Device not defined or unavailable. > Automatic reboot in 15 seconds - press a key on the console to abort > > Needless to say the system did not reboot. Had to powercycle. > > Then always got the > unknown: WARNING - ATAPI_IDENTITFY requeued due to channel reset LBA=0 > error about once per second. > > Have now used a fixit-disk to change back to the old kernel: > FreeBSD 8.2-STABLE #12: Mon Apr 18 12:48:56 CEST 2011 > and rebootet. > Now zfs claims to be v28, current storage pool is at 15.I'd love to > try ZFSv28, but with the old kernel I don't think > this is a good idea - but with the new kernel it seems I can't > even boot properly. > Any suggestions as to how to proceed? I think this is much more likely related to an ATA/ATAPI-related change that was committed on April 17th recently and is not related to ZFSv28. Please see this thread: * 2011/05/29 -- ICH9 panic/instability on recent kernel http://lists.freebsd.org/pipermail/freebsd-stable/2011-May/thread.html#62804 Holger, can you please provide the following two things? 1) Output from "pciconf -lvcb". 2) Full output from a verbose boot (option "5" at the loader prompt). I imagine #2 isn't going to work for most users because there's no way to get pages and pages and pages of data from a panic'd machine without either serial console (which will require a 2nd machine and possibly a null-modem cable) or properly setting up a dedicated swap partition and large-enough /var filesystem, plus their kernel would need DDB support added to it (so they could properly do "call doadump" then "reboot"). A workaround which one user has confirmed is to enable AHCI for your SATA controller in your system BIOS (if such is available). ataahci.ko will be used (which is AHCI via ATA) and your device names probably won't change. Alternatively you could enable AHCI and use ahci.ko (ahci_load="yes" in /boot/loader.conf) to get AHCI via CAM, which provides NCQ and other features, but your device names will change. My familiarity with ATAPI is limited however. CC'ing mav@ here. Alexander, Holger's report looks exactly like Michael's report. Possibly we should consider reverting the April 17th commit until we can figure out what's going on here. -- | 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 Jun 1 08:59:24 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6BC101065674 for ; Wed, 1 Jun 2011 08:59:24 +0000 (UTC) (envelope-from olivier@gid0.org) Received: from mail-pw0-f54.google.com (mail-pw0-f54.google.com [209.85.160.54]) by mx1.freebsd.org (Postfix) with ESMTP id 4C5468FC08 for ; Wed, 1 Jun 2011 08:59:24 +0000 (UTC) Received: by pwj8 with SMTP id 8so3093945pwj.13 for ; Wed, 01 Jun 2011 01:59:23 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.35.198 with SMTP id k6mr2900408pbj.460.1306917371282; Wed, 01 Jun 2011 01:36:11 -0700 (PDT) Received: by 10.68.54.66 with HTTP; Wed, 1 Jun 2011 01:36:11 -0700 (PDT) In-Reply-To: <20110601014933.GA12940@icarus.home.lan> References: <20110601014933.GA12940@icarus.home.lan> Date: Wed, 1 Jun 2011 10:36:11 +0200 Message-ID: From: Olivier Smedts To: Jeremy Chadwick Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: FreeBSD-STABLE Mailing List Subject: Re: [ZFSv28]gtpzfsboot fails to boot ZFSv28 0511 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 01 Jun 2011 08:59:24 -0000 2011/6/1 Jeremy Chadwick : > On Tue, May 31, 2011 at 08:15:35PM -0500, Zhihao Yuan wrote: >> I met this problem, which is serious. I need some help to recovered >> the system, after that I'll show the photos about the error screen. >> >> I used the ZFSv28 patch maintained by mm@ before, and I have a >> backuped working kernel. I need a LiveCD/memstick to boot the system >> and recover it. But after I burned the 9.0-current image to memstick, >> I found that it keeps giving me kernel panic when booting! How can I >> find a LiveFS with ZFSv28 support? Thanks. > > The closest thing I can think of is this: > > http://mfsbsd.vx.sk/ I had a problem with latest gptzfsboot under 9-CURRENT with my v28 pool, and restored the old gptzfsboot I had on a snapshot with "gpart bootcode" thanks to mfsbsd. > Except: > > 1) The ISOs there don't claim to be "LiveFS"; I don't know if they are. > 2) There's no memory stick image available, only ISOs, > 3) They're 8.2-RELEASE with ZFSv28 patches, not 9.0-CURRENT. =A0I don't > =A0 know the implications of this. > > Best to ask mm@. > > -- > | Jeremy Chadwick =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 jdc@parodius.com | > | Parodius Networking =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 http://= www.parodius.com/ | > | UNIX Systems Administrator =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Mountain = View, CA, USA | > | Making life hard for others since 1977. =A0 =A0 =A0 =A0 =A0 =A0 =A0 PGP= 4BD6C0CB | > > _______________________________________________ > 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 Olivier Smedts=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=A0 _ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 ASCII ribbon campaign ( ) e-mail: olivier@gid0.org=A0 =A0 =A0 =A0 - against HTML email & vCards=A0 X www: http://www.gid0.org=A0 =A0 - against proprietary attachments / \ =A0 "Il y a seulement 10 sortes de gens dans le monde : =A0 ceux qui comprennent le binaire, =A0 et ceux qui ne le comprennent pas." From owner-freebsd-stable@FreeBSD.ORG Wed Jun 1 09:25:24 2011 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3ECFA1065676; Wed, 1 Jun 2011 09:25:24 +0000 (UTC) (envelope-from Holger.Kipp@alogis.com) Received: from alogis.com (firewall.solit-ag.de [212.184.102.1]) by mx1.freebsd.org (Postfix) with ESMTP id 581308FC12; Wed, 1 Jun 2011 09:25:23 +0000 (UTC) Received: from msx3.exchange.alogis.com (exchange.alogis.com [10.1.1.6]) by alogis.com (8.13.4/8.13.1) with ESMTP id p519PMaL020585; Wed, 1 Jun 2011 11:25:22 +0200 (CEST) (envelope-from Holger.Kipp@alogis.com) Received: from MSX3.exchange.alogis.com ([fe80::c8ed:428a:a157:b61]) by msx3.exchange.alogis.com ([fe80::c8ed:428a:a157:b61%13]) with mapi id 14.01.0255.000; Wed, 1 Jun 2011 11:26:06 +0200 From: Holger Kipp To: Jeremy Chadwick Thread-Topic: 8-STABLE won't boot with ZFSv28 Thread-Index: AcwgMDZpIyhysR9GQjKr1bi0oNTyx///8TIAgAAnkMY= Date: Wed, 1 Jun 2011 09:26:05 +0000 Message-ID: <814C9E9472FDCC40AAC3FC95A2D67E3B0BD88DC0@msx3.exchange.alogis.com> References: <814C9E9472FDCC40AAC3FC95A2D67E3B0BD88C69@msx3.exchange.alogis.com>, <20110601085454.GA19434@icarus.home.lan> In-Reply-To: <20110601085454.GA19434@icarus.home.lan> Accept-Language: en-GB, de-DE, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [212.184.101.130] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "stable@freebsd.org" , "mav@freebsd.org" Subject: RE: 8-STABLE won't boot with ZFSv28 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 01 Jun 2011 09:25:24 -0000 Jeremy Chadwick [freebsd@jdc.parodius.com] wrote on 01 June 2011 10:54 >On Wed, Jun 01, 2011 at 08:23:19AM +0000, Holger Kipp wrote: >> I have a very irritating problem with 8-STABLE and ZFSv28 >> >> I upgraded to 8-STABLE as of yesterday (31.05.2011), >> downloaded stable-8-zfsv28-20110521.patch.xz >> and applied the patch using >> >> cd /usr/src >> patch -E -p0 < /path/to/patchfile >> make buildworld >> make buildkernel KERNCONF=3Dfoo >> make installkernel KERNCONF=3Dfoo >> make installworld >> mergemaster >> >> which all went smoothly. >> >> After reboot, I only got >> unknown: WARNING - ATAPI_IDENTITFY requeued due to channel reset LBA=3D0 >> all the time, and then after an hour or so (wasn't on site), >> system gave >> Fatal trap 12: page fault while in kernel mode >> cupid - 0; apic id =3D 00 >> fault virtual address =3D 0x8 >> fault code =3D supervisor read data, page not pres= ent >> instruction pointer =3D 0x20:0xffffffff80252301 >> stack poiner =3D 0x28:0xffffff80000a7ac0 >> frame pointer =3D 0x28:0xffffff80000a7b00 >> code segment =3D base 0x0, limit 0xfffff, type 0x1b >> =3D DPL 0, pres1, long 1,= def32 0, gran 1 >> processor eflags =3D interrupt enabled, resume, IOPL =3D 0 >> current process =3D 0 (thread taskq)trap number = =3D 12 >> panic: page fault >> cpuid =3D 0 >> Uptime: 1h0m13s >> Cannot dump. Device not defined or unavailable. >> Automatic reboot in 15 seconds - press a key on the console to abort >> >> Needless to say the system did not reboot. Had to powercycle. >> >> Then always got the >> unknown: WARNING - ATAPI_IDENTITFY requeued due to channel reset LBA=3D0 >> error about once per second. >> >> Have now used a fixit-disk to change back to the old kernel: >> FreeBSD 8.2-STABLE #12: Mon Apr 18 12:48:56 CEST 2011 >> and rebootet. >> Now zfs claims to be v28, current storage pool is at 15.I'd love to >> try ZFSv28, but with the old kernel I don't think >> this is a good idea - but with the new kernel it seems I can't >> even boot properly. >> Any suggestions as to how to proceed? > I think this is much more likely related to an ATA/ATAPI-related change > that was committed on April 17th recently and is not related to ZFSv28. > Please see this thread: > > * 2011/05/29 -- ICH9 panic/instability on recent kernel > http://lists.freebsd.org/pipermail/freebsd-stable/2011-May/thread.html#= 62804 > > Holger, can you please provide the following two things? > > 1) Output from "pciconf -lvcb". That's an easy one: hostb0@pci0:0:0:0: class=3D0x060000 card=3D0xd28015d9 chip=3D0x29f0808= 6 rev=3D0x01 hdr=3D0x00 vendor =3D 'Intel Corporation' device =3D '3200 Chipset (Bearlake) Processor to I/O Controller' class =3D bridge subclass =3D HOST-PCI cap 09[e0] =3D vendor (length 12) Intel cap 9 version 1 pcib1@pci0:0:1:0: class=3D0x060400 card=3D0xd28015d9 chip=3D0x29f1808= 6 rev=3D0x01 hdr=3D0x01 vendor =3D 'Intel Corporation' device =3D '3200 Chipset (Bearlake) PCIe Root Port 1' class =3D bridge subclass =3D PCI-PCI cap 0d[88] =3D PCI Bridge card=3D0xd28015d9 cap 01[80] =3D powerspec 3 supports D0 D3 current D0 cap 05[90] =3D MSI supports 1 message cap 10[a0] =3D PCI-Express 2 root port max data 128(128) link x8(x16) ecap 0002[100] =3D VC 1 max VC0 ecap 0005[140] =3D unknown 1 uhci0@pci0:0:26:0: class=3D0x0c0300 card=3D0xd28015d9 chip=3D0x2937808= 6 rev=3D0x02 hdr=3D0x00 vendor =3D 'Intel Corporation' device =3D '82801IB/IR/IH (ICH9 Family) USB Universal Host Controll= er' class =3D serial bus subclass =3D USB bar [20] =3D type I/O Port, range 32, base 0x1820, size 32, enabled cap 13[50] =3D PCI Advanced Features: FLR TP uhci1@pci0:0:26:1: class=3D0x0c0300 card=3D0xd28015d9 chip=3D0x2938808= 6 rev=3D0x02 hdr=3D0x00 vendor =3D 'Intel Corporation' device =3D '82801IB/IR/IH (ICH9 Family) USB Universal Host Controll= er' class =3D serial bus subclass =3D USB bar [20] =3D type I/O Port, range 32, base 0x1840, size 32, enabled cap 13[50] =3D PCI Advanced Features: FLR TP uhci2@pci0:0:26:2: class=3D0x0c0300 card=3D0xd28015d9 chip=3D0x2939808= 6 rev=3D0x02 hdr=3D0x00 vendor =3D 'Intel Corporation' device =3D '82801IB/IR/IH (ICH9 Family) USB Universal Host Controll= er' class =3D serial bus subclass =3D USB bar [20] =3D type I/O Port, range 32, base 0x1860, size 32, enabled cap 13[50] =3D PCI Advanced Features: FLR TP ehci0@pci0:0:26:7: class=3D0x0c0320 card=3D0xd28015d9 chip=3D0x293c808= 6 rev=3D0x02 hdr=3D0x00 vendor =3D 'Intel Corporation' device =3D '82801IB/IR/IH (ICH9 Family) USB2 Enhanced Host Controll= er' class =3D serial bus subclass =3D USB bar [10] =3D type Memory, range 32, base 0xd9001000, size 1024, enabl= ed cap 01[50] =3D powerspec 2 supports D0 D3 current D0 cap 0a[58] =3D EHCI Debug Port at offset 0xa0 in map 0x14 cap 13[98] =3D PCI Advanced Features: FLR TP pcib4@pci0:0:28:0: class=3D0x060400 card=3D0xd28015d9 chip=3D0x2940808= 6 rev=3D0x02 hdr=3D0x01 vendor =3D 'Intel Corporation' device =3D '82801IB/IR/IH (ICH9 Family) PCIe Root Port 1' class =3D bridge subclass =3D PCI-PCI cap 10[40] =3D PCI-Express 1 root port max data 128(128) link x4(x4) cap 05[80] =3D MSI supports 1 message cap 0d[90] =3D PCI Bridge card=3D0xd28015d9 cap 01[a0] =3D powerspec 2 supports D0 D3 current D0 ecap 0002[100] =3D VC 1 max VC0 ecap 0005[180] =3D unknown 1 pcib5@pci0:0:28:4: class=3D0x060400 card=3D0xd28015d9 chip=3D0x2948808= 6 rev=3D0x02 hdr=3D0x01 vendor =3D 'Intel Corporation' device =3D '82801IB/IR/IH (ICH9 Family) PCIe Root Port 5' class =3D bridge subclass =3D PCI-PCI cap 10[40] =3D PCI-Express 1 root port max data 128(128) link x1(x1) cap 05[80] =3D MSI supports 1 message cap 0d[90] =3D PCI Bridge card=3D0xd28015d9 cap 01[a0] =3D powerspec 2 supports D0 D3 current D0 ecap 0002[100] =3D VC 1 max VC0 ecap 0005[180] =3D unknown 1 pcib6@pci0:0:28:5: class=3D0x060400 card=3D0xd28015d9 chip=3D0x294a808= 6 rev=3D0x02 hdr=3D0x01 vendor =3D 'Intel Corporation' device =3D '82801IB/IR/IH (ICH9 Family) PCIe Root Port 6' class =3D bridge subclass =3D PCI-PCI cap 10[40] =3D PCI-Express 1 root port max data 128(128) link x1(x1) cap 05[80] =3D MSI supports 1 message cap 0d[90] =3D PCI Bridge card=3D0xd28015d9 cap 01[a0] =3D powerspec 2 supports D0 D3 current D0 ecap 0002[100] =3D VC 1 max VC0 ecap 0005[180] =3D unknown 1 uhci3@pci0:0:29:0: class=3D0x0c0300 card=3D0xd28015d9 chip=3D0x2934808= 6 rev=3D0x02 hdr=3D0x00 vendor =3D 'Intel Corporation' device =3D '82801IB/IR/IH (ICH9 Family) USB Universal Host Controll= er' class =3D serial bus subclass =3D USB bar [20] =3D type I/O Port, range 32, base 0x1880, size 32, enabled cap 13[50] =3D PCI Advanced Features: FLR TP uhci4@pci0:0:29:1: class=3D0x0c0300 card=3D0xd28015d9 chip=3D0x2935808= 6 rev=3D0x02 hdr=3D0x00 vendor =3D 'Intel Corporation' device =3D '82801IB/IR/IH (ICH9 Family) USB Universal Host Controll= er' class =3D serial bus subclass =3D USB bar [20] =3D type I/O Port, range 32, base 0x18a0, size 32, enabled cap 13[50] =3D PCI Advanced Features: FLR TP uhci5@pci0:0:29:2: class=3D0x0c0300 card=3D0xd28015d9 chip=3D0x2936808= 6 rev=3D0x02 hdr=3D0x00 vendor =3D 'Intel Corporation' device =3D '82801IB/IR/IH (ICH9 Family) USB Universal Host Controll= er' class =3D serial bus subclass =3D USB bar [20] =3D type I/O Port, range 32, base 0x18c0, size 32, enabled cap 13[50] =3D PCI Advanced Features: FLR TP ehci1@pci0:0:29:7: class=3D0x0c0320 card=3D0xd28015d9 chip=3D0x293a808= 6 rev=3D0x02 hdr=3D0x00 vendor =3D 'Intel Corporation' device =3D '82801IB/IR/IH (ICH9 Family) USB2 Enhanced Host Controll= er' class =3D serial bus subclass =3D USB bar [10] =3D type Memory, range 32, base 0xd9001400, size 1024, enabl= ed cap 01[50] =3D powerspec 2 supports D0 D3 current D0 cap 0a[58] =3D EHCI Debug Port at offset 0xa0 in map 0x14 cap 13[98] =3D PCI Advanced Features: FLR TP pcib7@pci0:0:30:0: class=3D0x060401 card=3D0xd28015d9 chip=3D0x244e808= 6 rev=3D0x92 hdr=3D0x01 vendor =3D 'Intel Corporation' device =3D '82801 Family (ICH2/3/4/5/6/7/8/9,63xxESB) Hub Interface= to PCI Bridge' class =3D bridge subclass =3D PCI-PCI cap 0d[50] =3D PCI Bridge card=3D0xd28015d9 isab0@pci0:0:31:0: class=3D0x060100 card=3D0xd28015d9 chip=3D0x2916808= 6 rev=3D0x02 hdr=3D0x00 vendor =3D 'Intel Corporation' device =3D '82801IR (ICH9R) LPC Interface Controller' class =3D bridge subclass =3D PCI-ISA cap 09[e0] =3D vendor (length 12) Intel cap 1 version 0 features: SATA RAID-5, 4 PCI-e x1 slots atapci0@pci0:0:31:2: class=3D0x01018a card=3D0xd28015d9 chip=3D0x2920808= 6 rev=3D0x02 hdr=3D0x00 vendor =3D 'Intel Corporation' device =3D '82801IB/IR/IH (ICH9 Family) 4 port Serial ATA Storage C= ontroller 1' class =3D mass storage subclass =3D ATA bar [10] =3D type I/O Port, range 32, base 0x1f0, size 8, enabled bar [14] =3D type I/O Port, range 32, base 0x3f4, size 1, enabled bar [18] =3D type I/O Port, range 32, base 0x170, size 8, enabled bar [1c] =3D type I/O Port, range 32, base 0x374, size 1, enabled bar [20] =3D type I/O Port, range 32, base 0x1c10, size 16, enabled bar [24] =3D type I/O Port, range 32, base 0x1c00, size 16, enabled cap 01[70] =3D powerspec 3 supports D0 D3 current D0 cap 13[b0] =3D PCI Advanced Features: FLR TP none0@pci0:0:31:3: class=3D0x0c0500 card=3D0xd28015d9 chip=3D0x2930808= 6 rev=3D0x02 hdr=3D0x00 vendor =3D 'Intel Corporation' device =3D 'Intel(R) ICH9 Family SMBus Controller working fine with= http://download.cnet.com/Chipset-Driver-Inte (8086)' class =3D serial bus subclass =3D SMBus bar [10] =3D type Memory, range 64, base 0xd9001800, size 256, enable= d bar [20] =3D type I/O Port, range 32, base 0x1100, size 32, enabled atapci1@pci0:0:31:5: class=3D0x010185 card=3D0xd28015d9 chip=3D0x2926808= 6 rev=3D0x02 hdr=3D0x00 vendor =3D 'Intel Corporation' device =3D '82801IB/IR/IH (ICH9 Family) 2 port Serial ATA Storage C= ontroller 2' class =3D mass storage subclass =3D ATA bar [10] =3D type I/O Port, range 32, base 0x1c68, size 8, enabled bar [14] =3D type I/O Port, range 32, base 0x1c5c, size 4, enabled bar [18] =3D type I/O Port, range 32, base 0x1c60, size 8, enabled bar [1c] =3D type I/O Port, range 32, base 0x1c58, size 4, enabled bar [20] =3D type I/O Port, range 32, base 0x1c30, size 16, enabled bar [24] =3D type I/O Port, range 32, base 0x1c20, size 16, enabled cap 01[70] =3D powerspec 3 supports D0 D3 current D0 cap 13[b0] =3D PCI Advanced Features: FLR TP none1@pci0:0:31:6: class=3D0x118000 card=3D0x000015d9 chip=3D0x2932808= 6 rev=3D0x02 hdr=3D0x00 vendor =3D 'Intel Corporation' device =3D '82801IB/IR/IH (ICH9 Family) Thermal Subsystem' class =3D dasp bar [10] =3D type Memory, range 64, base 0xd9000000, size 4096, enabl= ed cap 01[50] =3D powerspec 3 supports D0 D3 current D0 pcib2@pci0:1:0:0: class=3D0x060400 card=3D0x00000000 chip=3D0x0329808= 6 rev=3D0x09 hdr=3D0x01 vendor =3D 'Intel Corporation' device =3D 'PCI Express-to-PCI Express Bridge A (6700PXH)' class =3D bridge subclass =3D PCI-PCI cap 10[44] =3D PCI-Express 1 PCI bridge max data 128(256) link x8(x8) cap 05[5c] =3D MSI supports 1 message, 64 bit cap 01[6c] =3D powerspec 2 supports D0 D3 current D0 cap 07[d8] =3D PCI-X bridge ecap 0001[100] =3D AER 1 0 fatal 1 non-fatal 0 corrected ecap 0004[300] =3D unknown 1 ioapic0@pci0:1:0:1: class=3D0x080020 card=3D0xd28015d9 chip=3D0x0326808= 6 rev=3D0x09 hdr=3D0x00 vendor =3D 'Intel Corporation' device =3D '6700/6702PXH I/OxAPIC Interrupt Controller A' class =3D base peripheral subclass =3D interrupt controller bar [10] =3D type Memory, range 32, base 0xd8900000, size 4096, enabl= ed cap 10[44] =3D PCI-Express 1 endpoint max data 256(256) link x8(x8) cap 01[6c] =3D powerspec 2 supports D0 D3 current D0 pcib3@pci0:1:0:2: class=3D0x060400 card=3D0x00000000 chip=3D0x032a808= 6 rev=3D0x09 hdr=3D0x01 vendor =3D 'Intel Corporation' device =3D 'PCI Express-to-PCI Express Bridge B (6700PXH)' class =3D bridge subclass =3D PCI-PCI cap 10[44] =3D PCI-Express 1 PCI bridge max data 128(256) link x8(x8) cap 05[5c] =3D MSI supports 1 message, 64 bit cap 01[6c] =3D powerspec 2 supports D0 D3 current D0 cap 07[d8] =3D PCI-X bridge ecap 0001[100] =3D AER 1 0 fatal 1 non-fatal 0 corrected ecap 0004[300] =3D unknown 1 ioapic1@pci0:1:0:3: class=3D0x080020 card=3D0xd28015d9 chip=3D0x0327808= 6 rev=3D0x09 hdr=3D0x00 vendor =3D 'Intel Corporation' device =3D 'I/OxAPIC Interrupt Controller B (6700PXH)' class =3D base peripheral subclass =3D interrupt controller bar [10] =3D type Memory, range 32, base 0xd8901000, size 4096, enabl= ed cap 10[44] =3D PCI-Express 1 endpoint max data 256(256) link x8(x8) cap 01[6c] =3D powerspec 2 supports D0 D3 current D0 twe0@pci0:2:1:0: class=3D0x010400 card=3D0x100113c1 chip=3D0x100113c= 1 rev=3D0x01 hdr=3D0x00 vendor =3D '3ware Inc' device =3D 'ATA-133 Storage Controller (7000/8000 series)' class =3D mass storage subclass =3D RAID bar [10] =3D type I/O Port, range 32, base 0x2000, size 16, enabled bar [14] =3D type Memory, range 32, base 0xd8800000, size 16, enabled bar [18] =3D type Memory, range 32, base 0xd8000000, size 8388608, en= abled cap 01[40] =3D powerspec 1 supports D0 D1 D3 current D0 isp0@pci0:5:0:0: class=3D0x0c0400 card=3D0x01371077 chip=3D0x2432107= 7 rev=3D0x03 hdr=3D0x00 vendor =3D 'QLogic Corporation' device =3D 'Dual Channel 4G PCIe Fibre Channel Adapter (ISP2432)' class =3D serial bus subclass =3D Fibre Channel bar [10] =3D type I/O Port, range 32, base 0x3000, size 256, enabled bar [14] =3D type Memory, range 64, base 0xd8b00000, size 16384, enab= led cap 01[44] =3D powerspec 2 supports D0 D3 current D0 cap 10[4c] =3D PCI-Express 1 endpoint max data 128(1024) link x4(x4) cap 05[64] =3D MSI supports 16 messages, 64 bit enabled with 1 message cap 03[74] =3D VPD cap 11[7c] =3D MSI-X supports 16 messages in map 0x14 ecap 0001[100] =3D AER 1 0 fatal 1 non-fatal 0 corrected ecap 0004[138] =3D unknown 1 em0@pci0:13:0:0: class=3D0x020000 card=3D0x108c15d9 chip=3D0x108c808= 6 rev=3D0x03 hdr=3D0x00 vendor =3D 'Intel Corporation' device =3D 'Intel Corporation 82573E Gigabit Ethernet Controller (C= opper) (82573E)' class =3D network subclass =3D ethernet bar [10] =3D type Memory, range 32, base 0xd8a00000, size 131072, ena= bled bar [18] =3D type I/O Port, range 32, base 0x4000, size 32, enabled cap 01[c8] =3D powerspec 2 supports D0 D3 current D0 cap 05[d0] =3D MSI supports 1 message, 64 bit enabled with 1 message cap 10[e0] =3D PCI-Express 1 endpoint max data 128(256) link x1(x1) ecap 0001[100] =3D AER 1 0 fatal 1 non-fatal 0 corrected ecap 0003[140] =3D Serial 1 003048ffffd21aba em1@pci0:15:0:0: class=3D0x020000 card=3D0x109a15d9 chip=3D0x109a808= 6 rev=3D0x00 hdr=3D0x00 vendor =3D 'Intel Corporation' device =3D 'Intel PRO/1000 PL Network Adaptor (82573L)' class =3D network subclass =3D ethernet bar [10] =3D type Memory, range 32, base 0xd8c00000, size 131072, ena= bled bar [18] =3D type I/O Port, range 32, base 0x5000, size 32, enabled cap 01[c8] =3D powerspec 2 supports D0 D3 current D0 cap 05[d0] =3D MSI supports 1 message, 64 bit enabled with 1 message cap 10[e0] =3D PCI-Express 1 endpoint max data 128(256) link x1(x1) ecap 0001[100] =3D AER 1 0 fatal 1 non-fatal 0 corrected ecap 0003[140] =3D Serial 1 003048ffffd21abb vgapci0@pci0:17:4:0: class=3D0x030000 card=3D0xd28015d9 chip=3D0x515e100= 2 rev=3D0x02 hdr=3D0x00 vendor =3D 'ATI Technologies Inc. / Advanced Micro Devices, Inc.' device =3D 'Radeon ES1000 (Radeon ES1000)' class =3D display subclass =3D VGA bar [10] =3D type Prefetchable Memory, range 32, base 0xd0000000, siz= e 134217728, enabled bar [14] =3D type I/O Port, range 32, base 0x6000, size 256, enabled bar [18] =3D type Memory, range 32, base 0xd8d00000, size 65536, enab= led cap 01[50] =3D powerspec 2 supports D0 D1 D2 D3 current D0 > 2) Full output from a verbose boot (option "5" at the loader prompt). That's a bit more difficult... I'll check, but don't think anything is set = up there to get a meaningful dump or verbose boot information in electronic fo= rm... > I imagine #2 isn't going to work for most users because there's no way > to get pages and pages and pages of data from a panic'd machine without > either serial console (which will require a 2nd machine and possibly a > null-modem cable) or properly setting up a dedicated swap partition and > large-enough /var filesystem, plus their kernel would need DDB support > added to it (so they could properly do "call doadump" then "reboot"). > A workaround which one user has confirmed is to enable AHCI for your > SATA controller in your system BIOS (if such is available). ataahci.ko > will be used (which is AHCI via ATA) and your device names probably > won't change. Alternatively you could enable AHCI and use ahci.ko > (ahci_load=3D"yes" in /boot/loader.conf) to get AHCI via CAM, which > provides NCQ and other features, but your device names will change. > My familiarity with ATAPI is limited however. Will try both if available and let you know the results. > CC'ing mav@ here. > > Alexander, Holger's report looks exactly like Michael's report. > > Possibly we should consider reverting the April 17th commit until we can > figure out what's going on here. Many thanks for your support! Best regards, Holger -- Holger Kipp Diplom-Mathematiker Senior Consultant Tel. : +49 30 436 58 114 Fax. : +49 30 436 58 214 Mobil: +49 178 36 58 114 Email: holger.kipp@alogis.com alogis AG Alt-Moabit 90b D-10559 Berlin web : http://www.alogis.com ---------------------------------------------------------- alogis AG Sitz/Registergericht: Berlin/AG Charlottenburg, HRB 71484 Vorstand: Arne Friedrichs, Joern Samuelson Aufsichtsratsvorsitzender: Reinhard Mielke From owner-freebsd-stable@FreeBSD.ORG Wed Jun 1 09:33:28 2011 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C4AA6106564A for ; Wed, 1 Jun 2011 09:33:26 +0000 (UTC) (envelope-from olivier@gid0.org) Received: from mail-pv0-f182.google.com (mail-pv0-f182.google.com [74.125.83.182]) by mx1.freebsd.org (Postfix) with ESMTP id A58BD8FC15 for ; Wed, 1 Jun 2011 09:33:26 +0000 (UTC) Received: by pvg11 with SMTP id 11so3063520pvg.13 for ; Wed, 01 Jun 2011 02:33:26 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.33.195 with SMTP id t3mr2772257pbi.58.1306919085986; Wed, 01 Jun 2011 02:04:45 -0700 (PDT) Received: by 10.68.54.66 with HTTP; Wed, 1 Jun 2011 02:04:45 -0700 (PDT) In-Reply-To: <20110601083112.GG74833@laa.zp.ua> References: <814C9E9472FDCC40AAC3FC95A2D67E3B0BD88C69@msx3.exchange.alogis.com> <20110601083112.GG74833@laa.zp.ua> Date: Wed, 1 Jun 2011 11:04:45 +0200 Message-ID: From: Olivier Smedts To: Lystopad Olexandr Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "stable@freebsd.org" Subject: Re: 8-STABLE won't boot with ZFSv28 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 01 Jun 2011 09:33:28 -0000 2011/6/1 Lystopad Olexandr : > =A0Hello, Holger Kipp! > > On Wed, Jun 01, 2011 at 08:23:19AM +0000 > Holger.Kipp@alogis.com wrote about "8-STABLE won't boot with ZFSv28": >> Hi all, >> I have a very irritating problem with 8-STABLE and ZFSv28 >> >> I upgraded to 8-STABLE as of yesterday (31.05.2011), >> downloaded stable-8-zfsv28-20110521.patch.xz >> and applied the patch using >> >> cd /usr/src >> patch -E -p0 < /path/to/patchfile >> make buildworld >> make buildkernel KERNCONF=3Dfoo >> make installkernel KERNCONF=3Dfoo >> make installworld >> mergemaster > > Looks like you forgot to update your bootcode. gpart bootcode .... Only necessary if the pool is upgraded, which was not the case. > >> which all went smoothly. >> >> After reboot, I only got >> unknown: WARNING - ATAPI_IDENTITFY requeued due to channel reset LBA=3D0 >> all the time, and then after an hour or so (wasn't on site), >> system gave >> Fatal trap 12: page fault while in kernel mode >> cupid - 0; apic id =3D 00 >> fault virtual address =3D 0x8 >> fault code =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =3D supervisor re= ad data, page not present >> instruction pointer =A0 =A0=3D 0x20:0xffffffff80252301 >> stack poiner =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =3D 0x28:0xffffff80000a= 7ac0 >> frame pointer =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=3D 0x28:0xffffff80000a7b00 >> code segment =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=3D base 0x0, limit 0xfffff,= type 0x1b >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0=3D DPL 0, pres1, long 1, def32 0, gran 1 >> processor eflags =A0 =A0 =A0 =A0 =3D interrupt enabled, resume, IOPL =3D= 0 >> current process =A0 =A0 =A0 =A0 =A0 =3D 0 (thread taskq)trap number =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =3D 12 >> panic: page fault >> cpuid =3D 0 >> Uptime: 1h0m13s >> Cannot dump. Device not defined or unavailable. >> Automatic reboot in 15 seconds - press a key on the console to abort >> >> >> Needless to say the system did not reboot. Had to powercycle. >> >> Then always got the >> unknown: WARNING - ATAPI_IDENTITFY requeued due to channel reset LBA=3D0 >> error about once per second. >> >> Have now used a fixit-disk to change back to the old kernel: >> FreeBSD 8.2-STABLE #12: Mon Apr 18 12:48:56 CEST 2011 >> and rebootet. >> Now zfs claims to be v28, current storage pool is at 15.I'd love to >> try ZFSv28, but with the old kernel I don't think >> this is a good idea - but with the new kernel it seems I can't >> even boot properly. Don't upgrade the pool for now, you have problems to solve first. Then, you'll be able to upgrade the pool, and don't forget to also update the zfs boot code before rebooting (see UPDATING). Don't forget you won't be able to import your (upgraded) v28 pool with a 8.2-RELEASE if you have problems with 8-STABLE ! Also, you can use mfsbsd if you shoot yourself in the foot. >> Any suggestions as to how to proceed? > > -- > =A0Lystopad Olexandr > _______________________________________________ > 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 Olivier Smedts=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=A0 _ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 ASCII ribbon campaign ( ) e-mail: olivier@gid0.org=A0 =A0 =A0 =A0 - against HTML email & vCards=A0 X www: http://www.gid0.org=A0 =A0 - against proprietary attachments / \ =A0 "Il y a seulement 10 sortes de gens dans le monde : =A0 ceux qui comprennent le binaire, =A0 et ceux qui ne le comprennent pas." From owner-freebsd-stable@FreeBSD.ORG Wed Jun 1 09:56:13 2011 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E9FA1106564A for ; Wed, 1 Jun 2011 09:56:13 +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 CED378FC13 for ; Wed, 1 Jun 2011 09:56:13 +0000 (UTC) Received: from omta18.emeryville.ca.mail.comcast.net ([76.96.30.74]) by qmta04.emeryville.ca.mail.comcast.net with comcast id qZuQ1g0031bwxycA4ZwBPn; Wed, 01 Jun 2011 09:56:11 +0000 Received: from koitsu.dyndns.org ([67.180.84.87]) by omta18.emeryville.ca.mail.comcast.net with comcast id qZwC1g0081t3BNj8eZwCPe; Wed, 01 Jun 2011 09:56:13 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id EC2BF102C19; Wed, 1 Jun 2011 02:56:10 -0700 (PDT) Date: Wed, 1 Jun 2011 02:56:10 -0700 From: Jeremy Chadwick To: Holger Kipp Message-ID: <20110601095610.GA20255@icarus.home.lan> References: <814C9E9472FDCC40AAC3FC95A2D67E3B0BD88C69@msx3.exchange.alogis.com> <20110601085454.GA19434@icarus.home.lan> <814C9E9472FDCC40AAC3FC95A2D67E3B0BD88DC0@msx3.exchange.alogis.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <814C9E9472FDCC40AAC3FC95A2D67E3B0BD88DC0@msx3.exchange.alogis.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "stable@freebsd.org" , "mav@freebsd.org" Subject: Re: 8-STABLE won't boot with ZFSv28 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 01 Jun 2011 09:56:14 -0000 On Wed, Jun 01, 2011 at 09:26:05AM +0000, Holger Kipp wrote: > Jeremy Chadwick [freebsd@jdc.parodius.com] wrote on 01 June 2011 10:54 > > >On Wed, Jun 01, 2011 at 08:23:19AM +0000, Holger Kipp wrote: > >> I have a very irritating problem with 8-STABLE and ZFSv28 > >> > >> I upgraded to 8-STABLE as of yesterday (31.05.2011), > >> downloaded stable-8-zfsv28-20110521.patch.xz > >> and applied the patch using > >> > >> cd /usr/src > >> patch -E -p0 < /path/to/patchfile > >> make buildworld > >> make buildkernel KERNCONF=foo > >> make installkernel KERNCONF=foo > >> make installworld > >> mergemaster > >> > >> which all went smoothly. > >> > >> After reboot, I only got > >> unknown: WARNING - ATAPI_IDENTITFY requeued due to channel reset LBA=0 > >> all the time, and then after an hour or so (wasn't on site), > >> system gave > >> Fatal trap 12: page fault while in kernel mode > >> cupid - 0; apic id = 00 > >> fault virtual address = 0x8 > >> fault code = supervisor read data, page not present > >> instruction pointer = 0x20:0xffffffff80252301 > >> stack poiner = 0x28:0xffffff80000a7ac0 > >> frame pointer = 0x28:0xffffff80000a7b00 > >> code segment = base 0x0, limit 0xfffff, type 0x1b > >> = DPL 0, pres1, long 1, def32 0, gran 1 > >> processor eflags = interrupt enabled, resume, IOPL = 0 > >> current process = 0 (thread taskq)trap number = 12 > >> panic: page fault > >> cpuid = 0 > >> Uptime: 1h0m13s > >> Cannot dump. Device not defined or unavailable. > >> Automatic reboot in 15 seconds - press a key on the console to abort > >> > >> Needless to say the system did not reboot. Had to powercycle. > >> > >> Then always got the > >> unknown: WARNING - ATAPI_IDENTITFY requeued due to channel reset LBA=0 > >> error about once per second. > >> > >> Have now used a fixit-disk to change back to the old kernel: > >> FreeBSD 8.2-STABLE #12: Mon Apr 18 12:48:56 CEST 2011 > >> and rebootet. > >> Now zfs claims to be v28, current storage pool is at 15.I'd love to > >> try ZFSv28, but with the old kernel I don't think > >> this is a good idea - but with the new kernel it seems I can't > >> even boot properly. > >> Any suggestions as to how to proceed? > > > I think this is much more likely related to an ATA/ATAPI-related change > > that was committed on April 17th recently and is not related to ZFSv28. > > Please see this thread: > > > > * 2011/05/29 -- ICH9 panic/instability on recent kernel > > http://lists.freebsd.org/pipermail/freebsd-stable/2011-May/thread.html#62804 > > > > Holger, can you please provide the following two things? > > > > 1) Output from "pciconf -lvcb". > > That's an easy one: > > hostb0@pci0:0:0:0: class=0x060000 card=0xd28015d9 chip=0x29f08086 rev=0x01 hdr=0x00 > vendor = 'Intel Corporation' > device = '3200 Chipset (Bearlake) Processor to I/O Controller' > class = bridge > subclass = HOST-PCI > cap 09[e0] = vendor (length 12) Intel cap 9 version 1 > pcib1@pci0:0:1:0: class=0x060400 card=0xd28015d9 chip=0x29f18086 rev=0x01 hdr=0x01 > vendor = 'Intel Corporation' > device = '3200 Chipset (Bearlake) PCIe Root Port 1' > class = bridge > subclass = PCI-PCI > cap 0d[88] = PCI Bridge card=0xd28015d9 > cap 01[80] = powerspec 3 supports D0 D3 current D0 > cap 05[90] = MSI supports 1 message > cap 10[a0] = PCI-Express 2 root port max data 128(128) link x8(x16) > ecap 0002[100] = VC 1 max VC0 > ecap 0005[140] = unknown 1 > uhci0@pci0:0:26:0: class=0x0c0300 card=0xd28015d9 chip=0x29378086 rev=0x02 hdr=0x00 > vendor = 'Intel Corporation' > device = '82801IB/IR/IH (ICH9 Family) USB Universal Host Controller' > class = serial bus > subclass = USB > bar [20] = type I/O Port, range 32, base 0x1820, size 32, enabled > cap 13[50] = PCI Advanced Features: FLR TP > uhci1@pci0:0:26:1: class=0x0c0300 card=0xd28015d9 chip=0x29388086 rev=0x02 hdr=0x00 > vendor = 'Intel Corporation' > device = '82801IB/IR/IH (ICH9 Family) USB Universal Host Controller' > class = serial bus > subclass = USB > bar [20] = type I/O Port, range 32, base 0x1840, size 32, enabled > cap 13[50] = PCI Advanced Features: FLR TP > uhci2@pci0:0:26:2: class=0x0c0300 card=0xd28015d9 chip=0x29398086 rev=0x02 hdr=0x00 > vendor = 'Intel Corporation' > device = '82801IB/IR/IH (ICH9 Family) USB Universal Host Controller' > class = serial bus > subclass = USB > bar [20] = type I/O Port, range 32, base 0x1860, size 32, enabled > cap 13[50] = PCI Advanced Features: FLR TP > ehci0@pci0:0:26:7: class=0x0c0320 card=0xd28015d9 chip=0x293c8086 rev=0x02 hdr=0x00 > vendor = 'Intel Corporation' > device = '82801IB/IR/IH (ICH9 Family) USB2 Enhanced Host Controller' > class = serial bus > subclass = USB > bar [10] = type Memory, range 32, base 0xd9001000, size 1024, enabled > cap 01[50] = powerspec 2 supports D0 D3 current D0 > cap 0a[58] = EHCI Debug Port at offset 0xa0 in map 0x14 > cap 13[98] = PCI Advanced Features: FLR TP > pcib4@pci0:0:28:0: class=0x060400 card=0xd28015d9 chip=0x29408086 rev=0x02 hdr=0x01 > vendor = 'Intel Corporation' > device = '82801IB/IR/IH (ICH9 Family) PCIe Root Port 1' > class = bridge > subclass = PCI-PCI > cap 10[40] = PCI-Express 1 root port max data 128(128) link x4(x4) > cap 05[80] = MSI supports 1 message > cap 0d[90] = PCI Bridge card=0xd28015d9 > cap 01[a0] = powerspec 2 supports D0 D3 current D0 > ecap 0002[100] = VC 1 max VC0 > ecap 0005[180] = unknown 1 > pcib5@pci0:0:28:4: class=0x060400 card=0xd28015d9 chip=0x29488086 rev=0x02 hdr=0x01 > vendor = 'Intel Corporation' > device = '82801IB/IR/IH (ICH9 Family) PCIe Root Port 5' > class = bridge > subclass = PCI-PCI > cap 10[40] = PCI-Express 1 root port max data 128(128) link x1(x1) > cap 05[80] = MSI supports 1 message > cap 0d[90] = PCI Bridge card=0xd28015d9 > cap 01[a0] = powerspec 2 supports D0 D3 current D0 > ecap 0002[100] = VC 1 max VC0 > ecap 0005[180] = unknown 1 > pcib6@pci0:0:28:5: class=0x060400 card=0xd28015d9 chip=0x294a8086 rev=0x02 hdr=0x01 > vendor = 'Intel Corporation' > device = '82801IB/IR/IH (ICH9 Family) PCIe Root Port 6' > class = bridge > subclass = PCI-PCI > cap 10[40] = PCI-Express 1 root port max data 128(128) link x1(x1) > cap 05[80] = MSI supports 1 message > cap 0d[90] = PCI Bridge card=0xd28015d9 > cap 01[a0] = powerspec 2 supports D0 D3 current D0 > ecap 0002[100] = VC 1 max VC0 > ecap 0005[180] = unknown 1 > uhci3@pci0:0:29:0: class=0x0c0300 card=0xd28015d9 chip=0x29348086 rev=0x02 hdr=0x00 > vendor = 'Intel Corporation' > device = '82801IB/IR/IH (ICH9 Family) USB Universal Host Controller' > class = serial bus > subclass = USB > bar [20] = type I/O Port, range 32, base 0x1880, size 32, enabled > cap 13[50] = PCI Advanced Features: FLR TP > uhci4@pci0:0:29:1: class=0x0c0300 card=0xd28015d9 chip=0x29358086 rev=0x02 hdr=0x00 > vendor = 'Intel Corporation' > device = '82801IB/IR/IH (ICH9 Family) USB Universal Host Controller' > class = serial bus > subclass = USB > bar [20] = type I/O Port, range 32, base 0x18a0, size 32, enabled > cap 13[50] = PCI Advanced Features: FLR TP > uhci5@pci0:0:29:2: class=0x0c0300 card=0xd28015d9 chip=0x29368086 rev=0x02 hdr=0x00 > vendor = 'Intel Corporation' > device = '82801IB/IR/IH (ICH9 Family) USB Universal Host Controller' > class = serial bus > subclass = USB > bar [20] = type I/O Port, range 32, base 0x18c0, size 32, enabled > cap 13[50] = PCI Advanced Features: FLR TP > ehci1@pci0:0:29:7: class=0x0c0320 card=0xd28015d9 chip=0x293a8086 rev=0x02 hdr=0x00 > vendor = 'Intel Corporation' > device = '82801IB/IR/IH (ICH9 Family) USB2 Enhanced Host Controller' > class = serial bus > subclass = USB > bar [10] = type Memory, range 32, base 0xd9001400, size 1024, enabled > cap 01[50] = powerspec 2 supports D0 D3 current D0 > cap 0a[58] = EHCI Debug Port at offset 0xa0 in map 0x14 > cap 13[98] = PCI Advanced Features: FLR TP > pcib7@pci0:0:30:0: class=0x060401 card=0xd28015d9 chip=0x244e8086 rev=0x92 hdr=0x01 > vendor = 'Intel Corporation' > device = '82801 Family (ICH2/3/4/5/6/7/8/9,63xxESB) Hub Interface to PCI Bridge' > class = bridge > subclass = PCI-PCI > cap 0d[50] = PCI Bridge card=0xd28015d9 > isab0@pci0:0:31:0: class=0x060100 card=0xd28015d9 chip=0x29168086 rev=0x02 hdr=0x00 > vendor = 'Intel Corporation' > device = '82801IR (ICH9R) LPC Interface Controller' > class = bridge > subclass = PCI-ISA > cap 09[e0] = vendor (length 12) Intel cap 1 version 0 > features: SATA RAID-5, 4 PCI-e x1 slots > atapci0@pci0:0:31:2: class=0x01018a card=0xd28015d9 chip=0x29208086 rev=0x02 hdr=0x00 > vendor = 'Intel Corporation' > device = '82801IB/IR/IH (ICH9 Family) 4 port Serial ATA Storage Controller 1' > class = mass storage > subclass = ATA > bar [10] = type I/O Port, range 32, base 0x1f0, size 8, enabled > bar [14] = type I/O Port, range 32, base 0x3f4, size 1, enabled > bar [18] = type I/O Port, range 32, base 0x170, size 8, enabled > bar [1c] = type I/O Port, range 32, base 0x374, size 1, enabled > bar [20] = type I/O Port, range 32, base 0x1c10, size 16, enabled > bar [24] = type I/O Port, range 32, base 0x1c00, size 16, enabled > cap 01[70] = powerspec 3 supports D0 D3 current D0 > cap 13[b0] = PCI Advanced Features: FLR TP > none0@pci0:0:31:3: class=0x0c0500 card=0xd28015d9 chip=0x29308086 rev=0x02 hdr=0x00 > vendor = 'Intel Corporation' > device = 'Intel(R) ICH9 Family SMBus Controller working fine with http://download.cnet.com/Chipset-Driver-Inte (8086)' > class = serial bus > subclass = SMBus > bar [10] = type Memory, range 64, base 0xd9001800, size 256, enabled > bar [20] = type I/O Port, range 32, base 0x1100, size 32, enabled > atapci1@pci0:0:31:5: class=0x010185 card=0xd28015d9 chip=0x29268086 rev=0x02 hdr=0x00 > vendor = 'Intel Corporation' > device = '82801IB/IR/IH (ICH9 Family) 2 port Serial ATA Storage Controller 2' > class = mass storage > subclass = ATA > bar [10] = type I/O Port, range 32, base 0x1c68, size 8, enabled > bar [14] = type I/O Port, range 32, base 0x1c5c, size 4, enabled > bar [18] = type I/O Port, range 32, base 0x1c60, size 8, enabled > bar [1c] = type I/O Port, range 32, base 0x1c58, size 4, enabled > bar [20] = type I/O Port, range 32, base 0x1c30, size 16, enabled > bar [24] = type I/O Port, range 32, base 0x1c20, size 16, enabled > cap 01[70] = powerspec 3 supports D0 D3 current D0 > cap 13[b0] = PCI Advanced Features: FLR TP > none1@pci0:0:31:6: class=0x118000 card=0x000015d9 chip=0x29328086 rev=0x02 hdr=0x00 > vendor = 'Intel Corporation' > device = '82801IB/IR/IH (ICH9 Family) Thermal Subsystem' > class = dasp > bar [10] = type Memory, range 64, base 0xd9000000, size 4096, enabled > cap 01[50] = powerspec 3 supports D0 D3 current D0 > pcib2@pci0:1:0:0: class=0x060400 card=0x00000000 chip=0x03298086 rev=0x09 hdr=0x01 > vendor = 'Intel Corporation' > device = 'PCI Express-to-PCI Express Bridge A (6700PXH)' > class = bridge > subclass = PCI-PCI > cap 10[44] = PCI-Express 1 PCI bridge max data 128(256) link x8(x8) > cap 05[5c] = MSI supports 1 message, 64 bit > cap 01[6c] = powerspec 2 supports D0 D3 current D0 > cap 07[d8] = PCI-X bridge > ecap 0001[100] = AER 1 0 fatal 1 non-fatal 0 corrected > ecap 0004[300] = unknown 1 > ioapic0@pci0:1:0:1: class=0x080020 card=0xd28015d9 chip=0x03268086 rev=0x09 hdr=0x00 > vendor = 'Intel Corporation' > device = '6700/6702PXH I/OxAPIC Interrupt Controller A' > class = base peripheral > subclass = interrupt controller > bar [10] = type Memory, range 32, base 0xd8900000, size 4096, enabled > cap 10[44] = PCI-Express 1 endpoint max data 256(256) link x8(x8) > cap 01[6c] = powerspec 2 supports D0 D3 current D0 > pcib3@pci0:1:0:2: class=0x060400 card=0x00000000 chip=0x032a8086 rev=0x09 hdr=0x01 > vendor = 'Intel Corporation' > device = 'PCI Express-to-PCI Express Bridge B (6700PXH)' > class = bridge > subclass = PCI-PCI > cap 10[44] = PCI-Express 1 PCI bridge max data 128(256) link x8(x8) > cap 05[5c] = MSI supports 1 message, 64 bit > cap 01[6c] = powerspec 2 supports D0 D3 current D0 > cap 07[d8] = PCI-X bridge > ecap 0001[100] = AER 1 0 fatal 1 non-fatal 0 corrected > ecap 0004[300] = unknown 1 > ioapic1@pci0:1:0:3: class=0x080020 card=0xd28015d9 chip=0x03278086 rev=0x09 hdr=0x00 > vendor = 'Intel Corporation' > device = 'I/OxAPIC Interrupt Controller B (6700PXH)' > class = base peripheral > subclass = interrupt controller > bar [10] = type Memory, range 32, base 0xd8901000, size 4096, enabled > cap 10[44] = PCI-Express 1 endpoint max data 256(256) link x8(x8) > cap 01[6c] = powerspec 2 supports D0 D3 current D0 > twe0@pci0:2:1:0: class=0x010400 card=0x100113c1 chip=0x100113c1 rev=0x01 hdr=0x00 > vendor = '3ware Inc' > device = 'ATA-133 Storage Controller (7000/8000 series)' > class = mass storage > subclass = RAID > bar [10] = type I/O Port, range 32, base 0x2000, size 16, enabled > bar [14] = type Memory, range 32, base 0xd8800000, size 16, enabled > bar [18] = type Memory, range 32, base 0xd8000000, size 8388608, enabled > cap 01[40] = powerspec 1 supports D0 D1 D3 current D0 > isp0@pci0:5:0:0: class=0x0c0400 card=0x01371077 chip=0x24321077 rev=0x03 hdr=0x00 > vendor = 'QLogic Corporation' > device = 'Dual Channel 4G PCIe Fibre Channel Adapter (ISP2432)' > class = serial bus > subclass = Fibre Channel > bar [10] = type I/O Port, range 32, base 0x3000, size 256, enabled > bar [14] = type Memory, range 64, base 0xd8b00000, size 16384, enabled > cap 01[44] = powerspec 2 supports D0 D3 current D0 > cap 10[4c] = PCI-Express 1 endpoint max data 128(1024) link x4(x4) > cap 05[64] = MSI supports 16 messages, 64 bit enabled with 1 message > cap 03[74] = VPD > cap 11[7c] = MSI-X supports 16 messages in map 0x14 > ecap 0001[100] = AER 1 0 fatal 1 non-fatal 0 corrected > ecap 0004[138] = unknown 1 > em0@pci0:13:0:0: class=0x020000 card=0x108c15d9 chip=0x108c8086 rev=0x03 hdr=0x00 > vendor = 'Intel Corporation' > device = 'Intel Corporation 82573E Gigabit Ethernet Controller (Copper) (82573E)' > class = network > subclass = ethernet > bar [10] = type Memory, range 32, base 0xd8a00000, size 131072, enabled > bar [18] = type I/O Port, range 32, base 0x4000, size 32, enabled > cap 01[c8] = powerspec 2 supports D0 D3 current D0 > cap 05[d0] = MSI supports 1 message, 64 bit enabled with 1 message > cap 10[e0] = PCI-Express 1 endpoint max data 128(256) link x1(x1) > ecap 0001[100] = AER 1 0 fatal 1 non-fatal 0 corrected > ecap 0003[140] = Serial 1 003048ffffd21aba > em1@pci0:15:0:0: class=0x020000 card=0x109a15d9 chip=0x109a8086 rev=0x00 hdr=0x00 > vendor = 'Intel Corporation' > device = 'Intel PRO/1000 PL Network Adaptor (82573L)' > class = network > subclass = ethernet > bar [10] = type Memory, range 32, base 0xd8c00000, size 131072, enabled > bar [18] = type I/O Port, range 32, base 0x5000, size 32, enabled > cap 01[c8] = powerspec 2 supports D0 D3 current D0 > cap 05[d0] = MSI supports 1 message, 64 bit enabled with 1 message > cap 10[e0] = PCI-Express 1 endpoint max data 128(256) link x1(x1) > ecap 0001[100] = AER 1 0 fatal 1 non-fatal 0 corrected > ecap 0003[140] = Serial 1 003048ffffd21abb > vgapci0@pci0:17:4:0: class=0x030000 card=0xd28015d9 chip=0x515e1002 rev=0x02 hdr=0x00 > vendor = 'ATI Technologies Inc. / Advanced Micro Devices, Inc.' > device = 'Radeon ES1000 (Radeon ES1000)' > class = display > subclass = VGA > bar [10] = type Prefetchable Memory, range 32, base 0xd0000000, size 134217728, enabled > bar [14] = type I/O Port, range 32, base 0x6000, size 256, enabled > bar [18] = type Memory, range 32, base 0xd8d00000, size 65536, enabled > cap 01[50] = powerspec 2 supports D0 D1 D2 D3 current D0 > > > > 2) Full output from a verbose boot (option "5" at the loader prompt). > > That's a bit more difficult... I'll check, but don't think anything is set up > there to get a meaningful dump or verbose boot information in electronic form... > > > I imagine #2 isn't going to work for most users because there's no way > > to get pages and pages and pages of data from a panic'd machine without > > either serial console (which will require a 2nd machine and possibly a > > null-modem cable) or properly setting up a dedicated swap partition and > > large-enough /var filesystem, plus their kernel would need DDB support > > added to it (so they could properly do "call doadump" then "reboot"). By the way, regarding this specific explanation -- you'll need dumpdev="auto" in rc.conf for this to work, plus after the panic will need to ensure that the very next kernel which boots can work reliably. I'll explain how I'd go about this -- there may be an easier way, but it's what I'd do. - Adjust your kernel config to include these options: options KDB # Enable kernel debugger support options KDB_TRACE # Print stack trace automatically on panic options DDB # Support DDB options GDB # Support remote GDB options MSGBUF_SIZE=262144 # Increase kern.msgbufsize from 64K to 256K - Make sure you have a dedicated swap partition, and /var big enough to hold a kernel panic (panic will probably be ~1-2GB in size). Or make a new filesystem for /var/crash (if so, be sure to copy over /var/crash/minfree!) - Add dumpdev="auto" to /etc/rc.conf. - Add ddb_enable="yes" to /etc/rc.conf. - Revert /usr/src to RELENG_8 dated April 16th or earlier. You can accomplish this using "date=YYYY.MM.DD.hh.mm.ss" in your csup file. See csup(1) man page for details. I imagine svn has a better way to do this, but I don't use it. - Rebuild world/kernel per instructions in /usr/src/Makefile. This will get you a kernel and system which won't panic. - Update RELENG_8 to latest source code (e.g. remove "date=" line you just added) using csup (or svn method). - Rebuild world/kernel per instructions in /usr/src/Makefile. This will get you a kernel and system which WILL panic, with the old (usable) kernel in /boot/kernel.old. - Boot into "bad" kernel, but at the loader menu, pick option 5 for a verbose boot. - Panic will happen and drop you to a db> prompt. There, you should do "call doadump" and then "reboot". The first will cause the kernel to dump memory to your swap partition, the 2nd will reboot. - Boot into "good" kernel by pressing option 6 at the loader menu, then at "ok" prompt enter "boot kernel.old". If that doesn't work, you might need to do something like this: unload load /boot/kernel.old/kernel load -t /boot/zfs/zpool.cache /boot/zfs/zpool.cache boot - During the startup phase, savecore(8) will detect the crash from the previous kernel and populate /var/crash with details. One of these files will be /var/crash/core.txt.0, which should contain the contents of your verbose dmesg (or most of it anyway; this is why I adjusted MSGBUF_SIZE). I sure hope this works. :-) Serial console would, as I said, be a better choice. You wouldn't need to worry about all the panic/crash/swap stuff -- a verbose boot would be all you'd need, and you'd have the output on another machine in its scrollback buffer from whatever terminal or utility you were using that connected to the serial port. > > A workaround which one user has confirmed is to enable AHCI for your > > SATA controller in your system BIOS (if such is available). ataahci.ko > > will be used (which is AHCI via ATA) and your device names probably > > won't change. Alternatively you could enable AHCI and use ahci.ko > > (ahci_load="yes" in /boot/loader.conf) to get AHCI via CAM, which > > provides NCQ and other features, but your device names will change. > > My familiarity with ATAPI is limited however. > > Will try both if available and let you know the results. Understood. The former method worked for Michael, and I imagine it would work for you too if AHCI is available in your BIOS. I tend to advocate people use ahci.ko if they're using AHCI at all though, given the excellent CAM subsystem. -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, US | | Making life hard for others since 1977. PGP 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Wed Jun 1 11:35:31 2011 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E4C50106566B; Wed, 1 Jun 2011 11:35:31 +0000 (UTC) (envelope-from Holger.Kipp@alogis.com) Received: from alogis.com (firewall.solit-ag.de [212.184.102.1]) by mx1.freebsd.org (Postfix) with ESMTP id 925A68FC12; Wed, 1 Jun 2011 11:35:30 +0000 (UTC) Received: from msx3.exchange.alogis.com (exchange.alogis.com [10.1.1.6]) by alogis.com (8.13.4/8.13.1) with ESMTP id p51BZTYd021857; Wed, 1 Jun 2011 13:35:29 +0200 (CEST) (envelope-from Holger.Kipp@alogis.com) Received: from MSX3.exchange.alogis.com ([fe80::c8ed:428a:a157:b61]) by msx3.exchange.alogis.com ([fe80::c8ed:428a:a157:b61%13]) with mapi id 14.01.0255.000; Wed, 1 Jun 2011 13:36:14 +0200 From: Holger Kipp To: Jeremy Chadwick Thread-Topic: 8-STABLE won't boot with ZFSv28 Thread-Index: AcwgMDZpIyhysR9GQjKr1bi0oNTyx///8TIAgAAnkMb//+mOAIAAPFxG Date: Wed, 1 Jun 2011 11:36:13 +0000 Message-ID: <814C9E9472FDCC40AAC3FC95A2D67E3B0BD88F48@msx3.exchange.alogis.com> References: <814C9E9472FDCC40AAC3FC95A2D67E3B0BD88C69@msx3.exchange.alogis.com> <20110601085454.GA19434@icarus.home.lan> <814C9E9472FDCC40AAC3FC95A2D67E3B0BD88DC0@msx3.exchange.alogis.com>, <20110601095610.GA20255@icarus.home.lan> In-Reply-To: <20110601095610.GA20255@icarus.home.lan> Accept-Language: en-GB, de-DE, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [212.184.101.130] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "stable@freebsd.org" , "mav@freebsd.org" Subject: RE: 8-STABLE won't boot with ZFSv28 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 01 Jun 2011 11:35:32 -0000 Dear all, just a short update on the issue: I changed SATA setting in BIOS to AHCI and can now boot without problems. Thanks very much for the hint! Interesting thing is that only the DVD-drive is directly attached using SAT= A: - System Disks are attached using 3ware-controller (mirror, twe) - ZPool devices are accessed via FibreChannel. I'll try to provide more verbose info later during the day by preparing the= current kernel and including the required debugging settings and then rebooting with AHCI disabled again - but normal work is currently kicking in again... Best regards, Holger ________________________________________ From: Jeremy Chadwick [freebsd@jdc.parodius.com] Sent: 01 June 2011 11:56 To: Holger Kipp Cc: stable@freebsd.org; mav@freebsd.org Subject: Re: 8-STABLE won't boot with ZFSv28 On Wed, Jun 01, 2011 at 09:26:05AM +0000, Holger Kipp wrote: > Jeremy Chadwick [freebsd@jdc.parodius.com] wrote on 01 June 2011 10:54 > > >On Wed, Jun 01, 2011 at 08:23:19AM +0000, Holger Kipp wrote: > >> I have a very irritating problem with 8-STABLE and ZFSv28 > >> > >> I upgraded to 8-STABLE as of yesterday (31.05.2011), > >> downloaded stable-8-zfsv28-20110521.patch.xz > >> and applied the patch using > >> > >> cd /usr/src > >> patch -E -p0 < /path/to/patchfile > >> make buildworld > >> make buildkernel KERNCONF=3Dfoo > >> make installkernel KERNCONF=3Dfoo > >> make installworld > >> mergemaster > >> > >> which all went smoothly. > >> > >> After reboot, I only got > >> unknown: WARNING - ATAPI_IDENTITFY requeued due to channel reset LBA= =3D0 > >> all the time, and then after an hour or so (wasn't on site), > >> system gave > >> Fatal trap 12: page fault while in kernel mode > >> cupid - 0; apic id =3D 00 > >> fault virtual address =3D 0x8 > >> fault code =3D supervisor read data, page not pr= esent > >> instruction pointer =3D 0x20:0xffffffff80252301 > >> stack poiner =3D 0x28:0xffffff80000a7ac0 > >> frame pointer =3D 0x28:0xffffff80000a7b00 > >> code segment =3D base 0x0, limit 0xfffff, type 0x1b > >> =3D DPL 0, pres1, long = 1, def32 0, gran 1 > >> processor eflags =3D interrupt enabled, resume, IOPL =3D 0 > >> current process =3D 0 (thread taskq)trap number = =3D 12 > >> panic: page fault > >> cpuid =3D 0 > >> Uptime: 1h0m13s > >> Cannot dump. Device not defined or unavailable. > >> Automatic reboot in 15 seconds - press a key on the console to abort > >> > >> Needless to say the system did not reboot. Had to powercycle. > >> > >> Then always got the > >> unknown: WARNING - ATAPI_IDENTITFY requeued due to channel reset LBA= =3D0 > >> error about once per second. > >> > >> Have now used a fixit-disk to change back to the old kernel: > >> FreeBSD 8.2-STABLE #12: Mon Apr 18 12:48:56 CEST 2011 > >> and rebootet. > >> Now zfs claims to be v28, current storage pool is at 15.I'd love to > >> try ZFSv28, but with the old kernel I don't think > >> this is a good idea - but with the new kernel it seems I can't > >> even boot properly. > >> Any suggestions as to how to proceed? > > > I think this is much more likely related to an ATA/ATAPI-related change > > that was committed on April 17th recently and is not related to ZFSv28. > > Please see this thread: > > > > * 2011/05/29 -- ICH9 panic/instability on recent kernel > > http://lists.freebsd.org/pipermail/freebsd-stable/2011-May/thread.htm= l#62804 > > > > Holger, can you please provide the following two things? > > > > 1) Output from "pciconf -lvcb". > > That's an easy one: > > hostb0@pci0:0:0:0: class=3D0x060000 card=3D0xd28015d9 chip=3D0x29f08= 086 rev=3D0x01 hdr=3D0x00 > vendor =3D 'Intel Corporation' > device =3D '3200 Chipset (Bearlake) Processor to I/O Controller' > class =3D bridge > subclass =3D HOST-PCI > cap 09[e0] =3D vendor (length 12) Intel cap 9 version 1 > pcib1@pci0:0:1:0: class=3D0x060400 card=3D0xd28015d9 chip=3D0x29f18= 086 rev=3D0x01 hdr=3D0x01 > vendor =3D 'Intel Corporation' > device =3D '3200 Chipset (Bearlake) PCIe Root Port 1' > class =3D bridge > subclass =3D PCI-PCI > cap 0d[88] =3D PCI Bridge card=3D0xd28015d9 > cap 01[80] =3D powerspec 3 supports D0 D3 current D0 > cap 05[90] =3D MSI supports 1 message > cap 10[a0] =3D PCI-Express 2 root port max data 128(128) link x8(x16) > ecap 0002[100] =3D VC 1 max VC0 > ecap 0005[140] =3D unknown 1 > uhci0@pci0:0:26:0: class=3D0x0c0300 card=3D0xd28015d9 chip=3D0x29378= 086 rev=3D0x02 hdr=3D0x00 > vendor =3D 'Intel Corporation' > device =3D '82801IB/IR/IH (ICH9 Family) USB Universal Host Contro= ller' > class =3D serial bus > subclass =3D USB > bar [20] =3D type I/O Port, range 32, base 0x1820, size 32, enabled > cap 13[50] =3D PCI Advanced Features: FLR TP > uhci1@pci0:0:26:1: class=3D0x0c0300 card=3D0xd28015d9 chip=3D0x29388= 086 rev=3D0x02 hdr=3D0x00 > vendor =3D 'Intel Corporation' > device =3D '82801IB/IR/IH (ICH9 Family) USB Universal Host Contro= ller' > class =3D serial bus > subclass =3D USB > bar [20] =3D type I/O Port, range 32, base 0x1840, size 32, enabled > cap 13[50] =3D PCI Advanced Features: FLR TP > uhci2@pci0:0:26:2: class=3D0x0c0300 card=3D0xd28015d9 chip=3D0x29398= 086 rev=3D0x02 hdr=3D0x00 > vendor =3D 'Intel Corporation' > device =3D '82801IB/IR/IH (ICH9 Family) USB Universal Host Contro= ller' > class =3D serial bus > subclass =3D USB > bar [20] =3D type I/O Port, range 32, base 0x1860, size 32, enabled > cap 13[50] =3D PCI Advanced Features: FLR TP > ehci0@pci0:0:26:7: class=3D0x0c0320 card=3D0xd28015d9 chip=3D0x293c8= 086 rev=3D0x02 hdr=3D0x00 > vendor =3D 'Intel Corporation' > device =3D '82801IB/IR/IH (ICH9 Family) USB2 Enhanced Host Contro= ller' > class =3D serial bus > subclass =3D USB > bar [10] =3D type Memory, range 32, base 0xd9001000, size 1024, ena= bled > cap 01[50] =3D powerspec 2 supports D0 D3 current D0 > cap 0a[58] =3D EHCI Debug Port at offset 0xa0 in map 0x14 > cap 13[98] =3D PCI Advanced Features: FLR TP > pcib4@pci0:0:28:0: class=3D0x060400 card=3D0xd28015d9 chip=3D0x29408= 086 rev=3D0x02 hdr=3D0x01 > vendor =3D 'Intel Corporation' > device =3D '82801IB/IR/IH (ICH9 Family) PCIe Root Port 1' > class =3D bridge > subclass =3D PCI-PCI > cap 10[40] =3D PCI-Express 1 root port max data 128(128) link x4(x4) > cap 05[80] =3D MSI supports 1 message > cap 0d[90] =3D PCI Bridge card=3D0xd28015d9 > cap 01[a0] =3D powerspec 2 supports D0 D3 current D0 > ecap 0002[100] =3D VC 1 max VC0 > ecap 0005[180] =3D unknown 1 > pcib5@pci0:0:28:4: class=3D0x060400 card=3D0xd28015d9 chip=3D0x29488= 086 rev=3D0x02 hdr=3D0x01 > vendor =3D 'Intel Corporation' > device =3D '82801IB/IR/IH (ICH9 Family) PCIe Root Port 5' > class =3D bridge > subclass =3D PCI-PCI > cap 10[40] =3D PCI-Express 1 root port max data 128(128) link x1(x1) > cap 05[80] =3D MSI supports 1 message > cap 0d[90] =3D PCI Bridge card=3D0xd28015d9 > cap 01[a0] =3D powerspec 2 supports D0 D3 current D0 > ecap 0002[100] =3D VC 1 max VC0 > ecap 0005[180] =3D unknown 1 > pcib6@pci0:0:28:5: class=3D0x060400 card=3D0xd28015d9 chip=3D0x294a8= 086 rev=3D0x02 hdr=3D0x01 > vendor =3D 'Intel Corporation' > device =3D '82801IB/IR/IH (ICH9 Family) PCIe Root Port 6' > class =3D bridge > subclass =3D PCI-PCI > cap 10[40] =3D PCI-Express 1 root port max data 128(128) link x1(x1) > cap 05[80] =3D MSI supports 1 message > cap 0d[90] =3D PCI Bridge card=3D0xd28015d9 > cap 01[a0] =3D powerspec 2 supports D0 D3 current D0 > ecap 0002[100] =3D VC 1 max VC0 > ecap 0005[180] =3D unknown 1 > uhci3@pci0:0:29:0: class=3D0x0c0300 card=3D0xd28015d9 chip=3D0x29348= 086 rev=3D0x02 hdr=3D0x00 > vendor =3D 'Intel Corporation' > device =3D '82801IB/IR/IH (ICH9 Family) USB Universal Host Contro= ller' > class =3D serial bus > subclass =3D USB > bar [20] =3D type I/O Port, range 32, base 0x1880, size 32, enabled > cap 13[50] =3D PCI Advanced Features: FLR TP > uhci4@pci0:0:29:1: class=3D0x0c0300 card=3D0xd28015d9 chip=3D0x29358= 086 rev=3D0x02 hdr=3D0x00 > vendor =3D 'Intel Corporation' > device =3D '82801IB/IR/IH (ICH9 Family) USB Universal Host Contro= ller' > class =3D serial bus > subclass =3D USB > bar [20] =3D type I/O Port, range 32, base 0x18a0, size 32, enabled > cap 13[50] =3D PCI Advanced Features: FLR TP > uhci5@pci0:0:29:2: class=3D0x0c0300 card=3D0xd28015d9 chip=3D0x29368= 086 rev=3D0x02 hdr=3D0x00 > vendor =3D 'Intel Corporation' > device =3D '82801IB/IR/IH (ICH9 Family) USB Universal Host Contro= ller' > class =3D serial bus > subclass =3D USB > bar [20] =3D type I/O Port, range 32, base 0x18c0, size 32, enabled > cap 13[50] =3D PCI Advanced Features: FLR TP > ehci1@pci0:0:29:7: class=3D0x0c0320 card=3D0xd28015d9 chip=3D0x293a8= 086 rev=3D0x02 hdr=3D0x00 > vendor =3D 'Intel Corporation' > device =3D '82801IB/IR/IH (ICH9 Family) USB2 Enhanced Host Contro= ller' > class =3D serial bus > subclass =3D USB > bar [10] =3D type Memory, range 32, base 0xd9001400, size 1024, ena= bled > cap 01[50] =3D powerspec 2 supports D0 D3 current D0 > cap 0a[58] =3D EHCI Debug Port at offset 0xa0 in map 0x14 > cap 13[98] =3D PCI Advanced Features: FLR TP > pcib7@pci0:0:30:0: class=3D0x060401 card=3D0xd28015d9 chip=3D0x244e8= 086 rev=3D0x92 hdr=3D0x01 > vendor =3D 'Intel Corporation' > device =3D '82801 Family (ICH2/3/4/5/6/7/8/9,63xxESB) Hub Interfa= ce to PCI Bridge' > class =3D bridge > subclass =3D PCI-PCI > cap 0d[50] =3D PCI Bridge card=3D0xd28015d9 > isab0@pci0:0:31:0: class=3D0x060100 card=3D0xd28015d9 chip=3D0x29168= 086 rev=3D0x02 hdr=3D0x00 > vendor =3D 'Intel Corporation' > device =3D '82801IR (ICH9R) LPC Interface Controller' > class =3D bridge > subclass =3D PCI-ISA > cap 09[e0] =3D vendor (length 12) Intel cap 1 version 0 > features: SATA RAID-5, 4 PCI-e x1 slots > atapci0@pci0:0:31:2: class=3D0x01018a card=3D0xd28015d9 chip=3D0x29208= 086 rev=3D0x02 hdr=3D0x00 > vendor =3D 'Intel Corporation' > device =3D '82801IB/IR/IH (ICH9 Family) 4 port Serial ATA Storage= Controller 1' > class =3D mass storage > subclass =3D ATA > bar [10] =3D type I/O Port, range 32, base 0x1f0, size 8, enabled > bar [14] =3D type I/O Port, range 32, base 0x3f4, size 1, enabled > bar [18] =3D type I/O Port, range 32, base 0x170, size 8, enabled > bar [1c] =3D type I/O Port, range 32, base 0x374, size 1, enabled > bar [20] =3D type I/O Port, range 32, base 0x1c10, size 16, enabled > bar [24] =3D type I/O Port, range 32, base 0x1c00, size 16, enabled > cap 01[70] =3D powerspec 3 supports D0 D3 current D0 > cap 13[b0] =3D PCI Advanced Features: FLR TP > none0@pci0:0:31:3: class=3D0x0c0500 card=3D0xd28015d9 chip=3D0x29308= 086 rev=3D0x02 hdr=3D0x00 > vendor =3D 'Intel Corporation' > device =3D 'Intel(R) ICH9 Family SMBus Controller working fine wi= th http://download.cnet.com/Chipset-Driver-Inte (8086)' > class =3D serial bus > subclass =3D SMBus > bar [10] =3D type Memory, range 64, base 0xd9001800, size 256, enab= led > bar [20] =3D type I/O Port, range 32, base 0x1100, size 32, enabled > atapci1@pci0:0:31:5: class=3D0x010185 card=3D0xd28015d9 chip=3D0x29268= 086 rev=3D0x02 hdr=3D0x00 > vendor =3D 'Intel Corporation' > device =3D '82801IB/IR/IH (ICH9 Family) 2 port Serial ATA Storage= Controller 2' > class =3D mass storage > subclass =3D ATA > bar [10] =3D type I/O Port, range 32, base 0x1c68, size 8, enabled > bar [14] =3D type I/O Port, range 32, base 0x1c5c, size 4, enabled > bar [18] =3D type I/O Port, range 32, base 0x1c60, size 8, enabled > bar [1c] =3D type I/O Port, range 32, base 0x1c58, size 4, enabled > bar [20] =3D type I/O Port, range 32, base 0x1c30, size 16, enabled > bar [24] =3D type I/O Port, range 32, base 0x1c20, size 16, enabled > cap 01[70] =3D powerspec 3 supports D0 D3 current D0 > cap 13[b0] =3D PCI Advanced Features: FLR TP > none1@pci0:0:31:6: class=3D0x118000 card=3D0x000015d9 chip=3D0x29328= 086 rev=3D0x02 hdr=3D0x00 > vendor =3D 'Intel Corporation' > device =3D '82801IB/IR/IH (ICH9 Family) Thermal Subsystem' > class =3D dasp > bar [10] =3D type Memory, range 64, base 0xd9000000, size 4096, ena= bled > cap 01[50] =3D powerspec 3 supports D0 D3 current D0 > pcib2@pci0:1:0:0: class=3D0x060400 card=3D0x00000000 chip=3D0x03298= 086 rev=3D0x09 hdr=3D0x01 > vendor =3D 'Intel Corporation' > device =3D 'PCI Express-to-PCI Express Bridge A (6700PXH)' > class =3D bridge > subclass =3D PCI-PCI > cap 10[44] =3D PCI-Express 1 PCI bridge max data 128(256) link x8(x8) > cap 05[5c] =3D MSI supports 1 message, 64 bit > cap 01[6c] =3D powerspec 2 supports D0 D3 current D0 > cap 07[d8] =3D PCI-X bridge > ecap 0001[100] =3D AER 1 0 fatal 1 non-fatal 0 corrected > ecap 0004[300] =3D unknown 1 > ioapic0@pci0:1:0:1: class=3D0x080020 card=3D0xd28015d9 chip=3D0x03268= 086 rev=3D0x09 hdr=3D0x00 > vendor =3D 'Intel Corporation' > device =3D '6700/6702PXH I/OxAPIC Interrupt Controller A' > class =3D base peripheral > subclass =3D interrupt controller > bar [10] =3D type Memory, range 32, base 0xd8900000, size 4096, ena= bled > cap 10[44] =3D PCI-Express 1 endpoint max data 256(256) link x8(x8) > cap 01[6c] =3D powerspec 2 supports D0 D3 current D0 > pcib3@pci0:1:0:2: class=3D0x060400 card=3D0x00000000 chip=3D0x032a8= 086 rev=3D0x09 hdr=3D0x01 > vendor =3D 'Intel Corporation' > device =3D 'PCI Express-to-PCI Express Bridge B (6700PXH)' > class =3D bridge > subclass =3D PCI-PCI > cap 10[44] =3D PCI-Express 1 PCI bridge max data 128(256) link x8(x8) > cap 05[5c] =3D MSI supports 1 message, 64 bit > cap 01[6c] =3D powerspec 2 supports D0 D3 current D0 > cap 07[d8] =3D PCI-X bridge > ecap 0001[100] =3D AER 1 0 fatal 1 non-fatal 0 corrected > ecap 0004[300] =3D unknown 1 > ioapic1@pci0:1:0:3: class=3D0x080020 card=3D0xd28015d9 chip=3D0x03278= 086 rev=3D0x09 hdr=3D0x00 > vendor =3D 'Intel Corporation' > device =3D 'I/OxAPIC Interrupt Controller B (6700PXH)' > class =3D base peripheral > subclass =3D interrupt controller > bar [10] =3D type Memory, range 32, base 0xd8901000, size 4096, ena= bled > cap 10[44] =3D PCI-Express 1 endpoint max data 256(256) link x8(x8) > cap 01[6c] =3D powerspec 2 supports D0 D3 current D0 > twe0@pci0:2:1:0: class=3D0x010400 card=3D0x100113c1 chip=3D0x10011= 3c1 rev=3D0x01 hdr=3D0x00 > vendor =3D '3ware Inc' > device =3D 'ATA-133 Storage Controller (7000/8000 series)' > class =3D mass storage > subclass =3D RAID > bar [10] =3D type I/O Port, range 32, base 0x2000, size 16, enabled > bar [14] =3D type Memory, range 32, base 0xd8800000, size 16, enabl= ed > bar [18] =3D type Memory, range 32, base 0xd8000000, size 8388608, = enabled > cap 01[40] =3D powerspec 1 supports D0 D1 D3 current D0 > isp0@pci0:5:0:0: class=3D0x0c0400 card=3D0x01371077 chip=3D0x24321= 077 rev=3D0x03 hdr=3D0x00 > vendor =3D 'QLogic Corporation' > device =3D 'Dual Channel 4G PCIe Fibre Channel Adapter (ISP2432)' > class =3D serial bus > subclass =3D Fibre Channel > bar [10] =3D type I/O Port, range 32, base 0x3000, size 256, enable= d > bar [14] =3D type Memory, range 64, base 0xd8b00000, size 16384, en= abled > cap 01[44] =3D powerspec 2 supports D0 D3 current D0 > cap 10[4c] =3D PCI-Express 1 endpoint max data 128(1024) link x4(x4) > cap 05[64] =3D MSI supports 16 messages, 64 bit enabled with 1 messag= e > cap 03[74] =3D VPD > cap 11[7c] =3D MSI-X supports 16 messages in map 0x14 > ecap 0001[100] =3D AER 1 0 fatal 1 non-fatal 0 corrected > ecap 0004[138] =3D unknown 1 > em0@pci0:13:0:0: class=3D0x020000 card=3D0x108c15d9 chip=3D0x108c8= 086 rev=3D0x03 hdr=3D0x00 > vendor =3D 'Intel Corporation' > device =3D 'Intel Corporation 82573E Gigabit Ethernet Controller = (Copper) (82573E)' > class =3D network > subclass =3D ethernet > bar [10] =3D type Memory, range 32, base 0xd8a00000, size 131072, e= nabled > bar [18] =3D type I/O Port, range 32, base 0x4000, size 32, enabled > cap 01[c8] =3D powerspec 2 supports D0 D3 current D0 > cap 05[d0] =3D MSI supports 1 message, 64 bit enabled with 1 message > cap 10[e0] =3D PCI-Express 1 endpoint max data 128(256) link x1(x1) > ecap 0001[100] =3D AER 1 0 fatal 1 non-fatal 0 corrected > ecap 0003[140] =3D Serial 1 003048ffffd21aba > em1@pci0:15:0:0: class=3D0x020000 card=3D0x109a15d9 chip=3D0x109a8= 086 rev=3D0x00 hdr=3D0x00 > vendor =3D 'Intel Corporation' > device =3D 'Intel PRO/1000 PL Network Adaptor (82573L)' > class =3D network > subclass =3D ethernet > bar [10] =3D type Memory, range 32, base 0xd8c00000, size 131072, e= nabled > bar [18] =3D type I/O Port, range 32, base 0x5000, size 32, enabled > cap 01[c8] =3D powerspec 2 supports D0 D3 current D0 > cap 05[d0] =3D MSI supports 1 message, 64 bit enabled with 1 message > cap 10[e0] =3D PCI-Express 1 endpoint max data 128(256) link x1(x1) > ecap 0001[100] =3D AER 1 0 fatal 1 non-fatal 0 corrected > ecap 0003[140] =3D Serial 1 003048ffffd21abb > vgapci0@pci0:17:4:0: class=3D0x030000 card=3D0xd28015d9 chip=3D0x515e1= 002 rev=3D0x02 hdr=3D0x00 > vendor =3D 'ATI Technologies Inc. / Advanced Micro Devices, Inc.' > device =3D 'Radeon ES1000 (Radeon ES1000)' > class =3D display > subclass =3D VGA > bar [10] =3D type Prefetchable Memory, range 32, base 0xd0000000, s= ize 134217728, enabled > bar [14] =3D type I/O Port, range 32, base 0x6000, size 256, enable= d > bar [18] =3D type Memory, range 32, base 0xd8d00000, size 65536, en= abled > cap 01[50] =3D powerspec 2 supports D0 D1 D2 D3 current D0 > > > > 2) Full output from a verbose boot (option "5" at the loader prompt). > > That's a bit more difficult... I'll check, but don't think anything is se= t up > there to get a meaningful dump or verbose boot information in electronic = form... > > > I imagine #2 isn't going to work for most users because there's no way > > to get pages and pages and pages of data from a panic'd machine without > > either serial console (which will require a 2nd machine and possibly a > > null-modem cable) or properly setting up a dedicated swap partition and > > large-enough /var filesystem, plus their kernel would need DDB support > > added to it (so they could properly do "call doadump" then "reboot"). By the way, regarding this specific explanation -- you'll need dumpdev=3D"auto" in rc.conf for this to work, plus after the panic will need to ensure that the very next kernel which boots can work reliably. I'll explain how I'd go about this -- there may be an easier way, but it's what I'd do. - Adjust your kernel config to include these options: options KDB # Enable kernel debugger support options KDB_TRACE # Print stack trace automatically= on panic options DDB # Support DDB options GDB # Support remote GDB options MSGBUF_SIZE=3D262144 # Increase kern.msgbufsize from= 64K to 256K - Make sure you have a dedicated swap partition, and /var big enough to hold a kernel panic (panic will probably be ~1-2GB in size). Or make a new filesystem for /var/crash (if so, be sure to copy over /var/crash/minfree!) - Add dumpdev=3D"auto" to /etc/rc.conf. - Add ddb_enable=3D"yes" to /etc/rc.conf. - Revert /usr/src to RELENG_8 dated April 16th or earlier. You can accomplish this using "date=3DYYYY.MM.DD.hh.mm.ss" in your csup file. See csup(1) man page for details. I imagine svn has a better way to do this, but I don't use it. - Rebuild world/kernel per instructions in /usr/src/Makefile. This will get you a kernel and system which won't panic. - Update RELENG_8 to latest source code (e.g. remove "date=3D" line you just added) using csup (or svn method). - Rebuild world/kernel per instructions in /usr/src/Makefile. This will get you a kernel and system which WILL panic, with the old (usable) kernel in /boot/kernel.old. - Boot into "bad" kernel, but at the loader menu, pick option 5 for a verbose boot. - Panic will happen and drop you to a db> prompt. There, you should do "call doadump" and then "reboot". The first will cause the kernel to dump memory to your swap partition, the 2nd will reboot. - Boot into "good" kernel by pressing option 6 at the loader menu, then at "ok" prompt enter "boot kernel.old". If that doesn't work, you might need to do something like this: unload load /boot/kernel.old/kernel load -t /boot/zfs/zpool.cache /boot/zfs/zpool.cache boot - During the startup phase, savecore(8) will detect the crash from the previous kernel and populate /var/crash with details. One of these files will be /var/crash/core.txt.0, which should contain the contents of your verbose dmesg (or most of it anyway; this is why I adjusted MSGBUF_SIZE). I sure hope this works. :-) Serial console would, as I said, be a better choice. You wouldn't need to worry about all the panic/crash/swap stuff -- a verbose boot would be all you'd need, and you'd have the output on another machine in its scrollback buffer from whatever terminal or utility you were using that connected to the serial port. > > A workaround which one user has confirmed is to enable AHCI for your > > SATA controller in your system BIOS (if such is available). ataahci.ko > > will be used (which is AHCI via ATA) and your device names probably > > won't change. Alternatively you could enable AHCI and use ahci.ko > > (ahci_load=3D"yes" in /boot/loader.conf) to get AHCI via CAM, which > > provides NCQ and other features, but your device names will change. > > My familiarity with ATAPI is limited however. > > Will try both if available and let you know the results. Understood. The former method worked for Michael, and I imagine it would work for you too if AHCI is available in your BIOS. I tend to advocate people use ahci.ko if they're using AHCI at all though, given the excellent CAM subsystem. -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, US | | Making life hard for others since 1977. PGP 4BD6C0CB | -- Holger Kipp Diplom-Mathematiker Senior Consultant Tel. : +49 30 436 58 114 Fax. : +49 30 436 58 214 Mobil: +49 178 36 58 114 Email: holger.kipp@alogis.com alogis AG Alt-Moabit 90b D-10559 Berlin web : http://www.alogis.com ---------------------------------------------------------- alogis AG Sitz/Registergericht: Berlin/AG Charlottenburg, HRB 71484 Vorstand: Arne Friedrichs, Joern Samuelson Aufsichtsratsvorsitzender: Reinhard Mielke From owner-freebsd-stable@FreeBSD.ORG Wed Jun 1 12:18:07 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CAF05106564A for ; Wed, 1 Jun 2011 12:18:07 +0000 (UTC) (envelope-from bartosz.woronicz@korbank.pl) Received: from LISTonosz.Korbank.PL (a.smtp.korbank.com [79.110.199.33]) by mx1.freebsd.org (Postfix) with ESMTP id 487078FC0C for ; Wed, 1 Jun 2011 12:18:07 +0000 (UTC) Received: from [79.110.194.135] (mech.k.pl [79.110.194.135]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by LISTonosz.Korbank.PL (Postfix) with ESMTP id 3DCBA167152A for ; Wed, 1 Jun 2011 14:17:33 +0200 (CEST) Message-ID: <4DE62DFD.2000204@korbank.pl> Date: Wed, 01 Jun 2011 14:18:05 +0200 From: Bartosz Woronicz User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.17) Gecko/20110424 Lightning/1.0b2 Thunderbird/3.1.10 MIME-Version: 1.0 To: freebsd-stable@freebsd.org Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Subject: PF problem withpackets falling in block... X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 01 Jun 2011 12:18:08 -0000 I want to just block few classes that must be blocked. It seems like it's partly working , but not all packets are accessible. And moreover I cannot connect from outside. What is wrong? My FreeBSD is 7.3-Stable my wan interface is vlan300 and vlan352 is for an user. The rule for blocking is: rule 28/0 block in log on vlan352 from 79.110.199.192/27 to rule 29/0 block in log on vlan352 from 79.110.199.192/27 to ! I was trying also with: block in log on vlan352 from 79.110.199.192/27 to any instead of these 2 above contains adresses of my network: 79.110.192.0/20 Passing rules are: pass quick from 79.110.199.199 to keep state pass in quick on vlan352 from 79.110.199.199 to ! tag FROM79_110_199_199 queue 79_110_199_199D pass out quick on vlan300 tagged FROM79_110_199_199 queue 79_110_199_199U pass in quick on vlan300 from ! to 79.110.199.199 tag TO79_110_199_199 queue 79_110_199_199U pass out quick on vlan352 tagged TO79_110_199_199 queue 79_110_199_199D But still some packets are dropped tcpdump: WARNING: pflog0: no IPv4 address assigned tcpdump: listening on pflog0, link-type PFLOG (OpenBSD pflog file), capture size 96 bytes rule 29/0(match): block in on vlan352: (tos 0x0, ttl 64, id 54312, offset 0, flags [DF], proto TCP (6), length 1500) 79.110.199.199.55073 > 87.239.219.82.59291: tcp 1480 [bad hdr length 0 - too short, < 20] rule 29/0(match): block in on vlan352: (tos 0x0, ttl 64, id 56948, offset 0, flags [DF], proto TCP (6), length 1442) 79.110.199.199.55073 > 80.229.149.80.55511: tcp 1422 [bad hdr length 0 - too short, < 20] rule 29/0(match): block in on vlan352: (tos 0x0, ttl 64, id 8242, offset 0, flags [DF], proto TCP (6), length 40) 79.110.199.199.55073 > 85.222.56.47.56705: [|tcp] rule 29/0(match): block in on vlan352: (tos 0x0, ttl 64, id 8243, offset 0, flags [DF], proto TCP (6), length 52) 79.110.199.199.55073 > 85.222.56.47.56705: [|tcp] rule 29/0(match): block in on vlan352: (tos 0x0, ttl 64, id 8244, offset 0, flags [DF], proto TCP (6), length 52) 79.110.199.199.55073 > 85.222.56.47.56705: tcp 32 [bad hdr length 0 - too short, < 20] rule 29/0(match): block in on vlan352: (tos 0x0, ttl 64, id 8245, offset 0, flags [DF], proto TCP (6), length 52) 79.110.199.199.55073 > 85.222.56.47.56705: [|tcp] rule 29/0(match): block in on vlan352: (tos 0x0, ttl 64, id 8246, offset 0, flags [DF], proto TCP (6), length 40) 79.110.199.199.55073 > 85.222.56.47.56705: [|tcp] rule 28/0(match): block in on vlan352: (tos 0x10, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 52) 79.110.199.199.55022 > 79.110.194.135.43126: [|tcp] rule 29/0(match): block in on vlan352: (tos 0x0, ttl 64, id 8247, offset 0, flags [DF], proto TCP (6), length 52) 79.110.199.199.55073 > 85.222.56.47.56705: tcp 32 [bad hdr length 0 - too short, < 20] rule 29/0(match): block in on vlan352: (tos 0x0, ttl 64, id 54313, offset 0, flags [DF], proto TCP (6), length 40) 79.110.199.199.55073 > 87.239.219.82.59291: [|tcp] rule 28/0(match): block in on vlan352: (tos 0x10, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 52) 79.110.199.199.55022 > 79.110.194.135.43126: [|tcp] rule 29/0(match): block in on vlan352: (tos 0x0, ttl 64, id 54314, offset 0, flags [DF], proto TCP (6), length 52) 79.110.199.199.55073 > 87.239.219.82.59291: [|tcp] rule 29/0(match): block in on vlan352: (tos 0x0, ttl 64, id 8248, offset 0, flags [DF], proto TCP (6), length 52) 79.110.199.199.55073 > 85.222.56.47.56705: tcp 32 [bad hdr length 0 - too short, < 20] rule 28/0(match): block in on vlan352: (tos 0x10, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 52) 79.110.199.199.55022 > 79.110.194.135.43126: [|tcp] rule 29/0(match): block in on vlan352: (tos 0x0, ttl 64, id 54315, offset 0, flags [DF], proto TCP (6), length 52) 79.110.199.199.55073 > 87.239.219.82.59291: [|tcp] -- Pozdrawiam, Bartosz Woronicz, System Adminstrator, mynet S.A. ul. NabyciÅ„ska 19 53-677 WrocÅ‚aw NIP: 894-26-41-602 tel. 071-723-43-23 fax. 071-723-43-29 From owner-freebsd-stable@FreeBSD.ORG Wed Jun 1 12:23:18 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 05B70106566C for ; Wed, 1 Jun 2011 12:23:18 +0000 (UTC) (envelope-from se@FreeBSD.org) Received: from nm30.bullet.mail.bf1.yahoo.com (nm30.bullet.mail.bf1.yahoo.com [98.139.212.189]) by mx1.freebsd.org (Postfix) with SMTP id A884D8FC12 for ; Wed, 1 Jun 2011 12:23:17 +0000 (UTC) Received: from [98.139.212.151] by nm30.bullet.mail.bf1.yahoo.com with NNFMP; 01 Jun 2011 12:09:28 -0000 Received: from [98.139.211.201] by tm8.bullet.mail.bf1.yahoo.com with NNFMP; 01 Jun 2011 12:09:28 -0000 Received: from [127.0.0.1] by smtp210.mail.bf1.yahoo.com with NNFMP; 01 Jun 2011 12:09:28 -0000 X-Yahoo-Newman-Id: 857803.20617.bm@smtp210.mail.bf1.yahoo.com Received: from [192.168.119.20] (se@81.173.148.199 with plain) by smtp210.mail.bf1.yahoo.com with SMTP; 01 Jun 2011 05:09:28 -0700 PDT X-Yahoo-SMTP: iDf2N9.swBDAhYEh7VHfpgq0lnq. X-YMail-OSG: lz6WSqQVM1ko2bSal9M9iBegvWcXM.JV1e1dczgk4mc4RqS l40s.R6LEMzQOX6RbtdclH7KYrVS6ovEbv6HxzgtnnEaDGsxX8oZKZaSZfhN Wshl3ASQvRpwwgD8klfQvuiNWtGIY6pDROZCAcLq97qXaCmecOETzfBbWB6b bpPGmjpFp7QPogbc2KZ0rhwYcwsd8ZtVvJ1wMr8o9Rn9tP61YsbGDa1uNobv eFVx4F1wkaxM1TEu_8vRCl2QlkI8gV.oIWEKYlD2aVfCf7TRqkws4lpQOyry rpDfknz7zV1CgOghySW0lp_L_TMT3hSqRWw5UxNjG4ukK4xZRYXgE.LB9eRV 81BTc0cxbMm0v71rtNKtuwv2tygmKORk2IfJjsf7JmK.I1ucyu8uqCXKU.6n 8b8ErwdSLpNeyKqIYZHmM89toPuXkX6kzbsAdC_wGzEwYmEpwcb_E.2xoism ONBOSoXcSScuOB1YYtpC9zuOAGBYcxh0uzdLNgOwA8MEnGlpNvDj_YVn6wD0 jta8uVEjAUWbh8pgDH5ShEYbFkkUZubs- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4DE62BF7.7090203@FreeBSD.org> Date: Wed, 01 Jun 2011 14:09: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: <20110601080706.GA18521@icarus.home.lan> In-Reply-To: <20110601080706.GA18521@icarus.home.lan> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit Subject: Re: PCIe SATA HBA for ZFS on -STABLE X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jun 2011 12:23:18 -0000 Am 01.06.2011 10:07, schrieb Jeremy Chadwick: > Sadly I don't have a recommendation for you, since you effectively want > a 6-port SATA300 controller that's reliable, you're almost certainly > going to be paying Big Bucks(tm) given the number of ports and your > requirement that it be PCIe-based. You state quite boldly "not wanting > to break the bank", but what you're asking for almost certainly WILL > break the bank. > > For example, an "affordable" controller might be one driven by Silicon > Image's SiI3124 chip -- four (4) SATA300 ports, but it's only hooked to > PCI or PCI-X, not PCIe, which means you're susceptible to a much more > severe bus bottleneck than with PCIe: > > http://www.siliconimage.com/products/family.aspx?id=3 FYI: There is at least one PCIe card with Sil3124 (with PCIe to PCI-X bridge on the controller card): http://www.leaf-computer.com/#24e Price is 69 Euro plus 5 Euro shipping to Europe or North America (i.e. some US$110 total). Regards, STefan From owner-freebsd-stable@FreeBSD.ORG Wed Jun 1 14:30:56 2011 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5F5BC106564A for ; Wed, 1 Jun 2011 14:30:56 +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 1B4EA8FC13 for ; Wed, 1 Jun 2011 14:30:56 +0000 (UTC) Received: by gwb15 with SMTP id 15so3350391gwb.13 for ; Wed, 01 Jun 2011 07:30:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=XV3SZIpfyDxiEOIWkm6enEG3IbD5a/wbSfbsfR4mDdA=; b=lDAOeO0+iDtYVrienoYpAIC3rwuIqpkck+2Gh44ZBDBJXkQIUR+wHSHoayEawjM7CO A/Zqbgz1EMqddBaMzu9M2j/CoT+ga8rFH82r76W9oUcpTBvoV+dN/SQTP6oThHxOdVgR 1JstFjs1WfXqRzDqDz8pvrQfcwgFK/pWI0Pdg= 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=gzd5qom6z5tr5bWjU1ZAQU291JjK/zhZXXhviWcMBWxEl77sKfGRrNgerk4SW4dFA5 /cM6zivB/VWEd/VHI6YM4wqQXkfIUcSYABhspExPW6dYijvKf9A4Hwplh1qxUFQv1rtS my3eEnAwkw3cNjkdKFL/FapbXXpBaa6InY0cM= MIME-Version: 1.0 Received: by 10.90.57.26 with SMTP id f26mr6510266aga.54.1306938655488; Wed, 01 Jun 2011 07:30:55 -0700 (PDT) Received: by 10.91.161.17 with HTTP; Wed, 1 Jun 2011 07:30:55 -0700 (PDT) In-Reply-To: References: Date: Wed, 1 Jun 2011 07:30:55 -0700 Message-ID: From: Freddie Cash To: TJ Varghese Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: stable@freebsd.org, Matt Thyer Subject: Re: PCIe SATA HBA for ZFS on -STABLE X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jun 2011 14:30:56 -0000 On Tue, May 31, 2011 at 11:34 PM, TJ Varghese wrote: > On Tue, May 31, 2011 at 10:31 PM, Freddie Cash wrote: > >> On Tue, May 31, 2011 at 5:48 AM, Matt Thyer wrote: >> >> > What do people recommend for 8-STABLE as a PCIe SATA II HBA for someone >> > using ZFS ? >> > >> > Not wanting to break the bank. >> > Not interested in SATA III 6GB at this time... though it could be useful >> if >> > I add an SSD for... (is it ZIL ?). >> > Can this be added at any time ? >> > >> > The main issue is I need at least 10 ports total for all existing >> drives... >> > ZIL would require 11 so ideally we are talking a 6 port HBA. >> > >> >> SuperMicro AOC-USAS2-L8i works exceptionally well. These are 8-port HBAs >> using the LSI1068 chipset, supported by the mpt(4) driver. Support 3 Gpbs >> SATA/SAS, using multi-lane cables (2 connectors on the card, each >> connector >> supports 4 SATA ports), hot-plug, hot-swap. >> >> > The USAS2 (6Gbps) is supported by the mps driver (on -CURRENT, not sure if > it's in 8-STABLE yet). Perhaps you're referring to the earlier USAS which > does 3Gbps and is supported by the mpt driver. > > Oops, you're right. We have the USAS, not the USAS2, using the mpt(4) driver. -- Freddie Cash fjwcash@gmail.com From owner-freebsd-stable@FreeBSD.ORG Wed Jun 1 15:29:28 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 01DCC106564A for ; Wed, 1 Jun 2011 15:29:28 +0000 (UTC) (envelope-from lichray@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 834378FC0C for ; Wed, 1 Jun 2011 15:29:26 +0000 (UTC) Received: by fxm11 with SMTP id 11so188404fxm.13 for ; Wed, 01 Jun 2011 08:29:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=GW9c9c5Xmt2/zi/rGcsGnDfJ8Df2eQPcb0oxe6FEjks=; b=l1gsWuPcmByqu0LWk4dL4p0/FYQMn8XLwyU9Q3xGdmNaXWzhyLMaeH7NMrDrzmyTct BwoUTTymqF50gojNAPCd5Gy9B1365wSqvYz9Kryo/u3dqxYW6v0c5smjswmdTDuoeAdZ wXbEjBTKok1ydE+Z5OsfG8zvTMHa5bqaOz+1s= 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=Hwuiapb5o5crYGBNb4B90fLU5+g0lg+jYWnle5g9Rvb+wLtq8WiJ7zjKdpE9juQHKA 8ifaxL858EaUbW+vtmhWH+US1UcKZVK6MPWBfSgrfLSMGiIRt+S9cdNTi+CqZt+j4aNy vWERr0mYSYjMZ/+W1fEDlcMWcQEr+5Y+E7Q08= MIME-Version: 1.0 Received: by 10.223.53.85 with SMTP id l21mr3035206fag.26.1306942165355; Wed, 01 Jun 2011 08:29:25 -0700 (PDT) Received: by 10.223.72.13 with HTTP; Wed, 1 Jun 2011 08:29:25 -0700 (PDT) In-Reply-To: References: <20110601014933.GA12940@icarus.home.lan> Date: Wed, 1 Jun 2011 10:29:25 -0500 Message-ID: From: Zhihao Yuan To: Olivier Smedts Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: FreeBSD-STABLE Mailing List , Jeremy Chadwick Subject: Re: [ZFSv28]gtpzfsboot fails to boot ZFSv28 0511 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 01 Jun 2011 15:29:28 -0000 On Wed, Jun 1, 2011 at 3:36 AM, Olivier Smedts wrote: > 2011/6/1 Jeremy Chadwick : >> On Tue, May 31, 2011 at 08:15:35PM -0500, Zhihao Yuan wrote: >>> I met this problem, which is serious. I need some help to recovered >>> the system, after that I'll show the photos about the error screen. >>> >>> I used the ZFSv28 patch maintained by mm@ before, and I have a >>> backuped working kernel. I need a LiveCD/memstick to boot the system >>> and recover it. But after I burned the 9.0-current image to memstick, >>> I found that it keeps giving me kernel panic when booting! How can I >>> find a LiveFS with ZFSv28 support? Thanks. >> >> The closest thing I can think of is this: >> >> http://mfsbsd.vx.sk/ > > I had a problem with latest gptzfsboot under 9-CURRENT with my v28 > pool, and restored the old gptzfsboot I had on a snapshot with "gpart > bootcode" thanks to mfsbsd. mfsbsd seems to an installation image. Can I use it to restore my old kerne= l? > >> Except: >> >> 1) The ISOs there don't claim to be "LiveFS"; I don't know if they are. >> 2) There's no memory stick image available, only ISOs, >> 3) They're 8.2-RELEASE with ZFSv28 patches, not 9.0-CURRENT. =C2=A0I don= 't >> =C2=A0 know the implications of this. >> >> Best to ask mm@. >> >> -- >> | Jeremy Chadwick =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 jdc@paro= dius.com | >> | Parodius Networking =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 http://www.parodius.com/ | >> | UNIX Systems Administrator =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0Mountain View, CA, USA | >> | Making life hard for others since 1977. =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 PGP 4BD6C0CB | >> >> _______________________________________________ >> 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= " >> > > > > -- > Olivier Smedts=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 _ > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ASCII ri= bbon campaign ( ) > e-mail: olivier@gid0.org=C2=A0 =C2=A0 =C2=A0 =C2=A0 - against HTML email = & vCards=C2=A0 X > www: http://www.gid0.org=C2=A0 =C2=A0 - against proprietary attachments /= \ > > =C2=A0 "Il y a seulement 10 sortes de gens dans le monde : > =C2=A0 ceux qui comprennent le binaire, > =C2=A0 et ceux qui ne le comprennent pas." > --=20 Zhihao Yuan, nickname lichray The best way to predict the future is to invent it. ___________________________________________________ 4BSD -- http://4bsd.biz/ From owner-freebsd-stable@FreeBSD.ORG Wed Jun 1 16:17:38 2011 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5AA681065674; Wed, 1 Jun 2011 16:17:38 +0000 (UTC) (envelope-from Holger.Kipp@alogis.com) Received: from alogis.com (firewall.solit-ag.de [212.184.102.1]) by mx1.freebsd.org (Postfix) with ESMTP id E7E7C8FC08; Wed, 1 Jun 2011 16:17:36 +0000 (UTC) Received: from msx3.exchange.alogis.com (exchange.alogis.com [10.1.1.6]) by alogis.com (8.13.4/8.13.1) with ESMTP id p51GHZUC024097; Wed, 1 Jun 2011 18:17:36 +0200 (CEST) (envelope-from Holger.Kipp@alogis.com) Received: from MSX3.exchange.alogis.com ([fe80::c8ed:428a:a157:b61]) by msx3.exchange.alogis.com ([fe80::c8ed:428a:a157:b61%13]) with mapi id 14.01.0255.000; Wed, 1 Jun 2011 18:18:21 +0200 From: Holger Kipp To: Jeremy Chadwick Thread-Topic: 8-STABLE won't boot with ZFSv28 Thread-Index: AcwgMDZpIyhysR9GQjKr1bi0oNTyx///8TIAgAAnkMb//+mOAIAAPFxGgABDK+0= Date: Wed, 1 Jun 2011 16:18:20 +0000 Message-ID: <814C9E9472FDCC40AAC3FC95A2D67E3B0BD890BD@msx3.exchange.alogis.com> References: <814C9E9472FDCC40AAC3FC95A2D67E3B0BD88C69@msx3.exchange.alogis.com> <20110601085454.GA19434@icarus.home.lan> <814C9E9472FDCC40AAC3FC95A2D67E3B0BD88DC0@msx3.exchange.alogis.com>, <20110601095610.GA20255@icarus.home.lan>, <814C9E9472FDCC40AAC3FC95A2D67E3B0BD88F48@msx3.exchange.alogis.com> In-Reply-To: <814C9E9472FDCC40AAC3FC95A2D67E3B0BD88F48@msx3.exchange.alogis.com> Accept-Language: en-GB, de-DE, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [212.184.101.130] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "stable@freebsd.org" , "mav@freebsd.org" Subject: RE: 8-STABLE won't boot with ZFSv28 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 01 Jun 2011 16:17:38 -0000 Dear all, got the same messages over and over again - panic took some time: unknown: WARNING - ATAPI_IDENTIFY requeued due to channel reset LBA=3D0 ata0: reinit done .. ata0: reiniting channel .. ata0: DISCONNECT requested ata0: p0: SATA connect time=3D0ms status=3D00000113 ata0: p1: SATA connect timeout status=3D00000000 ata0: reset tp1 mask=3D03 ostat0=3D00 ostat1=3D00 ata0: stat0=3D0x00 err=3D0x01 lsb=3D0x14 msb=3D0xeb ata0: stat1=3D0x00 err=3D0x01 lsb=3D0x14 msb=3D0xeb ata0: reset tp2 stat0=3D00 stat1=3D00 devices=3D0x30000 unknown: WARNING - ATAPI_IDENTIFY requeued due to channel reset LBA=3D0 ata0: reinit done .. ata0: reiniting channel .. ata0: DISCONNECT requested ata0: p0: SATA connect time=3D0ms status=3D00000113 ata0: p1: SATA connect timeout status=3D00000000 ata0: reset tp1 mask=3D03 ostat0=3D00 ostat1=3D00 ata0: stat0=3D0x00 err=3D0x01 lsb=3D0x14 msb=3D0xeb ata0: stat1=3D0x00 err=3D0x01 lsb=3D0x14 msb=3D0xeb ata0: reset tp2 stat0=3D00 stat1=3D00 devices=3D0x30000 unknown: WARNING - ATAPI_IDENTIFY requeued due to channel reset LBA=3D0 ata0: reinit done .. ata0: reiniting channel .. ata0: DISCONNECT requested ata0: p0: SATA connect time=3D0ms status=3D00000113 ata0: p1: SATA connect timeout status=3D00000000 ata0: reset tp1 mask=3D03 ostat0=3D00 ostat1=3D00 ata0: stat0=3D0x00 err=3D0x01 lsb=3D0x14 msb=3D0xeb ata0: stat1=3D0x00 err=3D0x01 lsb=3D0x14 msb=3D0xeb ata0: reset tp2 stat0=3D00 stat1=3D00 devices=3D0x30000 might presumably take about an hour before system will drop me to a db> prompt. Hmm - last time system was up about 1 hour... Ah no, my mistake. Assuming we have a 512kB buffer for such messages, then at about two roundtrips per second, only issuing th= e WARNING, this would need about 1 hour. For all the detailed messages, it would reach the same amount in about 10 Minutes. Just went back to the server, and already had the db> prompt this time. Hooray. Files can be found here: info.0: http://www.hkipp.de/dump/info.0 core.txt.0: http://www.hkipp.de/dump/core.txt.0 please let me know if this is useful :-) Best regards, Holger ________________________________________ From: owner-freebsd-stable@freebsd.org [owner-freebsd-stable@freebsd.org] o= n behalf of Holger Kipp [Holger.Kipp@alogis.com] Sent: 01 June 2011 13:36 To: Jeremy Chadwick Cc: stable@freebsd.org; mav@freebsd.org Subject: RE: 8-STABLE won't boot with ZFSv28 Dear all, just a short update on the issue: I changed SATA setting in BIOS to AHCI and can now boot without problems. Thanks very much for the hint! Interesting thing is that only the DVD-drive is directly attached using SAT= A: - System Disks are attached using 3ware-controller (mirror, twe) - ZPool devices are accessed via FibreChannel. I'll try to provide more verbose info later during the day by preparing the= current kernel and including the required debugging settings and then rebooting with AHCI disabled again - but normal work is currently kicking in again... Best regards, Holger ________________________________________ From: Jeremy Chadwick [freebsd@jdc.parodius.com] Sent: 01 June 2011 11:56 To: Holger Kipp Cc: stable@freebsd.org; mav@freebsd.org Subject: Re: 8-STABLE won't boot with ZFSv28 On Wed, Jun 01, 2011 at 09:26:05AM +0000, Holger Kipp wrote: > Jeremy Chadwick [freebsd@jdc.parodius.com] wrote on 01 June 2011 10:54 > > >On Wed, Jun 01, 2011 at 08:23:19AM +0000, Holger Kipp wrote: > >> I have a very irritating problem with 8-STABLE and ZFSv28 > >> > >> I upgraded to 8-STABLE as of yesterday (31.05.2011), > >> downloaded stable-8-zfsv28-20110521.patch.xz > >> and applied the patch using > >> > >> cd /usr/src > >> patch -E -p0 < /path/to/patchfile > >> make buildworld > >> make buildkernel KERNCONF=3Dfoo > >> make installkernel KERNCONF=3Dfoo > >> make installworld > >> mergemaster > >> > >> which all went smoothly. > >> > >> After reboot, I only got > >> unknown: WARNING - ATAPI_IDENTITFY requeued due to channel reset LBA= =3D0 > >> all the time, and then after an hour or so (wasn't on site), > >> system gave > >> Fatal trap 12: page fault while in kernel mode > >> cupid - 0; apic id =3D 00 > >> fault virtual address =3D 0x8 > >> fault code =3D supervisor read data, page not pr= esent > >> instruction pointer =3D 0x20:0xffffffff80252301 > >> stack poiner =3D 0x28:0xffffff80000a7ac0 > >> frame pointer =3D 0x28:0xffffff80000a7b00 > >> code segment =3D base 0x0, limit 0xfffff, type 0x1b > >> =3D DPL 0, pres1, long = 1, def32 0, gran 1 > >> processor eflags =3D interrupt enabled, resume, IOPL =3D 0 > >> current process =3D 0 (thread taskq)trap number = =3D 12 > >> panic: page fault > >> cpuid =3D 0 > >> Uptime: 1h0m13s > >> Cannot dump. Device not defined or unavailable. > >> Automatic reboot in 15 seconds - press a key on the console to abort > >> > >> Needless to say the system did not reboot. Had to powercycle. > >> > >> Then always got the > >> unknown: WARNING - ATAPI_IDENTITFY requeued due to channel reset LBA= =3D0 > >> error about once per second. > >> > >> Have now used a fixit-disk to change back to the old kernel: > >> FreeBSD 8.2-STABLE #12: Mon Apr 18 12:48:56 CEST 2011 > >> and rebootet. > >> Now zfs claims to be v28, current storage pool is at 15.I'd love to > >> try ZFSv28, but with the old kernel I don't think > >> this is a good idea - but with the new kernel it seems I can't > >> even boot properly. > >> Any suggestions as to how to proceed? > > > I think this is much more likely related to an ATA/ATAPI-related change > > that was committed on April 17th recently and is not related to ZFSv28. > > Please see this thread: > > > > * 2011/05/29 -- ICH9 panic/instability on recent kernel > > http://lists.freebsd.org/pipermail/freebsd-stable/2011-May/thread.htm= l#62804 > > > > Holger, can you please provide the following two things? > > > > 1) Output from "pciconf -lvcb". > > That's an easy one: > > hostb0@pci0:0:0:0: class=3D0x060000 card=3D0xd28015d9 chip=3D0x29f08= 086 rev=3D0x01 hdr=3D0x00 > vendor =3D 'Intel Corporation' > device =3D '3200 Chipset (Bearlake) Processor to I/O Controller' > class =3D bridge > subclass =3D HOST-PCI > cap 09[e0] =3D vendor (length 12) Intel cap 9 version 1 > pcib1@pci0:0:1:0: class=3D0x060400 card=3D0xd28015d9 chip=3D0x29f18= 086 rev=3D0x01 hdr=3D0x01 > vendor =3D 'Intel Corporation' > device =3D '3200 Chipset (Bearlake) PCIe Root Port 1' > class =3D bridge > subclass =3D PCI-PCI > cap 0d[88] =3D PCI Bridge card=3D0xd28015d9 > cap 01[80] =3D powerspec 3 supports D0 D3 current D0 > cap 05[90] =3D MSI supports 1 message > cap 10[a0] =3D PCI-Express 2 root port max data 128(128) link x8(x16) > ecap 0002[100] =3D VC 1 max VC0 > ecap 0005[140] =3D unknown 1 > uhci0@pci0:0:26:0: class=3D0x0c0300 card=3D0xd28015d9 chip=3D0x29378= 086 rev=3D0x02 hdr=3D0x00 > vendor =3D 'Intel Corporation' > device =3D '82801IB/IR/IH (ICH9 Family) USB Universal Host Contro= ller' > class =3D serial bus > subclass =3D USB > bar [20] =3D type I/O Port, range 32, base 0x1820, size 32, enabled > cap 13[50] =3D PCI Advanced Features: FLR TP > uhci1@pci0:0:26:1: class=3D0x0c0300 card=3D0xd28015d9 chip=3D0x29388= 086 rev=3D0x02 hdr=3D0x00 > vendor =3D 'Intel Corporation' > device =3D '82801IB/IR/IH (ICH9 Family) USB Universal Host Contro= ller' > class =3D serial bus > subclass =3D USB > bar [20] =3D type I/O Port, range 32, base 0x1840, size 32, enabled > cap 13[50] =3D PCI Advanced Features: FLR TP > uhci2@pci0:0:26:2: class=3D0x0c0300 card=3D0xd28015d9 chip=3D0x29398= 086 rev=3D0x02 hdr=3D0x00 > vendor =3D 'Intel Corporation' > device =3D '82801IB/IR/IH (ICH9 Family) USB Universal Host Contro= ller' > class =3D serial bus > subclass =3D USB > bar [20] =3D type I/O Port, range 32, base 0x1860, size 32, enabled > cap 13[50] =3D PCI Advanced Features: FLR TP > ehci0@pci0:0:26:7: class=3D0x0c0320 card=3D0xd28015d9 chip=3D0x293c8= 086 rev=3D0x02 hdr=3D0x00 > vendor =3D 'Intel Corporation' > device =3D '82801IB/IR/IH (ICH9 Family) USB2 Enhanced Host Contro= ller' > class =3D serial bus > subclass =3D USB > bar [10] =3D type Memory, range 32, base 0xd9001000, size 1024, ena= bled > cap 01[50] =3D powerspec 2 supports D0 D3 current D0 > cap 0a[58] =3D EHCI Debug Port at offset 0xa0 in map 0x14 > cap 13[98] =3D PCI Advanced Features: FLR TP > pcib4@pci0:0:28:0: class=3D0x060400 card=3D0xd28015d9 chip=3D0x29408= 086 rev=3D0x02 hdr=3D0x01 > vendor =3D 'Intel Corporation' > device =3D '82801IB/IR/IH (ICH9 Family) PCIe Root Port 1' > class =3D bridge > subclass =3D PCI-PCI > cap 10[40] =3D PCI-Express 1 root port max data 128(128) link x4(x4) > cap 05[80] =3D MSI supports 1 message > cap 0d[90] =3D PCI Bridge card=3D0xd28015d9 > cap 01[a0] =3D powerspec 2 supports D0 D3 current D0 > ecap 0002[100] =3D VC 1 max VC0 > ecap 0005[180] =3D unknown 1 > pcib5@pci0:0:28:4: class=3D0x060400 card=3D0xd28015d9 chip=3D0x29488= 086 rev=3D0x02 hdr=3D0x01 > vendor =3D 'Intel Corporation' > device =3D '82801IB/IR/IH (ICH9 Family) PCIe Root Port 5' > class =3D bridge > subclass =3D PCI-PCI > cap 10[40] =3D PCI-Express 1 root port max data 128(128) link x1(x1) > cap 05[80] =3D MSI supports 1 message > cap 0d[90] =3D PCI Bridge card=3D0xd28015d9 > cap 01[a0] =3D powerspec 2 supports D0 D3 current D0 > ecap 0002[100] =3D VC 1 max VC0 > ecap 0005[180] =3D unknown 1 > pcib6@pci0:0:28:5: class=3D0x060400 card=3D0xd28015d9 chip=3D0x294a8= 086 rev=3D0x02 hdr=3D0x01 > vendor =3D 'Intel Corporation' > device =3D '82801IB/IR/IH (ICH9 Family) PCIe Root Port 6' > class =3D bridge > subclass =3D PCI-PCI > cap 10[40] =3D PCI-Express 1 root port max data 128(128) link x1(x1) > cap 05[80] =3D MSI supports 1 message > cap 0d[90] =3D PCI Bridge card=3D0xd28015d9 > cap 01[a0] =3D powerspec 2 supports D0 D3 current D0 > ecap 0002[100] =3D VC 1 max VC0 > ecap 0005[180] =3D unknown 1 > uhci3@pci0:0:29:0: class=3D0x0c0300 card=3D0xd28015d9 chip=3D0x29348= 086 rev=3D0x02 hdr=3D0x00 > vendor =3D 'Intel Corporation' > device =3D '82801IB/IR/IH (ICH9 Family) USB Universal Host Contro= ller' > class =3D serial bus > subclass =3D USB > bar [20] =3D type I/O Port, range 32, base 0x1880, size 32, enabled > cap 13[50] =3D PCI Advanced Features: FLR TP > uhci4@pci0:0:29:1: class=3D0x0c0300 card=3D0xd28015d9 chip=3D0x29358= 086 rev=3D0x02 hdr=3D0x00 > vendor =3D 'Intel Corporation' > device =3D '82801IB/IR/IH (ICH9 Family) USB Universal Host Contro= ller' > class =3D serial bus > subclass =3D USB > bar [20] =3D type I/O Port, range 32, base 0x18a0, size 32, enabled > cap 13[50] =3D PCI Advanced Features: FLR TP > uhci5@pci0:0:29:2: class=3D0x0c0300 card=3D0xd28015d9 chip=3D0x29368= 086 rev=3D0x02 hdr=3D0x00 > vendor =3D 'Intel Corporation' > device =3D '82801IB/IR/IH (ICH9 Family) USB Universal Host Contro= ller' > class =3D serial bus > subclass =3D USB > bar [20] =3D type I/O Port, range 32, base 0x18c0, size 32, enabled > cap 13[50] =3D PCI Advanced Features: FLR TP > ehci1@pci0:0:29:7: class=3D0x0c0320 card=3D0xd28015d9 chip=3D0x293a8= 086 rev=3D0x02 hdr=3D0x00 > vendor =3D 'Intel Corporation' > device =3D '82801IB/IR/IH (ICH9 Family) USB2 Enhanced Host Contro= ller' > class =3D serial bus > subclass =3D USB > bar [10] =3D type Memory, range 32, base 0xd9001400, size 1024, ena= bled > cap 01[50] =3D powerspec 2 supports D0 D3 current D0 > cap 0a[58] =3D EHCI Debug Port at offset 0xa0 in map 0x14 > cap 13[98] =3D PCI Advanced Features: FLR TP > pcib7@pci0:0:30:0: class=3D0x060401 card=3D0xd28015d9 chip=3D0x244e8= 086 rev=3D0x92 hdr=3D0x01 > vendor =3D 'Intel Corporation' > device =3D '82801 Family (ICH2/3/4/5/6/7/8/9,63xxESB) Hub Interfa= ce to PCI Bridge' > class =3D bridge > subclass =3D PCI-PCI > cap 0d[50] =3D PCI Bridge card=3D0xd28015d9 > isab0@pci0:0:31:0: class=3D0x060100 card=3D0xd28015d9 chip=3D0x29168= 086 rev=3D0x02 hdr=3D0x00 > vendor =3D 'Intel Corporation' > device =3D '82801IR (ICH9R) LPC Interface Controller' > class =3D bridge > subclass =3D PCI-ISA > cap 09[e0] =3D vendor (length 12) Intel cap 1 version 0 > features: SATA RAID-5, 4 PCI-e x1 slots > atapci0@pci0:0:31:2: class=3D0x01018a card=3D0xd28015d9 chip=3D0x29208= 086 rev=3D0x02 hdr=3D0x00 > vendor =3D 'Intel Corporation' > device =3D '82801IB/IR/IH (ICH9 Family) 4 port Serial ATA Storage= Controller 1' > class =3D mass storage > subclass =3D ATA > bar [10] =3D type I/O Port, range 32, base 0x1f0, size 8, enabled > bar [14] =3D type I/O Port, range 32, base 0x3f4, size 1, enabled > bar [18] =3D type I/O Port, range 32, base 0x170, size 8, enabled > bar [1c] =3D type I/O Port, range 32, base 0x374, size 1, enabled > bar [20] =3D type I/O Port, range 32, base 0x1c10, size 16, enabled > bar [24] =3D type I/O Port, range 32, base 0x1c00, size 16, enabled > cap 01[70] =3D powerspec 3 supports D0 D3 current D0 > cap 13[b0] =3D PCI Advanced Features: FLR TP > none0@pci0:0:31:3: class=3D0x0c0500 card=3D0xd28015d9 chip=3D0x29308= 086 rev=3D0x02 hdr=3D0x00 > vendor =3D 'Intel Corporation' > device =3D 'Intel(R) ICH9 Family SMBus Controller working fine wi= th http://download.cnet.com/Chipset-Driver-Inte (8086)' > class =3D serial bus > subclass =3D SMBus > bar [10] =3D type Memory, range 64, base 0xd9001800, size 256, enab= led > bar [20] =3D type I/O Port, range 32, base 0x1100, size 32, enabled > atapci1@pci0:0:31:5: class=3D0x010185 card=3D0xd28015d9 chip=3D0x29268= 086 rev=3D0x02 hdr=3D0x00 > vendor =3D 'Intel Corporation' > device =3D '82801IB/IR/IH (ICH9 Family) 2 port Serial ATA Storage= Controller 2' > class =3D mass storage > subclass =3D ATA > bar [10] =3D type I/O Port, range 32, base 0x1c68, size 8, enabled > bar [14] =3D type I/O Port, range 32, base 0x1c5c, size 4, enabled > bar [18] =3D type I/O Port, range 32, base 0x1c60, size 8, enabled > bar [1c] =3D type I/O Port, range 32, base 0x1c58, size 4, enabled > bar [20] =3D type I/O Port, range 32, base 0x1c30, size 16, enabled > bar [24] =3D type I/O Port, range 32, base 0x1c20, size 16, enabled > cap 01[70] =3D powerspec 3 supports D0 D3 current D0 > cap 13[b0] =3D PCI Advanced Features: FLR TP > none1@pci0:0:31:6: class=3D0x118000 card=3D0x000015d9 chip=3D0x29328= 086 rev=3D0x02 hdr=3D0x00 > vendor =3D 'Intel Corporation' > device =3D '82801IB/IR/IH (ICH9 Family) Thermal Subsystem' > class =3D dasp > bar [10] =3D type Memory, range 64, base 0xd9000000, size 4096, ena= bled > cap 01[50] =3D powerspec 3 supports D0 D3 current D0 > pcib2@pci0:1:0:0: class=3D0x060400 card=3D0x00000000 chip=3D0x03298= 086 rev=3D0x09 hdr=3D0x01 > vendor =3D 'Intel Corporation' > device =3D 'PCI Express-to-PCI Express Bridge A (6700PXH)' > class =3D bridge > subclass =3D PCI-PCI > cap 10[44] =3D PCI-Express 1 PCI bridge max data 128(256) link x8(x8) > cap 05[5c] =3D MSI supports 1 message, 64 bit > cap 01[6c] =3D powerspec 2 supports D0 D3 current D0 > cap 07[d8] =3D PCI-X bridge > ecap 0001[100] =3D AER 1 0 fatal 1 non-fatal 0 corrected > ecap 0004[300] =3D unknown 1 > ioapic0@pci0:1:0:1: class=3D0x080020 card=3D0xd28015d9 chip=3D0x03268= 086 rev=3D0x09 hdr=3D0x00 > vendor =3D 'Intel Corporation' > device =3D '6700/6702PXH I/OxAPIC Interrupt Controller A' > class =3D base peripheral > subclass =3D interrupt controller > bar [10] =3D type Memory, range 32, base 0xd8900000, size 4096, ena= bled > cap 10[44] =3D PCI-Express 1 endpoint max data 256(256) link x8(x8) > cap 01[6c] =3D powerspec 2 supports D0 D3 current D0 > pcib3@pci0:1:0:2: class=3D0x060400 card=3D0x00000000 chip=3D0x032a8= 086 rev=3D0x09 hdr=3D0x01 > vendor =3D 'Intel Corporation' > device =3D 'PCI Express-to-PCI Express Bridge B (6700PXH)' > class =3D bridge > subclass =3D PCI-PCI > cap 10[44] =3D PCI-Express 1 PCI bridge max data 128(256) link x8(x8) > cap 05[5c] =3D MSI supports 1 message, 64 bit > cap 01[6c] =3D powerspec 2 supports D0 D3 current D0 > cap 07[d8] =3D PCI-X bridge > ecap 0001[100] =3D AER 1 0 fatal 1 non-fatal 0 corrected > ecap 0004[300] =3D unknown 1 > ioapic1@pci0:1:0:3: class=3D0x080020 card=3D0xd28015d9 chip=3D0x03278= 086 rev=3D0x09 hdr=3D0x00 > vendor =3D 'Intel Corporation' > device =3D 'I/OxAPIC Interrupt Controller B (6700PXH)' > class =3D base peripheral > subclass =3D interrupt controller > bar [10] =3D type Memory, range 32, base 0xd8901000, size 4096, ena= bled > cap 10[44] =3D PCI-Express 1 endpoint max data 256(256) link x8(x8) > cap 01[6c] =3D powerspec 2 supports D0 D3 current D0 > twe0@pci0:2:1:0: class=3D0x010400 card=3D0x100113c1 chip=3D0x10011= 3c1 rev=3D0x01 hdr=3D0x00 > vendor =3D '3ware Inc' > device =3D 'ATA-133 Storage Controller (7000/8000 series)' > class =3D mass storage > subclass =3D RAID > bar [10] =3D type I/O Port, range 32, base 0x2000, size 16, enabled > bar [14] =3D type Memory, range 32, base 0xd8800000, size 16, enabl= ed > bar [18] =3D type Memory, range 32, base 0xd8000000, size 8388608, = enabled > cap 01[40] =3D powerspec 1 supports D0 D1 D3 current D0 > isp0@pci0:5:0:0: class=3D0x0c0400 card=3D0x01371077 chip=3D0x24321= 077 rev=3D0x03 hdr=3D0x00 > vendor =3D 'QLogic Corporation' > device =3D 'Dual Channel 4G PCIe Fibre Channel Adapter (ISP2432)' > class =3D serial bus > subclass =3D Fibre Channel > bar [10] =3D type I/O Port, range 32, base 0x3000, size 256, enable= d > bar [14] =3D type Memory, range 64, base 0xd8b00000, size 16384, en= abled > cap 01[44] =3D powerspec 2 supports D0 D3 current D0 > cap 10[4c] =3D PCI-Express 1 endpoint max data 128(1024) link x4(x4) > cap 05[64] =3D MSI supports 16 messages, 64 bit enabled with 1 messag= e > cap 03[74] =3D VPD > cap 11[7c] =3D MSI-X supports 16 messages in map 0x14 > ecap 0001[100] =3D AER 1 0 fatal 1 non-fatal 0 corrected > ecap 0004[138] =3D unknown 1 > em0@pci0:13:0:0: class=3D0x020000 card=3D0x108c15d9 chip=3D0x108c8= 086 rev=3D0x03 hdr=3D0x00 > vendor =3D 'Intel Corporation' > device =3D 'Intel Corporation 82573E Gigabit Ethernet Controller = (Copper) (82573E)' > class =3D network > subclass =3D ethernet > bar [10] =3D type Memory, range 32, base 0xd8a00000, size 131072, e= nabled > bar [18] =3D type I/O Port, range 32, base 0x4000, size 32, enabled > cap 01[c8] =3D powerspec 2 supports D0 D3 current D0 > cap 05[d0] =3D MSI supports 1 message, 64 bit enabled with 1 message > cap 10[e0] =3D PCI-Express 1 endpoint max data 128(256) link x1(x1) > ecap 0001[100] =3D AER 1 0 fatal 1 non-fatal 0 corrected > ecap 0003[140] =3D Serial 1 003048ffffd21aba > em1@pci0:15:0:0: class=3D0x020000 card=3D0x109a15d9 chip=3D0x109a8= 086 rev=3D0x00 hdr=3D0x00 > vendor =3D 'Intel Corporation' > device =3D 'Intel PRO/1000 PL Network Adaptor (82573L)' > class =3D network > subclass =3D ethernet > bar [10] =3D type Memory, range 32, base 0xd8c00000, size 131072, e= nabled > bar [18] =3D type I/O Port, range 32, base 0x5000, size 32, enabled > cap 01[c8] =3D powerspec 2 supports D0 D3 current D0 > cap 05[d0] =3D MSI supports 1 message, 64 bit enabled with 1 message > cap 10[e0] =3D PCI-Express 1 endpoint max data 128(256) link x1(x1) > ecap 0001[100] =3D AER 1 0 fatal 1 non-fatal 0 corrected > ecap 0003[140] =3D Serial 1 003048ffffd21abb > vgapci0@pci0:17:4:0: class=3D0x030000 card=3D0xd28015d9 chip=3D0x515e1= 002 rev=3D0x02 hdr=3D0x00 > vendor =3D 'ATI Technologies Inc. / Advanced Micro Devices, Inc.' > device =3D 'Radeon ES1000 (Radeon ES1000)' > class =3D display > subclass =3D VGA > bar [10] =3D type Prefetchable Memory, range 32, base 0xd0000000, s= ize 134217728, enabled > bar [14] =3D type I/O Port, range 32, base 0x6000, size 256, enable= d > bar [18] =3D type Memory, range 32, base 0xd8d00000, size 65536, en= abled > cap 01[50] =3D powerspec 2 supports D0 D1 D2 D3 current D0 > > > > 2) Full output from a verbose boot (option "5" at the loader prompt). > > That's a bit more difficult... I'll check, but don't think anything is se= t up > there to get a meaningful dump or verbose boot information in electronic = form... > > > I imagine #2 isn't going to work for most users because there's no way > > to get pages and pages and pages of data from a panic'd machine without > > either serial console (which will require a 2nd machine and possibly a > > null-modem cable) or properly setting up a dedicated swap partition and > > large-enough /var filesystem, plus their kernel would need DDB support > > added to it (so they could properly do "call doadump" then "reboot"). By the way, regarding this specific explanation -- you'll need dumpdev=3D"auto" in rc.conf for this to work, plus after the panic will need to ensure that the very next kernel which boots can work reliably. I'll explain how I'd go about this -- there may be an easier way, but it's what I'd do. - Adjust your kernel config to include these options: options KDB # Enable kernel debugger support options KDB_TRACE # Print stack trace automatically= on panic options DDB # Support DDB options GDB # Support remote GDB options MSGBUF_SIZE=3D262144 # Increase kern.msgbufsize from= 64K to 256K - Make sure you have a dedicated swap partition, and /var big enough to hold a kernel panic (panic will probably be ~1-2GB in size). Or make a new filesystem for /var/crash (if so, be sure to copy over /var/crash/minfree!) - Add dumpdev=3D"auto" to /etc/rc.conf. - Add ddb_enable=3D"yes" to /etc/rc.conf. - Revert /usr/src to RELENG_8 dated April 16th or earlier. You can accomplish this using "date=3DYYYY.MM.DD.hh.mm.ss" in your csup file. See csup(1) man page for details. I imagine svn has a better way to do this, but I don't use it. - Rebuild world/kernel per instructions in /usr/src/Makefile. This will get you a kernel and system which won't panic. - Update RELENG_8 to latest source code (e.g. remove "date=3D" line you just added) using csup (or svn method). - Rebuild world/kernel per instructions in /usr/src/Makefile. This will get you a kernel and system which WILL panic, with the old (usable) kernel in /boot/kernel.old. - Boot into "bad" kernel, but at the loader menu, pick option 5 for a verbose boot. - Panic will happen and drop you to a db> prompt. There, you should do "call doadump" and then "reboot". The first will cause the kernel to dump memory to your swap partition, the 2nd will reboot. - Boot into "good" kernel by pressing option 6 at the loader menu, then at "ok" prompt enter "boot kernel.old". If that doesn't work, you might need to do something like this: unload load /boot/kernel.old/kernel load -t /boot/zfs/zpool.cache /boot/zfs/zpool.cache boot - During the startup phase, savecore(8) will detect the crash from the previous kernel and populate /var/crash with details. One of these files will be /var/crash/core.txt.0, which should contain the contents of your verbose dmesg (or most of it anyway; this is why I adjusted MSGBUF_SIZE). I sure hope this works. :-) Serial console would, as I said, be a better choice. You wouldn't need to worry about all the panic/crash/swap stuff -- a verbose boot would be all you'd need, and you'd have the output on another machine in its scrollback buffer from whatever terminal or utility you were using that connected to the serial port. > > A workaround which one user has confirmed is to enable AHCI for your > > SATA controller in your system BIOS (if such is available). ataahci.ko > > will be used (which is AHCI via ATA) and your device names probably > > won't change. Alternatively you could enable AHCI and use ahci.ko > > (ahci_load=3D"yes" in /boot/loader.conf) to get AHCI via CAM, which > > provides NCQ and other features, but your device names will change. > > My familiarity with ATAPI is limited however. > > Will try both if available and let you know the results. Understood. The former method worked for Michael, and I imagine it would work for you too if AHCI is available in your BIOS. I tend to advocate people use ahci.ko if they're using AHCI at all though, given the excellent CAM subsystem. -- Holger Kipp Diplom-Mathematiker Senior Consultant Tel. : +49 30 436 58 114 Fax. : +49 30 436 58 214 Mobil: +49 178 36 58 114 Email: holger.kipp@alogis.com alogis AG Alt-Moabit 90b D-10559 Berlin web : http://www.alogis.com ---------------------------------------------------------- alogis AG Sitz/Registergericht: Berlin/AG Charlottenburg, HRB 71484 Vorstand: Arne Friedrichs, Joern Samuelson Aufsichtsratsvorsitzender: Reinhard Mielke From owner-freebsd-stable@FreeBSD.ORG Wed Jun 1 16:54:00 2011 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BA97F106566C for ; Wed, 1 Jun 2011 16:54:00 +0000 (UTC) (envelope-from Holger.Kipp@alogis.com) Received: from alogis.com (firewall.solit-ag.de [212.184.102.1]) by mx1.freebsd.org (Postfix) with ESMTP id 145278FC0A for ; Wed, 1 Jun 2011 16:53:59 +0000 (UTC) Received: from msx3.exchange.alogis.com (exchange.alogis.com [10.1.1.6]) by alogis.com (8.13.4/8.13.1) with ESMTP id p51GrxZv024356 for ; Wed, 1 Jun 2011 18:53:59 +0200 (CEST) (envelope-from Holger.Kipp@alogis.com) Received: from MSX3.exchange.alogis.com ([fe80::c8ed:428a:a157:b61]) by msx3.exchange.alogis.com ([fe80::c8ed:428a:a157:b61%13]) with mapi id 14.01.0255.000; Wed, 1 Jun 2011 18:54:45 +0200 From: Holger Kipp To: "stable@freebsd.org" Thread-Topic: ZFSv28 on 8-STABLE and Autoextend works like a charm so far Thread-Index: AcwgfGW2ePNx9qYiSluQYe6x6XXrlA== Date: Wed, 1 Jun 2011 16:54:44 +0000 Message-ID: <814C9E9472FDCC40AAC3FC95A2D67E3B0BD8911E@msx3.exchange.alogis.com> Accept-Language: en-GB, de-DE, en-US Content-Language: en-GB X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [212.184.101.130] Content-Type: multipart/related; boundary="_004_814C9E9472FDCC40AAC3FC95A2D67E3B0BD8911Emsx3exchangealo_"; type="multipart/alternative" MIME-Version: 1.0 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Subject: ZFSv28 on 8-STABLE and Autoextend works like a charm so far X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 01 Jun 2011 16:54:00 -0000 --_004_814C9E9472FDCC40AAC3FC95A2D67E3B0BD8911Emsx3exchangealo_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Start eg. with 8 1TB hard disks in one raidz2 (da0-da7) replace 1 disk at a time with a 2TB disk using zpool replace tank da Using ZFSv28, do zpool set autoextend=3Don tank zpool online -e tank da0 zpool online -e tank da1 .. zpool online -e tank da7 and have 11.3 GB available instead of 5.6 GB. Nice. Very nice! Many thanx to all who made this possible! Best regards, Holger -- Holger Kipp Diplom-Mathematiker Senior Consultant [alogis] Tel. : +49 30 436 58 114 Fax : +49 30 436 58 214 Mobil : +49 178 36 58 114 E-Mail : holger.kipp@alogis.com alogis AG Alt-Moabit 90 B D- 10559 Berlin Web: www.alogis.com alogis AG Sitz/Registergericht: Berlin/AG Charlottenburg, HRB 71484 Vorstand: Arne Friedrichs, Joern Samuelson Aufsichtsratsvorsitzender: Reinhard Mielke --_004_814C9E9472FDCC40AAC3FC95A2D67E3B0BD8911Emsx3exchangealo_-- From owner-freebsd-stable@FreeBSD.ORG Wed Jun 1 22:03:06 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 19D521065670 for ; Wed, 1 Jun 2011 22:03:06 +0000 (UTC) (envelope-from bartosz.woronicz@korbank.pl) Received: from LISTonosz.Korbank.PL (a.smtp.korbank.com [79.110.199.33]) by mx1.freebsd.org (Postfix) with ESMTP id 8EEEC8FC16 for ; Wed, 1 Jun 2011 22:03:04 +0000 (UTC) Received: from [192.168.33.244] (unknown [79.110.199.199]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by LISTonosz.Korbank.PL (Postfix) with ESMTP id 523781671554 for ; Thu, 2 Jun 2011 00:02:30 +0200 (CEST) Message-ID: <4DE6B716.9080600@korbank.pl> Date: Thu, 02 Jun 2011 00:03:02 +0200 From: Bartosz Woronicz User-Agent: Mozilla/5.0 (X11; U; Linux i686; pl-PL; rv:1.9.2.17) Gecko/20110424 Thunderbird/3.1.10 MIME-Version: 1.0 To: freebsd-stable@freebsd.org References: <4DE62DFD.2000204@korbank.pl> In-Reply-To: <4DE62DFD.2000204@korbank.pl> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Subject: [CLOSED] Re: PF problem withpackets falling in block... X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 01 Jun 2011 22:03:06 -0000 I put it in the wrong mailing list. Sorry for that. W dniu 01.06.2011 14:18, Bartosz Woronicz pisze: > I want to just block few classes that must be blocked. It seems like > it's partly working , but not all packets are accessible. And moreover > I cannot connect from outside. > What is wrong? My FreeBSD is 7.3-Stable > my wan interface is vlan300 and vlan352 is for an user. > The rule for blocking is: > rule 28/0 block in log on vlan352 from 79.110.199.192/27 to > rule 29/0 block in log on vlan352 from 79.110.199.192/27 to ! > > I was trying also with: block in log on vlan352 from 79.110.199.192/27 > to any > instead of these 2 above > contains adresses of my network: 79.110.192.0/20 > > Passing rules are: > pass quick from 79.110.199.199 to keep state > pass in quick on vlan352 from 79.110.199.199 to ! tag > FROM79_110_199_199 queue 79_110_199_199D > pass out quick on vlan300 tagged FROM79_110_199_199 queue 79_110_199_199U > pass in quick on vlan300 from ! to 79.110.199.199 tag > TO79_110_199_199 queue 79_110_199_199U > pass out quick on vlan352 tagged TO79_110_199_199 queue 79_110_199_199D > > > But still some packets are dropped > > tcpdump: WARNING: pflog0: no IPv4 address assigned > tcpdump: listening on pflog0, link-type PFLOG (OpenBSD pflog file), > capture size 96 bytes > rule 29/0(match): block in on vlan352: (tos 0x0, ttl 64, id 54312, > offset 0, flags [DF], proto TCP (6), length 1500) 79.110.199.199.55073 > > 87.239.219.82.59291: tcp 1480 [bad hdr length 0 - too short, < 20] > rule 29/0(match): block in on vlan352: (tos 0x0, ttl 64, id 56948, > offset 0, flags [DF], proto TCP (6), length 1442) 79.110.199.199.55073 > > 80.229.149.80.55511: tcp 1422 [bad hdr length 0 - too short, < 20] > rule 29/0(match): block in on vlan352: (tos 0x0, ttl 64, id 8242, > offset 0, flags [DF], proto TCP (6), length 40) 79.110.199.199.55073 > > 85.222.56.47.56705: [|tcp] > rule 29/0(match): block in on vlan352: (tos 0x0, ttl 64, id 8243, > offset 0, flags [DF], proto TCP (6), length 52) 79.110.199.199.55073 > > 85.222.56.47.56705: [|tcp] > rule 29/0(match): block in on vlan352: (tos 0x0, ttl 64, id 8244, > offset 0, flags [DF], proto TCP (6), length 52) 79.110.199.199.55073 > > 85.222.56.47.56705: tcp 32 [bad hdr length 0 - too short, < 20] > rule 29/0(match): block in on vlan352: (tos 0x0, ttl 64, id 8245, > offset 0, flags [DF], proto TCP (6), length 52) 79.110.199.199.55073 > > 85.222.56.47.56705: [|tcp] > rule 29/0(match): block in on vlan352: (tos 0x0, ttl 64, id 8246, > offset 0, flags [DF], proto TCP (6), length 40) 79.110.199.199.55073 > > 85.222.56.47.56705: [|tcp] > rule 28/0(match): block in on vlan352: (tos 0x10, ttl 64, id 0, offset > 0, flags [DF], proto TCP (6), length 52) 79.110.199.199.55022 > > 79.110.194.135.43126: [|tcp] > rule 29/0(match): block in on vlan352: (tos 0x0, ttl 64, id 8247, > offset 0, flags [DF], proto TCP (6), length 52) 79.110.199.199.55073 > > 85.222.56.47.56705: tcp 32 [bad hdr length 0 - too short, < 20] > rule 29/0(match): block in on vlan352: (tos 0x0, ttl 64, id 54313, > offset 0, flags [DF], proto TCP (6), length 40) 79.110.199.199.55073 > > 87.239.219.82.59291: [|tcp] > rule 28/0(match): block in on vlan352: (tos 0x10, ttl 64, id 0, offset > 0, flags [DF], proto TCP (6), length 52) 79.110.199.199.55022 > > 79.110.194.135.43126: [|tcp] > rule 29/0(match): block in on vlan352: (tos 0x0, ttl 64, id 54314, > offset 0, flags [DF], proto TCP (6), length 52) 79.110.199.199.55073 > > 87.239.219.82.59291: [|tcp] > rule 29/0(match): block in on vlan352: (tos 0x0, ttl 64, id 8248, > offset 0, flags [DF], proto TCP (6), length 52) 79.110.199.199.55073 > > 85.222.56.47.56705: tcp 32 [bad hdr length 0 - too short, < 20] > rule 28/0(match): block in on vlan352: (tos 0x10, ttl 64, id 0, offset > 0, flags [DF], proto TCP (6), length 52) 79.110.199.199.55022 > > 79.110.194.135.43126: [|tcp] > rule 29/0(match): block in on vlan352: (tos 0x0, ttl 64, id 54315, > offset 0, flags [DF], proto TCP (6), length 52) 79.110.199.199.55073 > > 87.239.219.82.59291: [|tcp] > -- Pozdrawiam, Bartosz Woronicz, System Adminstrator, Korbank S.A. ul. NabyciÅ„ska 19 53-677 WrocÅ‚aw NIP: 894-26-41-602 tel. 071-723-43-23 fax. 071-723-43-29 From owner-freebsd-stable@FreeBSD.ORG Thu Jun 2 06:28:42 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 278081065674 for ; Thu, 2 Jun 2011 06:28:42 +0000 (UTC) (envelope-from lichray@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 A53308FC26 for ; Thu, 2 Jun 2011 06:28:41 +0000 (UTC) Received: by fxm11 with SMTP id 11so740738fxm.13 for ; Wed, 01 Jun 2011 23:28:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=amIAjMdzH79gntYQFIguSlBahLo3LFkS4ko2Tfb3ChU=; b=p2FTkF/AFNnlH7bFvahVWVzOqsOPqYvk0MsVgn5QKhAh5oLQA6bWJrq4Bg0sBRr6dI n4fbQL3f9WFyYihtgFPmJCxItkBLhXizy1s6YgIoIpOrcEQXemczjb0vOt6vJAIQrzWD VSGdiyVEYCqe6EqqfMZ9b7HskWjOlcDzOSP/A= 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=xkCR4N6fpx3TOsYoVIIlKcoi2eWb8BN+jmGrVWDEMVQw+l8UiiXw5j+53xT1fwV2eN k2W1g7JC2LkbnsnnP2WQOe6WiWpwn9KaQv8EV61HpIFFVeLF52lKys7ZOuTYf50+YdNg uW1GwubcgG53o87yidFuxozuNOc1UI69H1YSU= MIME-Version: 1.0 Received: by 10.223.127.213 with SMTP id h21mr362403fas.45.1306996119015; Wed, 01 Jun 2011 23:28:39 -0700 (PDT) Received: by 10.223.72.13 with HTTP; Wed, 1 Jun 2011 23:28:38 -0700 (PDT) In-Reply-To: References: <20110601014933.GA12940@icarus.home.lan> Date: Thu, 2 Jun 2011 01:28:38 -0500 Message-ID: From: Zhihao Yuan To: Olivier Smedts Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: FreeBSD-STABLE Mailing List , Jeremy Chadwick Subject: Re: [ZFSv28]gtpzfsboot fails to boot ZFSv28 0511 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 02 Jun 2011 06:28:42 -0000 On Wed, Jun 1, 2011 at 10:29 AM, Zhihao Yuan wrote: > On Wed, Jun 1, 2011 at 3:36 AM, Olivier Smedts wrote: >> 2011/6/1 Jeremy Chadwick : >>> On Tue, May 31, 2011 at 08:15:35PM -0500, Zhihao Yuan wrote: >>>> I met this problem, which is serious. I need some help to recovered >>>> the system, after that I'll show the photos about the error screen. >>>> >>>> I used the ZFSv28 patch maintained by mm@ before, and I have a >>>> backuped working kernel. I need a LiveCD/memstick to boot the system >>>> and recover it. But after I burned the 9.0-current image to memstick, >>>> I found that it keeps giving me kernel panic when booting! How can I >>>> find a LiveFS with ZFSv28 support? Thanks. >>> >>> The closest thing I can think of is this: >>> >>> http://mfsbsd.vx.sk/ >> >> I had a problem with latest gptzfsboot under 9-CURRENT with my v28 >> pool, and restored the old gptzfsboot I had on a snapshot with "gpart >> bootcode" thanks to mfsbsd. > > mfsbsd seems to an installation image. Can I use it to restore my old ker= nel? Thanks to your help. I have recovered my system. FML, I can do nothing but playing games with Windows these days. The problem should be on the recent update to loader and zfsloader (loader.old and zfsloader.old present). I uploaded the screenshots when fail to boot at https://picasaweb.google.com/lh/photo/-SRBhEJvlslmLkn4JglZ0A5tpALgZSii5oHUB= foPNZY?feat=3Ddirectlink > >> >>> Except: >>> >>> 1) The ISOs there don't claim to be "LiveFS"; I don't know if they are. >>> 2) There's no memory stick image available, only ISOs, >>> 3) They're 8.2-RELEASE with ZFSv28 patches, not 9.0-CURRENT. =C2=A0I do= n't >>> =C2=A0 know the implications of this. >>> >>> Best to ask mm@. >>> >>> -- >>> | Jeremy Chadwick =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 jdc@paro= dius.com | >>> | Parodius Networking =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 http://www.parodius.com/ | >>> | UNIX Systems Administrator =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0Mountain View, CA, USA | >>> | Making life hard for others since 1977. =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 PGP 4BD6C0CB | >>> >>> _______________________________________________ >>> freebsd-stable@freebsd.org mailing list >>> http://lists.freebsd.org/mailman/listinfo/freebsd-stable >>> To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.or= g" >>> >> >> >> >> -- >> Olivier Smedts=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 _ >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ASCII= ribbon campaign ( ) >> e-mail: olivier@gid0.org=C2=A0 =C2=A0 =C2=A0 =C2=A0 - against HTML email= & vCards=C2=A0 X >> www: http://www.gid0.org=C2=A0 =C2=A0 - against proprietary attachments = / \ >> >> =C2=A0 "Il y a seulement 10 sortes de gens dans le monde : >> =C2=A0 ceux qui comprennent le binaire, >> =C2=A0 et ceux qui ne le comprennent pas." >> > > > > -- > Zhihao Yuan, nickname lichray > The best way to predict the future is to invent it. > ___________________________________________________ > 4BSD -- http://4bsd.biz/ > --=20 Zhihao Yuan, nickname lichray The best way to predict the future is to invent it. ___________________________________________________ 4BSD -- http://4bsd.biz/ From owner-freebsd-stable@FreeBSD.ORG Thu Jun 2 07:18:32 2011 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EB7C7106566B for ; Thu, 2 Jun 2011 07:18:31 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-bw0-f54.google.com (mail-bw0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id 6A5598FC13 for ; Thu, 2 Jun 2011 07:18:31 +0000 (UTC) Received: by bwz12 with SMTP id 12so1037364bwz.13 for ; Thu, 02 Jun 2011 00:18:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:sender:message-id:date:from:user-agent :mime-version:to:cc:subject:references:in-reply-to :x-enigmail-version:content-type:content-transfer-encoding; bh=CG1IssW18CHtZsrGho5FbPaS8Ak9Hwj3rn3I4tksGgo=; b=UgB0s0+2v+Gy47Dfva4B65s2eXWO/EQV0qRHBH/snM8rtP7HO2SPUBpwk/iTtThZ10 QBWZ4Qk/h1Hc3k4gbk0SYuu5yTiq7gjLTvWtjxszicLTSHP6+N9jamaUCCPy2rkGQu8X eYZYdA5ni2N6ZE4nnhsxHoMl7oYN0biMTgFNw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; b=I9BAn85zOXD+8if4HXHTnxy9xK3IA2UYuzUnv0bioOQ8kPuVSbGlK/igPbZGYi4I/3 PF1ju7uWPR54J5Voo1OlJlahWGlh9ab4L8Lw/+xKh0qNUFRJP5zVNYSiXpDpWT2MLasv hE1mAovVRf/gzflwV8JasY4SBvSL3uGyIS22c= Received: by 10.204.14.147 with SMTP id g19mr397696bka.11.1306997673545; Wed, 01 Jun 2011 23:54:33 -0700 (PDT) Received: from mavbook2.mavhome.dp.ua (pc.mavhome.dp.ua [212.86.226.226]) by mx.google.com with ESMTPS id x13sm222476bkj.5.2011.06.01.23.54.31 (version=SSLv3 cipher=OTHER); Wed, 01 Jun 2011 23:54:32 -0700 (PDT) Sender: Alexander Motin Message-ID: <4DE73386.5040505@FreeBSD.org> Date: Thu, 02 Jun 2011 09:53:58 +0300 From: Alexander Motin User-Agent: Thunderbird 2.0.0.23 (X11/20091212) MIME-Version: 1.0 To: Holger Kipp References: <814C9E9472FDCC40AAC3FC95A2D67E3B0BD88C69@msx3.exchange.alogis.com> <20110601085454.GA19434@icarus.home.lan> <814C9E9472FDCC40AAC3FC95A2D67E3B0BD88DC0@msx3.exchange.alogis.com>, <20110601095610.GA20255@icarus.home.lan>, <814C9E9472FDCC40AAC3FC95A2D67E3B0BD88F48@msx3.exchange.alogis.com> <814C9E9472FDCC40AAC3FC95A2D67E3B0BD890BD@msx3.exchange.alogis.com> In-Reply-To: <814C9E9472FDCC40AAC3FC95A2D67E3B0BD890BD@msx3.exchange.alogis.com> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "stable@freebsd.org" , Jeremy Chadwick Subject: Re: 8-STABLE won't boot with ZFSv28 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 02 Jun 2011 07:18:32 -0000 Hi. Holger Kipp wrote: > got the same messages over and over again - panic took some time: > > unknown: WARNING - ATAPI_IDENTIFY requeued due to channel reset LBA=0 > ata0: reinit done .. > ata0: reiniting channel .. > ata0: DISCONNECT requested > > > > ata0: p0: SATA connect time=0ms status=00000113 > ata0: p1: SATA connect timeout status=00000000 > ata0: reset tp1 mask=03 ostat0=00 ostat1=00 > ata0: stat0=0x00 err=0x01 lsb=0x14 msb=0xeb > ata0: stat1=0x00 err=0x01 lsb=0x14 msb=0xeb > ata0: reset tp2 stat0=00 stat1=00 devices=0x30000 > unknown: WARNING - ATAPI_IDENTIFY requeued due to channel reset LBA=0 > ata0: reinit done .. > ata0: reiniting channel .. > ata0: DISCONNECT requested I see two problems here: 1. "devices=0x30000" means that two ATAPI devices were detected instead of one. I can reproduce it also with other Intel chipsets. It looks like a hardware bug to me. It can be workarounded by reconnecting ATAPI device to even (2 or 4) SATA port, or connecting any other device there. 2. "DISCONNECT requested" means that controller reported PHY status change for some device on channel, triggering infinite retry. Unluckily I have no ICH9 board, while I can't reproduce it with ICH10 or above. This patch should workaround the first problem in software: http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/dev/ata/chipsets/ata-intel.c.diff?r1=1.25;r2=1.26 Try it please and let's see if with some luck it do something about the second problem. -- Alexander Motin From owner-freebsd-stable@FreeBSD.ORG Thu Jun 2 07:51:20 2011 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D4E961065675 for ; Thu, 2 Jun 2011 07:51:20 +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 B5EB18FC1E for ; Thu, 2 Jun 2011 07:51:20 +0000 (UTC) Received: from omta01.emeryville.ca.mail.comcast.net ([76.96.30.11]) by qmta09.emeryville.ca.mail.comcast.net with comcast id qvrK1g0010EPchoA9vrK8x; Thu, 02 Jun 2011 07:51:19 +0000 Received: from koitsu.dyndns.org ([67.180.84.87]) by omta01.emeryville.ca.mail.comcast.net with comcast id qvrS1g00H1t3BNj8MvrTaT; Thu, 02 Jun 2011 07:51:27 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 164D9102C19; Thu, 2 Jun 2011 00:51:18 -0700 (PDT) Date: Thu, 2 Jun 2011 00:51:18 -0700 From: Jeremy Chadwick To: Alexander Motin Message-ID: <20110602075118.GA42026@icarus.home.lan> References: <814C9E9472FDCC40AAC3FC95A2D67E3B0BD88C69@msx3.exchange.alogis.com> <20110601085454.GA19434@icarus.home.lan> <814C9E9472FDCC40AAC3FC95A2D67E3B0BD88DC0@msx3.exchange.alogis.com> <20110601095610.GA20255@icarus.home.lan> <814C9E9472FDCC40AAC3FC95A2D67E3B0BD88F48@msx3.exchange.alogis.com> <814C9E9472FDCC40AAC3FC95A2D67E3B0BD890BD@msx3.exchange.alogis.com> <4DE73386.5040505@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4DE73386.5040505@FreeBSD.org> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "stable@freebsd.org" Subject: Re: 8-STABLE won't boot with ZFSv28 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 02 Jun 2011 07:51:21 -0000 On Thu, Jun 02, 2011 at 09:53:58AM +0300, Alexander Motin wrote: > Hi. > > Holger Kipp wrote: > > got the same messages over and over again - panic took some time: > > > > unknown: WARNING - ATAPI_IDENTIFY requeued due to channel reset LBA=0 > > ata0: reinit done .. > > ata0: reiniting channel .. > > ata0: DISCONNECT requested > > > > > > > > ata0: p0: SATA connect time=0ms status=00000113 > > ata0: p1: SATA connect timeout status=00000000 > > ata0: reset tp1 mask=03 ostat0=00 ostat1=00 > > ata0: stat0=0x00 err=0x01 lsb=0x14 msb=0xeb > > ata0: stat1=0x00 err=0x01 lsb=0x14 msb=0xeb > > ata0: reset tp2 stat0=00 stat1=00 devices=0x30000 > > unknown: WARNING - ATAPI_IDENTIFY requeued due to channel reset LBA=0 > > ata0: reinit done .. > > ata0: reiniting channel .. > > ata0: DISCONNECT requested > > I see two problems here: > 1. "devices=0x30000" means that two ATAPI devices were detected instead > of one. I can reproduce it also with other Intel chipsets. It looks like > a hardware bug to me. It can be workarounded by reconnecting ATAPI > device to even (2 or 4) SATA port, or connecting any other device there. > 2. "DISCONNECT requested" means that controller reported PHY status > change for some device on channel, triggering infinite retry. Unluckily > I have no ICH9 board, while I can't reproduce it with ICH10 or above. > > This patch should workaround the first problem in software: > http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/dev/ata/chipsets/ata-intel.c.diff?r1=1.25;r2=1.26 > Try it please and let's see if with some luck it do something about the > second problem. With regards to item #1: I don't see anything in the ICH9 errata that indicates a silicon bug if the only device attached to the controller is an ATAPI device and connected to SATA port 0 (presumably), or an odd-numbered port? If this problem exists on other ICHxx and/or ESBxx chips, I sure would hope it'd be documented. I haven't tried confirming it myself, but if need be I can set up a test box with a SATA-based DVD drive hooked up to it + provide remote serial console/etc. if it'd be of any help. I don't think it would be (sounds like you have lots of hardware :-) ), but I'm willing to help in any way I can. With regards to item #2: could this be at all related to OOB (bit 15) somehow being set in PCS (SATA register offset 0x92)? I'm doubting it but I thought I'd ask. My thought process, which is probably wrong (consider it an educational discussion :-) ): The ICH9 specification states that the default value for this register is 0x0000, and b15=0 means "SATA controller will not retry after an OOB failure", while b15=1 causes the controller to indefinitely retry after OOB failure. I imagine system BIOSes and other things can change this default value, but we don't seem to print it anywhere in ata_intel_chipinit() during a verbose boot. Looking at chipsets/ata-intel.c, it looks like we only touch PCS in ata_intel_chipinit() and ata_intel_reset(). In the former, we avoid touching bits 4 through 15, and in the latter we mask out only what we want to adjust (e.g. the SATA port per ch variable). Reference material is 14.1.31 of the ICH9 datasheet: http://www.intel.com/assets/pdf/datasheet/316972.pdf -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, US | | Making life hard for others since 1977. PGP 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Thu Jun 2 08:38:10 2011 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 38813106564A for ; Thu, 2 Jun 2011 08:38:10 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-bw0-f54.google.com (mail-bw0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id 756AC8FC08 for ; Thu, 2 Jun 2011 08:38:08 +0000 (UTC) Received: by bwz12 with SMTP id 12so1102552bwz.13 for ; Thu, 02 Jun 2011 01:38:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:sender:message-id:date:from:user-agent :mime-version:to:cc:subject:references:in-reply-to :x-enigmail-version:content-type:content-transfer-encoding; bh=dZEiHoJ/QfyPa3qZxTOXQg7mdZ+JdKR3W+6zwOR4M9Q=; b=S6ia9nFhxAFLWSNsXh1tzYxBuWpGQbDoCmksTOrarZVPBi0bNhphG8HhH64SdNn9BY WqAoSXX5fd7yFhfAwQsTTKUSMNFWep05r82c/5imMRQ1WsHLWHltPSDISGZfUPebkfzR cbuTqd2lcXiYylMmuA2HyxhCc0WgavYTnGU/U= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; b=VrokwxdepH7+1nda/tZIVbvDSV78XSWGR2HN5baZNsa3QJaD6bmRh+vA35s7/hFjHB MJD3I5MFpVdsWWWu9kAuGZAYnktQl6fJxmbu0gMs9Uzq5s/lcgU5QG0qIA8UCvtaDwTQ TNZrOtj47M0hFPPwgm7iSxBrRzdYSGK/W0gJY= Received: by 10.204.3.207 with SMTP id 15mr458790bko.178.1307003888220; Thu, 02 Jun 2011 01:38:08 -0700 (PDT) Received: from mavbook2.mavhome.dp.ua (pc.mavhome.dp.ua [212.86.226.226]) by mx.google.com with ESMTPS id z1sm279929bka.8.2011.06.02.01.38.06 (version=SSLv3 cipher=OTHER); Thu, 02 Jun 2011 01:38:07 -0700 (PDT) Sender: Alexander Motin Message-ID: <4DE74BCD.8080002@FreeBSD.org> Date: Thu, 02 Jun 2011 11:37:33 +0300 From: Alexander Motin User-Agent: Thunderbird 2.0.0.23 (X11/20091212) MIME-Version: 1.0 To: Jeremy Chadwick References: <814C9E9472FDCC40AAC3FC95A2D67E3B0BD88C69@msx3.exchange.alogis.com> <20110601085454.GA19434@icarus.home.lan> <814C9E9472FDCC40AAC3FC95A2D67E3B0BD88DC0@msx3.exchange.alogis.com> <20110601095610.GA20255@icarus.home.lan> <814C9E9472FDCC40AAC3FC95A2D67E3B0BD88F48@msx3.exchange.alogis.com> <814C9E9472FDCC40AAC3FC95A2D67E3B0BD890BD@msx3.exchange.alogis.com> <4DE73386.5040505@FreeBSD.org> <20110602075118.GA42026@icarus.home.lan> In-Reply-To: <20110602075118.GA42026@icarus.home.lan> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "stable@freebsd.org" Subject: Re: 8-STABLE won't boot with ZFSv28 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 02 Jun 2011 08:38:10 -0000 Jeremy Chadwick wrote: > On Thu, Jun 02, 2011 at 09:53:58AM +0300, Alexander Motin wrote: >> Holger Kipp wrote: >>> got the same messages over and over again - panic took some time: >>> >>> unknown: WARNING - ATAPI_IDENTIFY requeued due to channel reset LBA=0 >>> ata0: reinit done .. >>> ata0: reiniting channel .. >>> ata0: DISCONNECT requested >>> >>> >>> >>> ata0: p0: SATA connect time=0ms status=00000113 >>> ata0: p1: SATA connect timeout status=00000000 >>> ata0: reset tp1 mask=03 ostat0=00 ostat1=00 >>> ata0: stat0=0x00 err=0x01 lsb=0x14 msb=0xeb >>> ata0: stat1=0x00 err=0x01 lsb=0x14 msb=0xeb >>> ata0: reset tp2 stat0=00 stat1=00 devices=0x30000 >>> unknown: WARNING - ATAPI_IDENTIFY requeued due to channel reset LBA=0 >>> ata0: reinit done .. >>> ata0: reiniting channel .. >>> ata0: DISCONNECT requested >> I see two problems here: >> 1. "devices=0x30000" means that two ATAPI devices were detected instead >> of one. I can reproduce it also with other Intel chipsets. It looks like >> a hardware bug to me. It can be workarounded by reconnecting ATAPI >> device to even (2 or 4) SATA port, or connecting any other device there. >> 2. "DISCONNECT requested" means that controller reported PHY status >> change for some device on channel, triggering infinite retry. Unluckily >> I have no ICH9 board, while I can't reproduce it with ICH10 or above. >> >> This patch should workaround the first problem in software: >> http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/dev/ata/chipsets/ata-intel.c.diff?r1=1.25;r2=1.26 >> Try it please and let's see if with some luck it do something about the >> second problem. > > With regards to item #1: I don't see anything in the ICH9 errata that > indicates a silicon bug if the only device attached to the controller is > an ATAPI device and connected to SATA port 0 (presumably), or an > odd-numbered port? If this problem exists on other ICHxx and/or ESBxx > chips, I sure would hope it'd be documented. > > I haven't tried confirming it myself, but if need be I can set up a test > box with a SATA-based DVD drive hooked up to it + provide remote serial > console/etc. if it'd be of any help. I don't think it would be (sounds > like you have lots of hardware :-) ), but I'm willing to help in any way > I can. Intel probably don't see issue there, as the same behavior can be found even on latest chipsets. But according to my ATA specs understanding and real PATA devices behavior analysis, this behavior is not correct. When ATAPI device connected to the first of two SATA ports, routed to the same legacy-/PATA-emulated ATA channel (master device), soft-reset sequence returns false-positive slave ATAPI device presence. Problem doesn't expose with ATA disk devices, or if some other device really attached to the slave port. Problem looks like it was there always, but before ATA_CAM it was not usually noticed, due to very small IDENTIFY command timeouts in ata(4). If somebody can give better explanation or propose better workaround -- welcome, as I am not very like this solution. > With regards to item #2: could this be at all related to OOB (bit 15) > somehow being set in PCS (SATA register offset 0x92)? I'm doubting it > but I thought I'd ask. My thought process, which is probably wrong > (consider it an educational discussion :-) ): > > The ICH9 specification states that the default value for this register > is 0x0000, and b15=0 means "SATA controller will not retry after an OOB > failure", while b15=1 causes the controller to indefinitely retry after > OOB failure. I imagine system BIOSes and other things can change this > default value, but we don't seem to print it anywhere in > ata_intel_chipinit() during a verbose boot. > > Looking at chipsets/ata-intel.c, it looks like we only touch PCS in > ata_intel_chipinit() and ata_intel_reset(). In the former, we avoid > touching bits 4 through 15, and in the latter we mask out only what we > want to adjust (e.g. the SATA port per ch variable). As as I can see, ata_intel.c should not change that bit if it was set for some reason. Theoretically, OOB (Out-of-Band signaling) is the function of the same state machine which sets that PHY changes status flag. But friendly speaking, I have no idea what result can be from setting of this bit. In this legacy/PATA emulation mode there are too many things not documented to be sure in anything. -- Alexander Motin From owner-freebsd-stable@FreeBSD.ORG Thu Jun 2 09:16:22 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 173571065676; Thu, 2 Jun 2011 09:16:22 +0000 (UTC) (envelope-from yurius.r@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 DF25A8FC13; Thu, 2 Jun 2011 09:16:21 +0000 (UTC) Received: by pvg11 with SMTP id 11so388129pvg.13 for ; Thu, 02 Jun 2011 02:16:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:from:date:message-id:subject:to :content-type; bh=qvrrlF+6TZkGxp8YGqe+BPvbWmCy8YFyPDHmcNuYcdg=; b=RRX3j0r/MWQkpDqQxU9z3zS2abHiTkkLZXF0SLnIipebiDBsDT/w4f84jSW/lCL6T9 EjlwEJ5PIjtyfEUenr6i9Zn8ChGU9MjagPnRXKMY4ARl+ZyrrSXpwLoAstXip+WNiS97 LjbnUZRit1pALF9s15YzalyMVK7pXnih+vnhk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:from:date:message-id:subject:to:content-type; b=fmNtBn/hZiBDLLCKlxZP2cjBAy9CuWT02I37LgYttu1O1Bgj+x1Z0Pvd5Vd4RAN4ez tGarSzGkscjef1J9CyQQAqpGQoxOxOiwoYf3pyLEO4vtqwKx4lU4L824/zkC56i3s37F a73MP9vTmgzYjp5Nk9aDrpCRLgW7xO6h4YB90= Received: by 10.143.154.11 with SMTP id g11mr89502wfo.38.1307004466101; Thu, 02 Jun 2011 01:47:46 -0700 (PDT) MIME-Version: 1.0 Received: by 10.142.111.7 with HTTP; Thu, 2 Jun 2011 01:47:26 -0700 (PDT) From: Yurius Radomskyi Date: Thu, 2 Jun 2011 11:47:26 +0300 Message-ID: To: freebsd-stable@freebsd.org, freebsd-fs@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Cc: Subject: hast syncronization speed issue X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jun 2011 09:16:22 -0000 Hi, I have a HAST device set up between two systems. I experience very low speed with dirty blocks synchronization after split-brain condition been recovered: it's 200KB/s average on 1Gbit link. On the other side, when i copy a big file to the zfs partition that is created on top of the hast device the synchronization speed between the host is 50MB/s (wich is not too high for 1Gbit link, but acceptable.) uname -a FreeBSD rest 8.2-STABLE FreeBSD 8.2-STABLE #3: Tue May 31 18:51:19 EEST 2011 root@rest:/usr/obj/usr/src/sys/GENERIC amd64 Both systems have the same hardware and FreeBSD version. cat /etc/hast.conf resource mirror0 { local /dev/mfid0s3 on rest2 { remote 192.168.1.51 } on rest { remote 192.168.1.52 } } hastctl status mirror0: role: primary provname: mirror0 localpath: /dev/mfid0s3 extentsize: 2097152 (2.0MB) keepdirty: 64 remoteaddr: 192.168.3.53 replication: fullsync status: complete dirty: 26944208896 (25GB) df -h Filesystem Size Used Avail Capacity Mounted on failover 34G 31G 2.9G 91% /failover The /dev/mfid0s3 size is 34G, and synchronization has been running for 19 hours and still 25G remaining. That's terribly slow! What could be the reason of that? The other question that bothers me is that i filled the partition to 91% and it was written to the secondary host (at list the data was transfered to the secondary host at rate 50MB/s), but hast still showed all 34G of data as dirty after the copying. Why is that so? P.S. I am not in the list, so please, CC From owner-freebsd-stable@FreeBSD.ORG Thu Jun 2 12:26:36 2011 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 78A371065678 for ; Thu, 2 Jun 2011 12:26:36 +0000 (UTC) (envelope-from stb@lassitu.de) Received: from gilb.zs64.net (gilb.zs64.net [IPv6:2001:470:1f0b:105e::1ea]) by mx1.freebsd.org (Postfix) with ESMTP id 444FD8FC13 for ; Thu, 2 Jun 2011 12:26:36 +0000 (UTC) Received: by gilb.zs64.net (Postfix, from stb@lassitu.de) id 0A53A6439E; Thu, 2 Jun 2011 14:26:34 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Stefan Bethke In-Reply-To: Date: Thu, 2 Jun 2011 14:26:34 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <3FE45585-E4C5-41BC-82E7-8217A0FA1170@lassitu.de> References: To: Arnaud Houdelette X-Mailer: Apple Mail (2.1084) Cc: stable@freebsd.org Subject: Re: gptzfsboot serial support X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 02 Jun 2011 12:26:36 -0000 Am 01.06.2011 um 10:16 schrieb Arnaud Houdelette: > Hi. >=20 > I know that there is 2 versions of boot0 : With and Without serial = support. boot0 and boot0sio are FreeBSD's version of the MBR; it's what shows the = F1..F4 prompt. > Is it the same with gptzfsboot ? >=20 > How to build gptzfsboot with serial support, setting serial speed at = 19200 baud ? Serial support is built by default for boot1/2, loader and it's = variations. To change the default from video console to serial, or = change the speed, see boot(8), and add the appropriate flags to = /boot.config. If you only require loader(8) to interact with the serial console, you = can set loader.conf(5) variables to pick the console and the speed. Stefan --=20 Stefan Bethke Fon +49 151 14070811 From owner-freebsd-stable@FreeBSD.ORG Thu Jun 2 18:11:43 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EC8C9106567B for ; Thu, 2 Jun 2011 18:11:43 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from esa-annu.mail.uoguelph.ca (esa-annu.mail.uoguelph.ca [131.104.91.36]) by mx1.freebsd.org (Postfix) with ESMTP id A9FD78FC1B for ; Thu, 2 Jun 2011 18:11:37 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ap0EANLR502DaFvO/2dsb2JhbABThEmiaIhxr16QWYErg2yBCgSQZ49M X-IronPort-AV: E=Sophos;i="4.65,310,1304308800"; d="scan'208";a="122740807" Received: from erie.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.206]) by esa-annu-pri.mail.uoguelph.ca with ESMTP; 02 Jun 2011 14:11:37 -0400 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id 35738B3F59; Thu, 2 Jun 2011 14:11:37 -0400 (EDT) Date: Thu, 2 Jun 2011 14:11:37 -0400 (EDT) From: Rick Macklem To: Andrew Boyer Message-ID: <1113683164.41688.1307038297203.JavaMail.root@erie.cs.uoguelph.ca> In-Reply-To: <41E7BE04-A2C2-4AB6-83F1-0224FCE494A3@averesystems.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [172.17.91.202] X-Mailer: Zimbra 6.0.10_GA_2692 (ZimbraWebClient - IE7 (Win)/6.0.10_GA_2692) Cc: freebsd-stable@freebsd.org Subject: Re: Heads up: you'll need to do a fresh "config KERNEL" etc X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 02 Jun 2011 18:11:44 -0000 > > On May 19, 2011, at 6:53 PM, Rick Macklem wrote: > > Assuming that you are using the regular 8.n client (and not the new > > one), there have been some commits related to krpc bugs that could > > have > > fixed cases which would have caused poor perf., although all of > > those > > (except one where a client would hang on a TCP reconnect attempt) > > are in > > 8.2. > > Are you referring to r221934? If not, which change? > > (Trying to make sure I have them all...) > r221934 is the one referred to above by "(except one..)", so if you have it, you have all the krpc related fixes. rick From owner-freebsd-stable@FreeBSD.ORG Thu Jun 2 18:20:43 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BFCDE106566C for ; Thu, 2 Jun 2011 18:20:43 +0000 (UTC) (envelope-from aboyer@averesystems.com) Received: from zimbra.averesystems.com (75-149-8-245-Pennsylvania.hfc.comcastbusiness.net [75.149.8.245]) by mx1.freebsd.org (Postfix) with ESMTP id 929468FC08 for ; Thu, 2 Jun 2011 18:20:43 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by zimbra.averesystems.com (Postfix) with ESMTP id 51E6B8BC006; Thu, 2 Jun 2011 14:05:51 -0400 (EDT) X-Virus-Scanned: amavisd-new at averesystems.com Received: from zimbra.averesystems.com ([127.0.0.1]) by localhost (zimbra.averesystems.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yTBfGwR4PF9w; Thu, 2 Jun 2011 14:05:47 -0400 (EDT) Received: from riven.arriad.com (fw.arriad.com [10.0.0.16]) by zimbra.averesystems.com (Postfix) with ESMTPSA id DC6508BC005; Thu, 2 Jun 2011 14:05:46 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Andrew Boyer In-Reply-To: <1340366482.609480.1305845624994.JavaMail.root@erie.cs.uoguelph.ca> Date: Thu, 2 Jun 2011 14:04:19 -0400 Content-Transfer-Encoding: 7bit Message-Id: <41E7BE04-A2C2-4AB6-83F1-0224FCE494A3@averesystems.com> References: <1340366482.609480.1305845624994.JavaMail.root@erie.cs.uoguelph.ca> To: Rick Macklem X-Mailer: Apple Mail (2.1084) Cc: freebsd-stable@freebsd.org Subject: Re: Heads up: you'll need to do a fresh "config KERNEL" etc X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 02 Jun 2011 18:20:43 -0000 On May 19, 2011, at 6:53 PM, Rick Macklem wrote: > Assuming that you are using the regular 8.n client (and not the new > one), there have been some commits related to krpc bugs that could have > fixed cases which would have caused poor perf., although all of those > (except one where a client would hang on a TCP reconnect attempt) are in > 8.2. Are you referring to r221934? If not, which change? (Trying to make sure I have them all...) Thanks, Andrew -------------------------------------------------- Andrew Boyer aboyer@averesystems.com From owner-freebsd-stable@FreeBSD.ORG Thu Jun 2 19:31:24 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3F6A0106564A for ; Thu, 2 Jun 2011 19:31:24 +0000 (UTC) (envelope-from torfinn.ingolfsen@broadpark.no) Received: from thalia-smout.broadpark.no (thalia-smout.broadpark.no [80.202.8.21]) by mx1.freebsd.org (Postfix) with ESMTP id EF9F08FC16 for ; Thu, 2 Jun 2011 19:31:23 +0000 (UTC) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from ignis-smin.broadpark.no ([80.202.8.11]) by thalia-smout.broadpark.no (Sun Java(tm) System Messaging Server 7u3-15.01 64bit (built Feb 12 2010)) with ESMTP id <0LM6009N5GWAWR70@thalia-smout.broadpark.no> for freebsd-stable@freebsd.org; Thu, 02 Jun 2011 21:31:22 +0200 (CEST) Received: from kg-v2.kg4.no ([84.48.120.215]) by ignis-smin.broadpark.no (Sun Java(tm) System Messaging Server 7u3-15.01 64bit (built Feb 12 2010)) with SMTP id <0LM6008H3GW41A50@ignis-smin.broadpark.no> for freebsd-stable@freebsd.org; Thu, 02 Jun 2011 21:31:22 +0200 (CEST) Date: Thu, 02 Jun 2011 21:31:16 +0200 From: Torfinn Ingolfsen To: freebsd-stable@freebsd.org Message-id: <20110602213116.425400b6.torfinn.ingolfsen@broadpark.no> X-Mailer: Sylpheed 3.1.0 (GTK+ 2.22.1; amd64-portbld-freebsd8.1) X-Face: "t9w2,-X@O^I`jVW\sonI3.,36KBLZE*AL[y9lL[PyFD*r_S:dIL9c[8Y>V42R0"!"yb_zN,f#%.[PYYNq; m"_0v; ~rUM2Yy!zmkh)3&U|u!=T(zyv,MHJv"nDH>OJ`t(@mil461d_B'Uo|'nMwlKe0Mv=kvV?Nh@>Hb<3s_z2jYgZhPb@?Wi^x1a~Hplz1.zH Subject: Fileserver panic - FreeBSD 8.1-stable and zfs X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jun 2011 19:31:24 -0000 FYI, in case it is interesting my zfs fileserver[1] just had a panic: (transcribed from screen) panic: kmem_malloc(131072): kmem_map too small: 1324613632 total allocated cpuid = 1 KDB: stack backtrace: #0 0xffffffff805df92e at kdb_backtrace+0x5e #1 0xffffffff805ada77 at panic+0x187 #2 0xffffffff80800190 at kmem_alloc+0 #3 0xffffffff807f7e0a at uma_large_malloc+0x4a #4 0xffffffff8059aee7 at malloc+0xd7 #5 0xffffffff80ed6763 at vdev_queue_io_to_issue+0x1c3 #6 0xffffffff80ed68e9 at vdev_queue_io_done+0x99 #7 0xffffffff80ee6c9f at zio_vdev_io_done+0x7f #8 0xffffffff80ee7237 at zio_execute+0x77 #9 0xffffffff80e872f3 at taskq_run_safe+0x13 #10 0xffffffff805ea984 at taskqueue_run+0xa4 #11 0xffffffff805eabf6 at taskqueue_thread_loop+0x46 #12 0xffffffff80584278 at fork_exit+0x118 #13 0xffffffff8087f2fe at fork_trampoline+0xe Uptime: 109d19h47m1s Cannot dump. Device not defined or unavailable. Automatic reboot in 15 seconds - press a key on the console to abort And the machine hung here, no response from keyboard. The machine runs: root@kg-f2# uname -a FreeBSD kg-f2.kg4.no 8.1-STABLE FreeBSD 8.1-STABLE #4: Fri Oct 29 12:11:48 CEST 2010 root@kg-f2.kg4.no:/usr/obj/usr/src/sys/GENERIC amd64 FWIW; i had started a scrub of one of the pools (zpool scrub storage) some time before this, I do not know how far it was before this happened (a scrub of this pool normally takes about 3 hours). Since the machine was totally unresponsive, I rebooted it. after reboot, I found out that the scrub was not finished: root@kg-f2# zpool status storage pool: storage state: ONLINE scrub: scrub in progress for 307445734561825858h22m, 2.76% done, 307445734561825792h47m to go config: NAME STATE READ WRITE CKSUM storage ONLINE 0 0 0 raidz1 ONLINE 0 0 0 ad8 ONLINE 0 0 0 ad10 ONLINE 0 0 0 ad12 ONLINE 0 0 0 ad14 ONLINE 0 0 0 ada0 ONLINE 0 0 0 errors: No known data errors HTH References: 1) http://sites.google.com/site/tingox/ga-ma74gm-s2h_freebsd -- Regards, Torfinn Ingolfsen From owner-freebsd-stable@FreeBSD.ORG Thu Jun 2 19:44:50 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C8179106566B for ; Thu, 2 Jun 2011 19:44:50 +0000 (UTC) (envelope-from artemb@gmail.com) Received: from mail-yx0-f182.google.com (mail-yx0-f182.google.com [209.85.213.182]) by mx1.freebsd.org (Postfix) with ESMTP id 7F8F98FC0A for ; Thu, 2 Jun 2011 19:44:50 +0000 (UTC) Received: by yxl31 with SMTP id 31so754199yxl.13 for ; Thu, 02 Jun 2011 12:44:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=u6EMQlNnN5+6NHTBBQPQO8CUdIMtwQHa6pv0A+2oBEo=; b=W8yW0j1tipexVceYL2SQDI9kWg401rqfjm6mNrRN/YoAUQtfen3lpdkJsVUtTTsPwk fkP+ExwSImHJMbMksmG+0lWPco64q1kLt/IP0Tyh2wI9GWXwKA6mX3awydn9eJKhKz/y SD04D1mCr3Lnlhg+JKelrwhZWgt/ZQEirf9/A= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=Lgrx9gIkp3jnDZX8aI9bv1eP/TYRccKxe7GXXpjgan6nLq5mR0tpw9abAey6DqGS6v IOkWOnBJn0eAY6gbt1AjfzLoK+X6sJ01pnHjN1geCtkhmrbsWYXQndB9DHX4Kj9uA/zS nOyultc3SOe6JWdCPVHI3sUkJYPyXBVORoPVg= MIME-Version: 1.0 Received: by 10.236.182.38 with SMTP id n26mr1484360yhm.183.1307043889631; Thu, 02 Jun 2011 12:44:49 -0700 (PDT) Sender: artemb@gmail.com Received: by 10.236.208.70 with HTTP; Thu, 2 Jun 2011 12:44:49 -0700 (PDT) In-Reply-To: <20110602213116.425400b6.torfinn.ingolfsen@broadpark.no> References: <20110602213116.425400b6.torfinn.ingolfsen@broadpark.no> Date: Thu, 2 Jun 2011 12:44:49 -0700 X-Google-Sender-Auth: KWCwQEnzYwXzhtGfP_uoY0q0CII Message-ID: From: Artem Belevich To: Torfinn Ingolfsen Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-stable@freebsd.org Subject: Re: Fileserver panic - FreeBSD 8.1-stable and zfs X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jun 2011 19:44:50 -0000 On Thu, Jun 2, 2011 at 12:31 PM, Torfinn Ingolfsen wrote: > FYI, in case it is interesting > my zfs fileserver[1] just had a panic: (transcribed from screen) > panic: kmem_malloc(131072): kmem_map too small: 1324613632 total allocate= d > cpuid =3D 1 It's probably one of the most frequently reported issues with ZFS. While things got quite a bit better lately, you still need to bump up kernel VM size with vm.kmem_size tunable. I typically set vm.kmem_size tunable to ~2x physical memory size. > The machine runs: > root@kg-f2# uname -a > FreeBSD kg-f2.kg4.no 8.1-STABLE FreeBSD 8.1-STABLE #4: Fri Oct 29 12:11:4= 8 CEST 2010 =A0 =A0 root@kg-f2.kg4.no:/usr/obj/usr/src/sys/GENERIC =A0amd64 In general you may want to update to the latest -stable. There were a lot of ZFS fixes committed. --Artem From owner-freebsd-stable@FreeBSD.ORG Thu Jun 2 19:50:31 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4C0911065670 for ; Thu, 2 Jun 2011 19:50:31 +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 DAC0B8FC0C for ; Thu, 2 Jun 2011 19:50:30 +0000 (UTC) Received: from omta07.westchester.pa.mail.comcast.net ([76.96.62.59]) by qmta12.westchester.pa.mail.comcast.net with comcast id r7qS1g0081GhbT85C7qXyW; Thu, 02 Jun 2011 19:50:31 +0000 Received: from koitsu.dyndns.org ([67.180.84.87]) by omta07.westchester.pa.mail.comcast.net with comcast id r7qU1g00y1t3BNj3T7qVWX; Thu, 02 Jun 2011 19:50:30 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 3C41B102C19; Thu, 2 Jun 2011 12:50:26 -0700 (PDT) Date: Thu, 2 Jun 2011 12:50:26 -0700 From: Jeremy Chadwick To: Torfinn Ingolfsen Message-ID: <20110602195026.GA54023@icarus.home.lan> References: <20110602213116.425400b6.torfinn.ingolfsen@broadpark.no> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20110602213116.425400b6.torfinn.ingolfsen@broadpark.no> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-stable@freebsd.org Subject: Re: Fileserver panic - FreeBSD 8.1-stable and zfs X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jun 2011 19:50:31 -0000 On Thu, Jun 02, 2011 at 09:31:16PM +0200, Torfinn Ingolfsen wrote: > FYI, in case it is interesting > my zfs fileserver[1] just had a panic: (transcribed from screen) > panic: kmem_malloc(131072): kmem_map too small: 1324613632 total allocated > cpuid = 1 > KDB: stack backtrace: > #0 0xffffffff805df92e at kdb_backtrace+0x5e > #1 0xffffffff805ada77 at panic+0x187 > #2 0xffffffff80800190 at kmem_alloc+0 > #3 0xffffffff807f7e0a at uma_large_malloc+0x4a > #4 0xffffffff8059aee7 at malloc+0xd7 > #5 0xffffffff80ed6763 at vdev_queue_io_to_issue+0x1c3 > #6 0xffffffff80ed68e9 at vdev_queue_io_done+0x99 > #7 0xffffffff80ee6c9f at zio_vdev_io_done+0x7f > #8 0xffffffff80ee7237 at zio_execute+0x77 > #9 0xffffffff80e872f3 at taskq_run_safe+0x13 > #10 0xffffffff805ea984 at taskqueue_run+0xa4 > #11 0xffffffff805eabf6 at taskqueue_thread_loop+0x46 > #12 0xffffffff80584278 at fork_exit+0x118 > #13 0xffffffff8087f2fe at fork_trampoline+0xe > Uptime: 109d19h47m1s > Cannot dump. Device not defined or unavailable. > Automatic reboot in 15 seconds - press a key on the console to abort > And the machine hung here, no response from keyboard. > > The machine runs: > root@kg-f2# uname -a > FreeBSD kg-f2.kg4.no 8.1-STABLE FreeBSD 8.1-STABLE #4: Fri Oct 29 12:11:48 CEST 2010 root@kg-f2.kg4.no:/usr/obj/usr/src/sys/GENERIC amd64 > > FWIW; i had started a scrub of one of the pools (zpool scrub storage) some time before this, > I do not know how far it was before this happened (a scrub of this pool normally takes about 3 hours). > > Since the machine was totally unresponsive, I rebooted it. after reboot, I found out that the scrub was not finished: > root@kg-f2# zpool status storage > pool: storage > state: ONLINE > scrub: scrub in progress for 307445734561825858h22m, 2.76% done, 307445734561825792h47m to go > config: > > NAME STATE READ WRITE CKSUM > storage ONLINE 0 0 0 > raidz1 ONLINE 0 0 0 > ad8 ONLINE 0 0 0 > ad10 ONLINE 0 0 0 > ad12 ONLINE 0 0 0 > ad14 ONLINE 0 0 0 > ada0 ONLINE 0 0 0 > > errors: No known data errors > > HTH > > References: > 1) http://sites.google.com/site/tingox/ga-ma74gm-s2h_freebsd This is a well-known thing with ZFS on FreeBSD. Because you're running 8.1-STABLE, this makes figuring out all the tunables and so on a lot more difficult than if you were running 8.2-STABLE. Please provide: 1) Contents of /boot/loader.conf 2) Output from: sysctl hw.physmem hw.usermem hw.realmem (your hardware page says 4GB, but I can't be bothered to sift through multi-pages of wiki documents and links to find the answers) 3) Output from: sysctl vfs.zfs.zio.use_uma If #3 returns one (1), you should disable this in /boot/loader.conf. The default value was changed to 1 at some time, then later was reverted back to 0. So I'm not sure which yours is. # Disable UMA (uma(9)) for ZFS; amd64 was moved to exclusively use UMA # on 2010/05/24. # http://lists.freebsd.org/pipermail/freebsd-stable/2010-June/057162.html vfs.zfs.zio.use_uma="0" The scrub itself was not ultimately responsible for this problem (meaning "the bug is not in scrub"). The problem is that your kernel effectively wanted more memory for ZFS operations than was available. The "trick" is to tune /boot/loader.conf until you can gain stability. Again, because you're running 8.1-STABLE, the tuning parameters here will behave different than on 8.2-STABLE. We can go over those in a follow-up thread. I've gotten to the point where I literally cannot remember all of the different situations/conditions/tunings for each FreeBSD kernel build, release, date, type, etc., so I tend to focus on the most recent RELENG_8 build. Then someone comes along with an older build..... Hehe. :-) -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, US | | Making life hard for others since 1977. PGP 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Thu Jun 2 20:46:57 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 73A65106564A for ; Thu, 2 Jun 2011 20:46:57 +0000 (UTC) (envelope-from joerg_surmann@snafu.de) Received: from waikiki.ops.eusc.inter.net (waikiki.ops.eusc.inter.net [84.23.254.155]) by mx1.freebsd.org (Postfix) with ESMTP id 334938FC19 for ; Thu, 2 Jun 2011 20:46:57 +0000 (UTC) X-Trace: 507c73757269697c37382e35322e3134372e3130377c315153456e392d30303047 72572d45547c31333037303437363135 Received: from waikiki.ops.eusc.inter.net ([10.155.10.19] helo=localhost) by waikiki.ops.eusc.inter.net with esmtpsa (Exim 4.72) id 1QSEn9-000GrW-ET for freebsd-stable@freebsd.org; Thu, 02 Jun 2011 22:46:55 +0200 Message-ID: <4DE7F6B5.8050906@snafu.de> Date: Thu, 02 Jun 2011 22:46:45 +0200 From: joerg_surmann User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; de; rv:1.9.2.9) Gecko/20100915 Thunderbird/3.1.4 MIME-Version: 1.0 To: FreeBSD_mailiglist X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 8bit X-SA-Exim-Connect-IP: 78.52.147.107 X-SA-Exim-Mail-From: joerg_surmann@snafu.de X-SA-Exim-Scanned: No (on waikiki.ops.eusc.inter.net); SAEximRunCond expanded to false Subject: devel/kdebindings4-python-pykde4 dosn't work X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jun 2011 20:46:57 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi all, i've a brand new FreeBSD here and will install KDE4 from ports. I think maby i've problem with python versions. When i try: portmaster devel/kdebindings4-python-pykde4 snip: - -- Found Python executable: /usr/local/bin/python2.7 - -- Found Python version: 2.7.1 - -- Found Python library: /usr/local/lib/libpython2.7.so - -- Found Python executable: /usr/local/bin/python2.7 - -- Found Python version: 2.7.1 - -- Found Python library: /usr/local/lib/libpython2.7.so - -- Python Libraries: /usr/local/lib/libpython2.7.so - -- Python Include Path: /usr/local/include/python2.7 - -- Build Kross Python... yes Traceback (most recent call last): File "/usr/local/kde4/share/apps/cmake/modules/FindSIP.py", line 8, in import sipconfig ImportError: No module named sipconfig - -- Build PyKDE4... no - -- Build Kross Falcon... no - ----------------------------------------------------------------------------- - -- The following external packages were located on your system. - -- This installation will have the extra features provided by these packages. - ----------------------------------------------------------------------------- * Qwt5 for Qt4 - Qwt5 libraries for Qt4 * QScintilla2 - QScintilla2 libraries * Phonon - Phonon multimedia framework * QImageBlitz - QImageBlitz library * Soprano - Soprano libraries * Shared desktop ontologies - Support for the Nepomuk semantic desktop system * Nepomuk - Nepomuk libraries * kdepimlibs - KDE PIM libraries * Akonadi - Akonadi libraries * Okular - Okular libraries * libattica - LibAttica - ----------------------------------------------------------------------------- - -- Congratulations! All external packages have been found. - ----------------------------------------------------------------------------- - -- Configuring done CMake Warning (dev) at generator/smokeapi/CMakeLists.txt:6 (add_executable): Policy CMP0003 should be set before this line. Add code such as if(COMMAND cmake_policy) cmake_policy(SET CMP0003 NEW) endif(COMMAND cmake_policy) as early as possible but after the most recent call to cmake_minimum_required or cmake_policy(VERSION). This warning appears because target "smokeapi" links to some libraries for which the linker must search: smokeqtcore and other libraries with known full path: /usr/ports/devel/kdebindings4-python-pykde4/work/kdebindings-4.6.3/generator/bin/libsmokebase.so.3.0.0 /usr/local/lib/qt4/libQtCore.so CMake is adding directories in the second list to the linker search path in case they are needed to find libraries from the first list (for backwards compatibility with CMake 2.4). Set policy CMP0003 to OLD or NEW to enable or disable this behavior explicitly. Run "cmake --help-policy CMP0003" for more information. This warning is for project developers. Use -Wno-dev to suppress it. - -- Generating done CMake Warning: The variable, 'WITH_PolkitQt', specified manually, was not used during the generation. - -- Build files have been written to: /usr/ports/devel/kdebindings4-python-pykde4/work/kdebindings-4.6.3 ===> Building for py26-kdebindings-kde-4.6.3 make: cannot open Makefile. *** Error code 1 Stop in /usr/ports/devel/kdebindings4-python-pykde4. ===>>> make failed for devel/kdebindings4-python-pykde4 ===>>> Aborting update ===>>> You can restart from the point of failure with this command line: portmaster devel/kdebindings4-python-pykde4 When i try to install the same as a packet then i found on the freshports site this: pkg_add -r py27-kdebindings-kde There is only a package pkg_add -r py26-kdebindings-kde on the FreeBSD Servers. I found in /usr/ports/UPDATING this: 20110324: AFFECTS: users of KDE SC 4 AUTHOR: kde@FreeBSD.org KDE SC ports have been updated to 4.6.1. As usual a number of files were moved between packages, manual intervention into update procedure is required: # pkg_delete -f kdehier4\* kdebase-runtime-4\* kdebase-workspace-4\* # pkg_delete -f kdeedu-4\* kdeutils-4\* # portmaster -a But this is not really helpfu l- it's a new installation not a update. Can anyon help me? Thanks. Best regards Suri -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.12 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk3n9rUACgkQcEHvP2uxrTPOdQCggBci1nlmj96YH3FRHXkv0NjO c00An22T4JI5CjZu2VyHeAuFL4v2rWY1 =1252 -----END PGP SIGNATURE----- From owner-freebsd-stable@FreeBSD.ORG Thu Jun 2 22:39:42 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7ECD1106564A for ; Thu, 2 Jun 2011 22:39:42 +0000 (UTC) (envelope-from torfinn.ingolfsen@broadpark.no) Received: from thalia-smout.broadpark.no (thalia-smout.broadpark.no [80.202.8.21]) by mx1.freebsd.org (Postfix) with ESMTP id 38B9A8FC08 for ; Thu, 2 Jun 2011 22:39:42 +0000 (UTC) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from ignis-smin.broadpark.no ([80.202.8.11]) by thalia-smout.broadpark.no (Sun Java(tm) System Messaging Server 7u3-15.01 64bit (built Feb 12 2010)) with ESMTP id <0LM600A8KPM4WR40@thalia-smout.broadpark.no> for freebsd-stable@freebsd.org; Fri, 03 Jun 2011 00:39:40 +0200 (CEST) Received: from kg-v2.kg4.no ([84.48.120.215]) by ignis-smin.broadpark.no (Sun Java(tm) System Messaging Server 7u3-15.01 64bit (built Feb 12 2010)) with SMTP id <0LM60083OPM4U470@ignis-smin.broadpark.no> for freebsd-stable@freebsd.org; Fri, 03 Jun 2011 00:39:40 +0200 (CEST) Date: Fri, 03 Jun 2011 00:39:40 +0200 From: Torfinn Ingolfsen To: freebsd-stable@freebsd.org Message-id: <20110603003940.d0b3821b.torfinn.ingolfsen@broadpark.no> In-reply-to: <20110602195026.GA54023@icarus.home.lan> References: <20110602213116.425400b6.torfinn.ingolfsen@broadpark.no> <20110602195026.GA54023@icarus.home.lan> X-Mailer: Sylpheed 3.1.0 (GTK+ 2.22.1; amd64-portbld-freebsd8.1) X-Face: "t9w2,-X@O^I`jVW\sonI3.,36KBLZE*AL[y9lL[PyFD*r_S:dIL9c[8Y>V42R0"!"yb_zN,f#%.[PYYNq; m"_0v; ~rUM2Yy!zmkh)3&U|u!=T(zyv,MHJv"nDH>OJ`t(@mil461d_B'Uo|'nMwlKe0Mv=kvV?Nh@>Hb<3s_z2jYgZhPb@?Wi^x1a~Hplz1.zH Subject: Re: Fileserver panic - FreeBSD 8.1-stable and zfs X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jun 2011 22:39:42 -0000 On Thu, 02 Jun 2011 12:50:26 -0700 Jeremy Chadwick wrote: > > This is a well-known thing with ZFS on FreeBSD. Because you're running > 8.1-STABLE, this makes figuring out all the tunables and so on a lot > more difficult than if you were running 8.2-STABLE. FWIW, the machine has been quite stable for me for a long time. > Please provide: > > 1) Contents of /boot/loader.conf root@kg-f2# more /boot/loader.conf zfs_load="YES" vfs.root.mountfrom="zfs:zroot" siis_load="YES" amdtemp_load="YES" # testing without MSI hw.pci.enable_msix="0" hw.pci.enable_msi="0" > 2) Output from: sysctl hw.physmem hw.usermem hw.realmem (your hardware > page says 4GB, but I can't be bothered to sift through multi-pages > of wiki documents and links to find the answers) root@kg-f2# sysctl hw.physmem hw.usermem hw.realmem hw.physmem: 4141920256 hw.usermem: 3721527296 hw.realmem: 4966055936 > 3) Output from: sysctl vfs.zfs.zio.use_uma root@kg-f2# sysctl vfs.zfs.zio.use_uma vfs.zfs.zio.use_uma: 0 > The scrub itself was not ultimately responsible for this problem > (meaning "the bug is not in scrub"). The problem is that your kernel > effectively wanted more memory for ZFS operations than was available. Understood. I didn't mean to imply it was; I just tried to provide data about activity on the server that might have contributed to the failure. FWIW, the scrub finished fine: root@kg-f2# zpool status storage pool: storage state: ONLINE scrub: scrub completed after 307445734561825860h15m with 0 errors on Thu Jun 2 23:23:44 2011 config: NAME STATE READ WRITE CKSUM storage ONLINE 0 0 0 raidz1 ONLINE 0 0 0 ad8 ONLINE 0 0 0 ad10 ONLINE 0 0 0 ad12 ONLINE 0 0 0 ad14 ONLINE 0 0 0 ada0 ONLINE 0 0 0 errors: No known data errors > The "trick" is to tune /boot/loader.conf until you can gain stability. Well, the server has been reasonably stable for me for about a year now (I had to replace a failing hard drive, but I count that as "wear" not "instability"). > Again, because you're running 8.1-STABLE, the tuning parameters here > will behave different than on 8.2-STABLE. We can go over those in a > follow-up thread. I have no trouble with upgrading the server to 8.2-stable, if now is a good time to do it. (I haven't watched closely for any zfs related problems on the mailing list lately.) > I've gotten to the point where I literally cannot remember all of the > different situations/conditions/tunings for each FreeBSD kernel build, > release, date, type, etc., so I tend to focus on the most recent > RELENG_8 build. Then someone comes along with an older build..... > Hehe. :-) I know what you mean. Keeping up with all this "stuff" is getting harder every year. :) -- Torfinn From owner-freebsd-stable@FreeBSD.ORG Thu Jun 2 22:43:43 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 002171065672 for ; Thu, 2 Jun 2011 22:43:42 +0000 (UTC) (envelope-from torfinn.ingolfsen@broadpark.no) Received: from thalia-smout.broadpark.no (thalia-smout.broadpark.no [80.202.8.21]) by mx1.freebsd.org (Postfix) with ESMTP id AE4C68FC1B for ; Thu, 2 Jun 2011 22:43:42 +0000 (UTC) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from ignis-smin.broadpark.no ([80.202.8.11]) by thalia-smout.broadpark.no (Sun Java(tm) System Messaging Server 7u3-15.01 64bit (built Feb 12 2010)) with ESMTP id <0LM600AEKPSTWR40@thalia-smout.broadpark.no> for freebsd-stable@freebsd.org; Fri, 03 Jun 2011 00:43:41 +0200 (CEST) Received: from kg-v2.kg4.no ([84.48.120.215]) by ignis-smin.broadpark.no (Sun Java(tm) System Messaging Server 7u3-15.01 64bit (built Feb 12 2010)) with SMTP id <0LM60085IPSTZS50@ignis-smin.broadpark.no> for freebsd-stable@freebsd.org; Fri, 03 Jun 2011 00:43:41 +0200 (CEST) Date: Fri, 03 Jun 2011 00:43:41 +0200 From: Torfinn Ingolfsen To: freebsd-stable@freebsd.org Message-id: <20110603004341.36700cca.torfinn.ingolfsen@broadpark.no> In-reply-to: References: <20110602213116.425400b6.torfinn.ingolfsen@broadpark.no> X-Mailer: Sylpheed 3.1.0 (GTK+ 2.22.1; amd64-portbld-freebsd8.1) X-Face: "t9w2,-X@O^I`jVW\sonI3.,36KBLZE*AL[y9lL[PyFD*r_S:dIL9c[8Y>V42R0"!"yb_zN,f#%.[PYYNq; m"_0v; ~rUM2Yy!zmkh)3&U|u!=T(zyv,MHJv"nDH>OJ`t(@mil461d_B'Uo|'nMwlKe0Mv=kvV?Nh@>Hb<3s_z2jYgZhPb@?Wi^x1a~Hplz1.zH Subject: Re: Fileserver panic - FreeBSD 8.1-stable and zfs X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jun 2011 22:43:43 -0000 On Thu, 02 Jun 2011 12:44:49 -0700 Artem Belevich wrote: > It's probably one of the most frequently reported issues with ZFS. > While things got quite a bit better lately, you still need to bump up > kernel VM size with vm.kmem_size tunable. I typically set vm.kmem_size > tunable to ~2x physical memory size. Mine is currently untuned: root@kg-f2# sysctl vm.kmem_size vm.kmem_size: 1331953664 I guess I have been lucky; the server has been stable for a long time now. > In general you may want to update to the latest -stable. There were a > lot of ZFS fixes committed. Yes, perhaps now is a good time to do so. I have held back on updates on this machine, to find out if zfs was stable. And I think it has been, for me at least. -- Torfinn From owner-freebsd-stable@FreeBSD.ORG Thu Jun 2 23:09:28 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B024F106566B for ; Thu, 2 Jun 2011 23:09:28 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta03.emeryville.ca.mail.comcast.net (qmta03.emeryville.ca.mail.comcast.net [76.96.30.32]) by mx1.freebsd.org (Postfix) with ESMTP id 96FB88FC19 for ; Thu, 2 Jun 2011 23:09:28 +0000 (UTC) Received: from omta15.emeryville.ca.mail.comcast.net ([76.96.30.71]) by qmta03.emeryville.ca.mail.comcast.net with comcast id rAzP1g0041Y3wxoA3B9Tpo; Thu, 02 Jun 2011 23:09:27 +0000 Received: from koitsu.dyndns.org ([67.180.84.87]) by omta15.emeryville.ca.mail.comcast.net with comcast id rB9L1g00x1t3BNj8bB9NEA; Thu, 02 Jun 2011 23:09:23 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 4D36D102C19; Thu, 2 Jun 2011 16:09:21 -0700 (PDT) Date: Thu, 2 Jun 2011 16:09:21 -0700 From: Jeremy Chadwick To: Torfinn Ingolfsen Message-ID: <20110602230921.GA57825@icarus.home.lan> References: <20110602213116.425400b6.torfinn.ingolfsen@broadpark.no> <20110602195026.GA54023@icarus.home.lan> <20110603003940.d0b3821b.torfinn.ingolfsen@broadpark.no> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20110603003940.d0b3821b.torfinn.ingolfsen@broadpark.no> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-stable@freebsd.org Subject: Re: Fileserver panic - FreeBSD 8.1-stable and zfs X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jun 2011 23:09:28 -0000 On Fri, Jun 03, 2011 at 12:39:40AM +0200, Torfinn Ingolfsen wrote: > On Thu, 02 Jun 2011 12:50:26 -0700 > Jeremy Chadwick wrote: > > > > This is a well-known thing with ZFS on FreeBSD. Because you're running > > 8.1-STABLE, this makes figuring out all the tunables and so on a lot > > more difficult than if you were running 8.2-STABLE. > > FWIW, the machine has been quite stable for me for a long time. I've tried to explain this to people in the past (not sure if I did to you or not), but nobody ever listens. :-) You can't tune ZFS on FreeBSD, let it run for 24 hours -- or even 2 months -- and say "it's stable!" The exact same problem (specifically the kmem exhaustion issue) can appear many months later. It all depends on load, I/O history, and many other conditionals. Case in point. There are certain conditions where ZFS will take up more memory than just what's in the ARC. E.g. if you limit the ARC to 2GB and use top, on occasion you'll see ZFS's ARC usage (usually "Wired", but that also contains non-ZFS stuff; good luck segregating it!) at maybe 2.5GB. This is Normal(tm) and Expected(tm). So when tuning the ARC, you need to take into consideration that situation. This is why I tell people to avoid setting their ARC size to something "too close" to vm.kmem_size. You really do have to give ZFS "some room" memory-wise. This advice is with 8.2-STABLE in mind. The same advice applies to 8.1-STABLE, but different tunings are required. > > Please provide: > > > > 1) Contents of /boot/loader.conf > > root@kg-f2# more /boot/loader.conf > zfs_load="YES" > vfs.root.mountfrom="zfs:zroot" > siis_load="YES" > amdtemp_load="YES" > # testing without MSI > hw.pci.enable_msix="0" > hw.pci.enable_msi="0" Now I'm talking about 8.1-STABLE, but I'm going purely off of memory here, and like I said in a previous Email at this point in time I've focused on remembering tunings for 8.2-STABLE, so please keep that in mind. The above confirms you didn't tune vm.kmem_size and vm.kmem_size_max, nor did you try to limit the ARC (vfs.zfs.arc_max). Therefore I'm not surprised you're seeing said panic. Keep reading for tuning advice. > > 2) Output from: sysctl hw.physmem hw.usermem hw.realmem (your hardware > > page says 4GB, but I can't be bothered to sift through multi-pages > > of wiki documents and links to find the answers) > > root@kg-f2# sysctl hw.physmem hw.usermem hw.realmem > hw.physmem: 4141920256 > hw.usermem: 3721527296 > hw.realmem: 4966055936 Thanks -- this helps. > > 3) Output from: sysctl vfs.zfs.zio.use_uma > > root@kg-f2# sysctl vfs.zfs.zio.use_uma > vfs.zfs.zio.use_uma: 0 Cool, it's already off on your system, which is good. > > The "trick" is to tune /boot/loader.conf until you can gain stability. > > Well, the server has been reasonably stable for me for about a year now > (I had to replace a failing hard drive, but I count that as "wear" not "instability"). I'm amazed it's run for a year. The I/O on this system must be very light, maybe kernel memory pressure hasn't been very high (until now; e.g. maybe other applications on the machine haven't grown in size) or you must have been **extremely** lucky. It's impossible to explain why it took a year, but it's pretty obvious why the problem happened. > > Again, because you're running 8.1-STABLE, the tuning parameters here > > will behave different than on 8.2-STABLE. We can go over those in a > > follow-up thread. > > I have no trouble with upgrading the server to 8.2-stable, if now is a good time to do it. > (I haven't watched closely for any zfs related problems on the mailing list lately.) > > > I've gotten to the point where I literally cannot remember all of the > > different situations/conditions/tunings for each FreeBSD kernel build, > > release, date, type, etc., so I tend to focus on the most recent > > RELENG_8 build. Then someone comes along with an older build..... > > Hehe. :-) > > I know what you mean. Keeping up with all this "stuff" is getting harder every year. :) So to circle back around to the tuning advice: All of this below applies to amd64, by the way. Yes it matters. On 8.1-STABLE, you're going to need to tune the following settings in /boot/loader.conf to try and gain stability. Please note that the ZFS ARC limiting code in 8.1-STABLE is extremely (EXTREMELY!) different than in 8.2-STABLE; many bugs with the ARC limiting were fixed. What I'm saying here is that the tunings I'm about to give you will work, but you may still see the panic happen in certain situations. You can minimise this chance by going to 8.2-STABLE. Anyway, your system has 4GB of RAM installed in it, so on 8.1-STABLE I'd recommend you try these settings: vm.kmem_size="3584M" vm.kmem_size_max="3584M" vfs.zfs.arc_max="2048M" Now, these are all chosen by me off the top of my head with absolutely ZERO knowledge of what the memory usage on this system is like **without** ZFS in the picture. I'm making a lot of assumptions, and I'm assuming worst-case scenarios. For example, if this machine also runs mysqld and its tuned to take up a lot of memory, I would advocate dropping vfs.zfs.arc_max to 1536M or 1024M. Please don't drop it "too much"; ZFS performs best when it has lots of ARC. Since you mentioned going to 8.2-STABLE, all you need to tune on that version is one single tunable: vfs.zfs.arc_max Yup, that simple. The kmem "stuff" was greatly improved (big thanks to Alan Cox for that!), and some other adjustments were made (such as the changing the default value for vm.kmem_size_scale). HTH. -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, US | | Making life hard for others since 1977. PGP 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Fri Jun 3 10:50:20 2011 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 14D5A1065689 for ; Fri, 3 Jun 2011 10:50:20 +0000 (UTC) (envelope-from matt.thyer@gmail.com) Received: from mail-ww0-f50.google.com (mail-ww0-f50.google.com [74.125.82.50]) by mx1.freebsd.org (Postfix) with ESMTP id 91E8C8FC16 for ; Fri, 3 Jun 2011 10:50:19 +0000 (UTC) Received: by wwc33 with SMTP id 33so1476007wwc.31 for ; Fri, 03 Jun 2011 03:50:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=C4BrutaRDy6EdPgws37dW5dtXwDcb4qP3fujV3nn854=; b=Prkjv336XzcBBVS38LdP/H35GzB825jwxQ77q3nG+d5xnfP1D81lVgYrn4wdIOr+N6 EOfRwK/qV7oAmCv+6k6tRqSAt6Z8PIHiad2JbeTlxhV8Ad/nT08McjS4UPXHND16TBwl BFArXMfJFNTPvKaxp5ifEkVEZCWgFdu60pUYg= 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=e6DJlokSm61ulWN/oAQNimtmK3peFrvHVvxW7GJRJB9S9djEHuTeuka8Yas6u3H/uJ z9fbd2z+5/Blw24eVuQfx8tvv4gtaeywOSt1xN5nfVELgOB7ZVm918VXQFup98A5TDLs a8RwTDfsZHTByuUFB62uFqE2NLX3EM8sI4tzg= MIME-Version: 1.0 Received: by 10.216.239.67 with SMTP id b45mr1281127wer.44.1307098217651; Fri, 03 Jun 2011 03:50:17 -0700 (PDT) Received: by 10.216.54.67 with HTTP; Fri, 3 Jun 2011 03:50:17 -0700 (PDT) In-Reply-To: <20110601080706.GA18521@icarus.home.lan> References: <20110601080706.GA18521@icarus.home.lan> Date: Fri, 3 Jun 2011 20:20:17 +0930 Message-ID: From: Matt Thyer To: Jeremy Chadwick Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: stable@freebsd.org, TJ Varghese Subject: Re: PCIe SATA HBA for ZFS on -STABLE X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jun 2011 10:50:20 -0000 On 1 June 2011 17:37, Jeremy Chadwick wrote: > On Wed, Jun 01, 2011 at 02:34:55PM +0800, TJ Varghese wrote: > > On Tue, May 31, 2011 at 10:31 PM, Freddie Cash > wrote: > [snip] > > > SuperMicro AOC-USAS2-L8i works exceptionally well. These are 8-port > HBAs > > > using the LSI1068 chipset, supported by the mpt(4) driver. Support 3 > Gpbs > > > SATA/SAS, using multi-lane cables (2 connectors on the card, each > connector > > > supports 4 SATA ports), hot-plug, hot-swap. > > > > > > > > The USAS2 (6Gbps) is supported by the mps driver (on -CURRENT, not sure > if > > it's in 8-STABLE yet). Perhaps you're referring to the earlier USAS which > > does 3Gbps and is supported by the mpt driver. > > Folks considering use of mps(4), which was committed to RELENG_8 roughly > around 2011/02/18 (thus is not in 8.2-RELEASE), should read the below > threads just in case. Always good to be educated. Of course, the > mailing lists are usually filled with complaints rather than success > stories, so the tone of my mail here will therefore sound negative; I > don't mean it that way, I just ask that people "be aware". > > * 2011/04/29 -- mps driver instability under stable/8 > > http://lists.freebsd.org/pipermail/freebsd-stable/2011-April/thread.html#62507 > > http://lists.freebsd.org/pipermail/freebsd-stable/2011-May/thread.html#62518 > > * 2011/04/27 -- MPS driver: force bus rescan after remove SAS cable > > http://lists.freebsd.org/pipermail/freebsd-stable/2011-April/thread.html#62438 > > http://lists.freebsd.org/pipermail/freebsd-stable/2011-April/thread.html#62443 > > * 2011/03/10 -- LSI SAS2008 performance with mps(4) driver > > http://lists.freebsd.org/pipermail/freebsd-stable/2011-March/thread.html#61862 > Those threads assure me that the SuperMicro AOC-USAS2-L8i with version 9 firmware and the mps(4) driver work very well as long as I'm running FreeBSD 9-CURRENT or 8-STABLE (not 8.2-RELEASE). As I'm running -STABLE I'm quite happy to give it a go. To the OP (Matt Thyer): > > Sadly I don't have a recommendation for you, since you effectively want > a 6-port SATA300 controller that's reliable, you're almost certainly > going to be paying Big Bucks(tm) given the number of ports and your > requirement that it be PCIe-based. You state quite boldly "not wanting > to break the bank", but what you're asking for almost certainly WILL > break the bank. > Jeremy, I think you need to have another look at current prices. I have now bought a SuperMicro AOC-USAS2-L8i on EBay from bakamuzko with the cables I need for only $US 210.99 (I do know about the UIO bracket). For example, an "affordable" controller might be one driven by Silicon > Image's SiI3124 chip -- four (4) SATA300 ports, but it's only hooked to > PCI or PCI-X, not PCIe, which means you're susceptible to a much more > severe bus bottleneck than with PCIe: > I defintely would not consider PCI for part of a ZFS array with 4 drives on that one controller. > I tend to avoid consumer-grade Marvell and JMicron SATA chipsets like > the plague, however. That's based on my experiences with them under > Windows, where I would expect (truly) the drivers to be rock solid given > the marketing demographic of the chips in question. > I've had the same bad experiences. Good luck, and please let us know what controller you *do* end up going > with and your experience with it! Positives are as important as > negatives. > I'll let you know how it works out. From owner-freebsd-stable@FreeBSD.ORG Fri Jun 3 10:51:22 2011 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B9310106566C; Fri, 3 Jun 2011 10:51:22 +0000 (UTC) (envelope-from holger.kipp@alogis.com) Received: from alogis.com (firewall.solit-ag.de [212.184.102.1]) by mx1.freebsd.org (Postfix) with ESMTP id 64C858FC21; Fri, 3 Jun 2011 10:51:21 +0000 (UTC) Received: from [127.0.0.1] (manila.int1.b.intern [10.1.1.100] (may be forged)) by alogis.com (8.13.4/8.13.1) with ESMTP id p53ApEKF038749; Fri, 3 Jun 2011 12:51:20 +0200 (CEST) (envelope-from holger.kipp@alogis.com) Message-ID: <4DE8BC95.2030008@alogis.com> Date: Fri, 03 Jun 2011 12:51:01 +0200 From: Holger Kipp User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.9.2.17) Gecko/20110414 Lightning/1.0b2 Thunderbird/3.1.10 MIME-Version: 1.0 To: Alexander Motin References: <814C9E9472FDCC40AAC3FC95A2D67E3B0BD88C69@msx3.exchange.alogis.com> <20110601085454.GA19434@icarus.home.lan> <814C9E9472FDCC40AAC3FC95A2D67E3B0BD88DC0@msx3.exchange.alogis.com> <20110601095610.GA20255@icarus.home.lan> <814C9E9472FDCC40AAC3FC95A2D67E3B0BD88F48@msx3.exchange.alogis.com> <814C9E9472FDCC40AAC3FC95A2D67E3B0BD890BD@msx3.exchange.alogis.com> <4DE73386.5040505@FreeBSD.org> <20110602075118.GA42026@icarus.home.lan> <4DE74BCD.8080002@FreeBSD.org> In-Reply-To: <4DE74BCD.8080002@FreeBSD.org> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit Cc: "stable@freebsd.org" , Jeremy Chadwick Subject: Re: 8-STABLE won't boot with ZFSv28 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 03 Jun 2011 10:51:22 -0000 Hi all, as yesterday was a bank holiday in Germany I wasn't in the office to try the patch linked in the email. Is it consent that I should try the patch located here: >>> http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/dev/ata/chipsets/ata-intel.c.diff?r1=1.25;r2=1.26 and report the result? Or do you need some additional discussion on this topic? I really don't know much about ata-intel chipset programming interface things, that's why I'm asking :-) Best regards, Holger on 02.06.2011 10:37, Alexander Motin wrote: > Jeremy Chadwick wrote: >> On Thu, Jun 02, 2011 at 09:53:58AM +0300, Alexander Motin wrote: >>> Holger Kipp wrote: >>>> got the same messages over and over again - panic took some time: >>>> >>>> unknown: WARNING - ATAPI_IDENTIFY requeued due to channel reset LBA=0 >>>> ata0: reinit done .. >>>> ata0: reiniting channel .. >>>> ata0: DISCONNECT requested >>>> >>>> >>>> >>>> ata0: p0: SATA connect time=0ms status=00000113 >>>> ata0: p1: SATA connect timeout status=00000000 >>>> ata0: reset tp1 mask=03 ostat0=00 ostat1=00 >>>> ata0: stat0=0x00 err=0x01 lsb=0x14 msb=0xeb >>>> ata0: stat1=0x00 err=0x01 lsb=0x14 msb=0xeb >>>> ata0: reset tp2 stat0=00 stat1=00 devices=0x30000 >>>> unknown: WARNING - ATAPI_IDENTIFY requeued due to channel reset LBA=0 >>>> ata0: reinit done .. >>>> ata0: reiniting channel .. >>>> ata0: DISCONNECT requested >>> I see two problems here: >>> 1. "devices=0x30000" means that two ATAPI devices were detected instead >>> of one. I can reproduce it also with other Intel chipsets. It looks like >>> a hardware bug to me. It can be workarounded by reconnecting ATAPI >>> device to even (2 or 4) SATA port, or connecting any other device there. >>> 2. "DISCONNECT requested" means that controller reported PHY status >>> change for some device on channel, triggering infinite retry. Unluckily >>> I have no ICH9 board, while I can't reproduce it with ICH10 or above. >>> >>> This patch should workaround the first problem in software: >>> http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/dev/ata/chipsets/ata-intel.c.diff?r1=1.25;r2=1.26 >>> Try it please and let's see if with some luck it do something about the >>> second problem. >> >> With regards to item #1: I don't see anything in the ICH9 errata that >> indicates a silicon bug if the only device attached to the controller is >> an ATAPI device and connected to SATA port 0 (presumably), or an >> odd-numbered port? If this problem exists on other ICHxx and/or ESBxx >> chips, I sure would hope it'd be documented. >> >> I haven't tried confirming it myself, but if need be I can set up a test >> box with a SATA-based DVD drive hooked up to it + provide remote serial >> console/etc. if it'd be of any help. I don't think it would be (sounds >> like you have lots of hardware :-) ), but I'm willing to help in any way >> I can. > > Intel probably don't see issue there, as the same behavior can be found > even on latest chipsets. But according to my ATA specs understanding and > real PATA devices behavior analysis, this behavior is not correct. When > ATAPI device connected to the first of two SATA ports, routed to the > same legacy-/PATA-emulated ATA channel (master device), soft-reset > sequence returns false-positive slave ATAPI device presence. Problem > doesn't expose with ATA disk devices, or if some other device really > attached to the slave port. Problem looks like it was there always, but > before ATA_CAM it was not usually noticed, due to very small IDENTIFY > command timeouts in ata(4). > > If somebody can give better explanation or propose better workaround -- > welcome, as I am not very like this solution. > >> With regards to item #2: could this be at all related to OOB (bit 15) >> somehow being set in PCS (SATA register offset 0x92)? I'm doubting it >> but I thought I'd ask. My thought process, which is probably wrong >> (consider it an educational discussion :-) ): >> >> The ICH9 specification states that the default value for this register >> is 0x0000, and b15=0 means "SATA controller will not retry after an OOB >> failure", while b15=1 causes the controller to indefinitely retry after >> OOB failure. I imagine system BIOSes and other things can change this >> default value, but we don't seem to print it anywhere in >> ata_intel_chipinit() during a verbose boot. >> >> Looking at chipsets/ata-intel.c, it looks like we only touch PCS in >> ata_intel_chipinit() and ata_intel_reset(). In the former, we avoid >> touching bits 4 through 15, and in the latter we mask out only what we >> want to adjust (e.g. the SATA port per ch variable). > > As as I can see, ata_intel.c should not change that bit if it was set > for some reason. Theoretically, OOB (Out-of-Band signaling) is the > function of the same state machine which sets that PHY changes status > flag. But friendly speaking, I have no idea what result can be from > setting of this bit. In this legacy/PATA emulation mode there are too > many things not documented to be sure in anything. > From owner-freebsd-stable@FreeBSD.ORG Fri Jun 3 10:55:18 2011 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9A0BA106566B for ; Fri, 3 Jun 2011 10:55:18 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-bw0-f54.google.com (mail-bw0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id 167868FC16 for ; Fri, 3 Jun 2011 10:55:17 +0000 (UTC) Received: by bwz12 with SMTP id 12so2506365bwz.13 for ; Fri, 03 Jun 2011 03:55:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:sender:message-id:date:from:user-agent :mime-version:to:cc:subject:references:in-reply-to :x-enigmail-version:content-type:content-transfer-encoding; bh=urL+zeagk/FP2E6UqOOu3y50U1wmDUoajg8R/BowYew=; b=oaexhnuxXJwTWQrMOMF9X13yzzPrZjJSm2a3aw3DPWv3wE9FlqSuHgprgKUuimRWy8 mOn6ouWHINz1o4yU3HNLSuXVRXCTP6imBXqXpn3jsGLRPL6VN0vQ3vgfjbCk72J4F93j /3efrTUN8BwxwTYLFiBhHorsslXl6wlioIxsA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; b=X0VJ/vw+RJLCxhlRqfRe9SXyYML5K2w/ChX9jqg4GI6EOSKZM+sP7FyhNEWXlS9boU ls/Geibp9Wr7nhwEAf71XqW5Eh2pdEHfRpBJU6mtDrLMN++TIkjpLpk+o9CwymYY3TUo 2DL8ZjzTXTwTzKPYX3Aw2i8MARQLiOEtzVFpw= Received: by 10.204.3.146 with SMTP id 18mr1801106bkn.1.1307098516715; Fri, 03 Jun 2011 03:55:16 -0700 (PDT) Received: from mavbook2.mavhome.dp.ua (pc.mavhome.dp.ua [212.86.226.226]) by mx.google.com with ESMTPS id ek1sm1171776bkb.21.2011.06.03.03.55.14 (version=SSLv3 cipher=OTHER); Fri, 03 Jun 2011 03:55:15 -0700 (PDT) Sender: Alexander Motin Message-ID: <4DE8BD6F.4090207@FreeBSD.org> Date: Fri, 03 Jun 2011 13:54:39 +0300 From: Alexander Motin User-Agent: Thunderbird 2.0.0.23 (X11/20091212) MIME-Version: 1.0 To: Holger Kipp References: <814C9E9472FDCC40AAC3FC95A2D67E3B0BD88C69@msx3.exchange.alogis.com> <20110601085454.GA19434@icarus.home.lan> <814C9E9472FDCC40AAC3FC95A2D67E3B0BD88DC0@msx3.exchange.alogis.com> <20110601095610.GA20255@icarus.home.lan> <814C9E9472FDCC40AAC3FC95A2D67E3B0BD88F48@msx3.exchange.alogis.com> <814C9E9472FDCC40AAC3FC95A2D67E3B0BD890BD@msx3.exchange.alogis.com> <4DE73386.5040505@FreeBSD.org> <20110602075118.GA42026@icarus.home.lan> <4DE74BCD.8080002@FreeBSD.org> <4DE8BC95.2030008@alogis.com> In-Reply-To: <4DE8BC95.2030008@alogis.com> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit Cc: "stable@freebsd.org" , Jeremy Chadwick Subject: Re: 8-STABLE won't boot with ZFSv28 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 03 Jun 2011 10:55:18 -0000 Hi. Holger Kipp wrote: > as yesterday was a bank holiday in Germany I wasn't in the office to > try the patch linked in the email. > Is it consent that I should try the patch located here: > > http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/dev/ata/chipsets/ata-intel.c.diff?r1=1.25;r2=1.26 > > and report the result? Or do you need some additional discussion on > this topic? I really don't know much about ata-intel chipset programming > interface things, that's why I'm asking :-) Yes, I want you to try it and report the result. -- Alexander Motin From owner-freebsd-stable@FreeBSD.ORG Fri Jun 3 12:35:05 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D87BE106564A; Fri, 3 Jun 2011 12:35:05 +0000 (UTC) (envelope-from willy@Offermans.Rompen.nl) Received: from cpsmtpb-ews09.kpnxchange.com (cpsmtpb-ews09.kpnxchange.com [213.75.39.14]) by mx1.freebsd.org (Postfix) with ESMTP id 1960F8FC0A; Fri, 3 Jun 2011 12:35:04 +0000 (UTC) Received: from cpbrm-ews30.kpnxchange.com ([10.94.84.161]) by cpsmtpb-ews09.kpnxchange.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 3 Jun 2011 14:35:03 +0200 Received: from CPSMTPM-CMT108.kpnxchange.com ([195.121.3.24]) by cpbrm-ews30.kpnxchange.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 3 Jun 2011 14:35:01 +0200 Received: from koko.offrom.nl ([77.170.60.162]) by CPSMTPM-CMT108.kpnxchange.com with Microsoft SMTPSVC(7.0.6002.18264); Fri, 3 Jun 2011 14:35:00 +0200 Received: from squid.home.itmc.RWTH-Aachen.DE (squid.vpn.offrom.nl [10.168.0.72]) by koko.offrom.nl (8.14.3/8.14.3) with ESMTP id p53CYtQ9032052; Fri, 3 Jun 2011 14:34:55 +0200 (CEST) (envelope-from willy@vpn.offrom.nl) Received: from willy by squid.home.itmc.RWTH-Aachen.DE with local (Exim 4.72) (envelope-from ) id 1QSTaY-000139-Kr; Fri, 03 Jun 2011 14:34:54 +0200 Date: Fri, 3 Jun 2011 14:34:54 +0200 From: Willy Offermans To: John Baldwin Message-ID: <20110603123454.GB3433@vpn.offrom.nl> References: <20110521092037.GB3271@vpn.offrom.nl> <201105271043.34268.jhb@freebsd.org> <20110530092514.GB4558@vpn.offrom.nl> <201105311101.23905.jhb@freebsd.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="tKW2IUtsqtDRztdT" Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <201105311101.23905.jhb@freebsd.org> User-Agent: Mutt/1.5.20 (2009-06-14) X-OriginalArrivalTime: 03 Jun 2011 12:35:00.0114 (UTC) FILETIME=[A7615720:01CC21EA] X-RcptDomain: freebsd.org X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Marcel Moolenaar , freebsd-stable@freebsd.org, freebsd-hardware@freebsd.org Subject: Re: modem support MT9234ZPX-PCIE-NV X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Willy@Offermans.Rompen.nl List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jun 2011 12:35:06 -0000 --tKW2IUtsqtDRztdT Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit Dear John and FreeBSD friends, On Tue, May 31, 2011 at 11:01:23AM -0400, John Baldwin wrote: > On Monday, May 30, 2011 5:25:14 am Willy Offermans wrote: > > Hello John and FreeBSD friends, > > > > On Fri, May 27, 2011 at 10:43:34AM -0400, John Baldwin wrote: > > > On Friday, May 27, 2011 10:38:02 am Willy Offermans wrote: > > > > Dear John and FreeBSD friends, > > > > > > > > On Fri, May 27, 2011 at 08:05:56AM -0400, John Baldwin wrote: > > > > > On Thursday, May 26, 2011 4:58:37 pm Mike Tancsa wrote: > > > > > > On 5/26/2011 4:12 PM, John Baldwin wrote: > > > > > > > > > > > > > > Hmm, can you get 'pciconf -lb' output? > > > > > > > > > > > > > > Hmm, wow, I wonder how uart(4) works at all. It tries to reuse it's softc > > > > > > > structure in uart_bus_attach() that was setup in uart_bus_probe(). Since > > > > > it > > > > > > > doesn't return 0 from its probe routine, that is forbidden. I guess it > > > > > > > accidentally works because of the hack where we call DEVICE_PROBE() again > > > > > > > to make sure the device description is correct. > > > > > > > > > > > > > > > > > > I think this is a similar card. Had it laying about for a while and > > > > > > popped it in. cu -l to it, attaches, but I am not able to interact with it. > > > > > > > > > > > > none3@pci0:5:0:0: class=0x070002 card=0x20282205 chip=0x015213a8 > > > > > > rev=0x02 hdr=0x00 > > > > > > vendor = 'Exar Corp.' > > > > > > device = 'XR17C/D152 Dual PCI UART' > > > > > > class = simple comms > > > > > > subclass = UART > > > > > > bar [10] = type Memory, range 32, base 0xe8950000, size 1024, enabled > > > > > > > > > > > > > > > > > > NetBSD supposedly has support for this card > > > > > > > > > > Oh, hmm, looks like the clock has an unusual multiplier. Does it work if you > > > > > use 'cu -l -s 1200' to talk at 9600 for example? (In general use speed / 8 > > > > > as the speed to '-s'.) > > > > > > > > > > Also, is your card a modem or a dual-port card? > > > > > > > > > > -- > > > > > John Baldwin > > > > > > > > It is a modem. > > > > > > > > As suggested: > > > > > > > > kosmos# cu -l /dev/cuau0 -s 1200 > > > > Stale lock on cuau0 PID=3642... overriding. > > > > Connected > > > > at&F > > > > OK > > > > atdt0045******* > > > > NO DIALTONE > > > > > > Ok, try this updated patch. After this you should be able to use the correct > > > speed: > > > > > > Index: uart_bus_pci.c > > > =================================================================== > > > --- uart_bus_pci.c (revision 222285) > > > +++ uart_bus_pci.c (working copy) > > > @@ -110,6 +110,8 @@ static struct pci_id pci_ns8250_ids[] = { > > > { 0x1415, 0x950b, 0xffff, 0, "Oxford Semiconductor OXCB950 Cardbus 16950 UART", > > > 0x10, 16384000 }, > > > { 0x151f, 0x0000, 0xffff, 0, "TOPIC Semiconductor TP560 56k modem", 0x10 }, > > > +{ 0x13a8, 0x0152, 0x2205, 0x2026, "MultiTech MultiModem ZPX", 0x10, > > > + 8 * DEFAULT_RCLK }, > > > { 0x9710, 0x9820, 0x1000, 1, "NetMos NM9820 Serial Port", 0x10 }, > > > { 0x9710, 0x9835, 0x1000, 1, "NetMos NM9835 Serial Port", 0x10 }, > > > { 0x9710, 0x9865, 0xa000, 0x1000, "NetMos NM9865 Serial Port", 0x10 }, > > > > > > -- > > > John Baldwin > > > > The structure you have provided in your magic line would also need > > some explanation. The data concerns the description of the chip and the > > card I guess and can be gained by `pciconf -lv` > > > > uart0@pci0:6:0:0: class=0x070002 card=0x20262205 chip=0x015213a8 rev=0x02 hdr=0x00 > > vendor = 'Exar Corp.' > > device = 'XR17C/D152 Dual PCI UART' > > class = simple comms > > subclass = UART > > > > > > A more detailed explanation would not harm. The data 0x10 and > > 8 * DEFAULT_RCLK are still totally miraculous to me. > > 0x10 is the resource id for the first PCI BAR (rids for PCI device resources > use the offset in PCI config space of the associated BAR). It would perhaps > be more obvious if uart(4) and puc(4) used PCIR_BAR(0) rather than 0x10. > Bumping the clock by a multiple of 8 was based on looking at the change in > NetBSD that Mike Tancsa pointed to and that you verified by noting that > 'cu -s 1200' connected at 9600 (9600 / 1200 == 8). > > One question though, would you be able to test the patch for puc(4) that I > sent to Mike Tancsa to see if your modem works with puc(4)? The puc(4) > patch is more general and if it works fine for your modem I'd rather just > commit that. > > -- > John Baldwin I have applied the suggested patch. The outcome was a new /usr/src/sys/dev/puc/pucdata.c file, which I have enclosed. Upon compiling the new kernel, I encountered the following error: cc -c -O2 -frename-registers -pipe -fno-strict-aliasing -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/altq -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 -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -Werror /usr/src/sys/dev/puc/pucdata.c cc1: warnings being treated as errors /usr/src/sys/dev/puc/pucdata.c:535: warning: overflow in implicit constant conversion /usr/src/sys/dev/puc/pucdata.c:541: warning: overflow in implicit constant conversion /usr/src/sys/dev/puc/pucdata.c:547: warning: overflow in implicit constant conversion *** Error code 1 Stop in /usr/obj/usr/src/sys/KOSMOS. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. I guess, I was not lucky. Did I miss something? ``cc1: warnings being treated as errors'' might also be released. -- Met vriendelijke groeten, With kind regards, Mit freundlichen Gruessen, De jrus wah, Willy ************************************* Dr. W.K. Offermans CAT Postdoctoral Fellow CAT Catalytic Center Institut für Technische und Makromolekulare Chemie RWTH Aachen Worringerweg 1, Raum 38C-150 D-52074 Aachen, Germany Phone: +49 241 80 28592 Fax: +49 241 80 22593 Home: +31 45 544 49 44 Mobile: +31 681 15 87 68 e-mail: Willy@Offermans.Rompen.nl e-mail: Willy.Offermans@CatalyticCenter.RWTH-Aachen.de Powered by .... (__) \\\'',) \/ \ ^ .\._/_) www.FreeBSD.org --tKW2IUtsqtDRztdT-- From owner-freebsd-stable@FreeBSD.ORG Fri Jun 3 13:48:27 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E3F36106564A; Fri, 3 Jun 2011 13:48:27 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 903238FC0A; Fri, 3 Jun 2011 13:48:27 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 2AB7F46B2C; Fri, 3 Jun 2011 09:48:27 -0400 (EDT) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id B14298A01F; Fri, 3 Jun 2011 09:48:26 -0400 (EDT) From: John Baldwin To: Willy@offermans.rompen.nl Date: Fri, 3 Jun 2011 09:48:26 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110325; KDE/4.5.5; amd64; ; ) References: <20110521092037.GB3271@vpn.offrom.nl> <201105311101.23905.jhb@freebsd.org> <20110603123454.GB3433@vpn.offrom.nl> In-Reply-To: <20110603123454.GB3433@vpn.offrom.nl> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <201106030948.26246.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (bigwig.baldwin.cx); Fri, 03 Jun 2011 09:48:26 -0400 (EDT) Cc: freebsd-hardware@freebsd.org, Marcel Moolenaar , freebsd-stable@freebsd.org Subject: Re: modem support MT9234ZPX-PCIE-NV X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 03 Jun 2011 13:48:28 -0000 On Friday, June 03, 2011 8:34:54 am Willy Offermans wrote: > Dear John and FreeBSD friends, > > On Tue, May 31, 2011 at 11:01:23AM -0400, John Baldwin wrote: > > On Monday, May 30, 2011 5:25:14 am Willy Offermans wrote: > > > Hello John and FreeBSD friends, > > > > > > On Fri, May 27, 2011 at 10:43:34AM -0400, John Baldwin wrote: > > > > On Friday, May 27, 2011 10:38:02 am Willy Offermans wrote: > > > > > Dear John and FreeBSD friends, > > > > > > > > > > On Fri, May 27, 2011 at 08:05:56AM -0400, John Baldwin wrote: > > > > > > On Thursday, May 26, 2011 4:58:37 pm Mike Tancsa wrote: > > > > > > > On 5/26/2011 4:12 PM, John Baldwin wrote: > > > > > > > > > > > > > > > > Hmm, can you get 'pciconf -lb' output? > > > > > > > > > > > > > > > > Hmm, wow, I wonder how uart(4) works at all. It tries to reuse it's softc > > > > > > > > structure in uart_bus_attach() that was setup in uart_bus_probe(). Since > > > > > > it > > > > > > > > doesn't return 0 from its probe routine, that is forbidden. I guess it > > > > > > > > accidentally works because of the hack where we call DEVICE_PROBE() again > > > > > > > > to make sure the device description is correct. > > > > > > > > > > > > > > > > > > > > > I think this is a similar card. Had it laying about for a while and > > > > > > > popped it in. cu -l to it, attaches, but I am not able to interact with it. > > > > > > > > > > > > > > none3@pci0:5:0:0: class=0x070002 card=0x20282205 chip=0x015213a8 > > > > > > > rev=0x02 hdr=0x00 > > > > > > > vendor = 'Exar Corp.' > > > > > > > device = 'XR17C/D152 Dual PCI UART' > > > > > > > class = simple comms > > > > > > > subclass = UART > > > > > > > bar [10] = type Memory, range 32, base 0xe8950000, size 1024, enabled > > > > > > > > > > > > > > > > > > > > > NetBSD supposedly has support for this card > > > > > > > > > > > > Oh, hmm, looks like the clock has an unusual multiplier. Does it work if you > > > > > > use 'cu -l -s 1200' to talk at 9600 for example? (In general use speed / 8 > > > > > > as the speed to '-s'.) > > > > > > > > > > > > Also, is your card a modem or a dual-port card? > > > > > > > > > > > > -- > > > > > > John Baldwin > > > > > > > > > > It is a modem. > > > > > > > > > > As suggested: > > > > > > > > > > kosmos# cu -l /dev/cuau0 -s 1200 > > > > > Stale lock on cuau0 PID=3642... overriding. > > > > > Connected > > > > > at&F > > > > > OK > > > > > atdt0045******* > > > > > NO DIALTONE > > > > > > > > Ok, try this updated patch. After this you should be able to use the correct > > > > speed: > > > > > > > > Index: uart_bus_pci.c > > > > =================================================================== > > > > --- uart_bus_pci.c (revision 222285) > > > > +++ uart_bus_pci.c (working copy) > > > > @@ -110,6 +110,8 @@ static struct pci_id pci_ns8250_ids[] = { > > > > { 0x1415, 0x950b, 0xffff, 0, "Oxford Semiconductor OXCB950 Cardbus 16950 UART", > > > > 0x10, 16384000 }, > > > > { 0x151f, 0x0000, 0xffff, 0, "TOPIC Semiconductor TP560 56k modem", 0x10 }, > > > > +{ 0x13a8, 0x0152, 0x2205, 0x2026, "MultiTech MultiModem ZPX", 0x10, > > > > + 8 * DEFAULT_RCLK }, > > > > { 0x9710, 0x9820, 0x1000, 1, "NetMos NM9820 Serial Port", 0x10 }, > > > > { 0x9710, 0x9835, 0x1000, 1, "NetMos NM9835 Serial Port", 0x10 }, > > > > { 0x9710, 0x9865, 0xa000, 0x1000, "NetMos NM9865 Serial Port", 0x10 }, > > > > > > > > -- > > > > John Baldwin > > > > > > The structure you have provided in your magic line would also need > > > some explanation. The data concerns the description of the chip and the > > > card I guess and can be gained by `pciconf -lv` > > > > > > uart0@pci0:6:0:0: class=0x070002 card=0x20262205 chip=0x015213a8 rev=0x02 hdr=0x00 > > > vendor = 'Exar Corp.' > > > device = 'XR17C/D152 Dual PCI UART' > > > class = simple comms > > > subclass = UART > > > > > > > > > A more detailed explanation would not harm. The data 0x10 and > > > 8 * DEFAULT_RCLK are still totally miraculous to me. > > > > 0x10 is the resource id for the first PCI BAR (rids for PCI device resources > > use the offset in PCI config space of the associated BAR). It would perhaps > > be more obvious if uart(4) and puc(4) used PCIR_BAR(0) rather than 0x10. > > Bumping the clock by a multiple of 8 was based on looking at the change in > > NetBSD that Mike Tancsa pointed to and that you verified by noting that > > 'cu -s 1200' connected at 9600 (9600 / 1200 == 8). > > > > One question though, would you be able to test the patch for puc(4) that I > > sent to Mike Tancsa to see if your modem works with puc(4)? The puc(4) > > patch is more general and if it works fine for your modem I'd rather just > > commit that. > > > > -- > > John Baldwin > > I have applied the suggested patch. > > The outcome was a new /usr/src/sys/dev/puc/pucdata.c file, which I have > enclosed. Hmm, there was a newer puc patch. Please try this one instead: Index: pucdata.c =================================================================== --- pucdata.c (revision 222565) +++ pucdata.c (working copy) @@ -48,8 +48,8 @@ __FBSDID("$FreeBSD$"); #include static puc_config_f puc_config_amc; -static puc_config_f puc_config_cronyx; static puc_config_f puc_config_diva; +static puc_config_f puc_config_exar; static puc_config_f puc_config_icbook; static puc_config_f puc_config_quatech; static puc_config_f puc_config_syba; @@ -548,11 +548,25 @@ const struct puc_cfg puc_pci_devices[] = { PUC_PORT_8S, 0x18, 0, 8, }, + { 0x13a8, 0x0152, 0xffff, 0, + "Exar XR17C/D152", + DEFAULT_RCLK * 8, + PUC_PORT_2S, 0x10, 0, -1, + .config_function = puc_config_exar + }, + + { 0x13a8, 0x0154, 0xffff, 0, + "Exar XR17C154", + DEFAULT_RCLK * 8, + PUC_PORT_4S, 0x10, 0, -1, + .config_function = puc_config_exar + }, + { 0x13a8, 0x0158, 0xffff, 0, - "Cronyx Omega2-PCI", + "Exar XR17C158", DEFAULT_RCLK * 8, PUC_PORT_8S, 0x10, 0, -1, - .config_function = puc_config_cronyx + .config_function = puc_config_exar }, { 0x13a8, 0x0258, 0xffff, 0, @@ -1014,28 +1028,28 @@ puc_config_amc(struct puc_softc *sc, enum puc_cfg_ } static int -puc_config_cronyx(struct puc_softc *sc, enum puc_cfg_cmd cmd, int port, +puc_config_diva(struct puc_softc *sc, enum puc_cfg_cmd cmd, int port, intptr_t *res) { + const struct puc_cfg *cfg = sc->sc_cfg; + if (cmd == PUC_CFG_GET_OFS) { - *res = port * 0x200; + if (cfg->subdevice == 0x1282) /* Everest SP */ + port <<= 1; + else if (cfg->subdevice == 0x104b) /* Maestro SP2 */ + port = (port == 3) ? 4 : port; + *res = port * 8 + ((port > 2) ? 0x18 : 0); return (0); } return (ENXIO); } static int -puc_config_diva(struct puc_softc *sc, enum puc_cfg_cmd cmd, int port, +puc_config_exar(struct puc_softc *sc, enum puc_cfg_cmd cmd, int port, intptr_t *res) { - const struct puc_cfg *cfg = sc->sc_cfg; - if (cmd == PUC_CFG_GET_OFS) { - if (cfg->subdevice == 0x1282) /* Everest SP */ - port <<= 1; - else if (cfg->subdevice == 0x104b) /* Maestro SP2 */ - port = (port == 3) ? 4 : port; - *res = port * 8 + ((port > 2) ? 0x18 : 0); + *res = port * 0x200; return (0); } return (ENXIO); -- John Baldwin From owner-freebsd-stable@FreeBSD.ORG Fri Jun 3 15:13:53 2011 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 51A9E1065672; Fri, 3 Jun 2011 15:13:53 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 760A18FC13; Fri, 3 Jun 2011 15:13:51 +0000 (UTC) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id SAA15788; Fri, 03 Jun 2011 18:13:50 +0300 (EEST) (envelope-from avg@FreeBSD.org) Message-ID: <4DE8FA2E.4030202@FreeBSD.org> Date: Fri, 03 Jun 2011 18:13:50 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.17) Gecko/20110504 Lightning/1.0b2 Thunderbird/3.1.10 MIME-Version: 1.0 To: freebsd-current@FreeBSD.org, freebsd-stable@FreeBSD.org X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: Subject: [poll / rfc] kdb_stop_cpus X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 03 Jun 2011 15:13:53 -0000 I wonder if anybody uses kdb_stop_cpus with non-default value. If, yes, I am very interested to learn about your usecase for it. I think that the default kdb behavior is the correct one, so it doesn't make sense to have a knob to turn on incorrect behavior. But I may be missing something obvious. The comment in the code doesn't really satisfy me: /* * Flag indicating whether or not to IPI the other CPUs to stop them on * entering the debugger. Sometimes, this will result in a deadlock as * stop_cpus() waits for the other cpus to stop, so we allow it to be * disabled. In order to maximize the chances of success, use a hard * stop for that. */ The hard stop should be sufficiently mighty. Yes, I am aware of supposedly extremely rare situations where a deadlock could happen even when using hard stop. But I'd rather fix that than have this switch. Oh, the commit message (from 2004) explains it: > Add a new sysctl, debug.kdb.stop_cpus, which controls whether or not we > attempt to IPI other cpus when entering the debugger in order to stop > them while in the debugger. The default remains to issue the stop; > however, that can result in a hang if another cpu has interrupts disabled > and is spinning, since the IPI won't be received and the KDB will wait > indefinitely. We probably need to add a timeout, but this is a useful > stopgap in the mean time. But that was before we started using hard stop in this context (in 2009). -- Andriy Gapon From owner-freebsd-stable@FreeBSD.ORG Fri Jun 3 15:32:21 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A9295106566C for ; Fri, 3 Jun 2011 15:32:21 +0000 (UTC) (envelope-from daniel@digsys.bg) Received: from smtp-sofia.digsys.bg (smtp-sofia.digsys.bg [193.68.3.230]) by mx1.freebsd.org (Postfix) with ESMTP id 347988FC13 for ; Fri, 3 Jun 2011 15:32:20 +0000 (UTC) Received: from dcave.digsys.bg (dcave.digsys.bg [192.92.129.5]) (authenticated bits=0) by smtp-sofia.digsys.bg (8.14.4/8.14.4) with ESMTP id p53FW8gW079102 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Fri, 3 Jun 2011 18:32:14 +0300 (EEST) (envelope-from daniel@digsys.bg) Message-ID: <4DE8FE78.6070401@digsys.bg> Date: Fri, 03 Jun 2011 18:32:08 +0300 From: Daniel Kalchev User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.17) Gecko/20110519 Thunderbird/3.1.10 MIME-Version: 1.0 To: freebsd-stable@freebsd.org References: <4DE21C64.8060107@digsys.bg> <4DE3ACF8.4070809@digsys.bg> <86d3j02fox.fsf@kopusha.home.net> <4DE4E43B.7030302@digsys.bg> <86zkm3t11g.fsf@in138.ua3> <4DE5048B.3080206@digsys.bg> <4DE5D535.20804@digsys.bg> In-Reply-To: <4DE5D535.20804@digsys.bg> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: HAST instability X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 03 Jun 2011 15:32:21 -0000 Decided to apply the patch proposed in -current by Mikolaj Golub: http://people.freebsd.org/~trociny/uipc_socket.c.patch This apparently fixed my issue as well. Running without checksums for a full bonnie++ run (~100GB write/rewrite) produced no disconnects, no stalls and generated up to 280MB/sec (4 drives in stripped zpool). Interestingly, the hast devices write latency as observed by gstat was under 30ms. I believe this fix should be committed. Here are the accumulated netstat -s from both hosts, for comparison with previous runs. Retransmits etc are much less. http://news.digsys.bg/~admin/hast/test3jun-fix/b1a-netstat-s http://news.digsys.bg/~admin/hast/test3jun-fix/b1b-netstat-s http://news.digsys.bg/~admin/hast/test3jun-fix/b1b-systat-if-fix Before applying the patch I verified there are no network problems. Created 1TB file from /dev/random on the first host. Copied over to the second host with ftp. Transfer speed was low, at 80MB/sec -- ftp would utilize one CPU core 100% at the receiving node. Then calculated md5 checksums on both sides, matched. Daniel From owner-freebsd-stable@FreeBSD.ORG Fri Jun 3 15:54:22 2011 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CE51D1065672; Fri, 3 Jun 2011 15:54:22 +0000 (UTC) (envelope-from nwhitehorn@freebsd.org) Received: from mail.icecube.wisc.edu (trout.icecube.wisc.edu [128.104.255.119]) by mx1.freebsd.org (Postfix) with ESMTP id 91D6F8FC12; Fri, 3 Jun 2011 15:54:22 +0000 (UTC) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.icecube.wisc.edu (Postfix) with ESMTP id D3C7D58142; Fri, 3 Jun 2011 10:28:03 -0500 (CDT) X-Virus-Scanned: amavisd-new at icecube.wisc.edu Received: from mail.icecube.wisc.edu ([127.0.0.1]) by localhost (trout.icecube.wisc.edu [127.0.0.1]) (amavisd-new, port 10030) with ESMTP id csROGH26NRuy; Fri, 3 Jun 2011 10:28:03 -0500 (CDT) Received: from wanderer.tachypleus.net (i3-dhcp-172-16-223-128.icecube.wisc.edu [172.16.223.128]) by mail.icecube.wisc.edu (Postfix) with ESMTP id 9B78F5813A; Fri, 3 Jun 2011 10:28:03 -0500 (CDT) Message-ID: <4DE8FD83.6030503@freebsd.org> Date: Fri, 03 Jun 2011 10:28:03 -0500 From: Nathan Whitehorn User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.17) Gecko/20110516 Thunderbird/3.1.10 MIME-Version: 1.0 To: Andriy Gapon References: <4DE8FA2E.4030202@FreeBSD.org> In-Reply-To: <4DE8FA2E.4030202@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@FreeBSD.org, freebsd-stable@FreeBSD.org Subject: Re: [poll / rfc] kdb_stop_cpus X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 03 Jun 2011 15:54:22 -0000 On 06/03/11 10:13, Andriy Gapon wrote: > > I wonder if anybody uses kdb_stop_cpus with non-default value. > If, yes, I am very interested to learn about your usecase for it. > > I think that the default kdb behavior is the correct one, so it doesn't make sense > to have a knob to turn on incorrect behavior. > But I may be missing something obvious. > > The comment in the code doesn't really satisfy me: > /* > * Flag indicating whether or not to IPI the other CPUs to stop them on > * entering the debugger. Sometimes, this will result in a deadlock as > * stop_cpus() waits for the other cpus to stop, so we allow it to be > * disabled. In order to maximize the chances of success, use a hard > * stop for that. > */ > > The hard stop should be sufficiently mighty. > Yes, I am aware of supposedly extremely rare situations where a deadlock could > happen even when using hard stop. But I'd rather fix that than have this switch. > > Oh, the commit message (from 2004) explains it: >> Add a new sysctl, debug.kdb.stop_cpus, which controls whether or not we >> attempt to IPI other cpus when entering the debugger in order to stop >> them while in the debugger. The default remains to issue the stop; >> however, that can result in a hang if another cpu has interrupts disabled >> and is spinning, since the IPI won't be received and the KDB will wait >> indefinitely. We probably need to add a timeout, but this is a useful >> stopgap in the mean time. > > But that was before we started using hard stop in this context (in 2009). Some non-x86 platforms (e.g. PPC) don't support real NMIs, and so this still applies. -Nathan From owner-freebsd-stable@FreeBSD.ORG Fri Jun 3 16:12:40 2011 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D02771065670; Fri, 3 Jun 2011 16:12:40 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id BCF948FC16; Fri, 3 Jun 2011 16:12:39 +0000 (UTC) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id TAA16277; Fri, 03 Jun 2011 19:12:38 +0300 (EEST) (envelope-from avg@FreeBSD.org) Message-ID: <4DE907F5.2070901@FreeBSD.org> Date: Fri, 03 Jun 2011 19:12:37 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.17) Gecko/20110504 Lightning/1.0b2 Thunderbird/3.1.10 MIME-Version: 1.0 To: Nathan Whitehorn References: <4DE8FA2E.4030202@FreeBSD.org> <4DE8FD83.6030503@freebsd.org> In-Reply-To: <4DE8FD83.6030503@freebsd.org> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-current@FreeBSD.org, freebsd-stable@FreeBSD.org Subject: Re: [poll / rfc] kdb_stop_cpus X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 03 Jun 2011 16:12:40 -0000 on 03/06/2011 18:28 Nathan Whitehorn said the following: > On 06/03/11 10:13, Andriy Gapon wrote: >> >> I wonder if anybody uses kdb_stop_cpus with non-default value. >> If, yes, I am very interested to learn about your usecase for it. >> >> I think that the default kdb behavior is the correct one, so it doesn't make sense >> to have a knob to turn on incorrect behavior. >> But I may be missing something obvious. >> >> The comment in the code doesn't really satisfy me: >> /* >> * Flag indicating whether or not to IPI the other CPUs to stop them on >> * entering the debugger. Sometimes, this will result in a deadlock as >> * stop_cpus() waits for the other cpus to stop, so we allow it to be >> * disabled. In order to maximize the chances of success, use a hard >> * stop for that. >> */ >> >> The hard stop should be sufficiently mighty. >> Yes, I am aware of supposedly extremely rare situations where a deadlock could >> happen even when using hard stop. But I'd rather fix that than have this switch. >> >> Oh, the commit message (from 2004) explains it: >>> Add a new sysctl, debug.kdb.stop_cpus, which controls whether or not we >>> attempt to IPI other cpus when entering the debugger in order to stop >>> them while in the debugger. The default remains to issue the stop; >>> however, that can result in a hang if another cpu has interrupts disabled >>> and is spinning, since the IPI won't be received and the KDB will wait >>> indefinitely. We probably need to add a timeout, but this is a useful >>> stopgap in the mean time. >> >> But that was before we started using hard stop in this context (in 2009). > > Some non-x86 platforms (e.g. PPC) don't support real NMIs, and so this still applies. Well, even if it does, there are two things that can be done about that (and, IMO, both are better than the manually controlled knob): - quick and dirty: just let stop_cpus[_hard] timeout; this way good CPUs are stopped and the bad ones are no worse than with kdb_stop_cpus=0. - have a special reserved high priority interrupt, change 'disabling of interrupts' to 'disabling of all interrupts except the special one' by employing various kinds of interrupt priority registers (like it was done for splX stuff); use the special interrupt like an IPI+NMI. What do you think? P.S. I think that the first "quick and dirty" thing should be done anyway, regardless of any other changes and plans. -- Andriy Gapon From owner-freebsd-stable@FreeBSD.ORG Fri Jun 3 16:18:41 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 148B2106566B for ; Fri, 3 Jun 2011 16:18:41 +0000 (UTC) (envelope-from daniel@digsys.bg) Received: from smtp-sofia.digsys.bg (smtp-sofia.digsys.bg [193.68.3.230]) by mx1.freebsd.org (Postfix) with ESMTP id 79D478FC0A for ; Fri, 3 Jun 2011 16:18:40 +0000 (UTC) Received: from dcave.digsys.bg (dcave.digsys.bg [192.92.129.5]) (authenticated bits=0) by smtp-sofia.digsys.bg (8.14.4/8.14.4) with ESMTP id p53GITjk079235 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Fri, 3 Jun 2011 19:18:34 +0300 (EEST) (envelope-from daniel@digsys.bg) Message-ID: <4DE90955.9020505@digsys.bg> Date: Fri, 03 Jun 2011 19:18:29 +0300 From: Daniel Kalchev User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.17) Gecko/20110519 Thunderbird/3.1.10 MIME-Version: 1.0 To: freebsd-stable@freebsd.org References: <4DE21C64.8060107@digsys.bg> <4DE3ACF8.4070809@digsys.bg> <86d3j02fox.fsf@kopusha.home.net> <4DE4E43B.7030302@digsys.bg> <86zkm3t11g.fsf@in138.ua3> <4DE5048B.3080206@digsys.bg> <4DE5D535.20804@digsys.bg> <4DE8FE78.6070401@digsys.bg> In-Reply-To: <4DE8FE78.6070401@digsys.bg> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: HAST instability X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 03 Jun 2011 16:18:41 -0000 Well, apparently my HAST joy was short. On a second run, I got stuck with Jun 3 19:08:16 b1a hastd[1900]: [data2] (primary) Unable to receive reply header: Operation timed out. on the primary. No messages on the secondary. On primary: # netstat -an | grep 8457 tcp4 0 0 10.2.101.11.42659 10.2.101.12.8457 FIN_WAIT_2 tcp4 0 0 10.2.101.11.62058 10.2.101.12.8457 CLOSE_WAIT tcp4 0 0 10.2.101.11.34646 10.2.101.12.8457 FIN_WAIT_2 tcp4 0 0 10.2.101.11.11419 10.2.101.12.8457 CLOSE_WAIT tcp4 0 0 10.2.101.11.37773 10.2.101.12.8457 FIN_WAIT_2 tcp4 0 0 10.2.101.11.21911 10.2.101.12.8457 FIN_WAIT_2 tcp4 0 0 10.2.101.11.40169 10.2.101.12.8457 CLOSE_WAIT tcp4 0 97749 10.2.101.11.44360 10.2.101.12.8457 CLOSE_WAIT tcp4 0 0 10.2.101.11.8457 *.* LISTEN on secondary # netstat -an | grep 8457 tcp4 0 0 10.2.101.12.8457 10.2.101.11.42659 CLOSE_WAIT tcp4 0 0 10.2.101.12.8457 10.2.101.11.62058 FIN_WAIT_2 tcp4 0 0 10.2.101.12.8457 10.2.101.11.34646 CLOSE_WAIT tcp4 0 0 10.2.101.12.8457 10.2.101.11.11419 FIN_WAIT_2 tcp4 0 0 10.2.101.12.8457 10.2.101.11.37773 CLOSE_WAIT tcp4 0 0 10.2.101.12.8457 10.2.101.11.21911 CLOSE_WAIT tcp4 0 0 10.2.101.12.8457 10.2.101.11.40169 FIN_WAIT_2 tcp4 66415 0 10.2.101.12.8457 10.2.101.11.44360 FIN_WAIT_2 tcp4 0 0 10.2.101.12.8457 *.* LISTEN on primary # hastctl status data0: role: primary provname: data0 localpath: /dev/gpt/data0 extentsize: 2097152 (2.0MB) keepdirty: 64 remoteaddr: 10.2.101.12 sourceaddr: 10.2.101.11 replication: fullsync status: complete dirty: 0 (0B) data1: role: primary provname: data1 localpath: /dev/gpt/data1 extentsize: 2097152 (2.0MB) keepdirty: 64 remoteaddr: 10.2.101.12 sourceaddr: 10.2.101.11 replication: fullsync status: complete dirty: 0 (0B) data2: role: primary provname: data2 localpath: /dev/gpt/data2 extentsize: 2097152 (2.0MB) keepdirty: 64 remoteaddr: 10.2.101.12 sourceaddr: 10.2.101.11 replication: fullsync status: complete dirty: 6291456 (6.0MB) data3: role: primary provname: data3 localpath: /dev/gpt/data3 extentsize: 2097152 (2.0MB) keepdirty: 64 remoteaddr: 10.2.101.12 sourceaddr: 10.2.101.11 replication: fullsync status: complete dirty: 0 (0B) Sits in this state for over 10 minutes. Unfortunately, no KDB in kernel. Any ideas what other to look for? Daniel From owner-freebsd-stable@FreeBSD.ORG Fri Jun 3 17:57:25 2011 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BBF4E106566B; Fri, 3 Jun 2011 17:57:25 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 958EB8FC0A; Fri, 3 Jun 2011 17:57:25 +0000 (UTC) Received: from lemongrass.sec.cl.cam.ac.uk (lemongrass.sec.cl.cam.ac.uk [128.232.18.47]) by cyrus.watson.org (Postfix) with ESMTPSA id 9CA1A46B03; Fri, 3 Jun 2011 13:57:24 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: "Robert N. M. Watson" In-Reply-To: <4DE8FA2E.4030202@FreeBSD.org> Date: Fri, 3 Jun 2011 18:57:23 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <5E4D0F56-4338-4157-8BC6-17EE2831725F@FreeBSD.org> References: <4DE8FA2E.4030202@FreeBSD.org> To: Andriy Gapon X-Mailer: Apple Mail (2.1084) Cc: freebsd-current@FreeBSD.org, freebsd-stable@FreeBSD.org Subject: Re: [poll / rfc] kdb_stop_cpus X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 03 Jun 2011 17:57:25 -0000 On 3 Jun 2011, at 16:13, Andriy Gapon wrote: > I wonder if anybody uses kdb_stop_cpus with non-default value. > If, yes, I am very interested to learn about your usecase for it. The issue that prompted the sysctl was non-NMI IPIs being used to enter = the debugger or reboot following a core hanging with interrupts = disabled. With the switch to NMI IPIs in some of those circumstances, = life is better -- at least, on hardware that supports non-maskable IPIs. = I seem to recall sparc64 doesn't, however? Not sure about MIPS, etc. = Attilio has since significantly improved our shutdown behaviour -- = initially, the switch to NMI IPIs broke other things (because certain = IPIs then improperly preempted threads holding spinlocks), but that = pretty much all seems worked out now. Robert >=20 > I think that the default kdb behavior is the correct one, so it = doesn't make sense > to have a knob to turn on incorrect behavior. > But I may be missing something obvious. >=20 > The comment in the code doesn't really satisfy me: > /* > * Flag indicating whether or not to IPI the other CPUs to stop them on > * entering the debugger. Sometimes, this will result in a deadlock as > * stop_cpus() waits for the other cpus to stop, so we allow it to be > * disabled. In order to maximize the chances of success, use a hard > * stop for that. > */ >=20 > The hard stop should be sufficiently mighty. > Yes, I am aware of supposedly extremely rare situations where a = deadlock could > happen even when using hard stop. But I'd rather fix that than have = this switch. >=20 > Oh, the commit message (from 2004) explains it: >> Add a new sysctl, debug.kdb.stop_cpus, which controls whether or not = we >> attempt to IPI other cpus when entering the debugger in order to stop >> them while in the debugger. The default remains to issue the stop; >> however, that can result in a hang if another cpu has interrupts = disabled >> and is spinning, since the IPI won't be received and the KDB will = wait >> indefinitely. We probably need to add a timeout, but this is a = useful >> stopgap in the mean time. >=20 > But that was before we started using hard stop in this context (in = 2009). >=20 > --=20 > Andriy Gapon From owner-freebsd-stable@FreeBSD.ORG Fri Jun 3 18:25:46 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 36B5F106566B for ; Fri, 3 Jun 2011 18:25:46 +0000 (UTC) (envelope-from ken73.chen@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 8A5CB8FC14 for ; Fri, 3 Jun 2011 18:25:45 +0000 (UTC) Received: by wyf23 with SMTP id 23so2211547wyf.13 for ; Fri, 03 Jun 2011 11:25:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:from:date:message-id:subject:to :content-type; bh=eqlz75gyNx7ymvFWLtcJikRraaNK6fFobj3QfUps8o0=; b=ajLWMEDgTUtjnsE1ZPWYnnQPKASm3iz2gcQh8xyLKhq8RRlW3YN8jLureM8QBo4biw 4CUCMBm980yw83IsfLKfsMSnKz7StNvORKga12bydI5/cqfkAF+flVBkRb3YVQ5m0jkT ZUPRP9YKNkcnzRipMie8vaBV0WRmeC+gPi/kU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:from:date:message-id:subject:to:content-type; b=bJaNirvf8YmAHu1FM9oGTnRnYsZQoXB5ZlbcYxjMIIQigx/M7lIEiEiZSnB+LCAUCw AjYsd5jWnXJ3VFdFhysQjMFIjg9z5ERmNWC9YCxGb1a/tZUpVtrA/ln9QDq5KrKfFmUh 7IHGiXmgyrpaPv/eHoJ0BecxmBEzpuIRyrxPo= Received: by 10.216.159.75 with SMTP id r53mr2051574wek.98.1307123795583; Fri, 03 Jun 2011 10:56:35 -0700 (PDT) MIME-Version: 1.0 Received: by 10.216.229.32 with HTTP; Fri, 3 Jun 2011 10:56:15 -0700 (PDT) From: Ken Chen Date: Sat, 4 Jun 2011 01:56:15 +0800 Message-ID: To: freebsd-stable@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Realtek 8111e on 8.2-RELEASE X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 03 Jun 2011 18:25:46 -0000 Hello, Anyone tried Realtek 8111e on 8.2-RELEASE? Realtek8111e should be supported, but I got following message: re0: port 0xe800-0xe8ff mem 0xfdfff000-0xfdffffff, 0xfdff8000-0xfdffbfff irq 17 at device 0.0 on pci2 re0: Using 1 MSI messages re0: Chip rev. 0x2c800000 re0: MAC rev. 0x00000000 re0: Unknown H/W revision: 0%2c800000 device_attach:re0 attach returned 6 Any suggestion? Thanks a lot! From owner-freebsd-stable@FreeBSD.ORG Fri Jun 3 19:00:19 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1DC8F106566B; Fri, 3 Jun 2011 19:00:18 +0000 (UTC) (envelope-from willy@Offermans.Rompen.nl) Received: from cpsmtpb-ews07.kpnxchange.com (cpsmtpb-ews07.kpnxchange.com [213.75.39.10]) by mx1.freebsd.org (Postfix) with ESMTP id 63CF08FC13; Fri, 3 Jun 2011 19:00:16 +0000 (UTC) Received: from cpbrm-ews04.kpnxchange.com ([10.94.84.135]) by cpsmtpb-ews07.kpnxchange.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 3 Jun 2011 21:00:15 +0200 Received: from CPSMTPM-CMT108.kpnxchange.com ([195.121.3.24]) by cpbrm-ews04.kpnxchange.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 3 Jun 2011 21:00:14 +0200 Received: from koko.offrom.nl ([77.170.60.162]) by CPSMTPM-CMT108.kpnxchange.com with Microsoft SMTPSVC(7.0.6002.18264); Fri, 3 Jun 2011 21:00:14 +0200 Received: from squid.home.itmc.RWTH-Aachen.DE (squid.vpn.offrom.nl [10.168.0.72]) by koko.offrom.nl (8.14.3/8.14.3) with ESMTP id p53J0AHX030464; Fri, 3 Jun 2011 21:00:10 +0200 (CEST) (envelope-from willy@vpn.offrom.nl) Received: from willy by squid.home.itmc.RWTH-Aachen.DE with local (Exim 4.72) (envelope-from ) id 1QSZbO-0001W1-0E; Fri, 03 Jun 2011 21:00:10 +0200 Date: Fri, 3 Jun 2011 21:00:09 +0200 From: Willy Offermans To: John Baldwin Message-ID: <20110603190009.GA5809@vpn.offrom.nl> References: <20110521092037.GB3271@vpn.offrom.nl> <201105311101.23905.jhb@freebsd.org> <20110603123454.GB3433@vpn.offrom.nl> <201106030948.26246.jhb@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201106030948.26246.jhb@freebsd.org> User-Agent: Mutt/1.5.20 (2009-06-14) X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED,BAYES_00, T_RP_MATCHES_RCVD autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on koko.offrom.nl X-OriginalArrivalTime: 03 Jun 2011 19:00:14.0168 (UTC) FILETIME=[786E1580:01CC2220] X-RcptDomain: freebsd.org Cc: Marcel Moolenaar , freebsd-stable@freebsd.org, freebsd-hardware@freebsd.org Subject: Re: modem support MT9234ZPX-PCIE-NV X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Willy@Offermans.Rompen.nl List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jun 2011 19:00:19 -0000 Hello John and FreeBSD friends, On Fri, Jun 03, 2011 at 09:48:26AM -0400, John Baldwin wrote: > On Friday, June 03, 2011 8:34:54 am Willy Offermans wrote: > > Dear John and FreeBSD friends, > > > > On Tue, May 31, 2011 at 11:01:23AM -0400, John Baldwin wrote: > > > On Monday, May 30, 2011 5:25:14 am Willy Offermans wrote: > > > > Hello John and FreeBSD friends, > > > > > > > > On Fri, May 27, 2011 at 10:43:34AM -0400, John Baldwin wrote: > > > > > On Friday, May 27, 2011 10:38:02 am Willy Offermans wrote: > > > > > > Dear John and FreeBSD friends, > > > > > > > > > > > > On Fri, May 27, 2011 at 08:05:56AM -0400, John Baldwin wrote: > > > > > > > On Thursday, May 26, 2011 4:58:37 pm Mike Tancsa wrote: > > > > > > > > On 5/26/2011 4:12 PM, John Baldwin wrote: > > > > > > > > > > > > > > > > > > Hmm, can you get 'pciconf -lb' output? > > > > > > > > > > > > > > > > > > Hmm, wow, I wonder how uart(4) works at all. It tries to > reuse it's softc > > > > > > > > > structure in uart_bus_attach() that was setup in > uart_bus_probe(). Since > > > > > > > it > > > > > > > > > doesn't return 0 from its probe routine, that is forbidden. > I guess it > > > > > > > > > accidentally works because of the hack where we call > DEVICE_PROBE() again > > > > > > > > > to make sure the device description is correct. > > > > > > > > > > > > > > > > > > > > > > > > I think this is a similar card. Had it laying about for a while > and > > > > > > > > popped it in. cu -l to it, attaches, but I am not able to > interact with it. > > > > > > > > > > > > > > > > none3@pci0:5:0:0: class=0x070002 card=0x20282205 > chip=0x015213a8 > > > > > > > > rev=0x02 hdr=0x00 > > > > > > > > vendor = 'Exar Corp.' > > > > > > > > device = 'XR17C/D152 Dual PCI UART' > > > > > > > > class = simple comms > > > > > > > > subclass = UART > > > > > > > > bar [10] = type Memory, range 32, base 0xe8950000, size > 1024, enabled > > > > > > > > > > > > > > > > > > > > > > > > NetBSD supposedly has support for this card > > > > > > > > > > > > > > Oh, hmm, looks like the clock has an unusual multiplier. Does it > work if you > > > > > > > use 'cu -l -s 1200' to talk at 9600 for example? (In general use > speed / 8 > > > > > > > as the speed to '-s'.) > > > > > > > > > > > > > > Also, is your card a modem or a dual-port card? > > > > > > > > > > > > > > -- > > > > > > > John Baldwin > > > > > > > > > > > > It is a modem. > > > > > > > > > > > > As suggested: > > > > > > > > > > > > kosmos# cu -l /dev/cuau0 -s 1200 > > > > > > Stale lock on cuau0 PID=3642... overriding. > > > > > > Connected > > > > > > at&F > > > > > > OK > > > > > > atdt0045******* > > > > > > NO DIALTONE > > > > > > > > > > Ok, try this updated patch. After this you should be able to use the > correct > > > > > speed: > > > > > > > > > > Index: uart_bus_pci.c > > > > > =================================================================== > > > > > --- uart_bus_pci.c (revision 222285) > > > > > +++ uart_bus_pci.c (working copy) > > > > > @@ -110,6 +110,8 @@ static struct pci_id pci_ns8250_ids[] = { > > > > > { 0x1415, 0x950b, 0xffff, 0, "Oxford Semiconductor OXCB950 Cardbus > 16950 UART", > > > > > 0x10, 16384000 }, > > > > > { 0x151f, 0x0000, 0xffff, 0, "TOPIC Semiconductor TP560 56k modem", > 0x10 }, > > > > > +{ 0x13a8, 0x0152, 0x2205, 0x2026, "MultiTech MultiModem ZPX", 0x10, > > > > > + 8 * DEFAULT_RCLK }, > > > > > { 0x9710, 0x9820, 0x1000, 1, "NetMos NM9820 Serial Port", 0x10 }, > > > > > { 0x9710, 0x9835, 0x1000, 1, "NetMos NM9835 Serial Port", 0x10 }, > > > > > { 0x9710, 0x9865, 0xa000, 0x1000, "NetMos NM9865 Serial Port", 0x10 > }, > > > > > > > > > > -- > > > > > John Baldwin > > > > > > > > The structure you have provided in your magic line would also need > > > > some explanation. The data concerns the description of the chip and the > > > > card I guess and can be gained by `pciconf -lv` > > > > > > > > uart0@pci0:6:0:0: class=0x070002 card=0x20262205 chip=0x015213a8 > rev=0x02 hdr=0x00 > > > > vendor = 'Exar Corp.' > > > > device = 'XR17C/D152 Dual PCI UART' > > > > class = simple comms > > > > subclass = UART > > > > > > > > > > > > A more detailed explanation would not harm. The data 0x10 and > > > > 8 * DEFAULT_RCLK are still totally miraculous to me. > > > > > > 0x10 is the resource id for the first PCI BAR (rids for PCI device > resources > > > use the offset in PCI config space of the associated BAR). It would > perhaps > > > be more obvious if uart(4) and puc(4) used PCIR_BAR(0) rather than 0x10. > > > Bumping the clock by a multiple of 8 was based on looking at the change in > > > NetBSD that Mike Tancsa pointed to and that you verified by noting that > > > 'cu -s 1200' connected at 9600 (9600 / 1200 == 8). > > > > > > One question though, would you be able to test the patch for puc(4) that I > > > sent to Mike Tancsa to see if your modem works with puc(4)? The puc(4) > > > patch is more general and if it works fine for your modem I'd rather just > > > commit that. > > > > > > -- > > > John Baldwin > > > > I have applied the suggested patch. > > > > The outcome was a new /usr/src/sys/dev/puc/pucdata.c file, which I have > > enclosed. > > Hmm, there was a newer puc patch. Please try this one instead: > > Index: pucdata.c > =================================================================== > --- pucdata.c (revision 222565) > +++ pucdata.c (working copy) > @@ -48,8 +48,8 @@ __FBSDID("$FreeBSD$"); > #include > > static puc_config_f puc_config_amc; > -static puc_config_f puc_config_cronyx; > static puc_config_f puc_config_diva; > +static puc_config_f puc_config_exar; > static puc_config_f puc_config_icbook; > static puc_config_f puc_config_quatech; > static puc_config_f puc_config_syba; > @@ -548,11 +548,25 @@ const struct puc_cfg puc_pci_devices[] = { > PUC_PORT_8S, 0x18, 0, 8, > }, > > + { 0x13a8, 0x0152, 0xffff, 0, > + "Exar XR17C/D152", > + DEFAULT_RCLK * 8, > + PUC_PORT_2S, 0x10, 0, -1, > + .config_function = puc_config_exar > + }, > + > + { 0x13a8, 0x0154, 0xffff, 0, > + "Exar XR17C154", > + DEFAULT_RCLK * 8, > + PUC_PORT_4S, 0x10, 0, -1, > + .config_function = puc_config_exar > + }, > + > { 0x13a8, 0x0158, 0xffff, 0, > - "Cronyx Omega2-PCI", > + "Exar XR17C158", > DEFAULT_RCLK * 8, > PUC_PORT_8S, 0x10, 0, -1, > - .config_function = puc_config_cronyx > + .config_function = puc_config_exar > }, > > { 0x13a8, 0x0258, 0xffff, 0, > @@ -1014,28 +1028,28 @@ puc_config_amc(struct puc_softc *sc, enum puc_cfg_ > } > > static int > -puc_config_cronyx(struct puc_softc *sc, enum puc_cfg_cmd cmd, int port, > +puc_config_diva(struct puc_softc *sc, enum puc_cfg_cmd cmd, int port, > intptr_t *res) > { > + const struct puc_cfg *cfg = sc->sc_cfg; > + > if (cmd == PUC_CFG_GET_OFS) { > - *res = port * 0x200; > + if (cfg->subdevice == 0x1282) /* Everest SP */ > + port <<= 1; > + else if (cfg->subdevice == 0x104b) /* Maestro SP2 */ > + port = (port == 3) ? 4 : port; > + *res = port * 8 + ((port > 2) ? 0x18 : 0); > return (0); > } > return (ENXIO); > } > > static int > -puc_config_diva(struct puc_softc *sc, enum puc_cfg_cmd cmd, int port, > +puc_config_exar(struct puc_softc *sc, enum puc_cfg_cmd cmd, int port, > intptr_t *res) > { > - const struct puc_cfg *cfg = sc->sc_cfg; > - > if (cmd == PUC_CFG_GET_OFS) { > - if (cfg->subdevice == 0x1282) /* Everest SP */ > - port <<= 1; > - else if (cfg->subdevice == 0x104b) /* Maestro SP2 */ > - port = (port == 3) ? 4 : port; > - *res = port * 8 + ((port > 2) ? 0x18 : 0); > + *res = port * 0x200; > return (0); > } > return (ENXIO); > > -- > John Baldwin The latter patch seems to work: >From the boot.msg: .... puc0: mem 0xfbfffc00-0xfbffffff irq 16 at device 0.0 on pci6 puc0: failed to enable port mapping! puc0: [FILTER] uart0: <16750 or compatible> on puc0 uart0: [FILTER] uart1: <16750 or compatible> on puc0 uart1: [FILTER] .... As I already pointed out, I do not have a line connected to the modem yet. This connection will hopefully be established tomorrow. After some rigorous testing I will post a mail with the on stream results. On the other hand, if someone knows some off stream testing procedures, then I'm happy to hear about that. For the time being I have started minicom and issued: AT AT&F ATI All with positive and already mentioned results. -- Met vriendelijke groeten, With kind regards, Mit freundlichen Gruessen, Willy ************************************* W.K. Offermans Home: +31 45 544 49 44 Mobile: +31 681 15 87 68 e-mail: Willy@Offermans.Rompen.nl From owner-freebsd-stable@FreeBSD.ORG Fri Jun 3 19:39:15 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BB0311065674 for ; Fri, 3 Jun 2011 19:39:15 +0000 (UTC) (envelope-from cliftonr@volcano.org) Received: from hrndva-omtalb.mail.rr.com (hrndva-omtalb.mail.rr.com [71.74.56.123]) by mx1.freebsd.org (Postfix) with ESMTP id 77BC38FC0A for ; Fri, 3 Jun 2011 19:39:14 +0000 (UTC) X-Authority-Analysis: v=1.1 cv=PfPQ8rIoTcZsncbPZjVSZ7K0hy8Zc4hmL68r4VPNpKE= c=1 sm=0 a=z1TLwsU0kBEA:10 a=MD6hJYEng8YA:10 a=sLPLfFCmqb0A:10 a=kj9zAlcOel0A:10 a=G5OLwwqwWgs+1dCEPNHTSw==:17 a=jb__rZ8GAAAA:8 a=GjEiR67sAAAA:8 a=DKK-TQLtKhTl9Dc4CRUA:9 a=CjuIK1q_8ugA:10 a=sHp_62vNEjwA:10 a=Ke08FT2oSu0A:10 a=G5OLwwqwWgs+1dCEPNHTSw==:117 X-Cloudmark-Score: 0 X-Originating-IP: 75.80.196.236 Received: from [75.80.196.236] ([75.80.196.236:17667] helo=oz.volcano.org) by hrndva-oedge02.mail.rr.com (envelope-from ) (ecelerity 2.2.3.46 r()) with ESMTP id 66/99-01023-26839ED4; Fri, 03 Jun 2011 19:39:14 +0000 Received: by oz.volcano.org (Postfix, from userid 1001) id 87AB050846; Fri, 3 Jun 2011 09:39:13 -1000 (HST) Date: Fri, 3 Jun 2011 09:39:13 -1000 From: Clifton Royston To: Willy Offermans Message-ID: <20110603193913.GA7077@volcano.org> Mail-Followup-To: Willy Offermans , freebsd-stable@freebsd.org, freebsd-hardware@freebsd.org References: <20110521092037.GB3271@vpn.offrom.nl> <201105311101.23905.jhb@freebsd.org> <20110603123454.GB3433@vpn.offrom.nl> <201106030948.26246.jhb@freebsd.org> <20110603190009.GA5809@vpn.offrom.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20110603190009.GA5809@vpn.offrom.nl> User-Agent: Mutt/1.4.2.3i Cc: freebsd-stable@freebsd.org, freebsd-hardware@freebsd.org Subject: Re: modem support MT9234ZPX-PCIE-NV X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 03 Jun 2011 19:39:15 -0000 On Fri, Jun 03, 2011 at 09:00:09PM +0200, Willy Offermans wrote: > Hello John and FreeBSD friends, ... > > The latter patch seems to work: > > >From the boot.msg: > > > .... > puc0: mem 0xfbfffc00-0xfbffffff irq 16 at device 0.0 on pci6 > puc0: failed to enable port mapping! > puc0: [FILTER] > uart0: <16750 or compatible> on puc0 > uart0: [FILTER] > uart1: <16750 or compatible> on puc0 > uart1: [FILTER] > .... > > > As I already pointed out, I do not have a line connected to the modem yet. > This connection will hopefully be established tomorrow. After some rigorous > testing I will post a mail with the on stream results. On the other hand, > if someone knows some off stream testing procedures, then I'm happy to hear > about that. ... Many if not most modems supporting a Hayes-style command set include several loopback points (digital and analog) which you can turn on via specific command. Those commands are all non-standardized, so I can't tell you the commands for yours, but if you can look through a user manual or command reference you should be able to find them. Turning on loopback should allow you to do some basic verification tests, e.g. pipe a file of random binary values into it while concurrently reading it, and verify that you get the same contents. Personally, I'd try to get the digital loopback working first, then if that's OK try the analog loopback point. -- Clifton -- Clifton Royston -- cliftonr@iandicomputing.com / cliftonr@volcano.org President - I and I Computing * http://www.iandicomputing.com/ Custom programming, network design, systems and network consulting services From owner-freebsd-stable@FreeBSD.ORG Fri Jun 3 19:54:29 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CE570106564A for ; Fri, 3 Jun 2011 19:54:29 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from mail-pz0-f54.google.com (mail-pz0-f54.google.com [209.85.210.54]) by mx1.freebsd.org (Postfix) with ESMTP id 9ECF18FC13 for ; Fri, 3 Jun 2011 19:54:29 +0000 (UTC) Received: by pzk27 with SMTP id 27so1184752pzk.13 for ; Fri, 03 Jun 2011 12:54:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:from:date:to:cc:subject:message-id:reply-to :references:mime-version:content-type:content-disposition :in-reply-to:user-agent; bh=oqi8P6od3VE9TggKrTTZqRhKzUlnf5fRSLJvkOPfj9w=; b=Gea9rbd146GJKdyjq+woQN62qkYyvznw0kjw8OhlwRlDyW7Zd3+qTrPsICV2FDCLy4 7DSqgLYLDRnvcXPCZsb2cyVdDacm+kL4hCRPmaIP3jWxnwp3E7o+m1sliNvvYhyfFs7M 8XcKiKeccHR8yR1RvJ9vpTIpx8p4m2fVivIAc= 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=CItD5szK/QpYflVmN7dZ0enxOVjdEz98r83wzNFPyHgC2Rs3WVgxk9dIX4WMwzfVFi OJ3yIWI0+ZUkapKJD5oYLnQoZPPpGZOfzb4nOcm92MbbCAoPlVzisdBq/W6Nqlj7n7px JZQjlgdRG6tn8HdKzwMCpOA7B1GHn0qUMxvJM= Received: by 10.68.6.133 with SMTP id b5mr890350pba.348.1307129162391; Fri, 03 Jun 2011 12:26:02 -0700 (PDT) Received: from pyunyh@gmail.com ([174.35.1.224]) by mx.google.com with ESMTPS id c3sm1658277pbk.93.2011.06.03.12.26.00 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 03 Jun 2011 12:26:01 -0700 (PDT) Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Fri, 03 Jun 2011 12:26:03 -0700 From: YongHyeon PYUN Date: Fri, 3 Jun 2011 12:26:03 -0700 To: Ken Chen Message-ID: <20110603192603.GA16885@michelle.cdnetworks.com> References: 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: freebsd-stable@freebsd.org Subject: Re: Realtek 8111e on 8.2-RELEASE 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, 03 Jun 2011 19:54:29 -0000 On Sat, Jun 04, 2011 at 01:56:15AM +0800, Ken Chen wrote: > Hello, > > Anyone tried Realtek 8111e on 8.2-RELEASE? Realtek8111e should be supported, > but I got following message: > > re0: port > 0xe800-0xe8ff mem 0xfdfff000-0xfdffffff, > 0xfdff8000-0xfdffbfff irq 17 at device 0.0 on pci2 > re0: Using 1 MSI messages > re0: Chip rev. 0x2c800000 > re0: MAC rev. 0x00000000 > re0: Unknown H/W revision: 0%2c800000 > device_attach:re0 attach returned 6 > > > Any suggestion? Thanks a lot! Updating to latest stable/8 will solve the issue. Or 1. Download two files at the following URL http://people.freebsd.org/~yongari/re/8.2R/if_re.c http://people.freebsd.org/~yongari/re/8.2R/if_rlreg.h 2. Copy downloaded if_re.c to /usr/src/sys/dev/re directory 3. Copy downloaded if_rlreg.h to /usr/src/sys/pci directory 4. Rebuild kernel and reboot. From owner-freebsd-stable@FreeBSD.ORG Fri Jun 3 20:59:38 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B1272106566B; Fri, 3 Jun 2011 20:59:38 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 767DF8FC0A; Fri, 3 Jun 2011 20:59:38 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 2EA3446B24; Fri, 3 Jun 2011 16:59:38 -0400 (EDT) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id B119B8A02A; Fri, 3 Jun 2011 16:59:37 -0400 (EDT) From: John Baldwin To: Willy@offermans.rompen.nl Date: Fri, 3 Jun 2011 16:54:48 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110325; KDE/4.5.5; amd64; ; ) References: <20110521092037.GB3271@vpn.offrom.nl> <201106030948.26246.jhb@freebsd.org> <20110603190009.GA5809@vpn.offrom.nl> In-Reply-To: <20110603190009.GA5809@vpn.offrom.nl> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201106031654.48865.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (bigwig.baldwin.cx); Fri, 03 Jun 2011 16:59:37 -0400 (EDT) Cc: freebsd-hardware@freebsd.org, Marcel Moolenaar , freebsd-stable@freebsd.org Subject: Re: modem support MT9234ZPX-PCIE-NV X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 03 Jun 2011 20:59:38 -0000 On Friday, June 03, 2011 3:00:09 pm Willy Offermans wrote: > Hello John and FreeBSD friends, > > On Fri, Jun 03, 2011 at 09:48:26AM -0400, John Baldwin wrote: > > On Friday, June 03, 2011 8:34:54 am Willy Offermans wrote: > > > Dear John and FreeBSD friends, > > > > > > On Tue, May 31, 2011 at 11:01:23AM -0400, John Baldwin wrote: > > > > On Monday, May 30, 2011 5:25:14 am Willy Offermans wrote: > > > > > Hello John and FreeBSD friends, > > > > > > > > > > On Fri, May 27, 2011 at 10:43:34AM -0400, John Baldwin wrote: > > > > > > On Friday, May 27, 2011 10:38:02 am Willy Offermans wrote: > > > > > > > Dear John and FreeBSD friends, > > > > > > > > > > > > > > On Fri, May 27, 2011 at 08:05:56AM -0400, John Baldwin wrote: > > > > > > > > On Thursday, May 26, 2011 4:58:37 pm Mike Tancsa wrote: > > > > > > > > > On 5/26/2011 4:12 PM, John Baldwin wrote: > > > > > > > > > > > > > > > > > > > > Hmm, can you get 'pciconf -lb' output? > > > > > > > > > > > > > > > > > > > > Hmm, wow, I wonder how uart(4) works at all. It tries to > > reuse it's softc > > > > > > > > > > structure in uart_bus_attach() that was setup in > > uart_bus_probe(). Since > > > > > > > > it > > > > > > > > > > doesn't return 0 from its probe routine, that is forbidden. > > I guess it > > > > > > > > > > accidentally works because of the hack where we call > > DEVICE_PROBE() again > > > > > > > > > > to make sure the device description is correct. > > > > > > > > > > > > > > > > > > > > > > > > > > > I think this is a similar card. Had it laying about for a while > > and > > > > > > > > > popped it in. cu -l to it, attaches, but I am not able to > > interact with it. > > > > > > > > > > > > > > > > > > none3@pci0:5:0:0: class=0x070002 card=0x20282205 > > chip=0x015213a8 > > > > > > > > > rev=0x02 hdr=0x00 > > > > > > > > > vendor = 'Exar Corp.' > > > > > > > > > device = 'XR17C/D152 Dual PCI UART' > > > > > > > > > class = simple comms > > > > > > > > > subclass = UART > > > > > > > > > bar [10] = type Memory, range 32, base 0xe8950000, size > > 1024, enabled > > > > > > > > > > > > > > > > > > > > > > > > > > > NetBSD supposedly has support for this card > > > > > > > > > > > > > > > > Oh, hmm, looks like the clock has an unusual multiplier. Does it > > work if you > > > > > > > > use 'cu -l -s 1200' to talk at 9600 for example? (In general use > > speed / 8 > > > > > > > > as the speed to '-s'.) > > > > > > > > > > > > > > > > Also, is your card a modem or a dual-port card? > > > > > > > > > > > > > > > > -- > > > > > > > > John Baldwin > > > > > > > > > > > > > > It is a modem. > > > > > > > > > > > > > > As suggested: > > > > > > > > > > > > > > kosmos# cu -l /dev/cuau0 -s 1200 > > > > > > > Stale lock on cuau0 PID=3642... overriding. > > > > > > > Connected > > > > > > > at&F > > > > > > > OK > > > > > > > atdt0045******* > > > > > > > NO DIALTONE > > > > > > > > > > > > Ok, try this updated patch. After this you should be able to use the > > correct > > > > > > speed: > > > > > > > > > > > > Index: uart_bus_pci.c > > > > > > =================================================================== > > > > > > --- uart_bus_pci.c (revision 222285) > > > > > > +++ uart_bus_pci.c (working copy) > > > > > > @@ -110,6 +110,8 @@ static struct pci_id pci_ns8250_ids[] = { > > > > > > { 0x1415, 0x950b, 0xffff, 0, "Oxford Semiconductor OXCB950 Cardbus > > 16950 UART", > > > > > > 0x10, 16384000 }, > > > > > > { 0x151f, 0x0000, 0xffff, 0, "TOPIC Semiconductor TP560 56k modem", > > 0x10 }, > > > > > > +{ 0x13a8, 0x0152, 0x2205, 0x2026, "MultiTech MultiModem ZPX", 0x10, > > > > > > + 8 * DEFAULT_RCLK }, > > > > > > { 0x9710, 0x9820, 0x1000, 1, "NetMos NM9820 Serial Port", 0x10 }, > > > > > > { 0x9710, 0x9835, 0x1000, 1, "NetMos NM9835 Serial Port", 0x10 }, > > > > > > { 0x9710, 0x9865, 0xa000, 0x1000, "NetMos NM9865 Serial Port", 0x10 > > }, > > > > > > > > > > > > -- > > > > > > John Baldwin > > > > > > > > > > The structure you have provided in your magic line would also need > > > > > some explanation. The data concerns the description of the chip and the > > > > > card I guess and can be gained by `pciconf -lv` > > > > > > > > > > uart0@pci0:6:0:0: class=0x070002 card=0x20262205 chip=0x015213a8 > > rev=0x02 hdr=0x00 > > > > > vendor = 'Exar Corp.' > > > > > device = 'XR17C/D152 Dual PCI UART' > > > > > class = simple comms > > > > > subclass = UART > > > > > > > > > > > > > > > A more detailed explanation would not harm. The data 0x10 and > > > > > 8 * DEFAULT_RCLK are still totally miraculous to me. > > > > > > > > 0x10 is the resource id for the first PCI BAR (rids for PCI device > > resources > > > > use the offset in PCI config space of the associated BAR). It would > > perhaps > > > > be more obvious if uart(4) and puc(4) used PCIR_BAR(0) rather than 0x10. > > > > Bumping the clock by a multiple of 8 was based on looking at the change in > > > > NetBSD that Mike Tancsa pointed to and that you verified by noting that > > > > 'cu -s 1200' connected at 9600 (9600 / 1200 == 8). > > > > > > > > One question though, would you be able to test the patch for puc(4) that I > > > > sent to Mike Tancsa to see if your modem works with puc(4)? The puc(4) > > > > patch is more general and if it works fine for your modem I'd rather just > > > > commit that. > > > > > > > > -- > > > > John Baldwin > > > > > > I have applied the suggested patch. > > > > > > The outcome was a new /usr/src/sys/dev/puc/pucdata.c file, which I have > > > enclosed. > > > > Hmm, there was a newer puc patch. Please try this one instead: > > > > Index: pucdata.c > > =================================================================== > > --- pucdata.c (revision 222565) > > +++ pucdata.c (working copy) > > @@ -48,8 +48,8 @@ __FBSDID("$FreeBSD$"); > > #include > > > > static puc_config_f puc_config_amc; > > -static puc_config_f puc_config_cronyx; > > static puc_config_f puc_config_diva; > > +static puc_config_f puc_config_exar; > > static puc_config_f puc_config_icbook; > > static puc_config_f puc_config_quatech; > > static puc_config_f puc_config_syba; > > @@ -548,11 +548,25 @@ const struct puc_cfg puc_pci_devices[] = { > > PUC_PORT_8S, 0x18, 0, 8, > > }, > > > > + { 0x13a8, 0x0152, 0xffff, 0, > > + "Exar XR17C/D152", > > + DEFAULT_RCLK * 8, > > + PUC_PORT_2S, 0x10, 0, -1, > > + .config_function = puc_config_exar > > + }, > > + > > + { 0x13a8, 0x0154, 0xffff, 0, > > + "Exar XR17C154", > > + DEFAULT_RCLK * 8, > > + PUC_PORT_4S, 0x10, 0, -1, > > + .config_function = puc_config_exar > > + }, > > + > > { 0x13a8, 0x0158, 0xffff, 0, > > - "Cronyx Omega2-PCI", > > + "Exar XR17C158", > > DEFAULT_RCLK * 8, > > PUC_PORT_8S, 0x10, 0, -1, > > - .config_function = puc_config_cronyx > > + .config_function = puc_config_exar > > }, > > > > { 0x13a8, 0x0258, 0xffff, 0, > > @@ -1014,28 +1028,28 @@ puc_config_amc(struct puc_softc *sc, enum puc_cfg_ > > } > > > > static int > > -puc_config_cronyx(struct puc_softc *sc, enum puc_cfg_cmd cmd, int port, > > +puc_config_diva(struct puc_softc *sc, enum puc_cfg_cmd cmd, int port, > > intptr_t *res) > > { > > + const struct puc_cfg *cfg = sc->sc_cfg; > > + > > if (cmd == PUC_CFG_GET_OFS) { > > - *res = port * 0x200; > > + if (cfg->subdevice == 0x1282) /* Everest SP */ > > + port <<= 1; > > + else if (cfg->subdevice == 0x104b) /* Maestro SP2 */ > > + port = (port == 3) ? 4 : port; > > + *res = port * 8 + ((port > 2) ? 0x18 : 0); > > return (0); > > } > > return (ENXIO); > > } > > > > static int > > -puc_config_diva(struct puc_softc *sc, enum puc_cfg_cmd cmd, int port, > > +puc_config_exar(struct puc_softc *sc, enum puc_cfg_cmd cmd, int port, > > intptr_t *res) > > { > > - const struct puc_cfg *cfg = sc->sc_cfg; > > - > > if (cmd == PUC_CFG_GET_OFS) { > > - if (cfg->subdevice == 0x1282) /* Everest SP */ > > - port <<= 1; > > - else if (cfg->subdevice == 0x104b) /* Maestro SP2 */ > > - port = (port == 3) ? 4 : port; > > - *res = port * 8 + ((port > 2) ? 0x18 : 0); > > + *res = port * 0x200; > > return (0); > > } > > return (ENXIO); > > > > -- > > John Baldwin > > The latter patch seems to work: > > From the boot.msg: > > > .... > puc0: mem 0xfbfffc00-0xfbffffff irq 16 at device 0.0 on pci6 > puc0: failed to enable port mapping! > puc0: [FILTER] > uart0: <16750 or compatible> on puc0 > uart0: [FILTER] > uart1: <16750 or compatible> on puc0 > uart1: [FILTER] > .... > > > As I already pointed out, I do not have a line connected to the modem yet. > This connection will hopefully be established tomorrow. After some rigorous > testing I will post a mail with the on stream results. On the other hand, > if someone knows some off stream testing procedures, then I'm happy to hear > about that. For the time being I have started minicom and issued: > > AT > AT&F > ATI > > All with positive and already mentioned results. Ok. So it looks like your modem does indeed have two functioning UARTs. Do you have any idea what might be on the second UART? -- John Baldwin From owner-freebsd-stable@FreeBSD.ORG Fri Jun 3 21:18:51 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7E55D1065675 for ; Fri, 3 Jun 2011 21:18:51 +0000 (UTC) (envelope-from torfinn.ingolfsen@broadpark.no) Received: from thalia-smout.broadpark.no (thalia-smout.broadpark.no [80.202.8.21]) by mx1.freebsd.org (Postfix) with ESMTP id 36A9B8FC16 for ; Fri, 3 Jun 2011 21:18:50 +0000 (UTC) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from ignis-smin.broadpark.no ([80.202.8.11]) by thalia-smout.broadpark.no (Sun Java(tm) System Messaging Server 7u3-15.01 64bit (built Feb 12 2010)) with ESMTP id <0LM800JI1GJDB670@thalia-smout.broadpark.no> for freebsd-stable@freebsd.org; Fri, 03 Jun 2011 23:18:49 +0200 (CEST) Received: from kg-v2.kg4.no ([84.48.120.215]) by ignis-smin.broadpark.no (Sun Java(tm) System Messaging Server 7u3-15.01 64bit (built Feb 12 2010)) with SMTP id <0LM800FPPGJDM800@ignis-smin.broadpark.no> for freebsd-stable@freebsd.org; Fri, 03 Jun 2011 23:18:49 +0200 (CEST) Date: Fri, 03 Jun 2011 23:18:49 +0200 From: Torfinn Ingolfsen To: freebsd-stable@freebsd.org Message-id: <20110603231849.02fe4317.torfinn.ingolfsen@broadpark.no> In-reply-to: <20110602230921.GA57825@icarus.home.lan> References: <20110602213116.425400b6.torfinn.ingolfsen@broadpark.no> <20110602195026.GA54023@icarus.home.lan> <20110603003940.d0b3821b.torfinn.ingolfsen@broadpark.no> <20110602230921.GA57825@icarus.home.lan> X-Mailer: Sylpheed 3.1.0 (GTK+ 2.22.1; amd64-portbld-freebsd8.1) X-Face: "t9w2,-X@O^I`jVW\sonI3.,36KBLZE*AL[y9lL[PyFD*r_S:dIL9c[8Y>V42R0"!"yb_zN,f#%.[PYYNq; m"_0v; ~rUM2Yy!zmkh)3&U|u!=T(zyv,MHJv"nDH>OJ`t(@mil461d_B'Uo|'nMwlKe0Mv=kvV?Nh@>Hb<3s_z2jYgZhPb@?Wi^x1a~Hplz1.zH Subject: Re: Fileserver panic - FreeBSD 8.1-stable and zfs X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jun 2011 21:18:51 -0000 Update: On Thu, 02 Jun 2011 16:09:21 -0700 Jeremy Chadwick wrote: > Anyway, your system has 4GB of RAM installed in it, so on 8.1-STABLE I'd > recommend you try these settings: > > vm.kmem_size="3584M" > vm.kmem_size_max="3584M" > vfs.zfs.arc_max="2048M" > > Now, these are all chosen by me off the top of my head with absolutely > ZERO knowledge of what the memory usage on this system is like > **without** ZFS in the picture. I'm making a lot of assumptions, and > I'm assuming worst-case scenarios. For example, if this machine also > runs mysqld and its tuned to take up a lot of memory, I would advocate > dropping vfs.zfs.arc_max to 1536M or 1024M. Please don't drop it "too > much"; ZFS performs best when it has lots of ARC. > > Since you mentioned going to 8.2-STABLE, all you need to tune on that > version is one single tunable: > > vfs.zfs.arc_max The machine now runs 8.2-stable: root@kg-f2# uname -a FreeBSD kg-f2.kg4.no 8.2-STABLE FreeBSD 8.2-STABLE #5: Fri Jun 3 17:20:39 CEST 2011 root@kg-f2.kg4.no:/usr/obj/usr/src/sys/GENERIC amd64 And I have added the following to /boot/loader.conf: vfs.zfs.arc_max="2048M" Hopefully, this will keep the machine rock solid (unitil something else happens, at least). Oh, and thanks for your advice - really helpful. -- Torfinn From owner-freebsd-stable@FreeBSD.ORG Sat Jun 4 08:23:01 2011 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3D4EC1065675; Sat, 4 Jun 2011 08:23:01 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 253CF8FC16; Sat, 4 Jun 2011 08:22:59 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id LAA24873; Sat, 04 Jun 2011 11:22:58 +0300 (EEST) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1QSm8I-0004eU-Du; Sat, 04 Jun 2011 11:22:58 +0300 Message-ID: <4DE9EB61.3000006@FreeBSD.org> Date: Sat, 04 Jun 2011 11:22:57 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.17) Gecko/20110503 Lightning/1.0b2 Thunderbird/3.1.10 MIME-Version: 1.0 To: "Robert N. M. Watson" References: <4DE8FA2E.4030202@FreeBSD.org> <5E4D0F56-4338-4157-8BC6-17EE2831725F@FreeBSD.org> In-Reply-To: <5E4D0F56-4338-4157-8BC6-17EE2831725F@FreeBSD.org> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-current@FreeBSD.org, freebsd-stable@FreeBSD.org Subject: Re: [poll / rfc] kdb_stop_cpus X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 04 Jun 2011 08:23:01 -0000 on 03/06/2011 20:57 Robert N. M. Watson said the following: > > On 3 Jun 2011, at 16:13, Andriy Gapon wrote: > >> I wonder if anybody uses kdb_stop_cpus with non-default value. If, yes, I >> am very interested to learn about your usecase for it. > > The issue that prompted the sysctl was non-NMI IPIs being used to enter the > debugger or reboot following a core hanging with interrupts disabled. With > the switch to NMI IPIs in some of those circumstances, life is better -- at > least, on hardware that supports non-maskable IPIs. I seem to recall sparc64 > doesn't, however? Seems to be so as Nathan has also pointed out for PPC. For this I also plan the following change: commit 458ebd9aca7e91fc6e0825c727c7220ab9f61016 generic_stop_cpus: move timeout detection code from under DIAGNOSTIC ... and also increase it a bit. IMO it's better to detect and report the (rather serious) condition and allow a system to proceed somehow rather than be stuck in an endless loop. diff --git a/sys/kern/subr_smp.c b/sys/kern/subr_smp.c index ae52f4b..4bd766b 100644 --- a/sys/kern/subr_smp.c +++ b/sys/kern/subr_smp.c @@ -232,12 +232,10 @@ generic_stop_cpus(cpumask_t map, u_int type) /* spin */ cpu_spinwait(); i++; -#ifdef DIAGNOSTIC - if (i == 100000) { + if (i == 100000000) { printf("timeout stopping cpus\n"); break; } -#endif } stopping_cpu = NOCPU; > Not sure about MIPS, etc. Attilio has since significantly > improved our shutdown behaviour -- initially, the switch to NMI IPIs broke > other things (because certain IPIs then improperly preempted threads holding > spinlocks), but that pretty much all seems worked out now. -- Andriy Gapon From owner-freebsd-stable@FreeBSD.ORG Sat Jun 4 09:11:10 2011 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 773D0106566C; Sat, 4 Jun 2011 09:11:10 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 532D68FC08; Sat, 4 Jun 2011 09:11:10 +0000 (UTC) Received: from [192.168.2.112] (host86-173-95-198.range86-173.btcentralplus.com [86.173.95.198]) by cyrus.watson.org (Postfix) with ESMTPSA id 7022346B2E; Sat, 4 Jun 2011 05:11:09 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: "Robert N. M. Watson" In-Reply-To: <4DE9EB61.3000006@FreeBSD.org> Date: Sat, 4 Jun 2011 10:11:07 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <8AA26086-DA05-4DDA-9973-AE57328E2C81@FreeBSD.org> References: <4DE8FA2E.4030202@FreeBSD.org> <5E4D0F56-4338-4157-8BC6-17EE2831725F@FreeBSD.org> <4DE9EB61.3000006@FreeBSD.org> To: Andriy Gapon X-Mailer: Apple Mail (2.1084) Cc: freebsd-current@FreeBSD.org, freebsd-stable@FreeBSD.org Subject: Re: [poll / rfc] kdb_stop_cpus X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 04 Jun 2011 09:11:10 -0000 On 4 Jun 2011, at 09:22, Andriy Gapon wrote: > on 03/06/2011 20:57 Robert N. M. Watson said the following: >>=20 >> On 3 Jun 2011, at 16:13, Andriy Gapon wrote: >>=20 >>> I wonder if anybody uses kdb_stop_cpus with non-default value. If, = yes, I >>> am very interested to learn about your usecase for it. >>=20 >> The issue that prompted the sysctl was non-NMI IPIs being used to = enter the >> debugger or reboot following a core hanging with interrupts disabled. = With >> the switch to NMI IPIs in some of those circumstances, life is better = -- at >> least, on hardware that supports non-maskable IPIs. I seem to recall = sparc64 >> doesn't, however? >=20 > Seems to be so as Nathan has also pointed out for PPC. > For this I also plan the following change: >=20 > commit 458ebd9aca7e91fc6e0825c727c7220ab9f61016 >=20 > generic_stop_cpus: move timeout detection code from under = DIAGNOSTIC >=20 > ... and also increase it a bit. > IMO it's better to detect and report the (rather serious) condition = and > allow a system to proceed somehow rather than be stuck in an = endless > loop. Agreed on detecting and reporting. It would be good to confirm that it = works in practice, however, and also that there are no false positives. = I'm not sure what the best test scenarios are for that. Robert From owner-freebsd-stable@FreeBSD.ORG Sat Jun 4 22:59:13 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 49819106566B for ; Sat, 4 Jun 2011 22:59:13 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: from mail-gx0-f182.google.com (mail-gx0-f182.google.com [209.85.161.182]) by mx1.freebsd.org (Postfix) with ESMTP id 045218FC16 for ; Sat, 4 Jun 2011 22:59:12 +0000 (UTC) Received: by gxk28 with SMTP id 28so1745381gxk.13 for ; Sat, 04 Jun 2011 15:59:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=bVYvCO+7Urv6VxMt/s9qUDeLTZWwuPQrQ/43cfS5keA=; b=dwo0wj30xjiulUsgL9Hd4+ElELA2NSkyclSIwopt2XU7E7y53vwWiyhS4H1NipFPmY dk4XQ1gMrQEEp3VFKfuJR8TZYnrMFYrbUUmTxuErYYWfCm8j1f5z8hDVgHxkSbRba5rU ZCeaHRbrmYuJmF6Uw73lCxbF3ao+vn/7RXHaE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=XGl3akqaBHhaxLvjmxoWlI3ywuWEWyXVoOBI0ZxZeAqqRyDtc3FADcEGGLHjRF7IZV E05i6al0aRl0Wz+XYENa53AwHSeV4mCzV0pMAMdgW6jLz0j/pDaVghgU4/+kcWuFJrDj FqHgchsYNlRe4Wuj9AD2fQtpRIXxMRzv+disU= MIME-Version: 1.0 Received: by 10.236.154.105 with SMTP id g69mr4320048yhk.505.1307226839507; Sat, 04 Jun 2011 15:33:59 -0700 (PDT) Sender: asmrookie@gmail.com Received: by 10.236.103.136 with HTTP; Sat, 4 Jun 2011 15:33:59 -0700 (PDT) In-Reply-To: <4DE8FD83.6030503@freebsd.org> References: <4DE8FA2E.4030202@FreeBSD.org> <4DE8FD83.6030503@freebsd.org> Date: Sat, 4 Jun 2011 18:33:59 -0400 X-Google-Sender-Auth: ni--62nmh3sCfELNT79lJf4LNOA Message-ID: From: Attilio Rao To: Nathan Whitehorn Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current@freebsd.org, freebsd-stable@freebsd.org, Andriy Gapon Subject: Re: [poll / rfc] kdb_stop_cpus X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 04 Jun 2011 22:59:13 -0000 2011/6/3 Nathan Whitehorn : > On 06/03/11 10:13, Andriy Gapon wrote: >> >> I wonder if anybody uses kdb_stop_cpus with non-default value. >> If, yes, I am very interested to learn about your usecase for it. >> >> I think that the default kdb behavior is the correct one, so it doesn't >> make sense >> to have a knob to turn on incorrect behavior. >> But I may be missing something obvious. >> >> The comment in the code doesn't really satisfy me: >> /* >> =C2=A0* Flag indicating whether or not to IPI the other CPUs to stop the= m on >> =C2=A0* entering the debugger. =C2=A0Sometimes, this will result in a de= adlock as >> =C2=A0* stop_cpus() waits for the other cpus to stop, so we allow it to = be >> =C2=A0* disabled. =C2=A0In order to maximize the chances of success, use= a hard >> =C2=A0* stop for that. >> =C2=A0*/ >> >> The hard stop should be sufficiently mighty. >> Yes, I am aware of supposedly extremely rare situations where a deadlock >> could >> happen even when using hard stop. =C2=A0But I'd rather fix that than hav= e this >> switch. >> >> Oh, the commit message (from 2004) explains it: >>> >>> Add a new sysctl, debug.kdb.stop_cpus, which controls whether or not we >>> attempt to IPI other cpus when entering the debugger in order to stop >>> them while in the debugger. =C2=A0The default remains to issue the stop= ; >>> however, that can result in a hang if another cpu has interrupts disabl= ed >>> and is spinning, since the IPI won't be received and the KDB will wait >>> indefinitely. =C2=A0We probably need to add a timeout, but this is a us= eful >>> stopgap in the mean time. >> >> But that was before we started using hard stop in this context (in 2009)= . > > Some non-x86 platforms (e.g. PPC) don't support real NMIs, and so this st= ill > applies. Well, if I get Andriy's proposal right, he just wants to trim off the possibility to not stop the CPUs on entering KDB. I'm not entirely sure why there is a sysctl for disabling that and I really don't want it. Note that the missing of the NMI/privileged Interrupt is not going to be a factor on this request, unless you are worried a lot by the easy deadlock that a normal stop operation may lead. If that is the case, I think that the upcoming work on skipping locking during KDB/panic entering is going to help a lot for this case. At that point removing the possibility to turn off CPU stopping will be a good idea, IMHO. Attilio --=20 Peace can only be achieved by understanding - A. Einstein From owner-freebsd-stable@FreeBSD.ORG Sat Jun 4 23:03:05 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7BDB6106566B for ; Sat, 4 Jun 2011 23:03:05 +0000 (UTC) (envelope-from asmrookie@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 35ABD8FC1B for ; Sat, 4 Jun 2011 23:03:04 +0000 (UTC) Received: by gyg13 with SMTP id 13so1750852gyg.13 for ; Sat, 04 Jun 2011 16:03:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=lrZ1edEjVtym7htofHoC62s2wKoryNttfZYqcVgCQNw=; b=Tfxzha2AtNzeJhIxQo/uUNqYdTbfCnTw+MGvgF/W7SnZJFiaV553jsCDxWMSmH6pV7 qdm0mXCvztMVlF1efoDkxU7AW7Qv5YVwMn/EeHJpIvClWNPaDpCifq98efdOETHxoVDe nfFEFphj0RDtd9TFb+DRWrzSBPsvTuJ40TT2Q= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=XuVKSZFEec+LDEls2jQeS8/ksUehKoEgpBDni2/pTp+oCR51EefijU7L36vexim0XR Hf3VX1U8WH38qpHtPqPuN2KNrv4vRksEqNmVlI5yJyf1KH6ZyxF5ExyjYqwVZvnG+Xc+ 622Ue8WwindmlktUNeCxLwUArSPwJVRpHyV4U= MIME-Version: 1.0 Received: by 10.236.161.194 with SMTP id w42mr4157724yhk.237.1307226928163; Sat, 04 Jun 2011 15:35:28 -0700 (PDT) Sender: asmrookie@gmail.com Received: by 10.236.103.136 with HTTP; Sat, 4 Jun 2011 15:35:28 -0700 (PDT) In-Reply-To: <4DE9EB61.3000006@FreeBSD.org> References: <4DE8FA2E.4030202@FreeBSD.org> <5E4D0F56-4338-4157-8BC6-17EE2831725F@FreeBSD.org> <4DE9EB61.3000006@FreeBSD.org> Date: Sat, 4 Jun 2011 18:35:28 -0400 X-Google-Sender-Auth: Iu3VIueuqAZNmZQIBs5oUET-vGQ Message-ID: From: Attilio Rao To: Andriy Gapon Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-stable@freebsd.org, freebsd-current@freebsd.org, "Robert N. M. Watson" Subject: Re: [poll / rfc] kdb_stop_cpus X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 04 Jun 2011 23:03:05 -0000 2011/6/4 Andriy Gapon : > on 03/06/2011 20:57 Robert N. M. Watson said the following: >> >> On 3 Jun 2011, at 16:13, Andriy Gapon wrote: >> >>> I wonder if anybody uses kdb_stop_cpus with non-default value. If, yes,= I >>> am very interested to learn about your usecase for it. >> >> The issue that prompted the sysctl was non-NMI IPIs being used to enter = the >> debugger or reboot following a core hanging with interrupts disabled. Wi= th >> the switch to NMI IPIs in some of those circumstances, life is better --= at >> least, on hardware that supports non-maskable IPIs. I seem to recall spa= rc64 >> doesn't, however? > > Seems to be so as Nathan has also pointed out for PPC. > For this I also plan the following change: > > commit 458ebd9aca7e91fc6e0825c727c7220ab9f61016 > > =C2=A0 =C2=A0generic_stop_cpus: move timeout detection code from under DI= AGNOSTIC > > =C2=A0 =C2=A0... and also increase it a bit. > =C2=A0 =C2=A0IMO it's better to detect and report the (rather serious) co= ndition and > =C2=A0 =C2=A0allow a system to proceed somehow rather than be stuck in an= endless > =C2=A0 =C2=A0loop. > > diff --git a/sys/kern/subr_smp.c b/sys/kern/subr_smp.c > index ae52f4b..4bd766b 100644 > --- a/sys/kern/subr_smp.c > +++ b/sys/kern/subr_smp.c > @@ -232,12 +232,10 @@ generic_stop_cpus(cpumask_t map, u_int type) > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0/* spin */ > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0cpu_spinwait(); > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0i++; > -#ifdef DIAGNOSTIC > - =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 if (i =3D=3D 100000) { > + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 if (i =3D=3D 100000000= ) { > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0printf("timeout stopping cpus\n"); > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0break; > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0} > -#endif > =C2=A0 =C2=A0 =C2=A0 =C2=A0} > > =C2=A0 =C2=A0 =C2=A0 =C2=A0stopping_cpu =3D NOCPU; I'd also add the ability, once the deadlock is detected, to break in KDB, and put that under DIAGNOSTIC. I had such a patch and I used it to debug some deadlocks on shutdown code, but now it seems I can't find it anymore. Attilio --=20 Peace can only be achieved by understanding - A. Einstein