-----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-----
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.
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
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)
-----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-----
-----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-----
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
-----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-----
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.
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
-----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-----
>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.
> 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 [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
---
Catalin(ux) BOIE
[email protected]
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
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 ([email protected])(http://www.yggdrasl.demon.co.uk/)
.oO("Ja voll, Herr General." )
PGP public key: http://www.yggdrasl.demon.co.uk/pubkey.asc
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 <[email protected]>
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
>
>
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
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
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
> 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.
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.
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
> > 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