kernel 2.6.31.1 + Sil 3512 + WDC WD5000AAKS-00V1A0 = no NCQ and UDMA5 instead of UDMA6

kernel 2.6.31.1 + Sil 3512 + WDC WD5000AAKS-00V1A0 = no NCQ and UDMA5 instead of UDMA6

[Stan Hoeppner]

Hi Jeff,

I recently added a Silicon Image 3512 based PCI card to an old Intel
440BX machine along with a single platter 500GB WD SATA2 drive.  I'd
have gone with an ahci sata2 controller but couldn't find one in 33MHz
PCI.  I compiled a new kernel, adding SCSI disk, libata and sata_sil
support using make menuconfig and kernel.org sources installed the
debian way on lenny 5.0.3.  I left the old piix diver in so I could
still boot from the old IDE disk and move the entire Linux system over.
 That all went pretty smoothly, I'm now booting from the new disk, and
the sata subsystem is working pretty well, especially compared to the
old 40GB Maxtor IDE disk (now removed from the system).

However, I noticed that when running hdparm with O_DIRECT the transfer
rate is ~85MB/s, while running buffered timings produces only ~55MB/s.
This is an approximate 38% difference and I thought something might be
amiss.  On a much newer workstation with nvidia IDE chipset and 120GB
Seagate IDE disk, running SLED10, O_DIRECT and buffered show identical
numbers.  I wouldn't think the kernel buffers in 2.6.31.1 would
introduce that much overhead even on a much slower proc/mem subsystem,
so I started digging around.  Additionally, I've read on a number of
Windows websites that this WD drive is averaging 100MB/s in various disk
benchmarks and peaking at over 120MB/s.  I have not tested my 3512/WD500
combo under Windows so I can't confirm those numbers.  However, assuming
they're valid, it seems my system is leaving quite a bit of performance
on the table...

I already knew from dmesg that the drive is being programmed at udma/100
even though the drive is capable of udma/133.  Until yesterday I didn't
realize that ncq was disabled (gasp).  This drive is not in the
blacklist in sata_sil.c or libata-core.c.  I tried enabling ncq with

echo 31 > /sys/block/sda/device/queue_depth

but that gave a permissions error.  I tried chmod +w on the above 'file'
but then received "write error: Input/output error".

So, I find myself stuck, not being a kernel hacker or even knowing the C
language, seeing the code for the first time today, and wanting to
change the behavior of my PCI card and disk.  I'd like to bump up to
udma/133 and enable ncq to at least test those modes, but don't quite
know how to do this.  I found sections in each of the c files above that
are probably relevant but I have no clue what mods I need to make to
effect the changes I want.  I've searched the interwebs twice and found
no solution, arriving at your doorstep.  Please take pity on me, and
provide me some basic english instructions on what to modify and where
in order to enable udma6 and ncq.  Or, better yet, if I could use boot
arguments that would be great.  I know how to do those, if given the
proper arguments.  I compile everything into my kernels, no driver
modules and no initrd.  Oh, and I still use LILO not grub. ;)

I know that making these changes might possibly cause problems and/or
data loss and I accept that responsibility.  I _need_ to know if I'm
leaving a bunch of performance on the table.  After seeing winders
benchmarks, I fear that I am.  I'm having trouble sleeping not knowing
the answer to this question.  I'm obsessed with it now. :(

Thanks in advance Jeff for any help you are able to provide.  I copied
the linux-ide list per your instructions in sata_sil.c.  I am not
subscribed to the list.  If anyone else has the solution or tips to
point me in the right direction, thank you all in advance as well.
Sorry for my ramblings and if I posted too much information or back
story.  I've been in this computer game since '86 and it seems more
information up front is usually better than not enough.

--
Stan

00:11.0 RAID bus controller: Silicon Image, Inc. SiI 3512
[SATALink/SATARaid] Serial ATA Controller (rev 01)
00:00.0 Host bridge: Intel Corporation 440BX/ZX/DX - 82443BX/ZX/DX Host
bridge (rev 03)
00:07.1 IDE interface: Intel Corporation 82371AB/EB/MB PIIX4 IDE (rev 01)

SCSI subsystem initialized
libata version 3.00 loaded
sata_sil 0000:00:11.0: version 2.4
sata_sil 0000:00:11.0: PCI->APIC IRQ transform: INT A -> IRQ 19
scsi0 : sata_sil
scsi1 : sata_sil
ata1: SATA max UDMA/100 mmio m512@0xe9610000 tf 0xe9610080 irq 19
ata2: SATA max UDMA/100 mmio m512@0xe9610000 tf 0xe96100c0 irq 19
ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 310)
ata1.00: ATA-8: WDC WD5000AAKS-00V1A0, 05.01D05, max UDMA/133
ata1.00: 976773168 sectors, multi 16: LBA48 NCQ (depth 0/32)
ata1.00: configured for UDMA/100
scsi 0:0:0:0: Direct-Access     ATA      WDC WD5000AAKS-0 05.0 PQ: 0 ANSI: 5
sd 0:0:0:0: [sda] 976773168 512-byte logical blocks: (500 GB/465 GiB)
sd 0:0:0:0: [sda] Write Protect is off
sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00
sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't
support DPO or FUA
 sda: sda1 sda2 sda3 < sda5 sda6 >
sd 0:0:0:0: [sda] Attached SCSI disk
ata2: SATA link down (SStatus 0 SControl 310)

Re: kernel 2.6.31.1 + Sil 3512 + WDC WD5000AAKS-00V1A0 = no NCQ and UDMA5 instead of UDMA6

[Jeff Garzik]

On 12/17/2009 09:16 AM, Stan Hoeppner wrote:
> Hi Jeff,
>
> I recently added a Silicon Image 3512 based PCI card to an old Intel
> 440BX machine along with a single platter 500GB WD SATA2 drive.  I'd
> have gone with an ahci sata2 controller but couldn't find one in 33MHz
> PCI.  I compiled a new kernel, adding SCSI disk, libata and sata_sil
> support using make menuconfig and kernel.org sources installed the
> debian way on lenny 5.0.3.  I left the old piix diver in so I could
> still boot from the old IDE disk and move the entire Linux system over.
>   That all went pretty smoothly, I'm now booting from the new disk, and
> the sata subsystem is working pretty well, especially compared to the
> old 40GB Maxtor IDE disk (now removed from the system).

sata_sil hardware does not support NCQ.

	Jeff

Re: kernel 2.6.31.1 + Sil 3512 + WDC WD5000AAKS-00V1A0 = no NCQ and UDMA5 instead of UDMA6

[Stan Hoeppner]

Jeff Garzik put forth on 12/17/2009 12:01 PM:
> On 12/17/2009 09:16 AM, Stan Hoeppner wrote:
>> Hi Jeff,
>>
>> I recently added a Silicon Image 3512 based PCI card to an old Intel
>> 440BX machine along with a single platter 500GB WD SATA2 drive.  I'd
>> have gone with an ahci sata2 controller but couldn't find one in 33MHz
>> PCI.  I compiled a new kernel, adding SCSI disk, libata and sata_sil
>> support using make menuconfig and kernel.org sources installed the
>> debian way on lenny 5.0.3.  I left the old piix diver in so I could
>> still boot from the old IDE disk and move the entire Linux system over.
>>   That all went pretty smoothly, I'm now booting from the new disk, and
>> the sata subsystem is working pretty well, especially compared to the
>> old 40GB Maxtor IDE disk (now removed from the system).
> 
> sata_sil hardware does not support NCQ.
> 
>     Jeff

Dangit, I thought the 3512 was one of the SiI chips that did support it.
  My mistake.  Is there anything else I can tweak to get more of this
drive's performance or am I stuck with what I have?  My read of your
default UDMA/100 comments is that it's a safety net type setting for the
3112.  Would bumping this to UDMA/133 give me any improvement over the
PCI bus?  Is there anything else I could tweak?

Thanks Jeff.

--
Stan

Re: kernel 2.6.31.1 + Sil 3512 + WDC WD5000AAKS-00V1A0 = no NCQ and UDMA5 instead of UDMA6

[Jeff Garzik]

On 12/17/2009 09:22 PM, Stan Hoeppner wrote:
> Jeff Garzik put forth on 12/17/2009 12:01 PM:
>> On 12/17/2009 09:16 AM, Stan Hoeppner wrote:
>>> Hi Jeff,
>>>
>>> I recently added a Silicon Image 3512 based PCI card to an old Intel
>>> 440BX machine along with a single platter 500GB WD SATA2 drive.  I'd
>>> have gone with an ahci sata2 controller but couldn't find one in 33MHz
>>> PCI.  I compiled a new kernel, adding SCSI disk, libata and sata_sil
>>> support using make menuconfig and kernel.org sources installed the
>>> debian way on lenny 5.0.3.  I left the old piix diver in so I could
>>> still boot from the old IDE disk and move the entire Linux system over.
>>>    That all went pretty smoothly, I'm now booting from the new disk, and
>>> the sata subsystem is working pretty well, especially compared to the
>>> old 40GB Maxtor IDE disk (now removed from the system).
>>
>> sata_sil hardware does not support NCQ.
>>
>>      Jeff
>
> Dangit, I thought the 3512 was one of the SiI chips that did support it.
>    My mistake.  Is there anything else I can tweak to get more of this
> drive's performance or am I stuck with what I have?  My read of your
> default UDMA/100 comments is that it's a safety net type setting for the
> 3112.  Would bumping this to UDMA/133 give me any improvement over the
> PCI bus?  Is there anything else I could tweak?

Nope.  You are pretty much maxing out the drive, of whatever drive you 
plug in.  The sata bus -- at its hardware spec'd maximum -- is far 
faster than just about any drive, and the PCI bus is far faster than the 
sata bus.

You could probably max out the SATA bus with a RAM-based SATA device; 
that's it.

	Jeff

Re: kernel 2.6.31.1 + Sil 3512 + WDC WD5000AAKS-00V1A0 = no NCQ and UDMA5 instead of UDMA6

[Stan Hoeppner]

Jeff Garzik put forth on 12/17/2009 9:10 PM:

> Nope.  You are pretty much maxing out the drive, of whatever drive you
> plug in.  The sata bus -- at its hardware spec'd maximum -- is far
> faster than just about any drive, and the PCI bus is far faster than the
> sata bus.

I'm on the old 32bit/33MHz PCI bus of 133MB/s.  SATA1 at 150MB/s is
slightly faster, no?  No argument here that both are far faster than
almost all drives on the market.  I was just wondering if bumping up
from the default UDMA/100 to UDMA/133 would allow quicker PCI bus
bursting and thus a slight improvement in overall performance.

> You could probably max out the SATA bus with a RAM-based SATA device;
> that's it.

Yeah, I've seen some results published of quality SSDs and they just
absolutely scream in latency, IOPs, and throughput.  That's not in my
future, it's complete overkill for my applications, performance and
dollar wise.  I just want to optimize the performance of what I already
have.

I think I only gave $15 for this Koutech Sil3512 PCI (32/33) controller
at Newegg.  You being you with the knowledge you have, would buying one
of the cards whose chipset supports NCQ, such as the sata_sil24 cards,
be anything close to worth the additional investment in dollars and time
spent swapping hardware and drivers?  Is NCQ the performance panacea
that some purport it to be?  How much difference does it really make?

Thanks again for your time and advice Jeff.

--
Stan

Re: kernel 2.6.31.1 + Sil 3512 + WDC WD5000AAKS-00V1A0 = no NCQ and UDMA5 instead of UDMA6

[Robert Hancock]

On 12/17/2009 09:49 PM, Stan Hoeppner wrote:
> Jeff Garzik put forth on 12/17/2009 9:10 PM:
>
>> Nope.  You are pretty much maxing out the drive, of whatever drive you
>> plug in.  The sata bus -- at its hardware spec'd maximum -- is far
>> faster than just about any drive, and the PCI bus is far faster than the
>> sata bus.
>
> I'm on the old 32bit/33MHz PCI bus of 133MB/s.  SATA1 at 150MB/s is
> slightly faster, no?  No argument here that both are far faster than
> almost all drives on the market.  I was just wondering if bumping up
> from the default UDMA/100 to UDMA/133 would allow quicker PCI bus
> bursting and thus a slight improvement in overall performance.

The UDMA speed doesn't make any difference at all with SATA, it's just 
an arbitrary number in almost all cases. Only the link speed really 
matters (which with these controllers will always be 1.5 Gbps).

>
>> You could probably max out the SATA bus with a RAM-based SATA device;
>> that's it.
>
> Yeah, I've seen some results published of quality SSDs and they just
> absolutely scream in latency, IOPs, and throughput.  That's not in my
> future, it's complete overkill for my applications, performance and
> dollar wise.  I just want to optimize the performance of what I already
> have.
>
> I think I only gave $15 for this Koutech Sil3512 PCI (32/33) controller
> at Newegg.  You being you with the knowledge you have, would buying one
> of the cards whose chipset supports NCQ, such as the sata_sil24 cards,
> be anything close to worth the additional investment in dollars and time
> spent swapping hardware and drivers?  Is NCQ the performance panacea
> that some purport it to be?  How much difference does it really make?

It's really hard to say, it depends on the drive and the workload, in 
most cases..

Re: kernel 2.6.31.1 + Sil 3512 + WDC WD5000AAKS-00V1A0 = no NCQ and UDMA5 instead of UDMA6

[Stan Hoeppner]

Robert Hancock put forth on 12/17/2009 10:05 PM:
> On 12/17/2009 09:49 PM, Stan Hoeppner wrote:
>> Jeff Garzik put forth on 12/17/2009 9:10 PM:
>>
>>> Nope.  You are pretty much maxing out the drive, of whatever drive you
>>> plug in.  The sata bus -- at its hardware spec'd maximum -- is far
>>> faster than just about any drive, and the PCI bus is far faster than the
>>> sata bus.
>>
>> I'm on the old 32bit/33MHz PCI bus of 133MB/s.  SATA1 at 150MB/s is
>> slightly faster, no?  No argument here that both are far faster than
>> almost all drives on the market.  I was just wondering if bumping up
>> from the default UDMA/100 to UDMA/133 would allow quicker PCI bus
>> bursting and thus a slight improvement in overall performance.
> 
> The UDMA speed doesn't make any difference at all with SATA, it's just
> an arbitrary number in almost all cases. Only the link speed really
> matters (which with these controllers will always be 1.5 Gbps).

Hi Robert.  Thanks for your informed reply.

So, how does this "phantom" UDMA setting affect either libata or
sata_sil?  If it effects nothing, why is it hanging around?  Is this a
backward compatibility thing for the kernel's benefit?  I'm not a kernel
hacker or programmer (yet), so please forgive my ignorant questions.

>> I think I only gave $15 for this Koutech Sil3512 PCI (32/33) controller
>> at Newegg.  You being you with the knowledge you have, would buying one
>> of the cards whose chipset supports NCQ, such as the sata_sil24 cards,
>> be anything close to worth the additional investment in dollars and time
>> spent swapping hardware and drivers?  Is NCQ the performance panacea
>> that some purport it to be?  How much difference does it really make?
> 
> It's really hard to say, it depends on the drive and the workload, in
> most cases..

On this particular machine, the greatest disk loading will be running
hdparm and other benchmarks.  Its real world workloads are modest, disk
and otherwise (though that may change).  If NCQ's greatest benefit comes
into play with multithreaded or multiuser workloads, then it would
probably not benefit this machine's real world performance much.  Unless
NCQ pumps up benchy numbers, which gives the machine owner a
psychological boost, if nothing else. ;)  (feels guilt)

Thanks for continuing to educate me folks.  It's so difficult to find
"under the hood" linux sata information of this type via Google.  All I
find are benchy results and accounts of personal experience, but not any
"this is why this works this way" info.

Please continue my education a bit more.  I'm trying not to be a pest,
but this stuff is fascinating to me, and more knowledge is always a good
thing, no?

--
Stan

Re: kernel 2.6.31.1 + Sil 3512 + WDC WD5000AAKS-00V1A0 = no NCQ and UDMA5 instead of UDMA6

[Robert Hancock]

On Thu, Dec 17, 2009 at 10:34 PM, Stan Hoeppner <stan@hardwarefreak.com> wrote:
> Robert Hancock put forth on 12/17/2009 10:05 PM:
>> On 12/17/2009 09:49 PM, Stan Hoeppner wrote:
>>> Jeff Garzik put forth on 12/17/2009 9:10 PM:
>>>
>>>> Nope.  You are pretty much maxing out the drive, of whatever drive you
>>>> plug in.  The sata bus -- at its hardware spec'd maximum -- is far
>>>> faster than just about any drive, and the PCI bus is far faster than the
>>>> sata bus.
>>>
>>> I'm on the old 32bit/33MHz PCI bus of 133MB/s.  SATA1 at 150MB/s is
>>> slightly faster, no?  No argument here that both are far faster than
>>> almost all drives on the market.  I was just wondering if bumping up
>>> from the default UDMA/100 to UDMA/133 would allow quicker PCI bus
>>> bursting and thus a slight improvement in overall performance.
>>
>> The UDMA speed doesn't make any difference at all with SATA, it's just
>> an arbitrary number in almost all cases. Only the link speed really
>> matters (which with these controllers will always be 1.5 Gbps).
>
> Hi Robert.  Thanks for your informed reply.
>
> So, how does this "phantom" UDMA setting affect either libata or
> sata_sil?  If it effects nothing, why is it hanging around?  Is this a
> backward compatibility thing for the kernel's benefit?  I'm not a kernel
> hacker or programmer (yet), so please forgive my ignorant questions.

It doesn't affect either the driver or the controller. Only the drive
may possibly care - that would be if there's a SATA-to-PATA bridge
involved (as some early SATA drives had internally, for example) and
there's an actual PATA bus that needs to be programmed properly for
speed. Other than that, it's basically vestigial.

>
>>> I think I only gave $15 for this Koutech Sil3512 PCI (32/33) controller
>>> at Newegg.  You being you with the knowledge you have, would buying one
>>> of the cards whose chipset supports NCQ, such as the sata_sil24 cards,
>>> be anything close to worth the additional investment in dollars and time
>>> spent swapping hardware and drivers?  Is NCQ the performance panacea
>>> that some purport it to be?  How much difference does it really make?
>>
>> It's really hard to say, it depends on the drive and the workload, in
>> most cases..
>
> On this particular machine, the greatest disk loading will be running
> hdparm and other benchmarks.  Its real world workloads are modest, disk
> and otherwise (though that may change).  If NCQ's greatest benefit comes
> into play with multithreaded or multiuser workloads, then it would
> probably not benefit this machine's real world performance much.  Unless
> NCQ pumps up benchy numbers, which gives the machine owner a
> psychological boost, if nothing else. ;)  (feels guilt)

In my experience, you get a little bit more performance with hdparm,
etc. with NCQ enabled. But that depends on the drive implementation a
lot - if it's poorly optimized for NCQ you can see a slowdown.

It's true the biggest benefits tend to be with multithreaded
workloads, but even single-threaded workloads can get broken down by
the kernel into multiple parallel requests.

>
> Thanks for continuing to educate me folks.  It's so difficult to find
> "under the hood" linux sata information of this type via Google.  All I
> find are benchy results and accounts of personal experience, but not any
> "this is why this works this way" info.
>
> Please continue my education a bit more.  I'm trying not to be a pest,
> but this stuff is fascinating to me, and more knowledge is always a good
> thing, no?
>
> --
> Stan
>

Re: kernel 2.6.31.1 + Sil 3512 + WDC WD5000AAKS-00V1A0 = no NCQ and UDMA5 instead of UDMA6

[Stan Hoeppner]

Robert Hancock put forth on 12/17/2009 11:00 PM:
> On Thu, Dec 17, 2009 at 10:34 PM, Stan Hoeppner <stan@hardwarefreak.com> wrote:

>> So, how does this "phantom" UDMA setting affect either libata or
>> sata_sil?  If it effects nothing, why is it hanging around?  Is this a
>> backward compatibility thing for the kernel's benefit?  I'm not a kernel
>> hacker or programmer (yet), so please forgive my ignorant questions.
> 
> It doesn't affect either the driver or the controller. Only the drive
> may possibly care - that would be if there's a SATA-to-PATA bridge
> involved (as some early SATA drives had internally, for example) and
> there's an actual PATA bus that needs to be programmed properly for
> speed. Other than that, it's basically vestigial.

So in sata_sil.c version 2.4, the following are only present in the case
one of these early drives with an onboard PATA-SATA bridge is connected?

        SIL_QUIRK_UDMA5MAX      = (1 << 1),

} sil_blacklist [] = {

        { "Maxtor 4D060H3",     SIL_QUIRK_UDMA5MAX },


static const struct ata_port_info sil_port_info[] = {
        /* sil_3512 */
        {
                .flags          = SIL_DFL_PORT_FLAGS |
SIL_FLAG_RERR_ON_DMA_ACT,
                .pio_mask       = ATA_PIO4,
                .mwdma_mask     = ATA_MWDMA2,
                .udma_mask      = ATA_UDMA5,
                .port_ops       = &sil_ops,
        },

 *      20040111 - Seagate drives affected by the Mod15Write bug are
blacklisted
 *      The Maxtor quirk is in the blacklist, but I'm keeping the original
 *      pessimistic fix for the following reasons...
 *      - There seems to be less info on it, only one device gleaned off the
 *      Windows driver, maybe only one is affected.  More info would be
greatly
 *      appreciated.
 *      - But then again UDMA5 is hardly anything to complain about

        /* limit to udma5 */
        if (quirks & SIL_QUIRK_UDMA5MAX) {
                if (print_info)
                        ata_dev_printk(dev, KERN_INFO, "applying Maxtor "
                                       "errata fix %s\n", model_num);
                dev->udma_mask &= ATA_UDMA5;
                return;
        }


Might it be beneficial, if merely to keep people like myself from asking
questions, to set the default for the 3512 to UDMA6 max instead of UDMA5
max, and only set UDMA5 in the case of a blacklisted Maxtor?  I'm sure
I'm not the first person to see in dmesg that my drive is showing
UDMA/133 capability but sata_sil is "limiting" the drive to UDMA/100.
If this setting is merely window dressing for all but the oldest borked
SATA1 drives with bridge chips, why not fix up this code so it at least
"appears" the controller is matching the mode the new pure SATA drive is
reporting?

> In my experience, you get a little bit more performance with hdparm,
> etc. with NCQ enabled. But that depends on the drive implementation a
> lot - if it's poorly optimized for NCQ you can see a slowdown.

So, not knowing whether my WD Blue has a good NCQ implementation or not,
it doesn't seem prudent to spend $40 on a new NCQ capable controller
card to get a few percent more performance from a $55 drive.  Agreed?

> It's true the biggest benefits tend to be with multithreaded
> workloads, but even single-threaded workloads can get broken down by
> the kernel into multiple parallel requests.

Noted.  Speaking of the kernel, why do I see 85MB/s using O_DIRECT with
hdparm, yet I only get 55MB/s with buffered reads?  On my workstation,
with a 4 year old 120GB Seagate IDE disk I get 32MB/s with both hdparm
test modes.  O_DIRECT gives no advantage on my workstation, but a 38%
advantage on the server.  The server with the SATA drive, the machine
we've been discussing the past few days, is a dual 550MHz CPU with PC100
memory bus, Intel BX chipset (circa 1998), and sil3512 PCI SATA card.
The workstation is an Athlon XP (32 bit) at 2GHz with nVidia nForce2
chipset, dual channel DDR2 400.  The server is running Debian 5.0.3 with
my custom 2.6.31.1 kernel built from kernel.org sources with make
menuconfig.  The workstation is running a stock SuSE Linux Enterprise
Desktop 10 kernel, though I can't recall what 2.6.x rev it is.  (I dual
boot winders and SLED and I'm in winders now)

Is the CPU/mem subsystem in the server the cause of the 38% drop in
buffered read performance vs O_DIRECT, or does my custom kernel need
some work somewhere?  Can someone point me to some docs that explain why
the buffer cache on this system is putting such a clamp on buffered
sequential disk reads in hdparm compared to raw performance?

Again, thanks for your help and patience.

--
Stan

Re: kernel 2.6.31.1 + Sil 3512 + WDC WD5000AAKS-00V1A0 = no NCQ and UDMA5 instead of UDMA6

[Robert Hancock]

On 12/18/2009 01:51 PM, Stan Hoeppner wrote:
> Robert Hancock put forth on 12/17/2009 11:00 PM:
>> On Thu, Dec 17, 2009 at 10:34 PM, Stan Hoeppner<stan@hardwarefreak.com>  wrote:
>
>>> So, how does this "phantom" UDMA setting affect either libata or
>>> sata_sil?  If it effects nothing, why is it hanging around?  Is this a
>>> backward compatibility thing for the kernel's benefit?  I'm not a kernel
>>> hacker or programmer (yet), so please forgive my ignorant questions.
>>
>> It doesn't affect either the driver or the controller. Only the drive
>> may possibly care - that would be if there's a SATA-to-PATA bridge
>> involved (as some early SATA drives had internally, for example) and
>> there's an actual PATA bus that needs to be programmed properly for
>> speed. Other than that, it's basically vestigial.
>
> So in sata_sil.c version 2.4, the following are only present in the case
> one of these early drives with an onboard PATA-SATA bridge is connected?
>
>          SIL_QUIRK_UDMA5MAX      = (1<<  1),
>
> } sil_blacklist [] = {
>
>          { "Maxtor 4D060H3",     SIL_QUIRK_UDMA5MAX },
>
>
> static const struct ata_port_info sil_port_info[] = {
>          /* sil_3512 */
>          {
>                  .flags          = SIL_DFL_PORT_FLAGS |
> SIL_FLAG_RERR_ON_DMA_ACT,
>                  .pio_mask       = ATA_PIO4,
>                  .mwdma_mask     = ATA_MWDMA2,
>                  .udma_mask      = ATA_UDMA5,
>                  .port_ops       =&sil_ops,
>          },
>
>   *      20040111 - Seagate drives affected by the Mod15Write bug are
> blacklisted
>   *      The Maxtor quirk is in the blacklist, but I'm keeping the original
>   *      pessimistic fix for the following reasons...
>   *      - There seems to be less info on it, only one device gleaned off the
>   *      Windows driver, maybe only one is affected.  More info would be
> greatly
>   *      appreciated.
>   *      - But then again UDMA5 is hardly anything to complain about
>
>          /* limit to udma5 */
>          if (quirks&  SIL_QUIRK_UDMA5MAX) {
>                  if (print_info)
>                          ata_dev_printk(dev, KERN_INFO, "applying Maxtor "
>                                         "errata fix %s\n", model_num);
>                  dev->udma_mask&= ATA_UDMA5;
>                  return;
>          }
>
>
> Might it be beneficial, if merely to keep people like myself from asking
> questions, to set the default for the 3512 to UDMA6 max instead of UDMA5
> max, and only set UDMA5 in the case of a blacklisted Maxtor?  I'm sure
> I'm not the first person to see in dmesg that my drive is showing
> UDMA/133 capability but sata_sil is "limiting" the drive to UDMA/100.
> If this setting is merely window dressing for all but the oldest borked
> SATA1 drives with bridge chips, why not fix up this code so it at least
> "appears" the controller is matching the mode the new pure SATA drive is
> reporting?

For whatever reason the sata_sil driver only indicates it supports 
UDMA5, not UDMA6. So it appears that Maxtor quirk doesn't really do 
anything, all drivers will only get programmed as UDMA5 max anyway.

>
>> In my experience, you get a little bit more performance with hdparm,
>> etc. with NCQ enabled. But that depends on the drive implementation a
>> lot - if it's poorly optimized for NCQ you can see a slowdown.
>
> So, not knowing whether my WD Blue has a good NCQ implementation or not,
> it doesn't seem prudent to spend $40 on a new NCQ capable controller
> card to get a few percent more performance from a $55 drive.  Agreed?

Most likely not for just NCQ. Though, the other thing a newer controller 
would have would be 3Gbps SATA support, you might see a little boost 
from that in some cases.

>
>> It's true the biggest benefits tend to be with multithreaded
>> workloads, but even single-threaded workloads can get broken down by
>> the kernel into multiple parallel requests.
>
> Noted.  Speaking of the kernel, why do I see 85MB/s using O_DIRECT with
> hdparm, yet I only get 55MB/s with buffered reads?  On my workstation,
> with a 4 year old 120GB Seagate IDE disk I get 32MB/s with both hdparm
> test modes.  O_DIRECT gives no advantage on my workstation, but a 38%
> advantage on the server.  The server with the SATA drive, the machine
> we've been discussing the past few days, is a dual 550MHz CPU with PC100
> memory bus, Intel BX chipset (circa 1998), and sil3512 PCI SATA card.
> The workstation is an Athlon XP (32 bit) at 2GHz with nVidia nForce2
> chipset, dual channel DDR2 400.  The server is running Debian 5.0.3 with
> my custom 2.6.31.1 kernel built from kernel.org sources with make
> menuconfig.  The workstation is running a stock SuSE Linux Enterprise
> Desktop 10 kernel, though I can't recall what 2.6.x rev it is.  (I dual
> boot winders and SLED and I'm in winders now)
>
> Is the CPU/mem subsystem in the server the cause of the 38% drop in
> buffered read performance vs O_DIRECT, or does my custom kernel need
> some work somewhere?  Can someone point me to some docs that explain why
> the buffer cache on this system is putting such a clamp on buffered
> sequential disk reads in hdparm compared to raw performance?

Not too sure about that one. It could be that the I/O pattern with 
buffered IO is somehow worse than with O_DIRECT, or that the CPU load is 
killing you somehow when using buffered IO.

Re: kernel 2.6.31.1 + Sil 3512 + WDC WD5000AAKS-00V1A0 = no NCQ and UDMA5 instead of UDMA6

[Stan Hoeppner]

Robert Hancock put forth on 12/19/2009 12:16 PM:
> On 12/18/2009 01:51 PM, Stan Hoeppner wrote:
>> Robert Hancock put forth on 12/17/2009 11:00 PM:
>>> On Thu, Dec 17, 2009 at 10:34 PM, Stan
>>> Hoeppner<stan@hardwarefreak.com>  wrote:
>>
>>>> So, how does this "phantom" UDMA setting affect either libata or
>>>> sata_sil?  If it effects nothing, why is it hanging around?  Is this a
>>>> backward compatibility thing for the kernel's benefit?  I'm not a
>>>> kernel
>>>> hacker or programmer (yet), so please forgive my ignorant questions.
>>>
>>> It doesn't affect either the driver or the controller. Only the drive
>>> may possibly care - that would be if there's a SATA-to-PATA bridge
>>> involved (as some early SATA drives had internally, for example) and
>>> there's an actual PATA bus that needs to be programmed properly for
>>> speed. Other than that, it's basically vestigial.
>>
>> So in sata_sil.c version 2.4, the following are only present in the case
>> one of these early drives with an onboard PATA-SATA bridge is connected?
>>
>>          SIL_QUIRK_UDMA5MAX      = (1<<  1),
>>
>> } sil_blacklist [] = {
>>
>>          { "Maxtor 4D060H3",     SIL_QUIRK_UDMA5MAX },
>>
>>
>> static const struct ata_port_info sil_port_info[] = {
>>          /* sil_3512 */
>>          {
>>                  .flags          = SIL_DFL_PORT_FLAGS |
>> SIL_FLAG_RERR_ON_DMA_ACT,
>>                  .pio_mask       = ATA_PIO4,
>>                  .mwdma_mask     = ATA_MWDMA2,
>>                  .udma_mask      = ATA_UDMA5,
>>                  .port_ops       =&sil_ops,
>>          },
>>
>>   *      20040111 - Seagate drives affected by the Mod15Write bug are
>> blacklisted
>>   *      The Maxtor quirk is in the blacklist, but I'm keeping the
>> original
>>   *      pessimistic fix for the following reasons...
>>   *      - There seems to be less info on it, only one device gleaned
>> off the
>>   *      Windows driver, maybe only one is affected.  More info would be
>> greatly
>>   *      appreciated.
>>   *      - But then again UDMA5 is hardly anything to complain about
>>
>>          /* limit to udma5 */
>>          if (quirks&  SIL_QUIRK_UDMA5MAX) {
>>                  if (print_info)
>>                          ata_dev_printk(dev, KERN_INFO, "applying
>> Maxtor "
>>                                         "errata fix %s\n", model_num);
>>                  dev->udma_mask&= ATA_UDMA5;
>>                  return;
>>          }
>>
>>
>> Might it be beneficial, if merely to keep people like myself from asking
>> questions, to set the default for the 3512 to UDMA6 max instead of UDMA5
>> max, and only set UDMA5 in the case of a blacklisted Maxtor?  I'm sure
>> I'm not the first person to see in dmesg that my drive is showing
>> UDMA/133 capability but sata_sil is "limiting" the drive to UDMA/100.
>> If this setting is merely window dressing for all but the oldest borked
>> SATA1 drives with bridge chips, why not fix up this code so it at least
>> "appears" the controller is matching the mode the new pure SATA drive is
>> reporting?
> 
> For whatever reason the sata_sil driver only indicates it supports
> UDMA5, not UDMA6. So it appears that Maxtor quirk doesn't really do
> anything, all drivers will only get programmed as UDMA5 max anyway.

According to the source comments Jeff seems to hint that it's a conscious
decision he made for sata_sil chips, although he doesn't elaborate as to all the
"why's" in the comments.  Jeff, would you shed more light on this please?  It
probably makes no difference in my case, I'm just curious.

> Most likely not for just NCQ. Though, the other thing a newer controller
> would have would be 3Gbps SATA support, you might see a little boost
> from that in some cases.

My controller card is brand new, although, obviously based on a rather old chip
design (what, 4-5 years on the 3512?), thus the $15 price tag.  So, I understand
your point, and agree that a 3Gbs controller might boost performance a little
bit in some cases, basically bursting to/from the drive cache.  But most of the
time, that 300MB/s bus would be limited one one side by a 133MB/s PCI bus and on
the other side by a drive that can only push a sequential read max of 126MB/s
according to the manufacturer, and that's a raw byte figure for the electronics
on this drive series, not particularly _this_ drive.  A couple of reasons I
didn't go with a sata2 controller are cost, though not extravagantly high, and
plugging in a dual channel card with 600MB/s potential into a 133MB/s PCI bus.
Oh, and 3rd I was under the mistaken impression that the card I was purchasing
did support NCQ.  Turns out that was not the case...

>>> It's true the biggest benefits tend to be with multithreaded
>>> workloads, but even single-threaded workloads can get broken down by
>>> the kernel into multiple parallel requests.
>>
>> Noted.  Speaking of the kernel, why do I see 85MB/s using O_DIRECT with
>> hdparm, yet I only get 55MB/s with buffered reads?  On my workstation,
>> with a 4 year old 120GB Seagate IDE disk I get 32MB/s with both hdparm
>> test modes.  O_DIRECT gives no advantage on my workstation, but a 38%
>> advantage on the server.  The server with the SATA drive, the machine
>> we've been discussing the past few days, is a dual 550MHz CPU with PC100
>> memory bus, Intel BX chipset (circa 1998), and sil3512 PCI SATA card.
>> The workstation is an Athlon XP (32 bit) at 2GHz with nVidia nForce2
>> chipset, dual channel DDR2 400.  The server is running Debian 5.0.3 with
>> my custom 2.6.31.1 kernel built from kernel.org sources with make
>> menuconfig.  The workstation is running a stock SuSE Linux Enterprise
>> Desktop 10 kernel, though I can't recall what 2.6.x rev it is.  (I dual
>> boot winders and SLED and I'm in winders now)
>>
>> Is the CPU/mem subsystem in the server the cause of the 38% drop in
>> buffered read performance vs O_DIRECT, or does my custom kernel need
>> some work somewhere?  Can someone point me to some docs that explain why
>> the buffer cache on this system is putting such a clamp on buffered
>> sequential disk reads in hdparm compared to raw performance?
> 
> Not too sure about that one. It could be that the I/O pattern with
> buffered IO is somehow worse than with O_DIRECT, or that the CPU load is
> killing you somehow when using buffered IO.

I performed a little rudimentary testing and grabbed some data with batch top.
I'm hoping you experts can actually discern something from it better than I can.

/dev/sda:
 Timing buffered disk reads:  166 MB in  3.01 seconds =  55.15 MB/sec

Cpu0  :  0.0%us, 31.1%sy,  0.0%ni, 47.6%id, 18.4%wa,  1.0%hi,  1.9%si,  0.0%st
Cpu0  :  1.0%us, 29.4%sy,  0.0%ni, 52.0%id, 15.7%wa,  0.0%hi,  2.0%si,  0.0%st
Cpu0  :  1.0%us, 20.6%sy,  0.0%ni, 60.8%id, 14.7%wa,  1.0%hi,  2.0%si,  0.0%st

Cpu1  :  2.9%us, 25.0%sy,  0.0%ni, 43.3%id, 23.1%wa,  1.0%hi,  4.8%si,  0.0%st
Cpu1  :  2.0%us, 29.4%sy,  0.0%ni, 43.1%id, 22.5%wa,  0.0%hi,  2.9%si,  0.0%st
Cpu1  :  1.0%us, 36.3%sy,  0.0%ni, 40.2%id, 19.6%wa,  0.0%hi,  2.9%si,  0.0%st

Running dd gives slightly lower throughput than hdparm -t, but since it runs a
longer duration I can get a better quality grab of stats from top.

greer:/home/stan# dd if=/dev/sda of=/dev/null
1226017+0 records in
1226016+0 records out
627720192 bytes (628 MB) copied, 13.7097 s, 45.8 MB/s

Cpu0  :  8.8%us, 21.6%sy,  0.0%ni, 48.0%id, 17.6%wa,  0.0%hi,  3.9%si,  0.0%st
Cpu0  :  8.8%us, 21.6%sy,  0.0%ni, 49.0%id, 18.6%wa,  0.0%hi,  2.0%si,  0.0%st
Cpu0  : 11.9%us, 21.8%sy,  0.0%ni, 43.6%id, 22.8%wa,  0.0%hi,  0.0%si,  0.0%st
Cpu0  :  5.0%us, 20.8%sy,  0.0%ni, 62.4%id, 10.9%wa,  0.0%hi,  1.0%si,  0.0%st
Cpu0  :  5.9%us, 24.5%sy,  0.0%ni, 49.0%id, 19.6%wa,  0.0%hi,  1.0%si,  0.0%st
Cpu0  :  7.8%us, 21.6%sy,  0.0%ni, 52.9%id, 14.7%wa,  0.0%hi,  2.9%si,  0.0%st
Cpu0  :  6.9%us, 23.5%sy,  0.0%ni, 50.0%id, 18.6%wa,  0.0%hi,  1.0%si,  0.0%st
Cpu0  :  8.9%us, 19.8%sy,  0.0%ni, 52.5%id, 16.8%wa,  0.0%hi,  2.0%si,  0.0%st

Cpu1  :  8.8%us, 29.4%sy,  0.0%ni, 43.1%id, 18.6%wa,  0.0%hi,  0.0%si,  0.0%st
Cpu1  :  9.8%us, 27.5%sy,  0.0%ni, 47.1%id, 15.7%wa,  0.0%hi,  0.0%si,  0.0%st
Cpu1  :  8.8%us, 25.5%sy,  0.0%ni, 52.0%id, 13.7%wa,  0.0%hi,  0.0%si,  0.0%st
Cpu1  : 11.9%us, 37.6%sy,  0.0%ni, 32.7%id, 17.8%wa,  0.0%hi,  0.0%si,  0.0%st
Cpu1  :  5.0%us, 31.7%sy,  0.0%ni, 45.5%id, 17.8%wa,  0.0%hi,  0.0%si,  0.0%st
Cpu1  :  9.7%us, 27.2%sy,  0.0%ni, 41.7%id, 21.4%wa,  0.0%hi,  0.0%si,  0.0%st
Cpu1  :  9.8%us, 27.5%sy,  0.0%ni, 46.1%id, 16.7%wa,  0.0%hi,  0.0%si,  0.0%st
Cpu1  :  8.9%us, 30.7%sy,  0.0%ni, 42.6%id, 17.8%wa,  0.0%hi,  0.0%si,  0.0%st

For comparison here's the hdparm O_DIRECT run.  User space code time is almost
nil, as is kernel time.  I/O wait times are much higher.

/dev/sda:
 Timing O_DIRECT disk reads:  252 MB in  3.02 seconds =  83.46 MB/sec

Cpu0  :  2.0%us,  1.0%sy,  0.0%ni, 84.3%id, 12.7%wa,  0.0%hi,  0.0%si,  0.0%st
Cpu0  :  2.0%us,  2.9%sy,  0.0%ni, 43.1%id, 50.0%wa,  0.0%hi,  2.0%si,  0.0%st
Cpu0  :  2.9%us,  2.9%sy,  0.0%ni,  0.0%id, 91.2%wa,  1.0%hi,  2.0%si,  0.0%st
Cpu0  :  2.0%us,  2.9%sy,  0.0%ni, 58.8%id, 36.3%wa,  0.0%hi,  0.0%si,  0.0%st

Cpu1  :  0.0%us,  0.0%sy,  0.0%ni, 91.1%id,  8.9%wa,  0.0%hi,  0.0%si,  0.0%st
Cpu1  :  0.0%us,  1.0%sy,  0.0%ni, 54.9%id, 43.1%wa,  0.0%hi,  1.0%si,  0.0%st
Cpu1  :  0.0%us,  0.0%sy,  0.0%ni, 97.0%id,  0.0%wa,  0.0%hi,  3.0%si,  0.0%st
Cpu1  :  1.0%us,  2.0%sy,  0.0%ni, 62.7%id, 34.3%wa,  0.0%hi,  0.0%si,  0.0%st


Any ideas on how I can get the buffered read numbers up closer to the raw
numbers, currently ~50MB/s vs ~80MB/s?  Simultaneously lower the CPU consumption
during I/O?

I'm using kernel 2.6.31.1, compiled myself using kernel.org sources and 'make
menuconfig' on a Debian 5.0.3 system using gcc 4.3.2-2 with the default compiler
performance flags, whatever they are.

Thanks again for your continued patience and insight.

--
Stan

Re: kernel 2.6.31.1 + Sil 3512 + WDC WD5000AAKS-00V1A0 = no NCQ and UDMA5 instead of UDMA6

[Jeff Garzik]

On 12/19/2009 06:15 PM, Stan Hoeppner wrote:
> Robert Hancock put forth on 12/19/2009 12:16 PM:
>> On 12/18/2009 01:51 PM, Stan Hoeppner wrote:
>>> Robert Hancock put forth on 12/17/2009 11:00 PM:
>>>> On Thu, Dec 17, 2009 at 10:34 PM, Stan
>>>> Hoeppner<stan@hardwarefreak.com>   wrote:
>>>
>>>>> So, how does this "phantom" UDMA setting affect either libata or
>>>>> sata_sil?  If it effects nothing, why is it hanging around?  Is this a
>>>>> backward compatibility thing for the kernel's benefit?  I'm not a
>>>>> kernel
>>>>> hacker or programmer (yet), so please forgive my ignorant questions.
>>>>
>>>> It doesn't affect either the driver or the controller. Only the drive
>>>> may possibly care - that would be if there's a SATA-to-PATA bridge
>>>> involved (as some early SATA drives had internally, for example) and
>>>> there's an actual PATA bus that needs to be programmed properly for
>>>> speed. Other than that, it's basically vestigial.
>>>
>>> So in sata_sil.c version 2.4, the following are only present in the case
>>> one of these early drives with an onboard PATA-SATA bridge is connected?
>>>
>>>           SIL_QUIRK_UDMA5MAX      = (1<<   1),
>>>
>>> } sil_blacklist [] = {
>>>
>>>           { "Maxtor 4D060H3",     SIL_QUIRK_UDMA5MAX },
>>>
>>>
>>> static const struct ata_port_info sil_port_info[] = {
>>>           /* sil_3512 */
>>>           {
>>>                   .flags          = SIL_DFL_PORT_FLAGS |
>>> SIL_FLAG_RERR_ON_DMA_ACT,
>>>                   .pio_mask       = ATA_PIO4,
>>>                   .mwdma_mask     = ATA_MWDMA2,
>>>                   .udma_mask      = ATA_UDMA5,
>>>                   .port_ops       =&sil_ops,
>>>           },
>>>
>>>    *      20040111 - Seagate drives affected by the Mod15Write bug are
>>> blacklisted
>>>    *      The Maxtor quirk is in the blacklist, but I'm keeping the
>>> original
>>>    *      pessimistic fix for the following reasons...
>>>    *      - There seems to be less info on it, only one device gleaned
>>> off the
>>>    *      Windows driver, maybe only one is affected.  More info would be
>>> greatly
>>>    *      appreciated.
>>>    *      - But then again UDMA5 is hardly anything to complain about
>>>
>>>           /* limit to udma5 */
>>>           if (quirks&   SIL_QUIRK_UDMA5MAX) {
>>>                   if (print_info)
>>>                           ata_dev_printk(dev, KERN_INFO, "applying
>>> Maxtor "
>>>                                          "errata fix %s\n", model_num);
>>>                   dev->udma_mask&= ATA_UDMA5;
>>>                   return;
>>>           }
>>>
>>>
>>> Might it be beneficial, if merely to keep people like myself from asking
>>> questions, to set the default for the 3512 to UDMA6 max instead of UDMA5
>>> max, and only set UDMA5 in the case of a blacklisted Maxtor?  I'm sure
>>> I'm not the first person to see in dmesg that my drive is showing
>>> UDMA/133 capability but sata_sil is "limiting" the drive to UDMA/100.
>>> If this setting is merely window dressing for all but the oldest borked
>>> SATA1 drives with bridge chips, why not fix up this code so it at least
>>> "appears" the controller is matching the mode the new pure SATA drive is
>>> reporting?
>>
>> For whatever reason the sata_sil driver only indicates it supports
>> UDMA5, not UDMA6. So it appears that Maxtor quirk doesn't really do
>> anything, all drivers will only get programmed as UDMA5 max anyway.
>
> According to the source comments Jeff seems to hint that it's a conscious
> decision he made for sata_sil chips, although he doesn't elaborate as to all the
> "why's" in the comments.  Jeff, would you shed more light on this please?  It
> probably makes no difference in my case, I'm just curious.

Which source comments?

I do not recall why sata_sil is limited to udma5.  udma5 limit does 
predate the now-ancient conversion of udma_mask from 0x3f to ATA_UDMA5.

According to the SiI docs and sample code, it seems like udma6 is 
supported by the hardware.

As you are guessing, s/ATA_UDMA5/ATA_UDMA6/ is unlikely to make any 
measurable difference.

	Jeff

Re: kernel 2.6.31.1 + Sil 3512 + WDC WD5000AAKS-00V1A0 = no NCQ and UDMA5 instead of UDMA6

[Stan Hoeppner]

Jeff Garzik put forth on 12/19/2009 5:29 PM:
> On 12/19/2009 06:15 PM, Stan Hoeppner wrote:
>> Robert Hancock put forth on 12/19/2009 12:16 PM:
>>> On 12/18/2009 01:51 PM, Stan Hoeppner wrote:
>>>> Robert Hancock put forth on 12/17/2009 11:00 PM:
>>>>> On Thu, Dec 17, 2009 at 10:34 PM, Stan
>>>>> Hoeppner<stan@hardwarefreak.com>   wrote:
>>>>
>>>>>> So, how does this "phantom" UDMA setting affect either libata or
>>>>>> sata_sil?  If it effects nothing, why is it hanging around?  Is
>>>>>> this a
>>>>>> backward compatibility thing for the kernel's benefit?  I'm not a
>>>>>> kernel
>>>>>> hacker or programmer (yet), so please forgive my ignorant questions.
>>>>>
>>>>> It doesn't affect either the driver or the controller. Only the drive
>>>>> may possibly care - that would be if there's a SATA-to-PATA bridge
>>>>> involved (as some early SATA drives had internally, for example) and
>>>>> there's an actual PATA bus that needs to be programmed properly for
>>>>> speed. Other than that, it's basically vestigial.
>>>>
>>>> So in sata_sil.c version 2.4, the following are only present in the
>>>> case
>>>> one of these early drives with an onboard PATA-SATA bridge is
>>>> connected?
>>>>
>>>>           SIL_QUIRK_UDMA5MAX      = (1<<   1),
>>>>
>>>> } sil_blacklist [] = {
>>>>
>>>>           { "Maxtor 4D060H3",     SIL_QUIRK_UDMA5MAX },
>>>>
>>>>
>>>> static const struct ata_port_info sil_port_info[] = {
>>>>           /* sil_3512 */
>>>>           {
>>>>                   .flags          = SIL_DFL_PORT_FLAGS |
>>>> SIL_FLAG_RERR_ON_DMA_ACT,
>>>>                   .pio_mask       = ATA_PIO4,
>>>>                   .mwdma_mask     = ATA_MWDMA2,
>>>>                   .udma_mask      = ATA_UDMA5,
>>>>                   .port_ops       =&sil_ops,
>>>>           },
>>>>
>>>>    *      20040111 - Seagate drives affected by the Mod15Write bug are
>>>> blacklisted
>>>>    *      The Maxtor quirk is in the blacklist, but I'm keeping the
>>>> original
>>>>    *      pessimistic fix for the following reasons...
>>>>    *      - There seems to be less info on it, only one device gleaned
>>>> off the
>>>>    *      Windows driver, maybe only one is affected.  More info
>>>> would be
>>>> greatly
>>>>    *      appreciated.
>>>>    *      - But then again UDMA5 is hardly anything to complain about
>>>>
>>>>           /* limit to udma5 */
>>>>           if (quirks&   SIL_QUIRK_UDMA5MAX) {
>>>>                   if (print_info)
>>>>                           ata_dev_printk(dev, KERN_INFO, "applying
>>>> Maxtor "
>>>>                                          "errata fix %s\n", model_num);
>>>>                   dev->udma_mask&= ATA_UDMA5;
>>>>                   return;
>>>>           }
>>>>
>>>>
>>>> Might it be beneficial, if merely to keep people like myself from
>>>> asking
>>>> questions, to set the default for the 3512 to UDMA6 max instead of
>>>> UDMA5
>>>> max, and only set UDMA5 in the case of a blacklisted Maxtor?  I'm sure
>>>> I'm not the first person to see in dmesg that my drive is showing
>>>> UDMA/133 capability but sata_sil is "limiting" the drive to UDMA/100.
>>>> If this setting is merely window dressing for all but the oldest borked
>>>> SATA1 drives with bridge chips, why not fix up this code so it at least
>>>> "appears" the controller is matching the mode the new pure SATA
>>>> drive is
>>>> reporting?
>>>
>>> For whatever reason the sata_sil driver only indicates it supports
>>> UDMA5, not UDMA6. So it appears that Maxtor quirk doesn't really do
>>> anything, all drivers will only get programmed as UDMA5 max anyway.
>>
>> According to the source comments Jeff seems to hint that it's a conscious
>> decision he made for sata_sil chips, although he doesn't elaborate as
>> to all the
>> "why's" in the comments.  Jeff, would you shed more light on this
>> please?  It
>> probably makes no difference in my case, I'm just curious.
> 
> Which source comments?

These:

>>>>    *      The Maxtor quirk is in the blacklist, but I'm keeping the
>>>> original
>>>>    *      pessimistic fix for the following reasons...
>>>>    *      - There seems to be less info on it, only one device gleaned
>>>> off the
>>>>    *      Windows driver, maybe only one is affected.  More info
>>>> would be
>>>> greatly
>>>>    *      appreciated.
>>>>    *      - But then again UDMA5 is hardly anything to complain about
>>>>
>>>>           /* limit to udma5 */

There was only one drive in the udma6 blacklist further down in sata_sil.c, the
Maxtor.  The Seagate drives were blacklisted for the Mod15Write bug.  It seems
from your comments above that you read in the Windows Sil3x12 driver comments
that the Maxtor drive combo would not do udma6, and you possibly read other
things that made you wonder if udma6 was a good idea for sata_sil at all.  The
comments above "I'm keeping the original pessimistic fix...", which I assume
means udma5 max across the board for sata_sil, and "But then again UDMA5 is
hardly anything to complain about" lead me to believe that you just went with
udma5 across the board for sata_sil because you were unsure of the nature of the
udma6 problems in the MS docs, and that udma5 is "hardly anything to complain
about".  Without having access to the Windows Sail3x12 driver docs, I can't
really say.  I was left guessing what your thoughts were.  That's why I asked
you. ;)

> I do not recall why sata_sil is limited to udma5.  udma5 limit does
> predate the now-ancient conversion of udma_mask from 0x3f to ATA_UDMA5.
> 
> According to the SiI docs and sample code, it seems like udma6 is
> supported by the hardware.
> 
> As you are guessing, s/ATA_UDMA5/ATA_UDMA6/ is unlikely to make any
> measurable difference.

I don't like guessing.  I like knowing.  I wouldn't mind testing the udma6
setting to see if it might make a difference, unless...

To qualify my previous comments, according to what Robert was saying, this udma
setting makes no difference on newer native sata drives which don't have the
pata<->sata bridge chips onboard--that this setting only affects drives with the
bridge chips.  I'm pretty sure my drive is without the bridge chip.  I don't
personally know enough about this stuff to guess at that one way or another.  I
don't know the libata or sata_sil code nearly well enough.  I'm a noobie here.
Assuming Robert is correct, I made the statement that udma6 would not benefit
me, as my drive is pure sata, no bridge, at least I assume so because it's a
sata2 drive, very new.  If Robert is incorrect, and this setting affects all
sata drives, then I'd love to test sata_sil with udma6.

--
Stan