Skip to contentSkip to conversation

sata_sil Mod15Write quirk workaround patch for vanilla kernel avaialble.

DISCUSSION Tejun Heo 3 participants 5 messages Mar 31, 2005 – Apr 4, 2005 libata

lore
Share & tools
lore

Tejun Heo

author
#0 lore raw

Hello, guys.

I generated m16w workaround patch for 2.6.11.6 (by just removing two
lines :-) and set up a page regarding m15w quirk and the workaournd. I'm planning on updating m15w patch against the vanilla tree until it gets into the mainline so that impatient users can try out and it gets more testing.

http://home-tj.org/m15w

Thanks.

Signature · 1 line
tejun
#1 lore raw
Quoted 9 lines · On Fri, 01 Apr 2005 00:01:23 +0900 Tejun Heo <[email protected]> wrote:

Hello, guys.

I generated m16w workaround patch for 2.6.11.6 (by just removing two
lines :-) and set up a page regarding m15w quirk and the workaournd. I'm planning on updating m15w patch against the vanilla tree until it gets into the mainline so that impatient users can try out and it gets more testing.

Quoted 7 lines

http://home-tj.org/m15w

Thanks.

Signature · 1 line
tejun

Tejun,

I applied the patch to a clean 2.6.11.6 kernel and got an unresolved symbol error for "ATA_TFLAG_LBA". I tried changing that to "ATA_TFLAG_LBA48" and it compiles and runs.

So far, no problems. Thanks a lot for the patch.

--john

diff -ru format
-----

linux-2.6.11.6-sata_sil/drivers/scsi/sata_sil.c ---
linux-2.6.11.6/drivers/scsi/sata_sil.c 2005-03-31 10:58:59.000000000 -0600
+++ linux-2.6.11.6-sata_sil/drivers/scsi/sata_sil.c 2005-03-31

11:05:00.000000000 -0600 @@ -280,7 +280,7 @@ {
        u64 block = 0;

- BUG_ON(!(tf->flags & ATA_TFLAG_LBA));
+ BUG_ON(!(tf->flags & ATA_TFLAG_LBA48));

        block |= (u64)tf->lbal;
        block |= (u64)tf->lbam << 8;
@@ -299,7 +299,7 @@
 static inline void sil_m15w_rewrite_tf (struct ata_taskfile *tf,
                                        u64 block, u16 nsect)

{
- BUG_ON(!(tf->flags & ATA_TFLAG_LBA));
+ BUG_ON(!(tf->flags & ATA_TFLAG_LBA48));

        tf->nsect = nsect & 0xff;
        tf->lbal = block & 0xff;
author
#2 lore raw

Hello, John.

Quoted 23 lines · John Lash
Quoted 8 lines · On Fri, 01 Apr 2005 00:01:23 +0900 Tejun Heo <[email protected]> wrote:

Hello, guys.

I generated m16w workaround patch for 2.6.11.6 (by just removing two lines :-) and set up a page regarding m15w quirk and the workaournd. I'm planning on updating m15w patch against the vanilla tree until it gets into the mainline so that impatient users can try out and it gets more testing.

Quoted 7 lines

http://home-tj.org/m15w

Thanks.

Signature · 1 line
tejun

Tejun,

Quoted 7 lines

I applied the patch to a clean 2.6.11.6 kernel and got an unresolved symbol error for "ATA_TFLAG_LBA". I tried changing that to "ATA_TFLAG_LBA48" and it compiles and runs.

So far, no problems. Thanks a lot for the patch.

--john

I'm sorry. I uploaded the original patch against libata-dev-2.6 tree. The two BUG_ON() lines should just be removed. I've uploaded fixed
patch. Thanks for pointing out.

Signature · 1 line
tejun
#3 lore raw

On Fri, Apr 01, 2005 at 07:51:28AM +0900, Tejun Heo wrote:
TH> Hello, John.
TH>
TH> John Lash wrote:
TH> >On Fri, 01 Apr 2005 00:01:23 +0900
TH> >Tejun Heo <[email protected]> wrote:
TH> >
TH> >
TH> >>Hello, guys.
TH> >>
TH> >>I generated m16w workaround patch for 2.6.11.6 (by just removing two TH> >>lines :-) and set up a page regarding m15w quirk and the workaournd. TH> >>I'm planning on updating m15w patch against the vanilla tree until it TH> >>gets into the mainline so that impatient users can try out and it gets TH> >>more testing.
TH> >>
TH> >>http://home-tj.org/m15w
TH> >>
TH> >>Thanks.
TH> >>
TH> >>--
TH> >>tejun
TH> >>
TH> >
TH> >
TH> >Tejun,
TH> >
TH> >I applied the patch to a clean 2.6.11.6 kernel and got an unresolved TH> >symbol error for "ATA_TFLAG_LBA". I tried changing that to TH> >"ATA_TFLAG_LBA48" and
TH> >it compiles and runs.
TH> >
TH> >So far, no problems. Thanks a lot for the patch.
TH>
TH> I'm sorry. I uploaded the original patch against libata-dev-2.6 tree. TH> The two BUG_ON() lines should just be removed. I've uploaded fixed TH> patch. Thanks for pointing out.

Thanks
Seems to be worked (I'm install with ide-ata-2.6 patch) But with heavy read load write performance is very very bad (near 50-100 KBps)
But I think that is not problem of Silicon card (I have also to SATA hard drives on Intel onboard SATA controller with same performance troubles)

Signature · 2 lines
Best regard, Aleksander Trotsai aka MAGE-RIPE aka MAGE-UANIC
My PGP key at ftp://blackhole.adamant.ua/pgp/trotsai.key[.asc]
author
#4 lore raw
Quoted 32 lines · Alexander Trotsai

On Fri, Apr 01, 2005 at 07:51:28AM +0900, Tejun Heo wrote:
TH> Hello, John.
TH> TH> John Lash wrote:
TH> >On Fri, 01 Apr 2005 00:01:23 +0900
TH> >Tejun Heo <[email protected]> wrote:
TH> >
TH> >
TH> >>Hello, guys.
TH> >>
TH> >>I generated m16w workaround patch for 2.6.11.6 (by just removing two
TH> >>lines :-) and set up a page regarding m15w quirk and the workaournd.
TH> >>I'm planning on updating m15w patch against the vanilla tree until it
TH> >>gets into the mainline so that impatient users can try out and it gets
TH> >>more testing.
TH> >>
TH> >>http://home-tj.org/m15w
TH> >>
TH> >>Thanks.
TH> >>
TH> >>-- TH> >>tejun
TH> >>
TH> >
TH> >
TH> >Tejun,
TH> >
TH> >I applied the patch to a clean 2.6.11.6 kernel and got an unresolved
TH> >symbol error for "ATA_TFLAG_LBA". I tried changing that to TH> >"ATA_TFLAG_LBA48" and
TH> >it compiles and runs.
TH> >
TH> >So far, no problems. Thanks a lot for the patch.
TH> TH> I'm sorry. I uploaded the original patch against libata-dev-2.6 tree. TH> The two BUG_ON() lines should just be removed. I've uploaded fixed TH> patch. Thanks for pointing out.

Quoted 7 lines

Thanks
Seems to be worked (I'm install with ide-ata-2.6 patch) But with heavy read load write performance is very very bad (near 50-100 KBps)
But I think that is not problem of Silicon card (I have also to SATA hard drives on Intel onboard SATA controller with same performance troubles)

It has been quite a while since I looked at the elevator code but,
IIRC, anticipatory elevator (rightfully) favors read requests over writes and doesn't care much about fairness between processes (IOW, request streams). It depends on your workload but try using cfq. For many puposes including common desktop usage, I find cfq to be better suited.

Thanks.

Signature · 1 line
tejun