Re: SII SATA request size limit

Re: SII SATA request size limit

[Eduardo Casino]

Hi All,

I had a look at the NetBSD pciide.c driver and found this interesting
bit of code:
	
	/*
	 * Rev. <= 0x01 of the 3112 have a bug that can cause data
	 * corruption if DMA transfers cross an 8K boundary.  This is
	 * apparently hard to tickle, but we'll go ahead and play it
	 * safe.
	 */
	if (PCI_REVISION(pa->pa_class) <= 0x01) {
		sc->sc_dma_maxsegsz = 8192;
		sc->sc_dma_boundary = 8192;
	}

This is basically the same as setting hwif->rqsize to 15, but the NetBSD
folks apply the restriction only if the SiI3112 chipset revision is 1 or
lower. As I have a rev. 2 chip, I raised the rqsize to 128 and made some
disk intensive tests: kernel compilation while recursively copying some
huge (~400MB) files. A couple of hours later, my system remained stable
and getting transfers over 55MB/s with my 120GB Seagate. I'm running
2.4.22-ac1.

This silly patch makes the siimage driver to set rqsize to 15 only for
older, supposedly buggy chips, and leaves the default for the rest.

Regards,
Eduardo.


--- siimage.c.orig	2003-09-12 11:52:26.000000000 +0200
+++ siimage.c	2003-09-12 15:42:20.000000000 +0200
@@ -1065,7 +1065,12 @@ static void __init init_iops_siimage (id
 	hwif->hwif_data = 0;
 
 	hwif->rqsize = 128;
-	if (is_sata(hwif))
+	/*
+	 * From the NetBSD driver:
+	 * "Rev. <= 0x01 of the 3112 have a bug that can cause data
+	 *  corruption if DMA transfers cross an 8K boundary."
+	 */
+	if (dev->device == PCI_DEVICE_ID_SII_3112 && class_rev < 0x02)
 		hwif->rqsize = 15;
 
 	if (pci_get_drvdata(dev) == NULL)

Re: SII SATA request size limit

[Jens Axboe]

On Fri, Sep 12 2003, Eduardo Casino wrote:
> Hi All,
> 
> I had a look at the NetBSD pciide.c driver and found this interesting
> bit of code:
> 	
> 	/*
> 	 * Rev. <= 0x01 of the 3112 have a bug that can cause data
> 	 * corruption if DMA transfers cross an 8K boundary.  This is
> 	 * apparently hard to tickle, but we'll go ahead and play it
> 	 * safe.
> 	 */
> 	if (PCI_REVISION(pa->pa_class) <= 0x01) {
> 		sc->sc_dma_maxsegsz = 8192;
> 		sc->sc_dma_boundary = 8192;
> 	}
> 
> This is basically the same as setting hwif->rqsize to 15, but the NetBSD

You can do much much better than that, it's pretty simply to just
restrict the segment size and boundary if you have a controller with
such a bug. And then you get the benefit of the larger requests too,
it's basically not a performance hit at that point.

-- 
Jens Axboe

RE: SII SATA request size limit

[Allen Martin]

> > much as soon as anything touches the SCSI bus on my aic7xxx card.
> > Disabling DMA on the SiI IDE channel seems to work around it, at the
> > cost of a lot of performance... (this is on stock 2.4.22, BTW)
> No, only on-board nForce2 IDE controller. Disabling ACPI 
> helped. - now it's 
> stable

There are ACPI issues with nForce boards, you will see PCI interrupts get
programmed to edge triggered mode in /proc/interrupts when APIC is enabled.
The easiest workaround is to disable ACPI like you have done.

-Allen

Re: SII SATA request size limit

[CASINO_E]

> Unfortunately the bug isnt exactly this (apparently) and is only
> revealed under NDA (see Alan Cox's mail).

If I get this post correctly 
(http://www.ussg.iu.edu/hypermail/linux/kernel/0306.0/0764.html), the 
bug is at least close to this. I understand that Alan's mail refers to 
which particular combinations of chip revisions and disk drives are 
affected, so that is why the workaround is applied to all the cases.

Eduardo.

Re: SII SATA request size limit

[CASINO_E]

Forgive me if I'm saying something stupid but, do you mean a special 
case for this controller in ide-dma.c:ide_build_dmatable()?

In this case, should not segment size and boundary be included in hwif 
so we can have a generic ide_build_dmatable() without dealing 
explicitly with special cases? We could initialize to the default for 
most controllers and set the values for the exceptions inside each 
particular driver.

----- Mensaje Original -----
De: Jens Axboe <axboe@suse.de>
Fecha: Lunes, Septiembre 15, 2003 10:47 am
Asunto: Re: SII SATA request size limit

> On Fri, Sep 12 2003, Eduardo Casino wrote:
> > Hi All,
> > 
> > I had a look at the NetBSD pciide.c driver and found this 
> interesting> bit of code:
> > 	
> > 	/*
> > 	 * Rev. <= 0x01 of the 3112 have a bug that can cause data
> > 	 * corruption if DMA transfers cross an 8K boundary.  This is
> > 	 * apparently hard to tickle, but we'll go ahead and play it
> > 	 * safe.
> > 	 */
> > 	if (PCI_REVISION(pa->pa_class) <= 0x01) {
> > 	        sc->sc_dma_maxsegsz = 8192;
> > 	        sc->sc_dma_boundary = 8192;
> > 	}
> > 
> > This is basically the same as setting hwif->rqsize to 15, but 
> the NetBSD
> 
> You can do much much better than that, it's pretty simply to just
> restrict the segment size and boundary if you have a controller with
> such a bug. And then you get the benefit of the larger requests too,
> it's basically not a performance hit at that point.
> 
> -- 
> Jens Axboe
> 
> 

Re: SII SATA request size limit

[Jens Axboe]

On Mon, Sep 15 2003, CASINO_E wrote:
> Forgive me if I'm saying something stupid but, do you mean a special 
> case for this controller in ide-dma.c:ide_build_dmatable()?

No that's not stupid at all. In 2.4 that would be how you do it, in 2.6
I was referring to the possibility of letting the drive queues that hang
off that controller be naturally limited. So you would do something ala

	if (hwif->dma_boundary)
		blk_queue_segment_boundary(drive->queue, 0x1fff);

and then no segment would be >= 8192 (or cross it, naturally) by
default.

> In this case, should not segment size and boundary be included in hwif 
> so we can have a generic ide_build_dmatable() without dealing 
> explicitly with special cases? We could initialize to the default for 
> most controllers and set the values for the exceptions inside each 
> particular driver.

Of course. But that is implementation detail, I was just worried that
someone would clamp on a nasty work around like 15 sectors (which would
in reality be just a 4kb request, nasty!) when you could get nice 128kb
requests with just the right segment limiting instead.

But basically I don't understand why the work-around was _ever_ in
sectors, if that is the bug in the hardware dma engine. Two
explanations: it's not really that bug and NetBSD is wrong, or the
person who did the work-around didn't know a better solution existed
(don't laugh, I wouldn't be surprised if something like that came down
from a vendor :)

-- 
Jens Axboe

Re: SII SATA request size limit

[Justin Cormack]

On Mon, 2003-09-15 at 16:32, Jens Axboe wrote:
> On Mon, Sep 15 2003, CASINO_E wrote:
> > Forgive me if I'm saying something stupid but, do you mean a special 
> > case for this controller in ide-dma.c:ide_build_dmatable()?
> 
> No that's not stupid at all. In 2.4 that would be how you do it, in 2.6
> I was referring to the possibility of letting the drive queues that hang
> off that controller be naturally limited. So you would do something ala
> 
> 	if (hwif->dma_boundary)
> 		blk_queue_segment_boundary(drive->queue, 0x1fff);
> 
> and then no segment would be >= 8192 (or cross it, naturally) by
> default.
> 
> > In this case, should not segment size and boundary be included in hwif 
> > so we can have a generic ide_build_dmatable() without dealing 
> > explicitly with special cases? We could initialize to the default for 
> > most controllers and set the values for the exceptions inside each 
> > particular driver.
> 
> Of course. But that is implementation detail, I was just worried that
> someone would clamp on a nasty work around like 15 sectors (which would
> in reality be just a 4kb request, nasty!) when you could get nice 128kb
> requests with just the right segment limiting instead.
> 
> But basically I don't understand why the work-around was _ever_ in
> sectors, if that is the bug in the hardware dma engine. Two
> explanations: it's not really that bug and NetBSD is wrong, or the
> person who did the work-around didn't know a better solution existed
> (don't laugh, I wouldn't be surprised if something like that came down
> from a vendor :)

Unfortunately the bug isnt exactly this (apparently) and is only
revealed under NDA (see Alan Cox's mail).

justin

Re: SII SATA request size limit

[Jens Axboe]

On Mon, Sep 15 2003, Justin Cormack wrote:
> On Mon, 2003-09-15 at 16:32, Jens Axboe wrote:
> > On Mon, Sep 15 2003, CASINO_E wrote:
> > > Forgive me if I'm saying something stupid but, do you mean a special 
> > > case for this controller in ide-dma.c:ide_build_dmatable()?
> > 
> > No that's not stupid at all. In 2.4 that would be how you do it, in 2.6
> > I was referring to the possibility of letting the drive queues that hang
> > off that controller be naturally limited. So you would do something ala
> > 
> > 	if (hwif->dma_boundary)
> > 		blk_queue_segment_boundary(drive->queue, 0x1fff);
> > 
> > and then no segment would be >= 8192 (or cross it, naturally) by
> > default.
> > 
> > > In this case, should not segment size and boundary be included in hwif 
> > > so we can have a generic ide_build_dmatable() without dealing 
> > > explicitly with special cases? We could initialize to the default for 
> > > most controllers and set the values for the exceptions inside each 
> > > particular driver.
> > 
> > Of course. But that is implementation detail, I was just worried that
> > someone would clamp on a nasty work around like 15 sectors (which would
> > in reality be just a 4kb request, nasty!) when you could get nice 128kb
> > requests with just the right segment limiting instead.
> > 
> > But basically I don't understand why the work-around was _ever_ in
> > sectors, if that is the bug in the hardware dma engine. Two
> > explanations: it's not really that bug and NetBSD is wrong, or the
> > person who did the work-around didn't know a better solution existed
> > (don't laugh, I wouldn't be surprised if something like that came down
> > from a vendor :)
> 
> Unfortunately the bug isnt exactly this (apparently) and is only
> revealed under NDA (see Alan Cox's mail).

Just read Alans mails, doesn't really explain anything. But the segment
patch must be close, if limiting max transfer size to 7.5K works. Which
(in spirit, at least) is identical to the NetBSD work-around.

And why you would want to keep a work around like this under NDA (for a
bug that completely cripples the hardware) I don't understand at all,
seems pretty damn stupid to me. "Thanks for buying our hardware, yes
it's buggy and we wont tell you what the bug is. Please come again!"

-- 
Jens Axboe

Re: SII SATA request size limit

[Alan Cox]

On Llu, 2003-09-15 at 16:32, Jens Axboe wrote:
> But basically I don't understand why the work-around was _ever_ in
> sectors, if that is the bug in the hardware dma engine. 

It is not a bug in the DMA engine. You will have to sign an SI NDA to
find out more.

Re: SII SATA request size limit

[Eduardo Casino]

>From the SiImage closed-source driver release notes:

"Limitations:                                                                             ...
3. Mod15Write fix for Seagate Drives (for chipset versions 3112 1.21 or
older)"

strings sii6512.o | grep Mod15Write shows the following:
Mod15Write
ST320012AS::Mod15Write
ST330013AS::Mod15Write
ST340017AS::Mod15Write
ST360015AS::Mod15Write
ST380023AS::Mod15Write
ST3120023AS::Mod15Write
ST340014ASL::Mod15Write
ST360014ASL::Mod15Write
ST380011ASL::Mod15Write
ST3120022ASL::Mod15Write
ST3160021ASL::Mod15Write

So they seem to apply the fix for SG drives only.

Just in case somebody finds this useful...

Eduardo.

Re: SII SATA request size limit

[Marcelo Penna Guerra]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Alan Cox escreveu:

> On Sad, 2003-09-13 at 00:07, Marcelo Penna Guerra wrote:
>> And I still don't know how to set this limit back to 128 with 2.6.x 
>kernels. 
>> It can't be done the same way as in 2.4.x, can it?
>
>I dont really track 2.6, if someone took reconfiguring it out of 2.6
>that would be unfortunate and suprising.

On 2.6.0-test4-mm6, /proc/ide/hde/settings:

name                    value           min             max             mode
- ----                    -----           ---             ---             ----
acoustic                0               0               254             rw
address                 0               0               2               rw
bios_cyl                65535           0               65535           rw
bios_head               16              0               255             rw
bios_sect               63              0               63              rw
bswap                   0               0               1               r
current_speed           69              0               70              rw
failures                0               0               65535           rw
init_speed              69              0               70              rw
io_32bit                1               0               3               rw
keepsettings            0               0               1               rw
lun                     0               0               7               rw
max_failures            1               0               65535           rw
multcount               16              0               16              rw
nice1                   1               0               1               rw
nowerr                  0               0               1               rw
number                  0               0               3               rw
pio_mode                write-only      0               255             w
slow                    0               0               1               rw
unmaskirq               1               0               1               rw
using_dma               1               0               1               rw
wcache                  0               0               1               rw

Anyone know the reason why it's not there anymore? Shouldn't it be 
reimplemented?

Marcelo Penna Guerra
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)

iD8DBQE/Y0lPD/U0kdg4PFoRAiV8AKCKjq2mUkt26uzS8lURWABNBM+dmACg4ZMF
dNZW2uZxh0UM8+0hOv0vtZQ=
=vDdg
-----END PGP SIGNATURE-----

Re: SII SATA request size limit

[Marcelo Penna Guerra]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Alan Cox escreveu:

> It isnt that simple, unfortunately you need an NDA for the full story.
> If you want to check which chips need it get a setup that hangs reliably
> with large transfers, put the same disks on a newer controller that
> doesnt and see what happens

So, shouldn't we go back to my suggestion? A lot of users won't know that this 
limit is being set and telling them on boot time would be a good thing I 
think.

And I still don't know how to set this limit back to 128 with 2.6.x kernels. 
It can't be done the same way as in 2.4.x, can it?

Marcelo Penna Guerra
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)

iD8DBQE/YlGyD/U0kdg4PFoRAiHdAJ97opZnlt0uVKh+GVERMtKbH4HmWACgj21x
0zSI4+LRkBs3Dz6gDvdilIU=
=Saft
-----END PGP SIGNATURE-----

Re: SII SATA request size limit

[Alan Cox]

On Sad, 2003-09-13 at 00:07, Marcelo Penna Guerra wrote:
> And I still don't know how to set this limit back to 128 with 2.6.x kernels. 
> It can't be done the same way as in 2.4.x, can it?

I dont really track 2.6, if someone took reconfiguring it out of 2.6
that would be unfortunate and suprising.

Re: SII SATA request size limit

[Marcelo Penna Guerra]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Alan Cox escreveu:

> It will depend what disks you have.
A friend from a forum found out this on NetBSD:

/* 
     * Rev. <= 0x01 of the 3112 have a bug that can cause data 
     * corruption if DMA transfers cross an 8K boundary.  This is 
     * apparently hard to tickle, but we'll go ahead and play it 
     * safe. 
     */ 
    if (PCI_REVISION(pa->pa_class) <= 0x01) { 
       sc->sc_dma_maxsegsz = 8192; 
       sc->sc_dma_boundary = 8192; 
    }

It seems to be a bug only in the first revisions of the chip. Can anyone 
confirm this? My chip is revision 2 and it doesn't have this bug.

> You can up it again at runtime.

How do I set the rqsize on 2.6.x?

Marcelo Penna Guerra
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)

iD8DBQE/YjPvD/U0kdg4PFoRAusNAKDiLWwPFAmmCH9L4AwhpKIkh5zkzQCeJ8JT
YRgXP0NIoM8hcWH8RvzwYr0=
=Z6aZ
-----END PGP SIGNATURE-----

Re: SII SATA request size limit

[Alan Cox]

On Gwe, 2003-09-12 at 22:00, Marcelo Penna Guerra wrote:
>      * Rev. <= 0x01 of the 3112 have a bug that can cause data 
>      * corruption if DMA transfers cross an 8K boundary.  This is 
>      * apparently hard to tickle, but we'll go ahead and play it 
>      * safe. 

It isnt that simple, unfortunately you need an NDA for the full story.
If you want to check which chips need it get a setup that hangs reliably
with large transfers, put the same disks on a newer controller that
doesnt and see what happens

Re: SII SATA request size limit

[Marcelo Penna Guerra]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Witold Krecicki escreveu:

> I've lost some of mails about siimage on LKML, but Im' getting more and more 
> confused about 'hangs' probably caused by siimage driver. I was using 15 
> rqsize, now 128 - doesn't matter. It happens in random moments - sometimes 
at 
> boot time when drive is fscked, sometimes when I'm trying to copy large 
> amount of data and sometimes without any particular reason after several 
> hours. I've updated MB (a7n8x deluxe rev 2.0) BIOS but controller (which is 
> on-board) bios seems to be untouched (4.1.25 or so ). Is there any 
controller 
> BIOS update which I could miss? what can be other reason

Do you have APIC enabled? If you enable both ACPI and APIC you'll have 
problems with DMA, using the onboard nForce2 IDE or the SATA chip. I filled a 
bug report and will add some debug info as soon as I recompile my kernel with 
APIC and debug support again.

Marcelo Penna Guerra
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)

iD8DBQE/YjK2D/U0kdg4PFoRAjWfAJ4qsWrGksxVzme3Nm1T14n6/ocVRQCgkdhS
0216vc1WSC+ercfYTLkDJxQ=
=pLvp
-----END PGP SIGNATURE-----

Re: SII SATA request size limit

[Witold Krecicki]

Dnia pią 12. września 2003 22:55, Marcelo Penna Guerra napisał:
> Witold Krecicki escreveu:
> > I've lost some of mails about siimage on LKML, but Im' getting more and
> > more confused about 'hangs' probably caused by siimage driver. I was
> > using 15 rqsize, now 128 - doesn't matter. It happens in random moments -
> > sometimes
>
> at
>
> > boot time when drive is fscked, sometimes when I'm trying to copy large
> > amount of data and sometimes without any particular reason after several
> > hours. I've updated MB (a7n8x deluxe rev 2.0) BIOS but controller (which
> > is on-board) bios seems to be untouched (4.1.25 or so ). Is there any
>
> controller
>
> > BIOS update which I could miss? what can be other reason
>
> Do you have APIC enabled? If you enable both ACPI and APIC you'll have
> problems with DMA, using the onboard nForce2 IDE or the SATA chip. I filled
> a bug report and will add some debug info as soon as I recompile my kernel
> with APIC and debug support again.
After disabling APIC in kernel/BIOS it still hanged, but when I've disabled 
ACPI:
 12:55pm  up 13:06,  4 users,  load average: 0.09, 0.03, 0.01
Longest uptime I've ever seen on this HW @ Linux
-- 
Witold Kręcicki (adasi) adasi [at] culm.net
GPG key: 7AE20871
http://www.culm.net

SII SATA request size limit

[Marcelo Penna Guerra]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi,

In recent kernels, the siimage driver limits the max kb per request size to 15 
(7.5kb). As I was having no problems with rqsize of 128 (64kb), I decided to 
comment out this part of the code and my system is rock solid.

I'm not suggesting that it should be removed, as it probably is necessary on 
other systems, but as the performance impact is huge (with 15 hdparm tests 
show an average 26mb/s and with 128 it's 47mb/s), I think the user should be 
warnned of this and there could be a option to set it to 128 in 2.6.x 
kernels, so people can try to see if it's stable. I really don't beleive that 
I have such an unique hardware configuration, so this should benefit other 
people.

Marcelo Penna Guerra
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)

iD8DBQE/YTYjD/U0kdg4PFoRAhBnAJ0TyeJx5nrxzDS5Rib5AEWQHx4iSACeKcn8
wg7cUhLobywfTCcPl8GqNCc=
=VuVw
-----END PGP SIGNATURE-----

Re: SII SATA request size limit

[Alan Cox]

On Gwe, 2003-09-12 at 03:57, Marcelo Penna Guerra wrote:
> In recent kernels, the siimage driver limits the max kb per request size to 15 
> (7.5kb). As I was having no problems with rqsize of 128 (64kb), I decided to 
> comment out this part of the code and my system is rock solid.

It will depend what disks you have.

> kernels, so people can try to see if it's stable. I really don't beleive that 
> I have such an unique hardware configuration, so this should benefit other 
> people.

You can up it again at runtime.

Re: SII SATA request size limit

[Witold Krecicki]

Dnia pią 12. września 2003 12:41, Alan Cox napisał:
> On Gwe, 2003-09-12 at 03:57, Marcelo Penna Guerra wrote:
> > In recent kernels, the siimage driver limits the max kb per request size
> > to 15 (7.5kb). As I was having no problems with rqsize of 128 (64kb), I
> > decided to comment out this part of the code and my system is rock solid.
>
> It will depend what disks you have.
>
> > kernels, so people can try to see if it's stable. I really don't beleive
> > that I have such an unique hardware configuration, so this should benefit
> > other people.
>
> You can up it again at runtime.
I've lost some of mails about siimage on LKML, but Im' getting more and more 
confused about 'hangs' probably caused by siimage driver. I was using 15 
rqsize, now 128 - doesn't matter. It happens in random moments - sometimes at 
boot time when drive is fscked, sometimes when I'm trying to copy large 
amount of data and sometimes without any particular reason after several 
hours. I've updated MB (a7n8x deluxe rev 2.0) BIOS but controller (which is 
on-board) bios seems to be untouched (4.1.25 or so ). Is there any controller 
BIOS update which I could miss? what can be other reason? 
-- 
Witold Kręcicki (adasi) adasi [at] culm.net
GPG key: 7AE20871
http://www.culm.net

Re: SII SATA request size limit

[Adam Jones]

In a futile gesture against entropy, Witold Krecicki wrote:

> I've lost some of mails about siimage on LKML, but Im' getting more and more 
> confused about 'hangs' probably caused by siimage driver. I was using 15 
> rqsize, now 128 - doesn't matter. It happens in random moments - sometimes at 
> boot time when drive is fscked, sometimes when I'm trying to copy large 
> amount of data and sometimes without any particular reason after several 
> hours.

Out of interest, do you have some sort of SCSI controller in your
system as well?  I've got a SiI3112 card and I get a hard lock-up pretty
much as soon as anything touches the SCSI bus on my aic7xxx card.
Disabling DMA on the SiI IDE channel seems to work around it, at the
cost of a lot of performance... (this is on stock 2.4.22, BTW)

Setting rqsize to 128 seems perfectly stable for me - my drive reports
itself as a ST380013AS (Seagate Barracuda 7200.7 SATA 80GB).
-- 
Adam Jones (adam@yggdrasl.demon.co.uk)(http://www.yggdrasl.demon.co.uk/)
.oO("Ja voll, Herr General."                                           )
PGP public key: http://www.yggdrasl.demon.co.uk/pubkey.asc

Re: SII SATA request size limit

[Witold Krecicki]

Dnia pon 15. września 2003 12:12, Adam Jones napisał:
> In a futile gesture against entropy, Witold Krecicki wrote:
> > I've lost some of mails about siimage on LKML, but Im' getting more and
> > more confused about 'hangs' probably caused by siimage driver. I was
> > using 15 rqsize, now 128 - doesn't matter. It happens in random moments -
> > sometimes at boot time when drive is fscked, sometimes when I'm trying to
> > copy large amount of data and sometimes without any particular reason
> > after several hours.
>
> Out of interest, do you have some sort of SCSI controller in your
> system as well?  I've got a SiI3112 card and I get a hard lock-up pretty
> much as soon as anything touches the SCSI bus on my aic7xxx card.
> Disabling DMA on the SiI IDE channel seems to work around it, at the
> cost of a lot of performance... (this is on stock 2.4.22, BTW)
No, only on-board nForce2 IDE controller. Disabling ACPI helped. - now it's 
stable

> Setting rqsize to 128 seems perfectly stable for me - my drive reports
> itself as a ST380013AS (Seagate Barracuda 7200.7 SATA 80GB).
I use 128 too, and I've got 2xST3120026AS (Barracuda 7200.7 120GB) in software 
RAID0
-- 
Witold Kręcicki (adasi) adasi [at] culm.net
GPG key: 7AE20871
http://www.culm.net

Re: SII SATA request size limit

[Catalin BOIE]

> In recent kernels, the siimage driver limits the max kb per request size to 15
> (7.5kb). As I was having no problems with rqsize of 128 (64kb), I decided to
> comment out this part of the code and my system is rock solid.
>
> I'm not suggesting that it should be removed, as it probably is necessary on
> other systems, but as the performance impact is huge (with 15 hdparm tests
> show an average 26mb/s and with 128 it's 47mb/s), I think the user should be
> warnned of this and there could be a option to set it to 128 in 2.6.x
> kernels, so people can try to see if it's stable. I really don't beleive that
> I have such an unique hardware configuration, so this should benefit other
> people.

I'm using 256 or 128, I don't remember exactly with a sii3112. It is rock
solid.

>
> Marcelo Penna Guerra
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.2.3 (GNU/Linux)
>
> iD8DBQE/YTYjD/U0kdg4PFoRAhBnAJ0TyeJx5nrxzDS5Rib5AEWQHx4iSACeKcn8
> wg7cUhLobywfTCcPl8GqNCc=
> =VuVw
> -----END PGP SIGNATURE-----
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
>

---
Catalin(ux) BOIE
catab@deuroconsult.ro