From owner-freebsd-current@FreeBSD.ORG Thu Sep 3 18:38:42 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 5C6C4106566C for ; Thu, 3 Sep 2009 18:38:42 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 2BF368FC0C for ; Thu, 3 Sep 2009 18:38:42 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id D261C46B03; Thu, 3 Sep 2009 14:38:41 -0400 (EDT) Received: from jhbbsd.hudson-trading.com (unknown [209.249.190.8]) by bigwig.baldwin.cx (Postfix) with ESMTPA id 004948A049; Thu, 3 Sep 2009 14:38:41 -0400 (EDT) From: John Baldwin To: Rainer Hurling Date: Thu, 3 Sep 2009 14:01:08 -0400 User-Agent: KMail/1.9.7 References: <4A9BF23F.6070801@netability.ie> <200909011717.57386.jhb@freebsd.org> <4A9FFEF0.1000502@gwdg.de> In-Reply-To: <4A9FFEF0.1000502@gwdg.de> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200909031401.08825.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (bigwig.baldwin.cx); Thu, 03 Sep 2009 14:38:41 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.95.1 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-1.6 required=4.2 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on bigwig.baldwin.cx Cc: Kostik Belousov , freebsd-current@freebsd.org Subject: Re: 8.0-beta3 does not detect several ata channels 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: Thu, 03 Sep 2009 18:38:42 -0000 On Thursday 03 September 2009 1:37:52 pm Rainer Hurling wrote: > On 01.09.2009 23:17 (UTC+2), John Baldwin wrote: > > On Tuesday 01 September 2009 4:40:41 pm Rainer Hurling wrote: > >> On 01.09.2009 21:05 (UTC+2), John Baldwin wrote: > >>> On Tuesday 01 September 2009 2:49:09 pm Rainer Hurling wrote: > >>>> On 01.09.2009 19:41 (UTC+2), John Baldwin wrote: > >>>>> On Tuesday 01 September 2009 12:47:50 pm Rainer Hurling wrote: > >>>>>> On 01.09.2009 16:02 (UTC+2), John Baldwin wrote: > >>>>>>> On Monday 31 August 2009 12:03:04 pm Florian Smeets wrote: > >>>>>>>> On 8/31/09 5:54 PM, Nick Hilliard wrote: > >>>>>>>>> Hi, > >>>>>>>>> > >>>>>>>>> I have a hp proliant ML115 with 6 sata ports which run in ATA mode > >>> (bios > >>>>>>>>> doesn't appear to give the option to use AHCI). On freebsd 7.x, all > >>>>>>>>> channels are detected. On freebsd8.0-beta3, the disks attached to > > the > >>>>>>>>> first two SATA ports are not detected, although it detects the ports > >>>>>>>>> themselves. > >>>>>>>>> > >>>>>>>>> I've attached a verbose dmesg from freebsd 7.1 and 8.0-beta3. > >>>>>>>>> > >>>>>>>>> Any ideas on what's going on here? This seems like a nasty > >>> regression. > >>>>>>>> There are 3 PRs about this problem: 128686, 132372, 137942. > >>>>>>>> > >>>>>>>> i386 version should recognize the disks. amd64 does when you set > >>>>>>>> hw.pci.mcfg=0 in loader.conf. > >>>>>>> Hmm, so an idea I had just now.. can you grab a dump of the PCI config > >>>>> space > >>>>>>> for the disk controller in the MCFG vs non-MCFG cases? That is, find > >>> the > >>>>>>> device's address using pciconf -lv (e.g. pci0:0:30:0 or some such) and > >>>>> then > >>>>>>> run this command under both configurations and save the output: > >>>>>>> > >>>>>>> pciconf -r pci0:0:30:0 0:0xfc > >>>>>>> > >>>>>> I am not sure if your idea has something to do with my (and some other > >>>>>> users) problem. So excuse me, if this posting is wrong. > >>>>>> > >>>>>> For some month now I am only able to boot CURRENT under amd64 with > >>>>>> setting hw.pci.mcfg=0. Under i386 all works fine. Below I listed output > >>>>>> under i386 and under amd64. Perhaps you are able to get a hint? > >>>>> Hmm, would you be able to boot with mcfg=1 on amd64 (perhaps using > > nfsroot > >>> or > >>>>> an mfsroot) and capture this output? The mcfg thing only affects access > >>> to > >>>>> PCI config space (what pciconf -r is displaying). I want to be able to > >>>>> compare the "broken" case (amd64 mcfg=1) with a working case. > >>>> My only amd64 system is at home. Sorry, but I have no idea how to start > >>>> this system using nfsroot oder mfsroot. > >>> Ok, I believe some of the other folks reporting an issue with this ATA > >>> controller had other disk controllers in the system so they may be able to > > do > >>> this. > >> Thanks to Kostik Belousov, I tried his hint with live CD. Here it is, > >> only for amd64, with snapshot from todays CURRENT: > >> > >> #systctl hw.pci.mcfg > >> hw.pci.mcfg: 1 > > > > Hmm, this one is identical to the mcfg=0 one on amd64 (except for a few values > > that also differ between the working i386 and working amd64). So it doesn't > > seem that PCI config access is horribly broken. :( Perhaps someone can spend > > some time comparing what the driver does in the two cases with some printfs > > to see when it starts behaving differently during its attach routine to help > > narrow this down. > > > > Is there any meaning in the differences of pciconf -lv output of i386 > and amd64 (already shown in older postings)? > > ------------------------------------------- > i386: > atapci1@pci0:0:5:0: class=0x010185 card=0x72601462 chip=0x037f10de > rev=0xa2 hdr=0x00 > vendor = 'Nvidia Corp' > device = 'MCP55 SATA/RAID Controller (MCP55S)' > class = mass storage > subclass = ATA > atapci2@pci0:0:5:1: class=0x010185 card=0x72601462 chip=0x037f10de > rev=0xa2 hdr=0x00 > vendor = 'Nvidia Corp' > device = 'MCP55 SATA/RAID Controller (MCP55S)' > class = mass storage > subclass = ATA > ------------------------------------------- > amd64: > atapci1@pci0:0:5:0: class=0x010185 card=0x72601462 chip=0x037f10de > rev=0xa2 hdr=0x00 > class = mass storage > subclass = ATA > atapci2@pci0:0:5:1: class=0x010185 card=0x72601462 chip=0x037f10de > rev=0xa2 hdr=0x00 > class = mass storage > subclass = ATA > ------------------------------------------- > > In the amd64 version there is no vendor and device string. Perhaps a > problem of reading or interpreting? No, the strings are pulled out of /usr/share/misc/pci_vendors based on the value in 'chip='. Since the 'chip=' values are identical it's probably just a matter of having different versions of the pci_vendors file. The only thing MCFG affects is how you read the 'chip=' number which are identical in the two cases. -- John Baldwin