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 |