From owner-freebsd-current@FreeBSD.ORG Sat Dec 26 03:03:06 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C0DE1106568B for ; Sat, 26 Dec 2009 03:03:06 +0000 (UTC) (envelope-from nslay@comcast.net) Received: from QMTA11.emeryville.ca.mail.comcast.net (qmta11.emeryville.ca.mail.comcast.net [76.96.27.211]) by mx1.freebsd.org (Postfix) with ESMTP id A93018FC0C for ; Sat, 26 Dec 2009 03:03:06 +0000 (UTC) Received: from OMTA04.emeryville.ca.mail.comcast.net ([76.96.30.35]) by QMTA11.emeryville.ca.mail.comcast.net with comcast id Mexg1d0020lTkoCABez24N; Sat, 26 Dec 2009 02:59:02 +0000 Received: from LIGHTBULB.LOCAL ([69.244.210.117]) by OMTA04.emeryville.ca.mail.comcast.net with comcast id Mf311d0032YXfpR8Qf363U; Sat, 26 Dec 2009 03:03:07 +0000 Message-ID: <4B357CC4.9020909@comcast.net> Date: Fri, 25 Dec 2009 22:02:28 -0500 From: Nathan Lay User-Agent: Thunderbird 2.0.0.23 (X11/20091223) MIME-Version: 1.0 To: Alexander Motin References: <1261707782.00199010.1261696205@10.7.7.3> <4B346BE0.2010909@FreeBSD.org> In-Reply-To: <4B346BE0.2010909@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: 8-STABLE ahci fails to attach, does not fallback on ataahci X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Dec 2009 03:03:06 -0000 Alexander Motin wrote: > Nathan Lay wrote: > >> I gave ATA_CAM a try last night and believe I have a similar setup >> (crippled hardware) in my laptop as Doug Barton's, although my >> controller is ICH6M. Nonetheless, ahci detects my controller and tries >> to attach and fails (returns 6). No ada nodes are created and the boot >> process halts trying to find a root mount. Verbose booting reveals >> nothing special. Anything else I can do to try to reveal the problem? >> >> I tried modular ATA with the following: >> >> device atacore >> device atapci >> device ataahci >> device ataintel >> >> device ahci >> >> From reading the lists more thoroughly, I now have the impression that >> either ahci or ataahci are necessary and not both. >> > > They duplicate each other, but should not conflict. > > >> If I remove 'device >> ahci' then 8-STABLE boots normally. However, I would think that if ahci >> failed to attach then the kernel should fallback on ataahci. If GENERIC >> included both ahci and ataahci, then I would never be able to boot >> FreeBSD let alone install it. >> > > There is no fallback mechanism on attach failure in newbus. ataahci will > only be used is ahci fail probe, not an attach. > > >> `uname -a` >> FreeBSD LIGHTBULB.LOCAL 8.0-STABLE FreeBSD 8.0-STABLE #4: Thu Dec 24 >> 02:40:23 EST 2009 >> nslay@LIGHTBULB.LOCAL:/usr/obj/usr/src/sys/LIGHTBULB i386 >> >> Here's what appears in my dmesg: >> atapci0: port >> 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0x18c0-0x18cf at device 31.2 on pci0 >> >> and the result of `pciconf -lv` >> atapci0@pci0:0:31:2: class=0x010180 card=0x056a1014 chip=0x26538086 >> rev=0x03 hdr=0x00 >> vendor = 'Intel Corporation' >> device = '82801FBM (ICH6M) SATA Controller' >> class = mass storage >> subclass = ATA >> > > There is the answer. ICH6 chipsets are using chip ID convention > different from other ICHs. Same ID used for AHCI and legacy modes. It > was false positive probe. This chip now runs in legacy mode. > > This patch should fix the issue: > > --- ahci.c.prev 2009-12-08 13:27:31.000000000 +0200 > +++ ahci.c 2009-12-25 09:28:32.000000000 +0200 > @@ -115,8 +115,8 @@ static struct { > {0x43931002, "ATI IXP700", 0}, > {0x43941002, "ATI IXP800", 0}, > {0x43951002, "ATI IXP800", 0}, > - {0x26528086, "Intel ICH6", 0}, > - {0x26538086, "Intel ICH6M", 0}, > + {0x26528086, "Intel ICH6", AHCI_Q_NOFORCE}, > + {0x26538086, "Intel ICH6M", AHCI_Q_NOFORCE}, > {0x26818086, "Intel ESB2", 0}, > {0x26828086, "Intel ESB2", 0}, > {0x26838086, "Intel ESB2", 0}, > > Hi Alexander, I also noticed in dmesg that ataahci never actually attaches (There's no AHCI messages). I examined ahci.c and ata-ahci.c and noticed that ata-ahci.c lacks the quirk table and code in ata_ahci_probe that would normally match this chip in ahci_probe. I think that it's subclass isn't PCIS_STORAGE_SATA. I tried to hardcode it to see if it would work but I never successfully persuaded ataahci to attach. I'm not familiar with kernel debugging or development and grew weary of constantly recompiling the kernel to try things. Best Regards, Nathan Lay