SiI 3112 & Seagate drivers

SiI 3112 & Seagate drivers

[Kanniball]

Hi!
First off all excuse me for bugging you with this, but I can't accept paying 
for something that I only can use at 20% by the manufacter's fault.
So what I'm asking here is for help me to make pressure with the manufactures 
in order to get a good answer (fix).
For that I would like to have some tecnical details about the faults on both 
sides, Sata controller and disk drive.
I know other people with the same situation, so maybe we can all make 
pressure :)

Sorry for the nature of this mail, and let me know if I can't make public your 
answer.

Thanks for any inconvenience and for your attention.

Regards,

Paulo Fidalgo
-- 
Jabber ID: kanniball@jabber80.com

Re: SiI 3112 & Seagate drivers

[David Richards]

Im with you in spirit!!

Kanniball wrote:

>Hi!
>First off all excuse me for bugging you with this, but I can't accept paying 
>for something that I only can use at 20% by the manufacter's fault.
>So what I'm asking here is for help me to make pressure with the manufactures 
>in order to get a good answer (fix).
>For that I would like to have some tecnical details about the faults on both 
>sides, Sata controller and disk drive.
>I know other people with the same situation, so maybe we can all make 
>pressure :)
>
>Sorry for the nature of this mail, and let me know if I can't make public your 
>answer.
>
>Thanks for any inconvenience and for your attention.
>
>Regards,
>
>Paulo Fidalgo
>  
>

Re: SiI 3112 & Seagate drivers

[Kanniball]

Well let's see if we can get the tecnical info...
This is a very annoying problem... so please "devs" give us the info we need, 
and we'll try to do your best

Regards,

Paulo Fidalgo

On Sunday 13 March 2005 15:37, David Richards wrote:
> Im with you in spirit!
>
> Kanniball wrote:
> >Hi!
> >First off all excuse me for bugging you with this, but I can't accept
> > paying for something that I only can use at 20% by the manufacter's
> > fault. So what I'm asking here is for help me to make pressure with the
> > manufactures in order to get a good answer (fix).
> >For that I would like to have some tecnical details about the faults on
> > both sides, Sata controller and disk drive.
> >I know other people with the same situation, so maybe we can all make
> >pressure :)
> >
> >Sorry for the nature of this mail, and let me know if I can't make public
> > your answer.
> >
> >Thanks for any inconvenience and for your attention.
> >
> >Regards,
> >
> >Paulo Fidalgo

-- 
Jabber ID: kanniball@jabber80.com

Re: SiI 3112 & Seagate drivers

[Mark Hahn]

> First off all excuse me for bugging you with this, but I can't accept paying 
> for something that I only can use at 20% by the manufacter's fault.

you can't accept that vendors sometime ship broken products?
I admire your idealism.

> For that I would like to have some tecnical details about the faults on both 
> sides, Sata controller and disk drive.

some Seagate drives cannot handle >15 sector IO through some SiI controllers.
you could have found out that much by reading the (very clear) kernel code.
that's what I did.

you also could have spent a few minutes googling:
here's an old patch (which didn't seem to survive to enter Linus's kernel):
http://linux.derkeiler.com/Mailing-Lists/Kernel/2004-03/3481.html
http://linux.derkeiler.com/Mailing-Lists/Kernel/2004-03/3534.html

and something written in Hedrick-ese that seems to say that the 
current mod15 fix is kind of harsh:
http://linux.derkeiler.com/Mailing-Lists/Kernel/2003-12/5225.html
but maybe that's a different issue.

this implies that the problem is odd-sized packets:
http://www.thisishull.net/archive/index.php/t-23170.html
which might mean the hint about splitting makes sense.

do you really care, though?  a sata controller costs $20/channel.

Re: SiI 3112 & Seagate drivers

[Tejun Heo]

Kanniball wrote:
> Well let's see if we can get the tecnical info...
> This is a very annoying problem... so please "devs" give us the info we need, 
> and we'll try to do your best

  Hello, Kanniball.

  I've digged lkml previously and what I've found out are

  * It's basically because of faulty SATA implementation of the affected 
seagate hard drives combined with standard-compliant but peculiar 
behavior of silicon image controllers.

  SATA communicates using packets which is called FIS in SATA 
terminology.  When transferring data for read/write, the data can be 
tranferred splitted on multiple packets.  The standard doesn't limit 
where the data can be splitted, but most controllers split them on block 
  (512 byte) boundaries.  Unfortunately, siimage controller doesn't 
always split them on block boundaries and some (well, many) seagate 
drives depend on packets split on block boundary.  So, that's where 
everything goes wrong.

  * Data FIS maximum payload size is 8k, or 16 blocks.  And siimage 
controllers doesn't split packets on odd boundaries (maybe not at all) 
when data size is equal to or less than 15 blocks.  So, sata_sil driver 
sets max_sectors to 15, and the drive never gets to transfer more than 
one page at a time.  So, it's dog slow.

  * As the problem occurs only when writing data, we can improve read 
performance to normal level, but the current block/libata driver 
structure isn't structured to support separate limits on reads/writes 
and the developers don't wanna change it because of some faulty hardware.

  * I don't know how Windows drivers handle this but from the past 
posts, it seems that Windows driver also has the blacklist.  It would be 
nice if someone can verify siimage+seagate read/write performance on 
Windows.  And it would be even better if someone with SATA tracer would 
investigate how the gruesome-twosome act on Windows.

  * The cleanest way would be some form of firmware updates for either 
the siimage controller or seagate drives.  Unfortunately, this doesn't 
seem to be feasible; otherwise, they would have come up with it way back.

  * To top it all, both companies keep details regarding above buggy 
behavior under strict NDA and continue to sell faulty devices.  Way to 
go, Silicon images / Seagate. OTZ

  * It seems that IDE/libata developers contacted both companies in the 
past without any positive result, so I doubt they will act any 
differently this time.  But, my heart, too, is with you.

  Thanks.

-- 
tejun

Re: SiI 3112 & Seagate drivers

[Kanniball]

Thanks for your replay.
I've sent one email to my board manufacter, because my sata controller is part 
of my MB, and in the SI site they say that don't provide support for that 
class of products.
Because I already know their answer (oh linux... we don't provide support for 
this, please ask your disto vendor ) I'm figuring out other possibilites, 
like buy a new sata controller without any SI chip, another board, or maybe 
one upgrade if I can sell my actual hardware.
Now I've added Silicon Image and Seagate to my black list... (that's a great 
idea for a site, have a blacklist of hardware vendors)
I've found this site with some unofficial bios updates:
http://homepage.ntlworld.com/michael.mcclay/
wich includes updates on Sil 3112 sata controller.
So one good point was to have access to firmware's changelog (sata 
controller).

Thanks and I'll keep you informed of the board's answer.
Regards,
Paulo Fidalgo

On Monday 14 March 2005 09:21, Tejun Heo wrote:
> Kanniball wrote:
> > Well let's see if we can get the tecnical info...
> > This is a very annoying problem... so please "devs" give us the info we
> > need, and we'll try to do your best
>
>   Hello, Kanniball.
>
>   I've digged lkml previously and what I've found out are
>
>   * It's basically because of faulty SATA implementation of the affected
> seagate hard drives combined with standard-compliant but peculiar
> behavior of silicon image controllers.
>
>   SATA communicates using packets which is called FIS in SATA
> terminology.  When transferring data for read/write, the data can be
> tranferred splitted on multiple packets.  The standard doesn't limit
> where the data can be splitted, but most controllers split them on block
>   (512 byte) boundaries.  Unfortunately, siimage controller doesn't
> always split them on block boundaries and some (well, many) seagate
> drives depend on packets split on block boundary.  So, that's where
> everything goes wrong.
>
>   * Data FIS maximum payload size is 8k, or 16 blocks.  And siimage
> controllers doesn't split packets on odd boundaries (maybe not at all)
> when data size is equal to or less than 15 blocks.  So, sata_sil driver
> sets max_sectors to 15, and the drive never gets to transfer more than
> one page at a time.  So, it's dog slow.
>
>   * As the problem occurs only when writing data, we can improve read
> performance to normal level, but the current block/libata driver
> structure isn't structured to support separate limits on reads/writes
> and the developers don't wanna change it because of some faulty hardware.
>
>   * I don't know how Windows drivers handle this but from the past
> posts, it seems that Windows driver also has the blacklist.  It would be
> nice if someone can verify siimage+seagate read/write performance on
> Windows.  And it would be even better if someone with SATA tracer would
> investigate how the gruesome-twosome act on Windows.
>
>   * The cleanest way would be some form of firmware updates for either
> the siimage controller or seagate drives.  Unfortunately, this doesn't
> seem to be feasible; otherwise, they would have come up with it way back.
>
>   * To top it all, both companies keep details regarding above buggy
> behavior under strict NDA and continue to sell faulty devices.  Way to
> go, Silicon images / Seagate. OTZ
>
>   * It seems that IDE/libata developers contacted both companies in the
> past without any positive result, so I doubt they will act any
> differently this time.  But, my heart, too, is with you.
>
>   Thanks.

-- 
Jabber ID: kanniball@jabber80.com

Re: SiI 3112 & Seagate drivers

[David Richards]

Thank you much for breaking this down so well.

>
>  Hello, Kanniball.
>
>  I've digged lkml previously and what I've found out are
>
>  * It's basically because of faulty SATA implementation of the 
> affected seagate hard drives combined with standard-compliant but 
> peculiar behavior of silicon image controllers.
>
>  SATA communicates using packets which is called FIS in SATA 
> terminology.  When transferring data for read/write, the data can be 
> tranferred splitted on multiple packets.  The standard doesn't limit 
> where the data can be splitted, but most controllers split them on 
> block  (512 byte) boundaries.  Unfortunately, siimage controller 
> doesn't always split them on block boundaries and some (well, many) 
> seagate drives depend on packets split on block boundary.  So, that's 
> where everything goes wrong.
>
>  * Data FIS maximum payload size is 8k, or 16 blocks.  And siimage 
> controllers doesn't split packets on odd boundaries (maybe not at all) 
> when data size is equal to or less than 15 blocks.  So, sata_sil 
> driver sets max_sectors to 15, and the drive never gets to transfer 
> more than one page at a time.  So, it's dog slow.
>
>  * As the problem occurs only when writing data, we can improve read 
> performance to normal level, but the current block/libata driver 
> structure isn't structured to support separate limits on reads/writes 
> and the developers don't wanna change it because of some faulty hardware.
>
>  * I don't know how Windows drivers handle this but from the past 
> posts, it seems that Windows driver also has the blacklist.  It would 
> be nice if someone can verify siimage+seagate read/write performance 
> on Windows.  And it would be even better if someone with SATA tracer 
> would investigate how the gruesome-twosome act on Windows.
>
>  * The cleanest way would be some form of firmware updates for either 
> the siimage controller or seagate drives.  Unfortunately, this doesn't 
> seem to be feasible; otherwise, they would have come up with it way back.
>
>  * To top it all, both companies keep details regarding above buggy 
> behavior under strict NDA and continue to sell faulty devices.  Way to 
> go, Silicon images / Seagate. OTZ
>
>  * It seems that IDE/libata developers contacted both companies in the 
> past without any positive result, so I doubt they will act any 
> differently this time.  But, my heart, too, is with you.
>
>  Thanks.
>