# Problem with SATA sii3112 in kernel >=2.6.8

## luisfeser

Hello,

I have a SATA seagate 160Gb, and it is configured as scsi (/dev/sda) in a Abit AN7 mobo with sii3112 sata controller.

But with kernel 2.6.9-rc1-mm or nitro, i have this:

```
/dev/sda:

 Timing buffer-cache reads:   1660 MB in  2.00 seconds = 829.71 MB/sec

BLKFLSBUF failed: Operation not supported

HDIO_DRIVE_CMD(null) (wait for flush complete) failed: Operation not supported

 Timing buffered disk reads:   72 MB in  3.07 seconds =  23.44 MB/sec

BLKFLSBUF failed: Operation not supported

HDIO_DRIVE_CMD(null) (wait for flush complete) failed: Operation not supported
```

And with 2.6.8.1-nitro or ck6, i have this:

```
/dev/sda:

 Timing cached reads:   1640 MB in  2.00 seconds = 818.49 MB/sec

 Timing buffered disk reads:   70 MB in  3.09 seconds =  22.69 MB/sec
```

don't fails, but the result is bad too.

What's wrong???

Anybody with same kernel and driver can put the result of "hdparm -Tt /dev/sdX"??

----------

## luisfeser

Nobody knows?

----------

## luisfeser

Well, the problem began in 2.6.8 kernel and newer. In the changelog say:

 *Quote:*   

> <jgarzik@pobox.com>
> 
> 	[libata sata_sil] Re-fix mod15write bug
> 
> 	Certain early SATA drives have problems with write requests whose
> ...

 

And i think my seagate is in the blacklist  :Sad: 

Now i am with ide sil drivers:

```
/dev/hde:

 Timing cached reads:   1528 MB in  2.00 seconds = 762.97 MB/sec

 Timing buffered disk reads:  164 MB in  3.01 seconds =  54.40 MB/sec
```

----------

## tgnb

Hmm i think i have this same problem .. hdparm shows terrible performance with kernel's greater than 2.6.7 with my sata / sil / seagate combo.

But i have no HD related problems in 2.6.7 so what does this "fix" do for me other than slow down performance?

----------

## sir_tez

I second that, I too am I using sil3112 sata and that's not an acceptable "solution" for me.

----------

## sir_tez

Bumping and hoping for a fix.  Could more Sil 3112 users post here to keep the thread alive and be counted?

----------

## sir_tez

Say, if other folks who have silicon image 3112 sata controllers could post here and show some solidarity, that'd be awesome   :Cool: 

----------

## tauruswho

Hi All

I have had the same problem for some time with Sil3114 on my lanparty NF2 Ultra, but have used it as is, should I be worried. I did post a while back but was told it was to do with the driver, which seems to be the correct answer. Two sumsung 160G and WD 120G drives all give the same error.  Should I revert to to the IDE driver?

Is my data safe from coruption????????????

 :Rolling Eyes: 

----------

## sir_tez

Bump

----------

## Loke

This doesnt just apply to the SI3112 chipset and seagate disks, Ive got the SI3512 and Im experiencing the same using seagate disks also. I dont know if the hdparm results can be trusted really, because for every consecutive run of hdparm my "Timing buffered disk read" increases with about 15MB/s.

As another note, my system sure doesnt feel as slow as hdparm say it is.. Actually it feels quite snappy, but I would rather have this fixed of course.

----------

## El_Presidente_Pufferfish

my wd 250gb seems affected  :Sad: 

```
hdparm -Tt /dev/sda

/dev/sda:

 Timing cached reads:   1040 MB in  2.00 seconds = 519.30 MB/sec

BLKFLSBUF failed: Operation not supported

HDIO_DRIVE_CMD(null) (wait for flush complete) failed: Operation not supported

 Timing buffered disk reads:  146 MB in  3.01 seconds =  48.51 MB/sec

BLKFLSBUF failed: Operation not supported

HDIO_DRIVE_CMD(null) (wait for flush complete) failed: Operation not supported
```

----------

## Loke

I just timed the copying of a 1.7GB file from my /home partition to the / (root) partition , using:

 *gentoo-dev-source-2.6.9-r9 wrote:*   

> 
> 
> real    4m55.921s
> 
> user    0m0.003s
> ...

 

 *SimplyMepis 2.6.7 wrote:*   

> 
> 
> real    1m33.339s
> 
> user    0m0.008s
> ...

 

Both using the SI3512 chip and Seagate ST3160023AS, through the scsi sata_sil interface. The difference is so outstanding, I dont even bother testing anymore. If Im reading the LKML lists correctly, Jeff Garzek the libata guy, thinks this performance loss is acceptable, given the alternative of data corruption. More importantly, this wont get fixed in the future either because it involves quite alot of work!

Im gonna have a hard time talking someone with this chip into using linux, if 3x less HDD performance is what they have to accept. Do the libata guys even know how many MBs are out there with SI chips?

Personally, Im  :Shocked:  right now...

----------

## dsd

it is not the sil chips. it is the _combination) of one sil chip with one of a few models of seagate hard disk. every other disk is fine.

those seagate disks arent being produced any more, as far as i know.  personally i would try and get the disk swapped.

----------

## Loke

 *dsd wrote:*   

> it is not the sil chips. it is the _combination) of one sil chip with one of a few models of seagate hard disk. every other disk is fine.
> 
> those seagate disks arent being produced any more, as far as i know.  personally i would try and get the disk swapped.

 

Yes, I know. Ive been looking at the source for sata_sil.c right now, and it seems there are about 10 seagate disks affected. However, this bug should only apply to SiI3112 chips and those seagate disks blacklisted, according to Jeff Garzik. But the driver just maps the SiI3512 ID and treats it as a SiI3112 chip (which perhaps was just a hack to enable support for the 3512 very quickly..?)

So now Im wondering: Does this bug also affect the SiI3512?

----------

## El_Presidente_Pufferfish

Since the blacklist seems to only affect seagate drives( from looking at the source )

Anybody have a clue why my WD2500JD( 250GB sata ) has the same symptoms?

----------

## Zyne

using 2.6.9-nitro4, having the same issues...  :Smile: 

my hd:

```

Dec 17 08:32:14 blast Vendor: ATA       Model: Maxtor 6Y160M0    Rev: YAR5

Dec 17 08:32:14 blast Type:   Direct-Access                      ANSI SCSI revision: 05

```

I'm gonna try and switch back to 2.6.8.1-love sources...

let's hope it's better...

mobo is Asus A7N8X-deluxe with SIL3112 controller

output of hdparm -Tt /dev/sda

```

hdparm -Tt /dev/sda

/dev/sda:

 Timing cached reads:   1524 MB in  2.00 seconds = 761.35 MB/sec

BLKFLSBUF failed: Operation not supported

HDIO_DRIVE_CMD(null) (wait for flush complete) failed: Operation not supported

 Timing buffered disk reads:  172 MB in  3.02 seconds =  56.91 MB/sec

BLKFLSBUF failed: Operation not supported

HDIO_DRIVE_CMD(null) (wait for flush complete) failed: Operation not supported

```

----------

## dsd

that performance looks good. what is the problem?

----------

## tauruswho

Only seagate?????  I use Samsung spin point and a Western Digital, they both give the same errors, see previous post.  I am thinking of trying the ide driver, but does this use the same ata-lib???

Lan party ultra B Sil3114.....

Is it possible to patch the kernel with an older SATA driver?

----------

## Zyne

true... I gotta admit those results are looking pretty good...

However, take a look now, as I've done the test 3 times in a row:

```

# hdparm -tT /dev/sda

/dev/sda:

 Timing cached reads:   1020 MB in  2.00 seconds = 509.57 MB/sec

BLKFLSBUF failed: Operation not supported

HDIO_DRIVE_CMD(null) (wait for flush complete) failed: Operation not supported

 Timing buffered disk reads:  488 MB in  3.00 seconds = 162.42 MB/sec

BLKFLSBUF failed: Operation not supported

HDIO_DRIVE_CMD(null) (wait for flush complete) failed: Operation not supported

```

probably a hdparm bug, but iirc hdparm used to work great on my 2.6.8.1-love1 kernel...

----------

## hw-tph

My lightly patched vanilla 2.6.9 works great with Sil3112 and a Seagate disk. 

Just for sanity checking - do thesee patchsets you all use contain Garzik's CVS/bk libata updates? What about vanilla 2.6.9 - does that work for you?

Håkan

----------

## nic01

Hey

I have the same board and disk as zyne  *Quote:*   

> my hd:
> 
> Code:
> 
> Dec 17 08:32:14 blast Vendor: ATA       Model: Maxtor 6Y160M0    Rev: YAR5
> ...

 

except that I run raid 0 and 1 across two disks and 2.6.9-ck3 kernel. 

I get the same error when I test the 'raw' disk. 

```
/dev/sda:

 Timing cached reads:   1612 MB in  2.00 seconds = 804.51 MB/sec

BLKFLSBUF failed: Operation not supported

HDIO_DRIVE_CMD(null) (wait for flush complete) failed: Operation not supported

 Timing buffered disk reads:  420 MB in  3.03 seconds = 138.54 MB/sec

BLKFLSBUF failed: Operation not supported

HDIO_DRIVE_CMD(null) (wait for flush complete) failed: Operation not supported

```

 But when I access my md devices it doesn't complain:

```
/dev/md1:

 Timing cached reads:   1636 MB in  2.00 seconds = 817.31 MB/sec

 Timing buffered disk reads:  252 MB in  3.00 seconds =  83.87 MB/sec

```

Beside that the system runs fine, so I can't complain

/nic

----------

## Loke

Perhaps Im stating the obvious now, but the problem described in this thread is NOT one of the following:

- Various errors when running hdparm, like blahblahblah: Operation not permitted

- Timing buffered results seems to double for each consecutive run.

The problem in this thread is related to 10 something Seagate HDDs combined with the SiI3112 raid chipset, which result in 10-15 MB/sec buffered disk read due to an errata patch introduced to prevent data corruption. 

Unless you have one of these Seagate drives, the driver is working full speed - regardless of what hdparm says! So If you get buffered disk reads in the 45 - 60 MB/sec range, you are already operation at full speed and nothing needs to be done.

Seems quite a few people misunderstood this...

Edit: This means: El_Presidente_Pufferfish, Zyne and a couple of other people posting in this thread - you do NOT have a problem with your setup. The error messages shown in hdparm is a bug with hdparm, and not your driver setup.

----------

## tauruswho

Yes But!  These errors only started to happen with later kernels, my system was fine (hdparm as well) utill I upgraded to later kernels, I get the same errors as the first post, although my speed seems ok.

This also seems to be the same with Fedora, mandrake etc......but again only on the later kernels.  I don't think I have updated hdparm recently.

Anyway do you mean, hdparm only has a bug with later kernels, what should I do? just assume that hdparm is telling me porky pies and hope it is not a serious bug in SATA drivers. 

This sort of error message is not what linux needs to sway people to use it, as it has made me question my data safty........

----------

## Loke

 *tauruswho wrote:*   

> This sort of error message is not what linux needs to sway people to use it, as it has made me question my data safty........

 

Like I said, the "error" in this thread is transfer speeds of about 10 - 15 MB/sec. If you have any other sane number like 35 - 60 you are ok. Better yet just dmesg|grep errata yourself and see if you get a hit - if yes, the driver is operating in "safemode" and you are affected.

Everything else related to hdparm output - just ignore for now.

----------

## luisfeser

Hello all

The problem with silicon 3112 and my seagate is worth with 2.6.10  :Sad: 

Before, with IDE driver of silicon was working well, but now i get a "Timing buffered disk reads" around 20MB/sec

With scsi driver i get 22MB/sec, still a bad result.

maybe some tweak for hdparm for increase performance???

----------

## priestjim

The actual code in the 2.6.10 kernel that applies the mod15write workaround that is :

	/* limit requests to 15 sectors */

	if (quirks & SIL_QUIRK_MOD15WRITE) {

		printk(KERN_INFO "ata%u(%u): applying Seagate errata fix\n",

		       ap->id, dev->devno);

		ap->host->max_sectors = 15;

		ap->host->hostt->max_sectors = 15;

		dev->flags |= ATA_DFLAG_LOCK_SECTORS;

		return;

	}

So if your drive is not in that list *maybe* you can remove these lines. Haven't tried it yet but I will...

----------

## luisfeser

Yes, my HD in the black list:

 *Quote:*   

> } sil_blacklist [] = {
> 
>         { "ST320012AS",         SIL_QUIRK_MOD15WRITE },
> 
>         { "ST330013AS",         SIL_QUIRK_MOD15WRITE },
> ...

 

My drive:

 *Quote:*   

> ata1(0): applying Seagate errata fix
> 
> ata1: dev 0 configured for UDMA/100
> 
> scsi0 : sata_sil
> ...

 

Because of that i thought that some parameters for hdparm can help, but i don't know how to use it, and i don't want to damage my HD.

----------

## vandorp

Kernel: gentoo-dev-sources 2.6.10-r1

Asus a7n8x, using the onboard SiI 3112 controller.

2 disk drives (I re-shuffled dmesg a bit):

```

sata_sil version 0.8

SCSI device sda: 312581808 512-byte hdwr sectors (160042 MB)

SCSI device sda: drive cache: write back

  Vendor: ATA       Model: WDC WD1600JD-00G  Rev: 02.0

  Type:   Direct-Access                      ANSI SCSI revision: 05

SCSI device sdb: 240121728 512-byte hdwr sectors (122942 MB)

SCSI device sdb: drive cache: write back

  Vendor: ATA       Model: Maxtor 6Y120M0    Rev: YAR5

  Type:   Direct-Access                      ANSI SCSI revision: 05

```

And the timing results:

```

root@machine # hdparm -Tt /dev/sda

/dev/sda:

 Timing cached reads:   1824 MB in  2.00 seconds = 912.14 MB/sec

HDIO_DRIVE_CMD(null) (wait for flush complete) failed: Inappropriate ioctl for device

 Timing buffered disk reads:   74 MB in  3.04 seconds =  24.35 MB/sec

HDIO_DRIVE_CMD(null) (wait for flush complete) failed: Inappropriate ioctl for device

root@machine #  hdparm -Tt /dev/sdb

/dev/sdb:

 Timing cached reads:   1648 MB in  2.00 seconds = 823.30 MB/sec

HDIO_DRIVE_CMD(null) (wait for flush complete) failed: Inappropriate ioctl for device

 Timing buffered disk reads:  142 MB in  3.02 seconds =  46.95 MB/sec

HDIO_DRIVE_CMD(null) (wait for flush complete) failed: Inappropriate ioctl for device

```

After running the test for a number of times, I get:

```

root@machine # hdparm -Tt /dev/sda

/dev/sda:

 Timing cached reads:   1800 MB in  2.00 seconds = 899.69 MB/sec

HDIO_DRIVE_CMD(null) (wait for flush complete) failed: Inappropriate ioctl for device

 Timing buffered disk reads:  122 MB in  3.05 seconds =  40.03 MB/sec

HDIO_DRIVE_CMD(null) (wait for flush complete) failed: Inappropriate ioctl for device

root@machine # hdparm -Tt /dev/sdb

/dev/sdb:

 Timing cached reads:   1768 MB in  2.00 seconds = 883.69 MB/sec

HDIO_DRIVE_CMD(null) (wait for flush complete) failed: Inappropriate ioctl for device

 Timing buffered disk reads:  142 MB in  3.01 seconds =  47.21 MB/sec

HDIO_DRIVE_CMD(null) (wait for flush complete) failed: Inappropriate ioctl for device
```

Rather strange really, but the system runs fine so I'll keep it this way.

Edit: my drives do not appear in the blacklist (you'll find it in /usr/src/linux/drivers/scsi/sata_sil.c)Last edited by vandorp on Mon Jan 10, 2005 12:22 am; edited 1 time in total

----------

## DrWoland

I have a SIl3112 chip and a Seagate 120 GB SATA HD... Here's my output:

```

bash-2.05b# cat /proc/scsi/scsi

Attached devices:

Host: scsi0 Channel: 00 Id: 00 Lun: 00

  Vendor: ATA      Model: ST3120026AS      Rev: 3.05

  Type:   Direct-Access                    ANSI SCSI revision: 05

bash-2.05b# hdparm -Tt /dev/sda

/dev/sda:

 Timing cached reads:   1700 MB in  2.00 seconds = 849.70 MB/sec

BLKFLSBUF failed: Operation not supported

HDIO_DRIVE_CMD(null) (wait for flush complete) failed: Operation not supported

 Timing buffered disk reads:  166 MB in  3.00 seconds =  55.29 MB/sec

BLKFLSBUF failed: Operation not supported

HDIO_DRIVE_CMD(null) (wait for flush complete) failed: Operation not supported

```

I'm not even sure what any of this means, but should I be worried?

Edit: I'm clearly in the blacklist, but my performance still seems good compared to some of the results posted in here... Is there a patch for this or what?

Edit2:

Now that I've stopped XMMS, it's up to this:

```
bash-2.05b# hdparm -Tt /dev/sda

/dev/sda:

 Timing cached reads:   1856 MB in  2.00 seconds = 926.75 MB/sec

BLKFLSBUF failed: Operation not supported

HDIO_DRIVE_CMD(null) (wait for flush complete) failed: Operation not supported

 Timing buffered disk reads:  312 MB in  3.02 seconds = 103.40 MB/sec

BLKFLSBUF failed: Operation not supported

HDIO_DRIVE_CMD(null) (wait for flush complete) failed: Operation not supported

```

Final Edit: This does not appear to affect me, even though I am using a blacklisted drive. Good day.

----------

## Loke

 *priestjim wrote:*   

> The actual code in the 2.6.10 kernel that applies the mod15write workaround that is :
> 
>  /* limit requests to 15 sectors */
> 
>  if (quirks & SIL_QUIRK_MOD15WRITE) {
> ...

 

Easier to remove the disk id from the blacklist struct. But please remember, this errata "fix" is included for a reason...

----------

## irondog

But, why does my system work fast in Windows?

Why haven't I ever suffered from datacorruption?

Why is 2.6.10 the only affected kernel?

And why can't they just make that stupid Activity LED working..

----------

## mad man moon

My system is affected as well. I tried several different kernel version, but stay with development-sources-2.6.8.1, which is the last release to handle the drive "the old way". The speed is quite good with 55 MB/sec.

Tried ck-sources-2.6.9-r3, ck-sources-2.6.10-r4, gentoo-dev-sources-2.6.10-r4 and mm-sources-2.6.10-r2, but always got the same result, speed was at about 15 MB/sec.

I try to get a newer Seagate disk that is not affected, but will keep my ST3120026AS for storage and backup purpose.

----------

## tgnb

The problem is not the HD but the combination of those HD's with the specific chipset. I think for me the solution will simply be sata card.

----------

## DrWoland

So how can I get around this on 2.6.10-nitro4? Just edit that file? Has anyone tried this? Did your system die? I upgraded kernels and my speed went down from 50mb/sec to 15 - unacceptable. Anybody come up with a fix for this ye?

Edit: Also, what file do I need to edit?

----------

## El_Goretto

Another victim of this deadly combinaison: ST3160023AS and Silicon Image sata on ASUS card...

12Mo/s with hdparm...  :Crying or Very sad: 

----------

## LynZ

Here are my results on ABIT NF7-SL and sil3112

lynz@laller /smb/incoming $ sudo /sbin/hdparm -tT /dev/sdb

/dev/sdb:

 Timing cached reads:   1564 MB in  2.00 seconds = 781.73 MB/sec

HDIO_DRIVE_CMD(null) (wait for flush complete) failed: Inappropriate ioctl for device

 Timing buffered disk reads:  146 MB in  3.02 seconds =  48.27 MB/sec

HDIO_DRIVE_CMD(null) (wait for flush complete) failed: Inappropriate ioctl for device

The errors are ok since they come from scsi emulation. They just don't get common IDE commands.

If theese do not affect performance.

Mine is usually 57Mb/s (I have only 256 RAM at the moment and quite loaded system)

HDD - Samsung

----------

## LynZ

DrWoland wrote:

 *Quote:*   

> 
> 
> bash-2.05b# hdparm -Tt /dev/sda
> 
> /dev/sda:
> ...

 

You HDD is lying. Noone can get 100Mb/s on a single drive...

----------

## DrWoland

 *LynZ wrote:*   

> DrWoland wrote:
> 
>  *Quote:*   
> 
> bash-2.05b# hdparm -Tt /dev/sda
> ...

 

Yup, it's more like 50 now, that musta been a fluke.

----------

## El_Goretto

 *sir_tez wrote:*   

> Say, if other folks who have silicon image 3112 sata controllers could post here and show some solidarity, that'd be awesome  

 

In this case, I suggest that luisfeser change the title of this post, for highlighting the fact that all SATA Seagate HD owners are concerned by this problem.

So, if i switch back to IDE SATA Sil driver in kernel (rather than SCSI SATA), the fix isn't present, right? But the problem of possible data corruption should remain...  :Question: 

----------

## El_Goretto

I made a few search, and 've read this:

http://www.ussg.iu.edu/hypermail/linux/kernel/0406.2/1113.html

http://oss.sgi.com/archives/linux-xfs/2004-06/msg00247.html

So, it may indicate that after a certain version of the seagate FW, a particular model of Seagate HD isn't concerned by the "fix", or that some releases only of the SI3112 are concerned by the problem of data corruption.

Has anyone more info about this? Maybe it would be worth not only testing the HD model before applying the "fix".

Well, just for my culture, were can I find info about my Sil chipset under linux? For the SATA HD, its "cat /proc/scsi/scsi", but I wasn't able to find Sil info, even using dmesg (yes, i probably could read this during the PC boot, but ... that's for culture  :Smile: )

--

edit:

some new info:

Found in txt shipped with Sil drivers FROM SIL:

Limitations [of the module shipped]:

1. No ATAPI device support.

2. Don't support old Maxtor drive in UDMA 6 due to Maxtor's firmware bug.

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

4. Make sure open source driver for SiI SATA drives is disabled (3112 only)

It should confirm that only "old" 3112 chipset are concerned by data corruption when combined with Seagate HD... 

Hope I have a recent one... will see that tonight, arghh.

----------

## byrnerat101

Ok, I have an abot an7 mobo with an onboard sil3112 chipset. I want this drive for my main/boot hd on a desktop system. The hd I am looking at buying is the Seagate 120GB Barracuda 7200RPM SATA Model ST3120827AS. This hd is not on the blacklist, should it run well? Will i have data corruption? Can I even use a sata drive to boot? This is after my 1 year old maxtor drive just died, im looking for some stablity. Thanks.

----------

## Kanniball

there is a new patch to solve this problem

just check this: http://marc.theaimsgroup.com/?l=linux-kernel&m=111173514717575&w=4

I haven't tried yet... if someone do it please report to the mailing list as asked.

----------

## piewie

 *sir_tez wrote:*   

> Bumping and hoping for a fix.  Could more Sil 3112 users post here to keep the thread alive and be counted?

 

 *byrnerat101 wrote:*   

> The hd I am looking at buying is the Seagate 120GB Barracuda 7200RPM SATA Model ST3120827AS. This hd is not on the blacklist

 

On Abit NF7-S 2.0, 2.6.11-rc4-love1:

Model: ST3160827AS       Rev: 3.42:

```

 Timing cached reads:   1956 MB in  2.00 seconds = 977.66 MB/sec

HDIO_DRIVE_CMD(null) (wait for flush complete) failed: Inappropriate ioctl for device

 Timing buffered disk reads:  166 MB in  3.00 seconds =  55.25 MB/sec

HDIO_DRIVE_CMD(null) (wait for flush complete) failed: Inappropriate ioctl for device
```

Model: ST3200822AS       Rev: 3.01

```

/dev/sdb:

 Timing cached reads:   1920 MB in  2.00 seconds = 957.75 MB/sec

HDIO_DRIVE_CMD(null) (wait for flush complete) failed: Inappropriate ioctl for device

 Timing buffered disk reads:   64 MB in  3.02 seconds =  21.20 MB/sec

HDIO_DRIVE_CMD(null) (wait for flush complete) failed: Inappropriate ioctl for device
```

----------

## Kanniball

the latest --mm 2.6.12-rc1-mm4 patchset include this patch...

If somebody could give it a change the kernel dev's would apreciate... and if performs well, it will be included in mainline kernel.

----------

## piewie

No improved performance with 2.6.12-rc1-mm4 here on abit nf7-s with Seagate ST3200822AS Rev: 3.01  :Sad: 

----------

## El_Goretto

 *Kanniball wrote:*   

> the latest --mm 2.6.12-rc1-mm4 patchset include this patch...
> 
> If somebody could give it a change the kernel dev's would apreciate... and if performs well, it will be included in mainline kernel.

 

Thanks, i'll try this ASAP

```
scsi1 : sata_sil

  Vendor: ATA       Model: ST3160023AS       Rev: 3.18

  Type:   Direct-Access                      ANSI SCSI revision: 05
```

For the moment with 2.6.11-morph5 (i'll edit the results with mm-sources):

```
# hdparm -tT /dev/sda

/dev/sda:

 Timing cached reads:   1668 MB in  2.00 seconds = 832.88 MB/sec

HDIO_DRIVE_CMD(null) (wait for flush complete) failed: Inappropriate ioctl for device

 Timing buffered disk reads:   44 MB in  3.08 seconds =  14.28 MB/sec

HDIO_DRIVE_CMD(null) (wait for flush complete) failed: Inappropriate ioctl for device
```

----------

## DrWoland

Is it included in 2.6.12-rc2-mm3?

----------

## El_Goretto

Yes, it is in linux-2.6.12-rc2-mm3 as the regular version is 0.8 

```
libata version 1.10 loaded.

sata_sil version 0.9

...

ata1(0): applying Seagate errata fix
```

I still have the fix, and...

```
scsi1 : sata_sil

  Vendor: ATA       Model: ST3160023AS       Rev: 3.18

  Type:   Direct-Access                      ANSI SCSI revision: 05
```

```
/dev/sda:

 Timing cached reads:   1548 MB in  2.00 seconds = 773.34 MB/sec

 Timing buffered disk reads:   44 MB in  3.05 seconds =  14.44 MB/sec
```

My results are as poor as before  :Sad: 

----------

## I.C.Wiener

Hi,

I have been using my sil3112 and seagate drives for about 6 month now and had no problems until I upgraded from 2.6.8 to 2.6.11.

Thx to some previous posts it took me just a few min to figure out my drives were added to the blacklist. This so called "fix" for a

problem I can't even reproduce gotta be a joke! 15MB/sec on a drive that can do 60MB/sec are inacceptable!

So I spent a few hours copying large files around (using the "unfixed" driver) and checking md5sum's afterwards - nothing! No corrupted files, nor any errors in syslog.

I find this whole thing is very confusing. 

Some ppl say only few firmare/revisions are affected, but can't say which version(s) exactly. 

Then there are at least 2 patches out (both degrading perfomace to inacceptable levels). 

There are 3 different drivers: the (obsolete?) ata-driver, the scsi-sata-driver (the one I'm currently using) and some sort of closed-source driver provided by Silicon Image. 

And finally: Silicon Image released a new firmware that fixes "data-corruption on nforce-boards" in summer 2004.  It's only available through the mainboard manufacturer.

I decided to go for the bios-update first: I got the lastest version (released Jul. 2004) from the epox-website and ... yep, no floppy, no dos, no windows anymore - so how to install it? Well, it took me half a day to build a bootable cd with caldera dr-dos. 

I ran awdflash.exe, selected the new bios-file, pressed the "y"-key and ....... woooow, it crashed!!! 

I almost got a heart-attack when I had to press the reset-button while the "DO NOT POWER DOWN OR RESET"-msg was on the screen and I'll never ever touch this  !£$|*<?*%&-DOS crap again!

My pc rebooted normally with the old bios - guess I got lucky :)

However until someone provides some more information (controller firmaware, mainboards, hdd-firmware,... that are affected) I'll just remove my drives from the blacklist and stick with the good old fashioned, unfixed, unpatched driver. I'll let you know if something get's corrupted.

My Hardware:

- Epox 8RDA3+ (SIL3112A rev.02, Firmware: 4.2.12)

- 2x Seagate ST3200822AS

using the unfixed driver (gentoo-sources-2.6.8) dmesg gives me this (and no: I've never seen any errors in syslog regarding my sata-hdds):

```
 libata version 1.02 loaded.

sata_sil version 0.54

ACPI: PCI interrupt 0000:01:0c.0[A] -> GSI 16 (level, high) -> IRQ 16

ata1: SATA max UDMA/100 cmd 0xF9809080 ctl 0xF980908A bmdma 0xF9809000 irq 16

ata2: SATA max UDMA/100 cmd 0xF98090C0 ctl 0xF98090CA bmdma 0xF9809008 irq 16

ata1: dev 0 cfg 49:2f00 82:346b 83:7d01 84:4003 85:3469 86:3c01 87:4003 88:207f

ata1: dev 0 ATA, max UDMA/133, 390721968 sectors: lba48

ata1: dev 0 configured for UDMA/100

scsi0 : sata_sil

ata2: dev 0 cfg 49:2f00 82:346b 83:7d01 84:4003 85:3469 86:3c01 87:4003 88:207f

ata2: dev 0 ATA, max UDMA/133, 390721968 sectors: lba48

ata2: dev 0 configured for UDMA/100

scsi1 : sata_sil

Using anticipatory io scheduler

  Vendor: ATA       Model: ST3200822AS       Rev: 3.01

  Type:   Direct-Access                      ANSI SCSI revision: 05

  Vendor: ATA       Model: ST3200822AS       Rev: 3.01

  Type:   Direct-Access                      ANSI SCSI revision: 05

SCSI device sda: 390721968 512-byte hdwr sectors (200050 MB)

SCSI device sda: drive cache: write back

 /dev/scsi/host0/bus0/target0/lun0: p1 p2 p3

Attached scsi disk sda at scsi0, channel 0, id 0, lun 0

SCSI device sdb: 390721968 512-byte hdwr sectors (200050 MB)

SCSI device sdb: drive cache: write back

 /dev/scsi/host1/bus0/target0/lun0: p1

Attached scsi disk sdb at scsi1, channel 0, id 0, lun 0

```

----------

## fourteen20

I have a seagate drive in the blacklist 80 gb one, in a fit of madness i decided to remove the code pertaining to my drive,boot was ok till it got to mounting with read/write then locked up.

Rebooted with old kernel and found massive corruption on root partition so if you have these specs buy a new drive  :Crying or Very sad: 

seagate ST380023AS will update on firmware no. when i remove it  :Smile: 

siimage 3112 chipset 1.21 revision bios 4.2.50

Abit nf7-s v2

Anyway not too bad ordered a 200gb 7200.8 seagate for less than i bought the original drive  :Very Happy: 

----------

## piewie

ST3200822AS Rev: 3.01 200 GB removed from Blacklist seems to work stable for two days now on abit nf7-s 2.0 with d26 manta rays XT bios (SIL 3112ACT144, (1.21), 4.2.47 Bios).

Timing buffered disk reads:  182 MB in  3.02 seconds =  60.17 MB/secLast edited by piewie on Sun Apr 17, 2005 9:01 pm; edited 2 times in total

----------

## El_Goretto

 *fourteen20 wrote:*   

> I have a seagate drive in the blacklist 80 gb one, in a fit of madness i decided to remove the code pertaining to my drive,boot was ok till it got to mounting with read/write then locked up.
> 
> Rebooted with old kernel and found massive corruption on root partition so if you have these specs buy a new drive 
> 
> siimage 3112 chipset 1.21 revision bios 4.2.50
> ...

 

See a previous post (just in this page) of mine: 3112 chipset 1.21 revision and previous are really impacted by the fix, and it SHOULD not be removed.

----------

## El_Goretto

Could you people please post your chipset's revision version, with your chipset BIOS' version? Rev seems to be a much more important criteria to see if "defixing" the driver can be done without harm.

I opened my box today, and I 've seen a sad "1.21" on the Sil chipset...Last edited by El_Goretto on Fri Apr 22, 2005 11:00 am; edited 1 time in total

----------

## DrWoland

 *El_Goretto wrote:*   

> Could you people please post your chipset's revision version, with your chipset BIOS' version? It seems to be a much more important criteria to see if "defixing" the driver can be done without harm.
> 
> I opened my box today, and I 've seen a sad "1.21" on the Sil chipset...

 

I'll look in a bit.

----------

## Supaiku

So if I am understanding this correctly then if I own any of the drives from this black list.

ST320012AS 

ST330013AS 

ST340017AS 

ST360015AS 

ST380023AS 

ST3120023AS 

ST3160023AS 

ST3120026AS 

ST340014ASL 

ST360014ASL 

ST380011ASL 

ST3120022ASL 

ST3160021ASL

Then there is No fix for them and I must either replace them or live with the low performance?

----------

## fourteen20

only if you have siimage 1.21 rev chipset afaik

Btw i have my new seagate 7200.8 200gb

/dev/sda:

 Timing cached reads:   1824 MB in  2.00 seconds = 911.23 MB/sec

HDIO_DRIVE_CMD(null) (wait for flush complete) failed: Inappropriate ioctl for device

 Timing buffered disk reads:  196 MB in  3.00 seconds =  65.28 MB/sec

nice speedup quieter too:)

----------

## El_Goretto

 *El_Goretto wrote:*   

> Could you people please post your chipset's revision version, with your chipset BIOS' version? Rev seems to be a much more important criteria to see if "defixing" the driver can be done without harm.

 

Up

Think about it, Ladies & Gentlemen  :Smile: 

----------

## Loke

When importing large DV files from my camcorder, I got occational lockups when removing my drive from the struct. After enabling the 

"errata fix" I dont get these lockups anymore. Might be a coincidence though, but I think not...

----------

## DrWoland

 *DrWoland wrote:*   

>  *El_Goretto wrote:*   Could you people please post your chipset's revision version, with your chipset BIOS' version? It seems to be a much more important criteria to see if "defixing" the driver can be done without harm.
> 
> I opened my box today, and I 've seen a sad "1.21" on the Sil chipset... 
> 
> I'll look in a bit.

 

Crap, I'm 1.21.

----------

## LynZ

Man i guess these error are normal, i suppose they happen because hdparm tries to work with you scsi drive as with an ide one.

Seagate ST31....  series just seems shitty and unstable (not only in linux) have 2 samsungs - no problems so far 

ST32 should be okay too

my hdparms:

```

/dev/sdb:

 Timing cached reads:   1932 MB in  2.00 seconds = 965.66 MB/sec

HDIO_DRIVE_CMD(null) (wait for flush complete) failed: Inappropriate ioctl for device

 Timing buffered disk reads:  166 MB in  3.03 seconds =  54.72 MB/sec

HDIO_DRIVE_CMD(null) (wait for flush complete) failed: Inappropriate ioctl for device

```

Real Reiser 3.6 performance (copying between the hard drives gives an avg speed if 40Mb/s)

----------

## DrWoland

So if I were to buy a Sii card with the Revision 02 chip on it, I'd be fine?

----------

## LynZ

Well i guess it should... But i wouldnt buy the Sil external controller.... They're not acting as normal RAID devices.

I would give my voice for a 60-bucks Promise controller =).

I just have the built in one.

Just try not to use the Seagates ST31....

A friend just brought his one to me... 18Mbps in hdparm... Contrasting? =)

----------

## El_Goretto

 *DrWoland wrote:*   

> So if I were to buy a Sii card with the Revision 02 chip on it, I'd be fine?

 

Errr, I've an ASUS A7N8X-E deluxe with 3112A with a rev02 appearing somewhere in the windows driver panel... but still the number 1.21 on the chip. I dunno what to think about it... I haven't disk space enough to backup my data from seagate HD and try to unfix the driver...

----------

## Krischi

I have a Tyan Thunder K8W board, and am seeing the same problems with the Seagate 200 GB drive. I contacted Tyan's technical support and just received an e-mailed response stating that a BIOS update to the latest revision, which also includes an update for the SIL controller firmware, should fix the problems and make it safe to remove the drive from the blacklist. 

FWIW, BIOS updates are also supposed to help with some boards from other vendors. I am going to try flashing the BIOS tomorrow, and will post a followup in a few days.

----------

## DrWoland

 *El_Goretto wrote:*   

>  *DrWoland wrote:*   So if I were to buy a Sii card with the Revision 02 chip on it, I'd be fine? 
> 
> Errr, I've an ASUS A7N8X-E deluxe with 3112A with a rev02 appearing somewhere in the windows driver panel... but still the number 1.21 on the chip. I dunno what to think about it... I haven't disk space enough to backup my data from seagate HD and try to unfix the driver...

 

Well, I looked at a photo of the card and it says Rev 02 on the chip  :Confused:  Should I be OK?

----------

## qnx

Hi everybody, 

I have the same problem as you, but it's been a while since this thread has been active. So have you found any solution for this? My problem is described in this thread, just about my second post I realize that something is wrong with the performance. 

Are there any "non-open-source" drivers avalible from SIL, as somebody mentioned? Have you found a firmware upgrade for the hard drive from Seagate?

Also, how can I check my chipset revision version?

Cheers,

Jacob

----------

## El_Goretto

 *qnx wrote:*   

> Hi everybody, 
> 
> I have the same problem as you, but it's been a while since this thread has been active. So have you found any solution for this? My problem is described in this thread, just about my second post I realize that something is wrong with the performance. 
> 
> Are there any "non-open-source" drivers avalible from SIL, as somebody mentioned? Have you found a firmware upgrade for the hard drive from Seagate?
> ...

 

Please read the entire thread, many infos are already written here.

To sum up:

-yes

-no

-On the chip itself  :Smile: 

----------

## qnx

Hi, 

I have ST3200822AS firmware 3.01 on SiI 3112. Can't find the chipset version, and even if there's any printed on the mobo, I have still upgraded my BIOS a couple of times, so it may possibly (hopefully) have changed. My mobo is Abit NF7-S, the changelog for BIOS can be found here. 

In Windows I found a device string with some intressting info, like "VEN_1095 (must be SII) DEV_3112 SUBSYS_61121095 REV_02". Subsystem number says nothing two me, the rest is obvious. So, revision 2 of 3112 chipset.. Also, I can see "Current Transfer Mode: Ultra DMA Mode 6" and "Serial Link Speed: Generation 1 (1.5Gb/s)". ATA Version is "ATA/ATAPI-6", "Look Ahead" and "Write Cache" are both enabled. Looks just fine in Windows, as others already pointed out. They seem to solve this problem in some - better - way than our current libata. (Although I have not tested, it's possible that Windows is fast because it's "not careful" and may give corrupted data, however, others said they had no problem with this under Windows.)

Since I have everything on my PATA and thte SATA is just empty, I have a nice playground system. So I will try removing ST3200822AS from the blacklist, rebuild and then do some test for and look for corrupted data. What kind of tests would you suggest? I know nothing about testing harddrives...  :Smile: 

Also, the patch added in 2.6.12-rcX-mmX, is it something new you are talking about or is it the blacklist-thing which limits the speed. Cause if it was supposed to be a new patch with normal speed, then I can second that it's still working <20MB/s (according to both hdparm and real copying in mc). 

Using 2.6.12-rc2-love1, NF7-S v2 with bios 27 (latest). 

And yes, I have read the thread now, El_Goretto  :Wink: 

----------

## qnx

For us with Seagate's disk, there's this tool, SeaTools, may show something. Download, burn and boot with  SeaTools Desktop Edition ISO CD-ROM Image (v2.01.05). Cheers!

----------

## qnx

```
hdparm -tT /dev/sda

/dev/sda:

 Timing cached reads:   1380 MB in  2.00 seconds = 688.73 MB/sec

HDIO_DRIVE_CMD(null) (wait for flush complete) failed: Inappropriate ioctl for device

 Timing buffered disk reads:  182 MB in  3.02 seconds =  60.29 MB/sec

HDIO_DRIVE_CMD(null) (wait for flush complete) failed: Inappropriate ioctl for device

```

Now it looks better. How can I check if data I've copied isn't corrupt? The best would be to make a huge tarball, copy it a couple of times and then md5checksum, right?

Edit: Thougt I'd show my dmesg as well:

```
libata version 1.10 loaded.

sata_sil version 0.9

ACPI: PCI Interrupt Link [APC3] enabled at IRQ 18

ACPI: PCI Interrupt 0000:01:0b.0[A] -> Link [APC3] -> GSI 18 (level, high) -> IRQ 18

ata1: SATA max UDMA/100 cmd 0xE0814080 ctl 0xE081408A bmdma 0xE0814000 irq 18

ata2: SATA max UDMA/100 cmd 0xE08140C0 ctl 0xE08140CA bmdma 0xE0814008 irq 18

ata1: dev 0 cfg 49:2f00 82:346b 83:7d01 84:4003 85:3469 86:3c01 87:4003 88:007f

ata1: dev 0 ATA, max UDMA/133, 390721968 sectors: lba48

ata1: dev 0 configured for UDMA/100

scsi0 : sata_sil

ata2: no device found (phy stat 00000000)

scsi1 : sata_sil

  Vendor: ATA       Model: ST3200822AS       Rev: 3.01

  Type:   Direct-Access                      ANSI SCSI revision: 05

ACPI: No ACPI bus support for 0:0:0:0

SCSI device sda: 390721968 512-byte hdwr sectors (200050 MB)

SCSI device sda: drive cache: write back

SCSI device sda: 390721968 512-byte hdwr sectors (200050 MB)

SCSI device sda: drive cache: write back

 /dev/scsi/host0/bus0/target0/lun0: p1 p2 p3 < p5 p6 p7 >

Attached scsi disk sda at scsi0, channel 0, id 0, lun 0

Attached scsi generic sg0 at scsi0, channel 0, id 0, lun 0,  type 0

```

----------

## qnx

Just wondering, but is this this the same issue? If so, then our problems will be solved by BIOS upgrade.

(Currently coping over and out between my disk, to see what happens..I'll let you know soon.)

----------

## qnx

No I have run my tests. I started with copying/moving the file 4 times SATA->PATA and back. md5sum was the same. Then I did this test with time as well:

```
bash-2.05b# ls -l ring.tar.gz

-rw-r--r--  1 root root 3111593259 Apr 27 19:17 ring.tar.gz

bash-2.05b# time cp ./ring.tar.gz /mnt/suse/ring.tar.gz

real    1m32.982s

user    0m0.089s

sys     0m24.660s

bash-2.05b# rm ./ring.tar.gz

bash-2.05b# time cp /mnt/suse/ring.tar.gz .

real    1m38.670s

user    0m0.076s

sys     0m23.160s

bash-2.05b# rm /mnt/suse/ring.tar.gz

bash-2.05b# mv ./ring.tar.gz /mnt/suse/

bash-2.05b# time mv ./ring.tar.gz /mnt/suse/

real    3m7.175s

user    0m0.062s

sys     0m50.455s

bash-2.05b# time mv /mnt/suse/ring.tar.gz ./

real    1m40.120s

user    0m0.073s

sys     0m22.633s

bash-2.05b# time mv ./ring.tar.gz /mnt/suse/

real    1m35.570s

user    0m0.088s

sys     0m25.577s

bash-2.05b# time mv /mnt/suse/ring.tar.gz ./

real    1m39.455s

user    0m0.084s

sys     0m22.794s

bash-2.05b# md5sum ring.tar.gz

b12fdb2cb29a838de860af58b9505d84  ring.tar.gz

bash-2.05b# cat ring.md5

b12fdb2cb29a838de860af58b9505d84

```

The file lays on SATA orginally. I copy it to PATA. And back. And again. And back. And again. And back.  :Wink: 

All the results are pretty similar, except the second SATA->PATA. Dunno why, I haven't done anything, but the computer did, obviously  :Wink:  . 

ring.md5 is a file with checksum I created before I started copying. As you can see, it's the same as output after the last copy. Which means no data corruption  :Smile: 

Edit: Reiser4 on both partitions on both disks. Might be good to know...  :Smile: 

----------

## El_Goretto

->qnx

Thanks for ur job  :Smile: 

But in a pure theorical point of view, I would test in a different way (I wish I hadn't full drives  :Smile: ). As data length is supposed to have a role in data corruption, I would test the same way but using a full directory instead of the tarball, with full range sized files. MD5 is a good idea, I wouldn't have done it an other way  :Wink: .

And I wouldn't use reiser4, to not interfere with the test, but I suppose it won't raise problem in fact.

Well, maybe I would have scripted these operations, in order to really stress the disks, maybe 40-50 move operations, to have something really representative.

Concerning the issue, there is a mention on Sil website too, but I don't think it's the same problem (I believe I saw a problem solved by firmware/bios update, another one wich concerned windows drivers. I don't exactly remember, sorry).

About my own chip, I saw the " REV_02" sting in windows too, but the "1.21" on the die is making me hesistate...

----------

## qnx

But how about you, have you removed your disk from blacklist and tried using it at full speed? Data corruption?

After doing the test with 3Gb tarball, I even backed up my 40GB of "important data", and then checked (just basicly, by looking at the number of files, file sizes, etc), seems OK. Is there any other way of checking? I can't md5 a directory, can I?

The reason I did this with Reiser4 was to.. well, don't know how to put it. I just thought that "if it completes on reiser4 without any problems, then it *must* work with other, more stable FS as well"  :Wink: . (Although I know this issue has _nothing_ to do with filesystem choice; but on the other hand an unstable file system could also corrupt data and then I won't know if it was FS's or HDD's fault...anyway.)

If you give me a short script template (I've never been good at BASH) then I can try coping a whole dir a couple of times, just don't want to sit and do it manually 50 times  :Wink: 

Cheers!

----------

## Krischi

 *Krischi wrote:*   

> I have a Tyan Thunder K8W board, and am seeing the same problems with the Seagate 200 GB drive. I contacted Tyan's technical support and just received an e-mailed response stating that a BIOS update to the latest revision, [...] should fix the problems and make it safe to remove the drive from the blacklist. 

 

Update: I've flashed the BIOS to revision 2.04 (firmware revision 5.0.48 for the SIL3114) and removed the ST3200822AS drive from the blacklist. No data corruption problems so far, and hdparm reports the expected values:

```

chessboard root # hdparm -tT /dev/sda

/dev/sda:

 Timing cached reads:   4080 MB in  2.00 seconds = 2040.31 MB/sec

HDIO_DRIVE_CMD(null) (wait for flush complete) failed: Inappropriate ioctl for device

 Timing buffered disk reads:  186 MB in  3.03 seconds =  61.42 MB/sec

HDIO_DRIVE_CMD(null) (wait for flush complete) failed: Inappropriate ioctl for device

```

It looks as if it is definitely worth checking with the mainboard manufacturer whether there is a BIOS update with a new firmware revision for the SATA controller. In fact, Tyan says explicitly on the web site that the firmware update fixes Linux compatibility problems, whatever that means.

----------

## El_Goretto

 *qnx wrote:*   

> 
> 
> After doing the test with 3Gb tarball, I even backed up my 40GB of "important data", and then checked (just basicly, by looking at the number of files, file sizes, etc), seems OK. Is there any other way of checking? I can't md5 a directory, can I?

 Well I tought using par2cmdline tools (par2create and par2verify) too, which can work on mutliple files and is very fast (without creating repair blocks, just the small error detection file).

 *qnx wrote:*   

> 
> 
> The reason I did this with Reiser4 was to.. well, don't know how to put it. I just thought that "if it completes on reiser4 without any problems, then it *must* work with other, more stable FS as well" . 
> 
> 

  Totaly agree  :Smile: 

 *qnx wrote:*   

> 
> 
> If you give me a short script template (I've never been good at BASH) then I can try coping a whole dir a couple of times, just don't want to sit and do it manually 50 times 
> 
> 

 Errr, me neither, but a simple "for" would do it:

```
#!/bin/sh

for i in `seq 1 50`

do

  your command list

done
```

-> Krischi:

errr, I don't know for Tyan, but SIL3114 isn't reported to be a problem for libata, just 3112 (and so I think it's unfair concerned by the "fix", it could be a simple chip detection problem, see early posts in the thread). No mention of "SIL3114 bugfix" in Sil own driver though.

----------

## Krischi

 *Quote:*   

> 
> 
> -> Krischi:
> 
> errr, I don't know for Tyan, but SIL3114 isn't reported to be a problem for libata, just 3112 (and so I think it's unfair concerned by the "fix", it could be a simple chip detection problem, see early posts in the thread). No mention of "SIL3114 bugfix" in Sil own driver though.

 

This page seems to indicate that it is both a 3112 and 3114 problem. Furthermore, why would Tyan report about Linux compatibility problems on their BIOS support page, if there were not something? Right now, no one seems to know for sure which combinations exactly are affected, so some data points are a good thing. Also, if you search on Google, you will turn up other hits for BIOS updates, including, I think, the 3112.

----------

## El_Goretto

What I tried to explain, is that what you are talking about is another problem that what is discussed here. (See the topic: 3112, not 3114). And according to what I've read on many sites, a BIOS update for 3112 won't fix the problem I'm talking about., it seems to be a revision matter: see Sil documentation. Moreover, if Tyan sais your 3114 is solved with actual BIOS releases, well, you lucky  :Smile: 

Conclusion: we are talking here about a 3112 specific problem that is not solved by BIOS update (thanks correcting me if you can prove the opposite).

----------

## I.C.Wiener

 *El_Goretto wrote:*   

> Conclusion: we are talking here about a 3112 specific problem that is not solved by BIOS update (thanks correcting me if you can prove the opposite).

 

How can you be sure? Actually Silicon Image released a bios-update for the 3112 that fixes some sort of data-corruption - might be exactly what we're looking for. 

However so far I haven't seen anyone who is really affected. And as long as there is no test to verify wether one is affected or not, we won't make any progress here. I guess there won't be any errors in syslog and not every file gets corrupted,  so there's no way to be sure.

Perhaps someone could generate a file (and md5sum) that gets corrupted when being copied around on affected systems. That would make testing of bios/firmware revisions easy.

----------

## El_Goretto

 *I.C.Wiener wrote:*   

>  *El_Goretto wrote:*   Conclusion: we are talking here about a 3112 specific problem that is not solved by BIOS update (thanks correcting me if you can prove the opposite). 
> 
> How can you be sure? Actually Silicon Image released a bios-update for the 3112 that fixes some sort of data-corruption - might be exactly what we're looking for. 

 

Maybe. I just read the Sil driver Changelog, and there is no mention of BIOS version in it. Only Chipset Revision (which implies a minimal BIOS version, I agree).

 *I.C.Wiener wrote:*   

> However so far I haven't seen anyone who is really affected. And as long as there is no test to verify wether one is affected or not, we won't make any progress here. I guess there won't be any errors in syslog and not every file gets corrupted,  so there's no way to be sure.

 

Right. 

 *I.C.Wiener wrote:*   

> Perhaps someone could generate a file (and md5sum) that gets corrupted when being copied around on affected systems. That would make testing of bios/firmware revisions easy.

 

qnx is excactly testing his system that way (see below), but for me, as long as I haven't sufficient space on another drive to move my data, testing my BIOS/Seagate firmware/3112 revision configuration isn't possible.

----------

## qnx

 *El_Goretto wrote:*   

> 
> 
>  *I.C.Wiener wrote:*   Perhaps someone could generate a file (and md5sum) that gets corrupted when being copied around on affected systems. That would make testing of bios/firmware revisions easy. 
> 
> qnx is excactly testing his system that way (see below), but for me, as long as I haven't sufficient space on another drive to move my data, testing my BIOS/Seagate firmware/3112 revision configuration isn't possible.

 

What I think I.C.Wiener is talking about is genereting a file that gets corrupted *for sure* when copied on affected combinations of drive/chipset. Something that could be used for testing, a file that is designed to *get* corrupted. I have no idea how such a file should look but there are surely others with better insight into this technical issue who might know how such a file should look like. But, on the other hand: if they'd have known how to make a generic testing file, why haven't they done it so far? Maybe impossible..?

However, as El_Goretto says, I've copied around a couple of files a couple of times after upgrading my BIOS and having modified my kernel. Take a look above in this thread.  :Smile: 

----------

## qnx

Hi everybody, 

have anybody tried the mod15write workaround by TeJun Heo yet? I did today and it looks amazing! Check out if affected by this "dog slow" Seagate SATA disks. Also take a look at the two posts of me over here where I wrote something more about my experience. 

Cheers!

----------

## El_Goretto

Cool.

Is it the "new fix" that is supposed to be in 0.9 SATA driver or a new one?

----------

## qnx

I have had sata_sil 0.9 all the time I was writing in this thread since I was using 2.6.12-rc2-love1 than and rc4-love1 now. No "new fix" in there however, had to patch myself as I said. Try out you too!  :Smile: 

----------

## I.C.Wiener

I know, besides that equally crappy 0.9 fix there is another unofficial fix which has at least good reading performance. 

But as far as I know writing was'n any better ( <20MB/sec). Also when I heard about it 2 or 3 weeks ago, it wasn't tested properly. 

So even if your hardware is actually not affected by this mysterious hardware bug you might get your data scrambled by some buggy pice of software. The more patched you try the higher the chance to get your data messed up.

Btw: I'm still using good old 2.6.8 gentoo-sources, as I can't get my webcam running on newer kernels (yet). sata_sil is completly "unfixed", performance is awesome and still there is no data-corruption.

----------

## El_Goretto

 *I.C.Wiener wrote:*   

> I know, besides that equally crappy 0.9 fix there is another unofficial fix which has at least good reading performance. 
> 
> But as far as I know writing was'n any better ( <20MB/sec). Also when I heard about it 2 or 3 weeks ago, it wasn't tested properly. 

 

This is exactly what qnx is talking about. For my personnal use (data storage) this patch would perfect fit.

 *I.C.Wiener wrote:*   

> So even if your hardware is actually not affected by this mysterious hardware bug you might get your data scrambled by some buggy pice of software. The more patched you try the higher the chance to get your data messed up.

 

Right, but... The patch is only activated by the detection of "a priori" concerned hardware. So no problem there. Moreover, the original fix intend to prevent "rumored" (do you prefer "not yet end-user constated"?) data corruption.

----------

## DrWoland

I'm just gonna go get a Promise TX2 :\

----------

## I.C.Wiener

I just read some more documentation about this issue and...  arrrgs, this whole thing is really starting to piss me off!

I'm getting tired of running to the shop every two month to replace brand new hardware just because of faulty/nonexistent driver-support under linux.

As some ppl mentioned before, the sil-chip is acting somehow strange but inside sata-specifications. So why the hell should I buy a new Controller if it's the hdd that's broken?  What's about that 5year warranty Seagate offered when I bought my hdd?! 

I'll check that out first. At least they would have to give me an answer whether my two disks are faulty or not, wouldn't they?!

----------

## I.C.Wiener

ok, that was quite pointless. Sometimes I wonder why companies offer email-support if they don't even read their customer's questions but just copy'n paste some parts of their faq.

However, I skipped those parts involving a windows-driver-update, but tried out those seatools someone mentioned before:

- controller check was skipped as it is not supported

- filsystem checks were skipped because I don't have any fat/ntfs partitions

- everything else completed without errors

Would be nice to see the results on systems that actually experienced data-corruption (if there are any).

----------

## qnx

Pretty useless, in other words.. I'm not sure how seatools works but they'd certainly inform if they'd be about to copy ??Gb, cause the users may not have those free Gb's needed on the drive. So how the h... are they gonna check for data corruption else? Sending 2Mb's a time to the disk's cache?! Yeah right...

----------

## jonnevers

 *qnx wrote:*   

> Pretty useless, in other words.. I'm not sure how seatools works but they'd certainly inform if they'd be about to copy ??Gb, cause the users may not have those free Gb's needed on the drive. So how the h... are they gonna check for data corruption else? Sending 2Mb's a time to the disk's cache?! Yeah right...

 

strange, I have almost the exact same system specs as you:

```
blue root # hdparm -Tt /dev/sda

/dev/sda:

 Timing cached reads:   1388 MB in  2.00 seconds = 693.07 MB/sec

HDIO_DRIVE_CMD(null) (wait for flush complete) failed: Inappropriate ioctl for d

evice

 Timing buffered disk reads:  166 MB in  3.01 seconds =  55.12 MB/sec

HDIO_DRIVE_CMD(null) (wait for flush complete) failed: Inappropriate ioctl for device

```

I haven't noticed any problem with the data i've put on the drive. Then again I only ran the above test because I happened upon this thread.

- Jon

----------

## qnx

Which kernel version?

----------

## jonnevers

 *qnx wrote:*   

> Which kernel version?

 

Linux blue 2.6.12-rc3-love1 #1 Tue May 10 11:16:25 EDT 2005 i686 AMD Athlon(tm)  AuthenticAMD GNU/Linux

Abit NFS-2 with sil3112 for SATA 

```
root #$ cat /proc/scsi/scsi

Attached devices:

Host: scsi0 Channel: 00 Id: 00 Lun: 00

  Vendor: ATA      Model: Maxtor 6Y120M0   Rev: YAR5

  Type:   Direct-Access                    ANSI SCSI revision: 05

```

----------

## I.C.Wiener

@jonnevers: You don't have a problem, your drive is not on the blacklist.

@qnx: there is actually a test to check communication between the disk and the controller - sounds pretty much like what we were looking for. Unfortunately just the sil3112 issn't supported, what a surprise...

And remember we don't need to copy several GB of data, we just need to send a block of 16kb the wrong way and it get's corrupted.

On the other hand, who cares if there is data on the disk? You can just read some raw-data (whatever filesystem), save it in ram, write some 1s and 0s and finally restore the original data. Or how would you check for bad sectors? Of course restoring the data might fail, but if that happens the user has other things to worry about :P

----------

## qnx

You're right, I.C. Wiener. As you said that, it seems pretty easy for anyone to check for corruption. Can you see any way for, let's say me, to do this test? We were previously talking about generating a file that *should* get corrupted on affected systems, etc. but nothing was actually done. Sending a couple of KBs sounds easy, maybe some C-code or something would do?

----------

## I.C.Wiener

Hmm, seems we had the same thought at the same time qnx, I actually wrote a little C program just an hour ago...

```

 * 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.

```

I thought it would be simple to write some huge arrays of junk-data to a file (in the pattern specified above), read from the file and compare it's content, but it turned out to be not that trivial.

Although the sil-chip hasn't any memory attached, the data I'm writing gotta be cached somewhere. Every few sec. there was a burst-write of a few MB and I guess it didn't even read from disk but kept the file in ram. It seems almost impossible to write data in a special pattern if the driver collects data half the day and writes it a few hours later. Any Ideas? 

Is there a way to set cache-mode to write-through instead of write-back?

ps: this is not a matter of filesize. Bigger files just cause heavy cpu-load (and also disk-load) but the data is buffered and written in huge blocks (btw. amazing speed, 83MB/sec.). And unless I generate files larger than 1GB, I think I'll always get a clean copy which was kept in ram.

----------

## qnx

Oh, cool  :Wink: 

Ok, let's see.. There's no possibility of using dd for this than, is it? Cause it is the OS itself that causes cacheing? 

I think you can disable write-back in BIOS, though I'm not sure, but check that. 

And what about generating files larger than your RAM? I have just 512Mb for example, so the file won't be abnormally big. 

Btw, I have already copied some of such files (have ripped some of my movies to xvid), and they end up at 700-800 Mb usualy. When I did some testing, some time ago, I copied that backup partition to the new SATA drive and back, about 10 times and checked then some of the movies with md5. Nothing happend. 

Still it would be nice with a general testing program, so if you want to send me a link or e-mail the source!  :Smile: 

Cheers!

----------

## qnx

Btw, it seems like you (I.C.Wiener) know more about your system setup than I do about mine. What I've figured out is that I have 3112 and my disk of course. But no idea about the revision or firmware, where did you get that? 

Here's what my chipset says:

```

SiL 3112ACT114

Q23144.1

0252

1.21

```

Any idea what those number represent?

I tried a couple of times to get a corruption, and you must be trying harder since both your disks are SATA..right?  :Wink:  Neither of us "succeeded" still. Both of us have upgraded the BIOS to latest version avalible. (I was trying to find a changelog of the SATA BIOS, but couldn't. All I can see is that my MoBo BIOS has the 4.2.5.0 version of that SATA BIOS-thing..)

I'm trying to find out if we really are affected by this, which version/revision of chipset it is about, etc. Still, with the latest fix I don't see any performance decrease, so I'm happy as it is now =)

----------

## I.C.Wiener

First, that program I wrote is useless, as the OS buffers the data before writing and thus writes it in a different pattern. I would have to run it on a stupid OS like DOS for example and use the old Int13-method to write data. But uhh, I'm too lazy to get a compiler, create a boot disc, delete one of my ext3 partitions to get some space for DOS,...

you can get your drives firmware revision and some other information with dmesg:

```

libata version 1.02 loaded.

sata_sil version 0.54

ACPI: PCI interrupt 0000:01:0c.0[A] -> GSI 16 (level, high) -> IRQ 16

ata1: SATA max UDMA/100 cmd 0xF9809080 ctl 0xF980908A bmdma 0xF9809000 irq 16

ata2: SATA max UDMA/100 cmd 0xF98090C0 ctl 0xF98090CA bmdma 0xF9809008 irq 16

ata1: dev 0 cfg 49:2f00 82:346b 83:7d01 84:4003 85:3469 86:3c01 87:4003 88:207f

ata1: dev 0 ATA, max UDMA/133, 390721968 sectors: lba48

ata1: dev 0 configured for UDMA/100

scsi0 : sata_sil

ata2: dev 0 cfg 49:2f00 82:346b 83:7d01 84:4003 85:3469 86:3c01 87:4003 88:207f

ata2: dev 0 ATA, max UDMA/133, 390721968 sectors: lba48

ata2: dev 0 configured for UDMA/100

scsi1 : sata_sil

Using anticipatory io scheduler

  Vendor: ATA       Model: ST3200822AS       Rev: 3.01

  Type:   Direct-Access                      ANSI SCSI revision: 05

  Vendor: ATA       Model: ST3200822AS       Rev: 3.01

  Type:   Direct-Access                      ANSI SCSI revision: 05

SCSI device sda: 390721968 512-byte hdwr sectors (200050 MB)

SCSI device sda: drive cache: write back

 /dev/scsi/host0/bus0/target0/lun0: p1 p2 p3

Attached scsi disk sda at scsi0, channel 0, id 0, lun 0

SCSI device sdb: 390721968 512-byte hdwr sectors (200050 MB)

SCSI device sdb: drive cache: write back

 /dev/scsi/host1/bus0/target0/lun0: p1

Attached scsi disk sdb at scsi1, channel 0, id 0, lun 0

```

To get the controller's rev. I just looked inside :P

My mainboard bios is from 2003, I tried to update, but my PC crashed during flashing.

And yes I copied some large amounts of data between my 2 discs and checked md5sums - no corruption.

However when copying data between the 2 discs performance on the sil sucks anyway. I can't get more than 30MB/sec (without any fix applied). Some windows user's complained about this behaviour, too.

Read-performance should not be affected by recent fixes, but I think write-performance issn't any better yet, is it?

----------

## mcfly.587

Same for mee : 

```
bash-2.05b# hdparm -t /dev/hde

/dev/hde:

 Timing buffered disk reads:   52 MB in  3.11 seconds =  16.70 MB/sec

bash-2.05b# hdparm -c1d1X69 /dev/hde

/dev/hde:

 setting 32-bit IO_support flag to 1

 setting using_dma to 1 (on)

 setting xfermode to 69 (UltraDMA mode5)

 IO_support   =  1 (32-bit)

 using_dma    =  1 (on)

bash-2.05b# hdparm -t /dev/hde

/dev/hde:

 Timing buffered disk reads:   50 MB in  3.00 seconds =  16.65 MB/sec
```

2* Sata Seagate ST3120026AS   120 go

Same controler with my other disk ( 2* raptors 36 go ) :

```
bash-2.05b# hdparm -t /dev/hdi

/dev/hdi:

 Timing buffered disk reads:  188 MB in  3.02 seconds =  62.26 MB/sec

```

 :Sad:   :Crying or Very sad:     no solution at this moment ?

My kernel config :

[*]     Support for SATA (deprecated; conflicts with libata SATA driver)

<*>         Silicon Image chipset support 

Revision of controler : 4.2.12 i think ...

----------

## El_Goretto

 *mcfly.587 wrote:*   

> Revision of controler : 4.2.12 i think ...

 

Mmmm no, that's the firmware version.  :Wink: 

Chip revision is ~1.21 (has someone ever seen a rev > 1.21?)

----------

## mcfly.587

ahhhhhhhhhhhh ok i don't know my chipset version  :Sad: 

Its very strange only seagate has this problem ?

----------

## I.C.Wiener

mcfly.587: you're using the ancient ata-based driver. This thread is about the new sata-driver in scsi-support.

Your transfer-rates look fine, but I think you may consider that driver "unfixed" as well, so data-corruption might occur. I think it's no longer maintained, so probably it probably will never get fixed.

Btw. I just spend 30Euro on ebay for a Promise SataII TX4. 

I'll do some benchmarking (sil3112 vs. TX4) when it arrives and let you guys know if there is maybe an other reason for a change than "just" data security. If xmms wouldn't get interrupted by an "emerge sync" would be a huge advantage for example...

----------

## I.C.Wiener

Ok, I installed my new Promise SataII TX4 last weekend.

It works, but has other issues:

1. my disks got swapped: /dev/sda became /dev/sdb and /dev/sdb became /dev/sda

    Never mind? Why not just attach them to each other's channel? 

    Because grub detects them in the opposite order - funny, isn't it?

2. The bios displays detected disks and that's it - you can't configure anything!

    So the bootloader has to be located on the first disk otherwise your system won't boot.

3. Once my pc crashed because for some reason my disks became inaccessable. So far this happend only

    once and there was nothing in syslog but it scares me anyway.

Performce doesn't differ from the Sil3112, except when you're copying data between two disks (both attached to the same controller).

The TX4 achives 46MB/sec while the Sil doesn't get faster than 32MB/sec - results may vary depending on your disks and CPU,...  but

I think it's save to say the Promise is faster. When using the Sil3112 I was often annoyed by xmms getting interrupted by other processes causing heavy disk activity like 'slocate' or 'emerge sync' - till now this didn't happen with the TX4. (and no, can't be because of TCQ/NCQ as my disks do not support this feature)

----------

## El_Goretto

Has someone succeded in booting a 2.6.12 kernel? With the r6 of gentoo or morph sources, I've a sudden kernel panic just when the message "applying Seagate errata fix" appears...

These 2.6.12 are supposed to have a updated libata, aren't they?

----------

## dsd

a new patch is under development which only applies the quirk causing the slowdown to the controllers which suffer from the "bug".

these controllers are the SII 3112's with a revision number of 1.21 or less.

if you have a 3112 with a revision greater than 1.21 or a sata_sil controller which isnt a 3112 then please post the "lspci" and "lspci -n" outputs here. (the 3114, 3124, and 3152 are already taken care of in the patch but it cant hurt to check that there aren't more id's).

----------

## El_Goretto

Well, as I previously said, on my chip it reads 1.21, but the linux and xp drivers report a mysterious "rev 02", that's why i still post the lspci output...

```
0000:01:0b.0 RAID bus controller: Silicon Image, Inc. (formerly CMD Technology Inc) SiI 3112 [SATALink/SATARaid] Serial ATA Controller (rev 02)

0000:01:0b.0 Class 0104: 1095:3112 (rev 02)
```

I don't know if this can help.

----------

## dsd

nope, that number refers to something else. to clarify, the revision i am referring to is the one printed on the chip. i don't know if it can be obtained through software or anything like that...

----------

## I.C.Wiener

Think it's time for a small update:

I'd been using the 3112 (rev. 1.21) for more than 8 month. I never applied any of those so called "fixes" enjoyed the great performce and had no trouble at all.

However the massive lack of information and the fact that I always had to edit my kernel sources to remove those "fixes" not knowing if some day my data could get scrambled I decided to buy a Promise TX4 SataII 4 month ago. Guess what, sine then I had trouble with my data! There is so much going wrong I think I'll just pull it out and use my good old Sil3112 again.

As I wrote before, the Promise is swapping my hdds (sda becomes sdb and twice versa during boot). Well I edited my config files accordingly. But what really bothers me is that sometimes (once or twice a week) the system locks up because the discs can no longer be accessed. And today I got my first messed up ext3 partition:

```

...

Sep  9 23:02:18 [kernel] attempt to access beyond end of device

                - Last output repeated 9 times -

Sep  9 23:03:38 [kernel] sdb3: rw=0, want=2351474328, limit=373302405

Sep  9 23:03:38 [kernel] attempt to access beyond end of device

Sep  9 23:03:38 [kernel] sdb3: rw=0, want=2351474328, limit=373302405

Sep  9 23:03:38 [kernel] attempt to access beyond end of device

...

Sep  9 23:09:46 [kernel] EXT3-fs error (device sdb3): ext3_free_blocks: Freeing blocks not in datazone - block = 2883469219, count = 1

Sep  9 23:09:46 [kernel] EXT3-fs error (device sdb3): ext3_free_blocks: Freeing blocks not in datazone - block = 2542566746, count = 1

Sep  9 23:09:46 [kernel] EXT3-fs error (device sdb3): ext3_free_blocks: Freeing blocks not in datazone - block = 3015062917, count = 1

Sep  9 23:09:46 [kernel] EXT3-fs error (device sdb3): ext3_free_blocks: Freeing blocks not in datazone - block = 884852724, count = 1

...

```

fsck even asked me to fix things (and not just once, I finally gave up pressing 'y' and had to run it with '-y'). So far fsck never asked me anything! If I find my old gentoo-live-cd (the one that's using the old sata-driver) I'll check if there's anything in the hdd's smart-log and let you know.

So unless you're gonna buy something really expensive (like one of those 3ware-controllers) I assume it's better to stick with the SIL.

----------

## piewie

Here also no problems with 1.21. Removed my Seagate Model: ST3200822AS Rev: 3.01 from the black list in the kernel about five months ago. There was no unusual behaviour.

----------

## qnx

Hello everybody, again!

Sad about your problem I.C.Wiener.. hope you can fix it someway!

But what I don't understead is why can't they (the libata-guys) put  this nice patch into the tree!! OK, one thing is that it can't be applied to the latest kernel anymore. I've been using it with 2.6.12-rc6-love1 for more than 2 months and it's been working completly wonderful. But now when I wanted to updated my kernel to kernel-2.6.13-archck7, I couldn't apply the patch anymore  :Sad: 

On the other hand, I'm not very good at using patch, so that might be the problem, but if somebody with greater skills (like maintainers of libata) would have done it, than it'd surely work. 

Why do we have to apply the patch manually by ourselves? Why can't they put it into libata-dev at least?   :Confused: 

/Jacob

----------

## eNTi

i do have a similar problem with one of my seagate drives, but it's connected to a Promise SATA150 TX2+ controller and my performance loss is incredible. even my cpu goes up to 100% when copying a file on that disk or over my gigabit lan. i'm thinking of throwing the disk in the garbage, but maybe there's some hope. i'll try to connect the disk to my onboard via controller and put the maxtor on the promise controller. here are some of my specs:

```

libata version 1.20 loaded.

sata_via 0000:00:0f.0: version 1.1

ACPI: PCI Interrupt 0000:00:0f.0[B] -> Link [ALKA] -> GSI 20 (level, low) -> IRQ 177

PCI: Via IRQ fixup for 0000:00:0f.0, from 11 to 1

sata_via 0000:00:0f.0: routed to hard irq line 1

ata1: SATA max UDMA/133 cmd 0xE200 ctl 0xE302 bmdma 0xE600 irq 177

ata2: SATA max UDMA/133 cmd 0xE400 ctl 0xE502 bmdma 0xE608 irq 177

ata1: SATA link up 1.5 Gbps (SStatus 113)

ata1: dev 0 cfg 49:2f00 82:346b 83:7d01 84:4003 85:3469 86:3c01 87:4003 88:407f

ata1: dev 0 ATA-6, max UDMA/133, 312581808 sectors: LBA48

ata1: dev 0 configured for UDMA/133

scsi0 : sata_via

ata2: SATA link up 1.5 Gbps (SStatus 113)

ata2: dev 0 cfg 49:2f00 82:7c6b 83:7f09 84:4063 85:7c69 86:3e01 87:4063 88:407f

ata2: dev 0 ATA-7, max UDMA/133, 398297088 sectors: LBA48

ata2: dev 0 configured for UDMA/133

scsi1 : sata_via

  Vendor: ATA       Model: ST3160023AS       Rev: 3.18

  Type:   Direct-Access                      ANSI SCSI revision: 05

  Vendor: ATA       Model: Maxtor 6B200M0    Rev: BANC

  Type:   Direct-Access                      ANSI SCSI revision: 05

SCSI device sda: 312581808 512-byte hdwr sectors (160042 MB)

sda: Write Protect is off

sda: Mode Sense: 00 3a 00 00

SCSI device sda: drive cache: write back

SCSI device sda: 312581808 512-byte hdwr sectors (160042 MB)

sda: Write Protect is off

sda: Mode Sense: 00 3a 00 00

SCSI device sda: drive cache: write back

 sda: sda1 sda2 sda3 sda4

sd 0:0:0:0: Attached scsi disk sda

SCSI device sdb: 398297088 512-byte hdwr sectors (203928 MB)

sdb: Write Protect is off

sdb: Mode Sense: 00 3a 00 00

SCSI device sdb: drive cache: write back

SCSI device sdb: 398297088 512-byte hdwr sectors (203928 MB)

sdb: Write Protect is off

sdb: Mode Sense: 00 3a 00 00

SCSI device sdb: drive cache: write back

 sdb: sdb1 sdb2 < sdb5 sdb6 >

sd 1:0:0:0: Attached scsi disk sdb

GSI 18 sharing vector 0xB9 and IRQ 18

```

```
sata_promise PATA port found

ata3: SATA max PIO4 cmd 0xFFFFC20000026200 ctl 0xFFFFC20000026238 bmdma 0x0 irq 177

ata4: SATA max PIO4 cmd 0xFFFFC20000026280 ctl 0xFFFFC200000262B8 bmdma 0x0 irq 177

ata5: PATA max PIO4 cmd 0xFFFFC20000026300 ctl 0xFFFFC20000026338 bmdma 0x0 irq 177

ieee1394: Initialized config rom entry `ip1394'

ata3: SATA link up 1.5 Gbps (SStatus 113)

ata3: dev 0 cfg 49:2f00 82:346b 83:7d01 84:4003 85:3469 86:3c01 87:4003 88:407f

ata3: dev 0 ATA-6, max UDMA/133, 390721968 sectors: LBA48

ata3: dev 0 configured for PIO4

scsi2 : sata_promise

ata4: SATA link down (SStatus 0)

scsi3 : sata_promise

ATA: abnormal status 0x8 on port 0xFFFFC2000002631C

ata5: disabling port

scsi4 : sata_promise

  Vendor: ATA       Model: ST3200822AS       Rev: 3.01

  Type:   Direct-Access                      ANSI SCSI revision: 05

SCSI device sdc: 390721968 512-byte hdwr sectors (200050 MB)

sdc: Write Protect is off

sdc: Mode Sense: 00 3a 00 00

SCSI device sdc: drive cache: write back

SCSI device sdc: 390721968 512-byte hdwr sectors (200050 MB)

sdc: Write Protect is off

sdc: Mode Sense: 00 3a 00 00

SCSI device sdc: drive cache: write back

 sdc:<4>nvidia: module license 'NVIDIA' taints kernel.

 sdc1

sd 2:0:0:0: Attached scsi disk sdc
```

```
root@enti $ hdparm -tT /dev/sda /dev/sdb /dev/sdc

/dev/sda:

 Timing cached reads:   3644 MB in  2.00 seconds = 1821.13 MB/sec

 Timing buffered disk reads:  158 MB in  3.03 seconds =  52.19 MB/sec

/dev/sdb:

 Timing cached reads:   3560 MB in  2.00 seconds = 1779.38 MB/sec

 Timing buffered disk reads:  182 MB in  3.02 seconds =  60.33 MB/sec

/dev/sdc:

 Timing cached reads:   3588 MB in  2.00 seconds = 1793.71 MB/sec

 Timing buffered disk reads:    6 MB in  4.28 seconds =   1.40 MB/sec

```

```
 link up 1.5 Gbps (SStatus 113)

ata2: dev 0 cfg 49:2f00 82:7c6b 83:7f09 84:4063 85:7c69 86:3e01 87:4063 88:407f

ata2: dev 0 ATA-7, max UDMA/133, 398297088 sectors: LBA48

ata2: dev 0 configured for UDMA/133

scsi1 : sata_via

  Vendor: ATA       Model: ST3160023AS       Rev: 3.18

  Type:   Direct-Access                      ANSI SCSI revision: 05

  Vendor: ATA       Model: Maxtor 6B200M0    Rev: BANC

  Type:   Direct-Access                      ANSI SCSI revision: 05

SCSI device sda: 312581808 512-byte hdwr sectors (160042 MB)

sda: Write Protect is off

sda: Mode Sense: 00 3a 00 00

SCSI device sda: drive cache: write back

SCSI device sda: 312581808 512-byte hdwr sectors (160042 MB)

sda: Write Protect is off

sda: Mode Sense: 00 3a 00 00

SCSI device sda: drive cache: write back

 sda: sda1 sda2 sda3 sda4

sd 0:0:0:0: Attached scsi disk sda

SCSI device sdb: 398297088 512-byte hdwr sectors (203928 MB)

sdb: Write Protect is off

sdb: Mode Sense: 00 3a 00 00

SCSI device sdb: drive cache: write back

SCSI device sdb: 398297088 512-byte hdwr sectors (203928 MB)

sdb: Write Protect is off

sdb: Mode Sense: 00 3a 00 00

SCSI device sdb: drive cache: write back

 sdb: sdb1 sdb2 < sdb5 sdb6 >

sd 1:0:0:0: Attached scsi disk sdb

GSI 18 sharing vector 0xB9 and IRQ 18

```

```
sata_promise PATA port found

ata3: SATA max PIO4 cmd 0xFFFFC20000026200 ctl 0xFFFFC20000026238 bmdma 0x0 irq 177

ata4: SATA max PIO4 cmd 0xFFFFC20000026280 ctl 0xFFFFC200000262B8 bmdma 0x0 irq 177

ata5: PATA max PIO4 cmd 0xFFFFC20000026300 ctl 0xFFFFC20000026338 bmdma 0x0 irq 177

ieee1394: Initialized config rom entry `ip1394'

ata3: SATA link up 1.5 Gbps (SStatus 113)

ata3: dev 0 cfg 49:2f00 82:346b 83:7d01 84:4003 85:3469 86:3c01 87:4003 88:407f

ata3: dev 0 ATA-6, max UDMA/133, 390721968 sectors: LBA48

ata3: dev 0 configured for PIO4

scsi2 : sata_promise

ata4: SATA link down (SStatus 0)

scsi3 : sata_promise

ATA: abnormal status 0x8 on port 0xFFFFC2000002631C

ata5: disabling port

scsi4 : sata_promise

  Vendor: ATA       Model: ST3200822AS       Rev: 3.01

  Type:   Direct-Access                      ANSI SCSI revision: 05

SCSI device sdc: 390721968 512-byte hdwr sectors (200050 MB)

sdc: Write Protect is off

sdc: Mode Sense: 00 3a 00 00

SCSI device sdc: drive cache: write back

SCSI device sdc: 390721968 512-byte hdwr sectors (200050 MB)

sdc: Write Protect is off

sdc: Mode Sense: 00 3a 00 00

SCSI device sdc: drive cache: write back

 sdc:<4>nvidia: module license 'NVIDIA' taints kernel.

 sdc1

sd 2:0:0:0: Attached scsi disk sdc
```

```
root@enti $ hdparm -tT /dev/sda /dev/sdb /dev/sdc

/dev/sda:

 Timing cached reads:   3644 MB in  2.00 seconds = 1821.13 MB/sec

 Timing buffered disk reads:  158 MB in  3.03 seconds =  52.19 MB/sec

/dev/sdb:

 Timing cached reads:   3560 MB in  2.00 seconds = 1779.38 MB/sec

 Timing buffered disk reads:  182 MB in  3.02 seconds =  60.33 MB/sec

/dev/sdc:

 Timing cached reads:   3588 MB in  2.00 seconds = 1793.71 MB/sec

 Timing buffered disk reads:    6 MB in  4.28 seconds =   1.40 MB/sec

```

```
root@enti $ hdparm -I /dev/sdc

/dev/sdc:

ATA device, with non-removable media

        Model Number:       ST3200822AS

        Serial Number:      5LJ0V7LT

        Firmware Revision:  3.01

Standards:

        Used: ATA/ATAPI-6 T13 1410D revision 2

        Supported: 6 5 4 3

Configuration:

        Logical         max     current

        cylinders       16383   16383

        heads           16      16

        sectors/track   63      63

        --

        CHS current addressable sectors:   16514064

        LBA    user addressable sectors:  268435455

        LBA48  user addressable sectors:  390721968

        device size with M = 1024*1024:      190782 MBytes

        device size with M = 1000*1000:      200049 MBytes (200 GB)

Capabilities:

        LBA, IORDY(can be disabled)

        bytes avail on r/w long: 4      Queue depth: 1

        Standby timer values: spec'd by Standard, no device specific minimum

        R/W multiple sector transfer: Max = 16  Current = ?

        Recommended acoustic management value: 254, current value: 0

        DMA: mdma0 mdma1 mdma2 udma0 udma1 udma2 udma3 udma4 udma5 *udma6

             Cycle time: min=120ns recommended=120ns

        PIO: pio0 pio1 pio2 pio3 pio4

             Cycle time: no flow control=240ns  IORDY flow control=120ns

Commands/features:

        Enabled Supported:

           *    READ BUFFER cmd

           *    WRITE BUFFER cmd

           *    Host Protected Area feature set

           *    Look-ahead

           *    Write cache

           *    Power Management feature set

                Security Mode feature set

           *    SMART feature set

           *    FLUSH CACHE EXT command

           *    Mandatory FLUSH CACHE command

           *    Device Configuration Overlay feature set

           *    48-bit Address feature set

                SET MAX security extension

           *    DOWNLOAD MICROCODE cmd

           *    SMART self-test

           *    SMART error logging

Security:

        Master password revision code = 65534

                supported

        not     enabled

        not     locked

        not     frozen

        not     expired: security count

        not     supported: enhanced erase

Checksum: correct

```

any thoughts?

----------

## eNTi

another strange thing is, that even though my second seagate is also on the sil_blacklist, it doesn't have that slowdown.

----------

