max_sectors in libata when using md

max_sectors in libata when using md

[Brad Campbell]

G'day all,

Hot on the trail of this libata oddity.

static Scsi_Host_Template svia_sht = {
         .module                 = THIS_MODULE,
         .name                   = DRV_NAME,
         .queuecommand           = ata_scsi_queuecmd,
         .eh_strategy_handler    = ata_scsi_error,
         .can_queue              = ATA_DEF_QUEUE,
         .this_id                = ATA_SHT_THIS_ID,
         .sg_tablesize           = LIBATA_MAX_PRD,
         .max_sectors            = ATA_MAX_SECTORS,

ATA_MAX_SECTORS == 200.

Should then the scsi layer be able to do this and queue 1/2 a Meg in a single request?

sd_rw_intr: sda: res=0x0
1024 sectors total, 524288 bytes done.
use_sg is 128
sd_init_command: disk=sda, block=0, count=1024
sda : block=0
sda : writing 1024/1024 512 byte blocks.
scsi_add_timer: scmd: dfc48a00, time: 30000, (c0283910)
ata_scsi_dump_cdb: CDB (13:0,0,0) 2a 00 00 00 00 00 00 04 00
ata_scsi_translate: ENTER
ata_scsi_rw_xlat: ten-byte command
ata_sg_setup: ENTER, ata13
ata_sg_setup: 128 sg elements mapped

And queue 1024 sectors in one hit?

If I talk to the drive directly with
dd if=/dev/zero of=/dev/sda bs=1024k count=1

The SCSI layer seems to break the request up into nice neat 127 sector chunks and send it on through.

If I talk to it via an md device.

mdadm --create --force --level=0 --raid-devices=1 /dev/md0 /dev/sda
dd if=/dev/zero of=/dev/md0 bs=1024k count=1

Then we get what we see above, and my PATA->SATA adaptor intermittently locks up with transfers that 
long. (It does not appear to if I crank the speed down to UDMA66 from UDMA100 but that is another story)


Am I looking at something completely weird? Is the block layer doing something I should know about? 
Can SATA transfers handle 1024 sectors in one go? Will Batman make it out of the cave alive?

Regards,
Brad

Re: max_sectors in libata when using md

[Dave]

On Thu, 26 Aug 2004 19:20:09 +0400, Brad Campbell <brad@wasp.net.au> wrote:
> G'day all,
> 
> Hot on the trail of this libata oddity.
> 
> 
> ATA_MAX_SECTORS == 200.
> 
> Should then the scsi layer be able to do this and queue 1/2 a Meg in a single request?
> 
> Am I looking at something completely weird? Is the block layer doing something I should know about?
> Can SATA transfers handle 1024 sectors in one go? Will Batman make it out of the cave alive?

That is decimal 200, not hex 200. Technically with ATA (or SATA)
drives you can bump it to 0x100 (256). That is the limitation of LBA28
drives. With LBA48 drives you can do 0xffff (64k) sectors per request
I believe. I wish the SATA layer would allow a mechanism to auto
detect drive being LBA48 or LBA28 and adjust accordingly instead of
just default to a very low sector count.

-- 
-= Dave =-

Software Engineer - Advanced Development Engineering Team 
Storage Component Division - Intel Corp. 
mailto://dave-DOT-jiang-AT-intel-DOT-com 
----
The views expressed in this email are
mine alone and do not necessarily 
reflect the views of my employer
(Intel Corp.).

Re: max_sectors in libata when using md

[Jeff Garzik]

Dave wrote:
> I believe. I wish the SATA layer would allow a mechanism to auto
> detect drive being LBA48 or LBA28 and adjust accordingly instead of
> just default to a very low sector count.


The SATA layer already does this...  but only on 2.6.x kernels.

drivers/scsi/libata-scsi.c, ata_scsi_slave_config()

	Jeff

Re: max_sectors in libata when using md

[Brad Campbell]

Dave wrote:
> On Thu, 26 Aug 2004 19:20:09 +0400, Brad Campbell <brad@wasp.net.au> wrote:
> 
>>G'day all,
>>
>>Hot on the trail of this libata oddity.
>>
>>
>>ATA_MAX_SECTORS == 200.
>>
>>Should then the scsi layer be able to do this and queue 1/2 a Meg in a single request?
>>
>>Am I looking at something completely weird? Is the block layer doing something I should know about?
>>Can SATA transfers handle 1024 sectors in one go? Will Batman make it out of the cave alive?
> 
> 
> That is decimal 200, not hex 200. Technically with ATA (or SATA)
> drives you can bump it to 0x100 (256). That is the limitation of LBA28
> drives. With LBA48 drives you can do 0xffff (64k) sectors per request
> I believe.

G'day Dave,

Thanks for the reply.

In theory I guess 0xffff sectors is possible. Over here, I'm getting requests of more than 256 
sectors intermittently locking up my SATA->PATA converters if run on a via sata interface (On a 
promise interface it's not a problem)

I also note than in sata_sil there is a workaround for Seagate drives that knocks max_sectors back 
to 15. Is the md driver going to circumvent that also and lock up those interfaces?

I realise that 200 is decimal, my question was more how are requests of 1024 sectors making it to 
the driver when the driver has a max_sector value of 200?

I'm only seeing sectors > 200 when the request comes from md, thus my cc'ing it to the raid list to 
see if anyone there has any idea.

Regards,
Brad (Getting warmer)

Re: max_sectors in libata when using md

[Brad Campbell]

Jeff Garzik wrote:
> Dave wrote:
> 
>> I believe. I wish the SATA layer would allow a mechanism to auto
>> detect drive being LBA48 or LBA28 and adjust accordingly instead of
>> just default to a very low sector count.
> 
> 
> 
> The SATA layer already does this...  but only on 2.6.x kernels.
> 
> drivers/scsi/libata-scsi.c, ata_scsi_slave_config()
> 

(Groan) <Places head in hands weeping>

I give up Batman.

In which case, these drives need to be knocked back to UDMA66 to function properly on anything later 
than 2.6.6. Don't know why.
I have tried multiple drives (I have 5 of them), multiple cables (lots of those) and multiple bridge 
boards (I have 6 of those). There is no combination that is reliable on the VIA controller with any 
transfer larger than about 0x80 sectors *OR* speeds greater than UDMA66 *OR* Kernel 2.6.6 or prior.



Regards,
Brad

Re: max_sectors in libata when using md

[Jeff Garzik]

Brad Campbell wrote:
> In which case, these drives need to be knocked back to UDMA66 to 
> function properly on anything later than 2.6.6. Don't know why.
> I have tried multiple drives (I have 5 of them), multiple cables (lots 
> of those) and multiple bridge boards (I have 6 of those). There is no 
> combination that is reliable on the VIA controller with any transfer 
> larger than about 0x80 sectors *OR* speeds greater than UDMA66 *OR* 
> Kernel 2.6.6 or prior.


We could always eliminate lba48 max-sectors increase on VIA controllers...

	Jeff

Re: max_sectors in libata when using md

[Dave]

On Thu, 26 Aug 2004 13:26:22 -0400, Jeff Garzik <jgarzik@pobox.com> wrote:
> Brad Campbell wrote:
> > In which case, these drives need to be knocked back to UDMA66 to
> > function properly on anything later than 2.6.6. Don't know why.
> > I have tried multiple drives (I have 5 of them), multiple cables (lots
> > of those) and multiple bridge boards (I have 6 of those). There is no
> > combination that is reliable on the VIA controller with any transfer
> > larger than about 0x80 sectors *OR* speeds greater than UDMA66 *OR*
> > Kernel 2.6.6 or prior.
> 
> We could always eliminate lba48 max-sectors increase on VIA controllers...
> 
>        Jeff
> 
> 

Has Brad tried it with native SATA drives instead of bridges? Could be
VIA controllers incompatible with PATA->SATA bridges.....

-- 
-= Dave =-

Software Engineer - Advanced Development Engineering Team 
Storage Component Division - Intel Corp. 
mailto://dave-DOT-jiang-AT-intel-DOT-com 
----
The views expressed in this email are
mine alone and do not necessarily 
reflect the views of my employer
(Intel Corp.).

Re: max_sectors in libata when using md

[Brad Campbell]

Jeff Garzik wrote:
> Brad Campbell wrote:
> 
>> In which case, these drives need to be knocked back to UDMA66 to 
>> function properly on anything later than 2.6.6. Don't know why.
>> I have tried multiple drives (I have 5 of them), multiple cables (lots 
>> of those) and multiple bridge boards (I have 6 of those). There is no 
>> combination that is reliable on the VIA controller with any transfer 
>> larger than about 0x80 sectors *OR* speeds greater than UDMA66 *OR* 
>> Kernel 2.6.6 or prior.
> 
> 
> 
> We could always eliminate lba48 max-sectors increase on VIA controllers...

Possibly, however I purchased a couple of new Maxtor Maxline-II SATA drives today and they play 
nicely with the VIA controller. It really appears to be a quirk of the WD Drive with the Addonics 
Bridge board.
I'll apply a patch locally I think rather than cripple every one using a VIA controller.
Either that or I can produce a patch along the lines of the sil quirk patch that looks for the 
WD2000JB (which is not a SATA model) and does it that way.
You never know, perhaps someone else out there might have the same combo of hardware some day.

Regards,
Brad

Re: max_sectors in libata when using md

[Jeff Garzik]

Dave wrote:
> On Thu, 26 Aug 2004 13:26:22 -0400, Jeff Garzik <jgarzik@pobox.com> wrote:
>>We could always eliminate lba48 max-sectors increase on VIA controllers...

> Has Brad tried it with native SATA drives instead of bridges? Could be
> VIA controllers incompatible with PATA->SATA bridges.....


Oh wait.  That's a damned good point.

I wonder if there is a problem with LBA48 large transfers (>256 sectors) 
and bridges.  Is Brad definitely using a bridge?  I may have missed that 
detail in a flurry of emails :)

	Jeff

Re: max_sectors in libata when using md

[Brad Campbell]

Jeff Garzik wrote:
> Dave wrote:
> 
>> On Thu, 26 Aug 2004 13:26:22 -0400, Jeff Garzik <jgarzik@pobox.com> 
>> wrote:
>>
>>> We could always eliminate lba48 max-sectors increase on VIA 
>>> controllers...
> 
> 
>> Has Brad tried it with native SATA drives instead of bridges? Could be
>> VIA controllers incompatible with PATA->SATA bridges.....
> 
> 
> 
> Oh wait.  That's a damned good point.
> 
> I wonder if there is a problem with LBA48 large transfers (>256 sectors) 
> and bridges.  Is Brad definitely using a bridge?  I may have missed that 
> detail in a flurry of emails :)

Yep.. using a bridge!
How to detect the bridge though?

Re: max_sectors in libata when using md

[Jeff Garzik]

Brad Campbell wrote:
> I also note than in sata_sil there is a workaround for Seagate drives 
> that knocks max_sectors back to 15.

That's very specific to SiI-311x + Seagate drives.


> Is the md driver going to circumvent 
> that also and lock up those interfaces?
> 
> I realise that 200 is decimal, my question was more how are requests of 
> 1024 sectors making it to the driver when the driver has a max_sector 
> value of 200?
> 
> I'm only seeing sectors > 200 when the request comes from md, thus my 
> cc'ing it to the raid list to see if anyone there has any idea.

With a filesystem+MD, you have two entities trying hard to generate the 
largest request possible, the VM [handles filesystem writeback] and MD. 
   If you remove MD from the picture, you remove one entity that tries 
to create large requests.  So that part makes sense.

However, if md violates or increases the max-sectors above what the 
driver sets, then hardware would be failing all over the place.  I could 
be wrong, but I tend to doubt md would do something like that.

	Jeff

Re: max_sectors in libata when using md

[Jeff Garzik]

Brad Campbell wrote:
> Jeff Garzik wrote:
> 
>> Dave wrote:
>>
>>> On Thu, 26 Aug 2004 13:26:22 -0400, Jeff Garzik <jgarzik@pobox.com> 
>>> wrote:
>>>
>>>> We could always eliminate lba48 max-sectors increase on VIA 
>>>> controllers...
>>
>>
>>
>>> Has Brad tried it with native SATA drives instead of bridges? Could be
>>> VIA controllers incompatible with PATA->SATA bridges.....
>>
>>
>>
>>
>> Oh wait.  That's a damned good point.
>>
>> I wonder if there is a problem with LBA48 large transfers (>256 
>> sectors) and bridges.  Is Brad definitely using a bridge?  I may have 
>> missed that detail in a flurry of emails :)
> 
> 
> Yep.. using a bridge!
> How to detect the bridge though?

It's not terribly easy :/

If you can google for the datasheet, that would be helpful.

Sometimes bridges will modify the underlying 40-char ATA model name,

	WD123456                        ADDONICS68

where "WD123456" is the underlying ATA device, and "ADDONICS68" is the 
bridge identifier.

	Jeff

Re: max_sectors in libata when using md

[Brad Campbell]

[-- Attachment #1: Type: text/plain, Size: 991 bytes --]

Jeff Garzik wrote:
>
>> Yep.. using a bridge!
>> How to detect the bridge though?
> 
> 
> It's not terribly easy :/
> 
> If you can google for the datasheet, that would be helpful.

Did that. No dice. The data available says nothing about any way of detection. It's a completely 
transparent bridge. SIL3611.

> Sometimes bridges will modify the underlying 40-char ATA model name,
> 
>     WD123456                        ADDONICS68
> 
> where "WD123456" is the underlying ATA device, and "ADDONICS68" is the 
> bridge identifier.

Nope. Does not do that either.

I based this on the fact the drive number is a PATA drive (the WD2000JD is a SATA drive).
This patch was modeled on the sil quirk detection code and "works for me" in that I have 
read/written 2GB with 2.6.9-rc1 now where 128KB would kill it before.

I have a little flat spot on my forehead and a little forehead shaped dent in the wall next to this 
machine.

Thanks for your help, patience and guidance guys.

Regards,
Brad

[-- Attachment #2: sata.patch --]
[-- Type: text/plain, Size: 2503 bytes --]

--- orig/linux-2.6.0/drivers/scsi/sata_via.c	2004-08-26 22:21:56.000000000 +0400
+++ linux-2.6.9-rc1/drivers/scsi/sata_via.c	2004-08-26 22:14:19.000000000 +0400
@@ -59,10 +59,13 @@
 
 	SATA_EXT_PHY		= (1 << 6), /* 0==use PATA, 1==ext phy */
 	SATA_2DEV		= (1 << 5), /* SATA is master/slave */
+	SVIA_QUIRK_200SECTS	= (1 << 0),
+
 };
 
 static int svia_init_one (struct pci_dev *pdev, const struct pci_device_id *ent);
 static u32 svia_scr_read (struct ata_port *ap, unsigned int sc_reg);
+static void svia_dev_config(struct ata_port *ap, struct ata_device *dev);
 static void svia_scr_write (struct ata_port *ap, unsigned int sc_reg, u32 val);
 
 static struct pci_device_id svia_pci_tbl[] = {
@@ -71,6 +74,14 @@
 	{ }	/* terminate list */
 };
 
+struct svia_drivelist {
+        const char * product;
+        unsigned int quirk;
+} svia_blacklist [] = {
+        { "WDC WD2000JB",         SVIA_QUIRK_200SECTS },
+        { }
+};
+
 static struct pci_driver svia_pci_driver = {
 	.name			= DRV_NAME,
 	.id_table		= svia_pci_tbl,
@@ -122,6 +133,8 @@
 
 	.port_start		= ata_port_start,
 	.port_stop		= ata_port_stop,
+	.dev_config		= svia_dev_config,
+
 };
 
 MODULE_AUTHOR("Jeff Garzik");
@@ -283,6 +296,40 @@
 	return rc;
 }
 
+static void svia_dev_config(struct ata_port *ap, struct ata_device *dev)
+{
+        unsigned int n, quirks = 0;
+        unsigned char model_num[40];
+        const char *s;
+        unsigned int len;
+
+        ata_dev_id_string(dev, model_num, ATA_ID_PROD_OFS,
+                          sizeof(model_num));
+        s = &model_num[0];
+        len = strnlen(s, sizeof(model_num));
+
+        /* ATAPI specifies that empty space is blank-filled; remove blanks */
+        while ((len > 0) && (s[len - 1] == ' '))
+                len--;
+
+        for (n = 0; svia_blacklist[n].product; n++) 
+                if (!memcmp(svia_blacklist[n].product, s,
+                            strlen(svia_blacklist[n].product))) {
+                        quirks = svia_blacklist[n].quirk;
+                        break;
+                }
+        
+        /* limit requests to 200 sectors */
+        if (quirks & SVIA_QUIRK_200SECTS) {
+                printk(KERN_INFO "ata%u(%u): applying WD errata fix\n",
+                       ap->id, dev->devno);
+                ap->host->max_sectors = 200;
+                ap->host->hostt->max_sectors = 200;
+                return;
+        }
+
+}
+
 static int __init svia_init(void)
 {
 	return pci_module_init(&svia_pci_driver);