why does UATA/133 == UATA/100 on amd64?

fbsdmail at dnswatch.com fbsdmail at dnswatch.com
Sun Jun 6 00:01:21 UTC 2010


Greetings Alexander, and thank you for your reply.
On Sat, June 5, 2010 3:39 am, Alexander Motin wrote:
> fbsdmail at dnswatch.com wrote:
>> On Fri, June 4, 2010 10:58 pm, Alexander Motin wrote:
>>
>>> Peter Jeremy wrote:
>>>
>>>> On 2010-Jun-04 16:36:08 -0700, fbsdmail at dnswatch.com wrote:
>>>>
>>>>
>>>>> After _finally_ making the correct decisions to install amd64 on
>>>>> an AMD64 system. I was able to make/build/install world && kernel,
>>>>> I see
>>>>> a difference in drive recognition.
>>>> Can you please do a verbose boot and post the resultant dmesg
>>>> somewhere (preferably with your USB DVD drive connected).
>>>>
>>>>
>>>>> kernel: ata3-master: pio=PIO4 wdma=WDMA2 udma=UDMA133 cable=40
>>>>> wire kernel: ad6: 476940MB <Seagate ST3500630AS 3.AAK> at
>>>>> ata3-master SATA300
>>>>>
>>>>>
>>>>> kernel: ata3-master: pio=PIO4 wdma=WDMA2 udma=UDMA133 cable=40
>>>>> wire kernel: ad6: setting UDMA100
>>>>> kernel: ad6: 476940MB <Seagate ST3500630AS 3.AAK> at ata3-master
>>>>> UDMA100
>>>>> SATA 3Gb/s
>>>>>
>>>>>
>>>> The 'UDMA' numbers are meaningless for SATA controllers/drives.
>>>>
>>>>
>>> The 'UDMA' numbers are meaningless for _native_ SATA
>>> controllers/drives.
>>>
>>> They may be not meaningless for legacy SATA devices, using SATA->PATA
>>>  bridge inside. Some bridges do not support UDMA133 on PATA part, so
>>> ata(4) prefers not to use it. But in this case it is indeed
>>> meaningless.
>>
>> If it's not already apparent. The board has an AMD 880G chipset, that
>> provides RAID support on 6 ports @ 6GBs. Now, from a purely logistical
>> standpoint. The numbers _can't_ be meaningless. It's clear that the
>> kernel is making a "judgment call" here: kernel: ad6: setting UDMA100
>
> It is impossible to detect SATA->PATA bridge presence, so kernel has to
> always follow worst scenario. But as I have said, for this particular
> device this value affects nothing.
>
>> The "judgment call" on both GENERIC/i386, and GENERIC/amd64 was never
>> made. The capability of both the port && the drive were accepted. Both
>> cases were booted using "verbose" (5). Please understand, I'm not
>> attempting to be argumentative here. I just observe this to be true. In
>> other words; it must have _some_ meaning - no?
>
> I have feeling that you have updated your sources while building custom
> kernel. I can't explain difference you have shown by other reasons.
Yes, that's a reasonable assessment. My "sig" indicates the current
version (8.1-PRERELEASE). As a rule, I always cvsup to -STABLE
after an install for security reasons, Which is apparently 8.1-PRERELEASE.
While the last server I updated (i386) returns 8.0-STABLE.

So if I understand you correctly. Unless I have reason to believe the
STATA port(s) are meerly a PATA->SATA bridge, I should simply ignore
the kernel output regarding them.

Thank you again Alexander, for your reply.

--Chris
>
> --
> Alexander Motin
>
>


-- 
kern:
FreeBSD 8.1-PRERELEASE amd64
MB:
MSI 880GMA-E45 (socket: AM3)
CPU:
AMD Phenom X3 440 (3 core) @3.5Ghz
RAM:
2 4Gb CORSAIR DDR3 DualChannel PC1600




More information about the freebsd-amd64 mailing list