From owner-freebsd-current@FreeBSD.ORG Thu Sep 3 19:40:12 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 9A8CA1065670; Thu, 3 Sep 2009 19:40:12 +0000 (UTC) (envelope-from rhurlin@gwdg.de) Received: from amailer.gwdg.de (amailer.gwdg.de [134.76.10.18]) by mx1.freebsd.org (Postfix) with ESMTP id 251FF8FC14; Thu, 3 Sep 2009 19:40:12 +0000 (UTC) Received: from p578b68b8.dip0.t-ipconnect.de ([87.139.104.184] helo=krabat.raven.hur) by mailer.gwdg.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1MjIAE-0007n9-3W; Thu, 03 Sep 2009 21:40:10 +0200 Message-ID: <4AA01B94.8000309@gwdg.de> Date: Thu, 03 Sep 2009 21:40:04 +0200 From: Rainer Hurling User-Agent: Thunderbird 2.0.0.23 (X11/20090824) MIME-Version: 1.0 To: John Baldwin References: <4A9BF23F.6070801@netability.ie> <200909011717.57386.jhb@freebsd.org> <4A9FFEF0.1000502@gwdg.de> <200909031401.08825.jhb@freebsd.org> In-Reply-To: <200909031401.08825.jhb@freebsd.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Authenticated: Id:rhurlin X-Spam-Level: - X-Virus-Scanned: (clean) by exiscan+sophie 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 19:40:12 -0000 On 03.09.2009 20:01 (UTC+2), John Baldwin wrote: > 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. > OK, I see. But on my system there are absolutely no differences between /usr/share/misc/pci_vendors of i386 and amd64.