Re: 8.0-beta3 does not detect several ata channels

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_at_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_at_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_at_pci0:0:5:0:     class=0x010185 card=0x72601462 chip=0x037f10de 
>> rev=0xa2 hdr=0x00
>>      class      = mass storage
>>      subclass   = ATA
>> atapci2_at_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.