# Silicon Image 3112 SerialATA FIX! (kernel patch inside)

## Heretic

If you have an Asus Deluxe board with SerialATA or one of the motherboards/PCI cards with the Silicon Image 3112 chipset, you've noticed bad performance or lockups if 'max_kb_per_request' in /proc/ide/hda/settings isn't set to 15.  However, setting the receive buffer to 15KB instead of 128KB causes horrible performance issues.

I read through the Linux IDE/PCI subsystems and then went on to analyze linux/drivers/ide/pci/siimage.[c|h] in which I found an error in the driver code.  I fixed this issue and have been running stress tests on the system for the last 40 hours with 128KByte receive buffer.  I've been copying around 4-8GB files with a script that constantly md5sum the new copies to make sure there was no corrutption.  So far I've copy around over a TB of data with no stability problems or errors.  With the driver patch, sequential read/write CPU utlization decreased by 70-90%.   Additionally, sequential read/write performance increased 5-7 MB/sec on my testbed--and Athlon1800 with 512MB RAM.

I'm still running benchmarks, but here are the initial results:

```
name,file_size,putc,putc_cpu,put_block,put_block_cpu,rewrite,rewrite_cpu,getc,getc_cpu,get_block,

get_block_cpu,seeks,seeks_cpu,num_files,seq_create,seq_create_cpu,seq_stat,seq_stat_cpu,seq_del,

seq_del_cpu,ran_create,ran_create_cpu,ran_stat,ran_stat_cpu,ran_del,ran_del_cpu

aeryn,2G,13394,98,44280,29,20448,8,18897,88,42106,11,206.9,0,16,19359,94,+++++,+++,18830,98,19631,99,+++++,+++,17084,100

aeryn,2G,13426,98,41892,28,19254,7,19021,88,39806,10,203.8,0,16,20929,99,+++++,+++,16702,91,20550,100,+++++,+++,16454,100

aeryn,2G,13491,99,41469,28,17846,7,18908,88,37610,9,204.0,0,16,21461,99,+++++,+++,18478,99,20609,100,+++++,+++,15858,95

aeryn,2G,13285,97,35673,23,16948,7,18934,88,34985,8,197.6,0,16,20864,96,+++++,+++,18135,100,20712,101,+++++,+++,16243,100

aeryn,2G,12428,91,52800,35,21584,9,18974,89,45868,12,191.3,0,16,21298,100,+++++,+++,15746,86,20526,100,+++++,+++,16347,100

aeryn,2G,13464,99,43526,29,20138,8,18978,88,42060,12,202.2,0,16,21233,99,+++++,+++,18045,100,19158,93,+++++,+++,16182,100

aeryn,2G,13170,97,42420,28,19145,7,19044,89,39721,10,209.8,0,16,20469,96,+++++,+++,18263,99,20636,100,+++++,+++,16327,99

aeryn,2G,13263,97,39844,26,17376,7,18844,88,36047,10,201.5,0,16,21212,99,+++++,+++,18221,100,20513,100,+++++,+++,14119,87

aeryn,2G,13087,96,38054,26,16139,6,18797,88,33860,8,197.0,0,16,20503,97,+++++,+++,18021,100,20281,99,+++++,+++,16120,99

aeryn,2G,12632,92,51055,34,20976,8,18841,88,45228,12,172.1,0,16,21476,100,+++++,+++,18446,100,20225,96,+++++,+++,15075,92
```

Without the patch, sequential reads are using almost all the pocessor.  This is with a single WD360GD "Raptor" drive.  I'll post more benchmarks later with 15KB buffer results.

Here is the patch/fix: 

```
*** /usr/src/linux/drivers/ide/pci/siimage.c.orig       Sun Nov 30 07:05:59 2003

--- /usr/src/linux/drivers/ide/pci/siimage.c    Sun Nov 30 07:05:59 2003

***************

*** 265,271 ****

  static void siimage_tuneproc (ide_drive_t *drive, byte mode_wanted)

  {

        ide_hwif_t *hwif        = HWIF(drive);

!       u32 speedt              = 0;

        u16 speedp              = 0;

        unsigned long addr      = siimage_seldev(drive, 0x04);

        unsigned long tfaddr    = siimage_selreg(hwif, 0x02);

--- 265,271 ----

  static void siimage_tuneproc (ide_drive_t *drive, byte mode_wanted)

  {

        ide_hwif_t *hwif        = HWIF(drive);

!       u16 speedt              = 0;    /* was a u32 that clobered over the port/addr section of the stack in OUTW */

        u16 speedp              = 0;

        unsigned long addr      = siimage_seldev(drive, 0x04);

        unsigned long tfaddr    = siimage_selreg(hwif, 0x02);

***************

*** 1065,1072 ****

--- 1065,1075 ----

        hwif->hwif_data = 0;

        hwif->rqsize = 128;

+

+ #if defined( SATA_BUGGY )

        if (is_sata(hwif))

                hwif->rqsize = 15;

+ #endif

        if (pci_get_drvdata(dev) == NULL)

                return;

```

The crux of the problem is that the first arguent to OUTW (out WORD) was a doubleword.  The arguments were getting all screwed up on the stack.  The lower order 16-bit were being used in the second argument of OUTW, and the upper order word was being used as the whole first argument, which was always 0000.  So basically the on-disk controller was being programmed with erroneous settings.  This fixes it and SATA on the SiI3112 is now good on Linux.  Apply this fix to linux/drivers/ide/pci/siimage.c and recompile your Kernel for SATA love.

----------

## barlad

Nice one. What kernel does it apply to?

I have not seen any problem with SiI & 2.6.0 - test 10 kernel.

----------

## Heretic

 *barlad wrote:*   

> Nice one. What kernel does it apply to?
> 
> I have not seen any problem with SiI & 2.6.0 - test 10 kernel.

 

I used the 2.4.23_pre8-gss source tree.  If you look at the code, you'll see the fix is pretty simple.  There error is there under the 2.6 tree as well; you'll still get horrible performance (cat /proc/ide/hdX/settings and check max_kb_per_request).  You can patch it by hand pretty easily.  This driver hasn't changed a lot since 2.4.21, but I didn't look at applying it to any earlier versions, sorry.

----------

## barlad

You are right. I just had to add some offsets to the patch lines in order to have it applied on a 2.6.0 test 10 kernel.

I did notice a slight performance increase.

I don't mean to abuse but since you seem quite knowledgable about this maybe you may find a solution to that awful delay I get when using siimage as a built-in driver:

That's what I get in dmesg. The hdg scan takes about 40 seconds!

 *Quote:*   

> SiI3112 Serial ATA: IDE controller at PCI slot 0000:02:04.0
> 
> SiI3112 Serial ATA: chipset revision 1
> 
> SiI3112 Serial ATA: 100% native mode on irq 21
> ...

 

----------

## Kesereti

 *barlad wrote:*   

> You are right. I just had to add some offsets to the patch lines in order to have it applied on a 2.6.0 test 10 kernel.
> 
> I did notice a slight performance increase.
> 
> I don't mean to abuse but since you seem quite knowledgable about this maybe you may find a solution to that awful delay I get when using siimage as a built-in driver:
> ...

 

Add the following to your kernel line in GRUB to fix that:

```

hdg=noprobe

```

Anyone know if there's any hope on the horizon for us poor SilImage3112A controller/Seagate SATA drive users?  I'm getting a little tired of getting 12MB/sec out of this drive =P

----------

## Heretic

 *Kesereti wrote:*   

> 
> 
> Anyone know if there's any hope on the horizon for us poor SilImage3112A controller/Seagate SATA drive users?  I'm getting a little tired of getting 12MB/sec out of this drive =P

 

Did you try my patch?  That's what this whole post is about.  Fix the SiI3112 driver with my patch, recompile, and test it.

----------

## i_hate_your_os

cool.  have you notified any kernel devs about this fix?

----------

## Heretic

 *i_hate_your_os wrote:*   

> cool.  have you notified any kernel devs about this fix?

 

Yes, it's being discussed on the linux-ide mailing list.

I've been running a benchmark suite for the last 14 hours, I'll post the results when it finishes.  The performance differential is staggering: 2x increase in sequential throughput.

----------

## Kesereti

 *Heretic wrote:*   

>  *Kesereti wrote:*   
> 
> Anyone know if there's any hope on the horizon for us poor SilImage3112A controller/Seagate SATA drive users?  I'm getting a little tired of getting 12MB/sec out of this drive =P 
> 
> Did you try my patch?  That's what this whole post is about.  Fix the SiI3112 driver with my patch, recompile, and test it.

 

OK, I'll give it a try, and let you know...I didn't know this was about Seagate drives, they have an entirely different issue apparently, since at this point most everyone I know is getting at least 60MB/sec using libata (treating the SATA controller as a SCSI device) for SilImage SATA controllers with the recent patches to libata, except for Seagate drive owners =\

----------

## Kesereti

```

/dev/hde:

 Timing buffer-cache reads:   1684 MB in  2.00 seconds = 840.45 MB/sec

 Timing buffered disk reads:  166 MB in  3.02 seconds =  55.03 MB/sec

```

Far better than what I was getting!  Report one success on 2.6.0-test11-love2 with a Seagata SATA drive ^_^

----------

## Heretic

 *Kesereti wrote:*   

> 
> 
> ```
> 
> /dev/hde:
> ...

 

Hey, check something for me.  Cat the drive settings under proc.  I haven't setup 2.6 yet, I don't know if they're still under /proc/ide/hdX/settings still, but check and post that.  They said on the Kernel mailing list that there is a problem with Seagate drives in particular.  I am suspicious of these claims.  Reading back on the lkml and what not, I'm not seeing why they believe it is a Seagate problem, but I continue to search.  I haven't seen reports of problems with Seagate on other SATA controllers.  Seagate has a native SATA interface, you'd think that they would have excellent support.

If your drive is operating stably with 128KB request buffers, then yea...  libata unfairly sets all Seagate SATA drivers to 15KB request buffers.  I was reading through libata in 2.6.  libata is badass, it's the future, but they haven't narrowed down that Seagate problem yet.  I don't know the details.  I know why the original siimage.c driver in the IDE subsystem was messing up though.  However, SATA has a feature set more akin to SCSI.  libata is going to handle all those extra things, like command queuing and hot-swap.

You should also attach all the information on your Seagate drive.  Check all the information on the drive and put that in this post.  Model and version numbers as given by the driver are especially important.  We can start getting a list of known good Seagate drives for libata.

Oh, here are some benchmarks on an Athlon1800 with 512MB RAM + 3112/Raptor and the patch:

```
hdparm -tT /dev/hda

/dev/hda:

 Timing buffer-cache reads:   1180 MB in  2.00 seconds = 590.00 MB/sec

 Timing buffered disk reads:  166 MB in  3.02 seconds =  54.97 MB/sec
```

This is bonnie++ with 15KB rbuf:

```
name,file_size,putc,putc_cpu,put_block,put_block_cpu,rewrite,rewrite_cpu,getc,getc_cpu,get_block,get_block_cpu,seeks,seeks_cpu,

num_files,seq_create,seq_create_cpu,seq_stat,seq_stat_cpu,seq_del,seq_del_cpu,ran_create,ran_create_cpu,ran_stat,ran_stat_cpu,

ran_del,ran_del_cpu

aeryn,2G,10907,83,26947,21,13777,6,17616,93,38100,10,209.5,0,32:30000:5/500,1548,28,474,4,14919,100,1293,25,253,1,1040,9

aeryn,2G,10721,82,25315,19,12721,5,17091,90,33329,9,157.2,0,32:30000:5/500,1514,28,498,4,15192,99,1332,23,215,1,921,8

aeryn,2G,10815,83,27391,21,14259,6,17705,93,40944,11,194.6,0,32:30000:5/500,1431,26,526,4,15320,100,1431,27,275,1,1377,13

aeryn,2G,10671,81,28287,22,14541,6,17801,94,42958,12,212.3,0,32:30000:5/500,1768,32,595,5,15873,99,1717,31,283,1,1170,11

aeryn,2G,10920,82,28101,22,14668,6,17798,94,43167,11,212.2,0,32:30000:5/500,1724,29,610,5,15482,99,1586,31,273,1,1251,12

aeryn,2G,10678,81,28005,22,14533,6,17742,93,42516,12,208.3,0,32:30000:5/500,1667,29,606,5,15166,99,1572,29,272,1,1195,12

aeryn,2G,10648,81,27595,21,14039,6,17744,94,39429,10,206.9,0,32:30000:5/500,1621,27,618,5,15001,100,1493,27,258,1,1206,11

aeryn,2G,10665,81,27151,21,13388,6,17707,93,35755,10,173.1,0,32:30000:5/500,1596,27,592,5,15082,99,1392,29,253,1,1347,13

aeryn,2G,10728,82,27222,21,14236,6,17731,93,41020,11,196.0,0,32:30000:5/500,1694,30,561,4,14452,99,1420,27,263,1,1287,12

aeryn,2G,10639,81,27390,21,14270,6,17817,94,41337,11,211.8,0,32:30000:5/500,1770,32,568,4,15260,95,1428,26,269,2,1396,13
```

And with 128:

```
name,file_size,putc,putc_cpu,put_block,put_block_cpu,rewrite,rewrite_cpu,getc,getc_cpu,get_block,get_block_cpu,seeks,seeks_cpu,

num_files,seq_create,seq_create_cpu,seq_stat,seq_stat_cpu,seq_del,seq_del_cpu,ran_create,ran_create_cpu,ran_stat,ran_stat_cpu,

ran_del,ran_del_cpu

aeryn,2G,13122,94,44005,28,19932,8,19192,91,42481,10,140.7,0,32:30000:5/500,1685,29,738,6,15582,97,2021,38,266,2,1362,13

aeryn,2G,13435,98,48514,31,21635,8,19310,91,45998,11,204.7,0,32:30000:5/500,2212,39,603,5,14356,99,1569,33,255,1,1310,12

aeryn,2G,13497,98,45713,29,20705,8,19367,91,42999,10,198.8,0,32:30000:5/500,2050,36,680,4,14388,98,1437,30,260,1,1392,13

aeryn,2G,13480,98,43830,27,18606,7,19163,90,39832,9,204.7,0,32:30000:5/500,2198,38,675,5,14526,99,1610,32,263,1,1320,12

aeryn,2G,12947,94,41503,26,18410,7,19265,90,39721,9,145.0,0,32:30000:5/500,2208,39,700,5,13931,99,1170,25,273,2,1382,13

aeryn,2G,13416,98,46736,30,21550,9,19098,90,45053,11,187.1,0,32:30000:5/500,2172,38,613,5,13864,99,1562,28,280,2,1323,13

aeryn,2G,13427,98,45948,29,20198,8,19069,89,42410,11,202.7,0,32:30000:5/500,1654,27,728,5,14842,100,1347,24,289,2,1379,12

aeryn,2G,12723,93,54903,34,22689,9,19317,90,50314,13,210.8,0,32:30000:5/500,1657,26,757,6,14978,100,1212,22,276,1,1261,11

aeryn,2G,13443,98,53581,34,21640,8,19281,90,47308,11,182.1,0,32:30000:5/500,2079,33,677,5,15280,99,2215,37,275,1,1339,12

aeryn,2G,13503,98,47917,30,19926,8,19186,90,43003,10,207.4,0,32:30000:5/500,2146,35,604,5,14924,97,1366,26,261,1,1308,12
```

----------

## archimedelemalin

Hello, I run kernel 2.6.0.-test11-gentoo-r1 and here's my cat and hdparm -tTi before your patch.. i'm gonna patch and post result..

as you see no sign of the max_buff_something=15kb

(Asus a7n8x dlx sata 120 seagate)

```
cat /proc/ide/hde/settings

name                    value           min             max             mode

----                    -----           ---             ---             ----

acoustic                0               0               254             rw

address                 1               0               2               rw

bios_cyl                16383           0               65535           rw

bios_head               255             0               255             rw

bios_sect               63              0               63              rw

bswap                   0               0               1               r

current_speed           70              0               70              rw

failures                0               0               65535           rw

init_speed              70              0               70              rw

io_32bit                0               0               3               rw

keepsettings            0               0               1               rw

lun                     0               0               7               rw

max_failures            1               0               65535           rw

multcount               0               0               16              rw

nice1                   1               0               1               rw

nowerr                  0               0               1               rw

number                  0               0               3               rw

pio_mode                write-only      0               255             w

slow                    0               0               1               rw

unmaskirq               0               0               1               rw

using_dma               1               0               1               rw

wcache                  0               0               1               rw

```

```
/dev/hde:

 

 Model=ST3120026AS, FwRev=3.05, SerialNo=3JT05AQR

 Config={ HardSect NotMFM HdSw>15uSec Fixed DTR>10Mbs RotSpdTol>.5% }

 RawCHS=16383/16/63, TrkSize=0, SectSize=0, ECCbytes=4

 BuffType=unknown, BuffSize=8192kB, MaxMultSect=16, MultSect=off

 CurCHS=16383/16/63, CurSects=16514064, LBA=yes, LBAsects=234441648

 IORDY=on/off, tPIO={min:240,w/IORDY:120}, tDMA={min:120,rec:120}

 PIO modes:  pio0 pio1 pio2 pio3 pio4

 DMA modes:  mdma0 mdma1 mdma2

 UDMA modes: udma0 udma1 udma2

 AdvancedPM=no WriteCache=enabled

 Drive conforms to: ATA/ATAPI-6 T13 1410D revision 2:

 

 * signifies the current active mode

 

 Timing buffer-cache reads:   1208 MB in  2.00 seconds = 602.59 MB/sec

 Timing buffered disk reads:   46 MB in  3.02 seconds =  15.24 MB/sec

```

****Update****

cd /usr/src/linux/drivers/ide/pci

patch -p1 -E Makefile /home/patch.diff

patching file Makefile

Hunk #1 FAILED at 265.

Hunk #2 FAILED at 1065.

2 out of 2 hunks FAILED -- saving rejects to file Makefile.rej

 :Sad: 

----------

## Heretic

Here is the 2.6.0-test11 diff.

```
# diff -c siimage.c.orig siimage.c

*** siimage.c.orig      Wed Dec  3 20:35:18 2003

--- siimage.c   Wed Dec  3 20:51:00 2003

***************

*** 266,272 ****

  static void siimage_tuneproc (ide_drive_t *drive, byte mode_wanted)

  {

        ide_hwif_t *hwif        = HWIF(drive);

!       u32 speedt              = 0;

        u16 speedp              = 0;

        unsigned long addr      = siimage_seldev(drive, 0x04);

        unsigned long tfaddr    = siimage_selreg(hwif, 0x02);

--- 266,272 ----

  static void siimage_tuneproc (ide_drive_t *drive, byte mode_wanted)

  {

        ide_hwif_t *hwif        = HWIF(drive);

!       u16 speedt              = 0; /* was u32 and did massive damage */

        u16 speedp              = 0;

        unsigned long addr      = siimage_seldev(drive, 0x04);

        unsigned long tfaddr    = siimage_selreg(hwif, 0x02);

***************

*** 1068,1075 ****

--- 1068,1092 ----

        hwif->hwif_data = 0;

        hwif->rqsize = 128;

+

+

+ #if !defined( BUGGY_HARDWARE )

+       /* Seagate users be warned, the follow drives need a fix:

+        * ST320012AS

+        * ST330013AS

+        * ST340017AS

+        * ST360015AS

+        * ST380023AS

+        * ST3120023AS

+        * ST340014ASL

+        * ST360014ASL

+        * ST380011ASL

+        * ST3120022ASL

+        * ST3160021ASL

+        */

        if (is_sata(hwif))

                hwif->rqsize = 15;

+ #endif

        if (pci_get_drvdata(dev) == NULL)

                return;

```

Run bonnie++: 

```
bonnie++ -u <a non-root user> -d /tmp -x 10 -s 2g -n 32:30000:5:500 -m <machine name> > /some/file/to/log/in
```

It might take awhile like 20-30 minutes, so do it when you have something else to do.

----------

## Kesereti

Here's the results of calling bonnie++ with that command line you listed:

```

name,file_size,putc,putc_cpu,put_block,put_block_cpu,rewrite,rewrite_cpu,getc,getc_cpu,get_block,get_block_cpu,seeks,seeks_cpu,num_files,seq_create,seq_create_cpu,seq_stat,seq_stat_cpu,seq_del,seq_del_cpu,ran_create,ran_create_cpu,ran_stat,ran_stat_cpu,ran_del,ran_del_cpu

musashi,2G,20524,82,42943,15,18307,6,15287,64,46231,6,132.7,0,32:30000:5/500,1848,17,1063,3,61204,65,2185,12,113,0,3316,6

musashi,2G,20995,83,42993,15,18706,6,15197,64,46228,6,132.1,0,32:30000:5/500,1788,15,975,3,29301,30,2531,15,114,0,3690,7

musashi,2G,18676,75,37714,13,18241,6,15502,66,47618,6,134.1,0,32:30000:5/500,1839,16,1307,4,19073,21,2569,15,115,0,3143,6

musashi,2G,8180,31,42111,15,18356,6,13659,61,48180,7,132.4,0,32:30000:5/500,1711,15,956,3,39175,43,2519,15,113,0,3168,6

musashi,2G,8241,32,42911,15,18349,6,13906,62,48506,7,128.5,0,32:30000:5/500,1718,15,1013,3,35495,37,2537,16,113,0,3179,6

musashi,2G,8285,31,40233,14,18238,6,13567,60,47582,7,133.7,0,32:30000:5/500,1824,13,1028,4,28280,31,2524,15,114,0,3173,6

musashi,2G,21313,85,40959,15,18312,6,15069,64,48240,6,133.6,0,32:30000:5/500,1949,19,1060,3,27979,30,2481,14,115,0,2996,6

musashi,2G,21340,85,41975,15,17842,6,14728,62,46400,6,131.6,0,32:30000:5/500,1762,15,946,3,29984,32,2504,16,114,0,3130,6

musashi,2G,20775,84,41865,15,17892,6,15173,64,46498,6,131.7,0,32:30000:5/500,1745,15,947,3,38533,40,2527,16,113,0,3136,6

musashi,2G,21656,86,43100,15,18462,6,15239,64,47687,6,131.7,0,32:30000:5/500,1806,16,979,3,39493,40,2419,15,114,0,2940,6

```

I know little to nothing about hard drive benchmarking, so I don't know what these numbers mean ^_^

----------

## archimedelemalin

Hunk #1 FAILED at 266.

Hunk #2 FAILED at 1068.

2 out of 2 hunks FAILED -- saving rejects to file Makefile.rej

patch for kernel 2.6.0 still doesn't work here.

----------

## Heretic

 *Kesereti wrote:*   

> Here's the results of calling bonnie++ with that command line you listed:

 

Nice.  musashi is apparently has a more capable processor than aeryn.

----------

## Heretic

 *archimedelemalin wrote:*   

> Hunk #1 FAILED at 266.
> 
> Hunk #2 FAILED at 1068.
> 
> 2 out of 2 hunks FAILED -- saving rejects to file Makefile.rej
> ...

 

What command are you using to patch?  You can just do it by hand, it's pretty simple.  test11?

----------

## Kesereti

 *Heretic wrote:*   

>  *Kesereti wrote:*   Here's the results of calling bonnie++ with that command line you listed: 
> 
> Nice.  musashi is apparently has a more capable processor than aeryn.

 

```

processor       : 0

vendor_id       : AuthenticAMD

cpu family      : 6

model           : 8

model name      : AMD Athlon(tm)

stepping        : 1

cpu MHz         : 2105.005

cache size      : 256 KB

fdiv_bug        : no

hlt_bug         : no

f00f_bug        : no

coma_bug        : no

fpu             : yes

fpu_exception   : yes

cpuid level     : 1

wp              : yes

flags           : fpu vme de tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 mmx fxsr sse syscall mmxext 3dnowext 3dnow

bogomips        : 4161.53

```

^_^

----------

## barnie

Hello!

I've also got a ASUS A7N8X Deluxe and a Seagate 120 GB SATA drive. I have lockups everyday - so I applied your patch, but it didn't help. FSCK locks up the computer.

Because FSCK is called before hdparm in gentoo, the SATA drive still runs in PIO mode while checking it. Maybe your fix does only cure DMA modes?

Now I'm using my system again with aborted FSCK. I'll try crashing it while in DMA mode and tell you about.

Then I want to ask something:

I have a seagate drive that is not listed in your comment. Is it safe to remove the 15kb thing to get full performance?

----------

## barnie

Hello again!

I successfully ran an FSCK of my 80 GB data partition in an kde terminal without lockup. This is excellent, but I never tried it this way before applying the patch. So I cannot know if the patch really fixed my problem.

In PIO mode while booting it hang (see above).

Thank you for your investigation of the problem. I crawled masses of posts on a variety of mailinglists but I found no solution for my problem before today.

Also I want to thank for the "hdg=noprobe" hint. This helped me too.

----------

## Heretic

I don't know you're using PIO, the driver should set the DMA mode appropraitely at drive detection.  You shouldn't need to run hdparm at all.

There is a Seagate errata.  Those harddrives were scanned out of the binary image for Silicon Image's 3512 closed-source driver.  The errata has something to do with the sector count.  

if (sector % 15 == 1 && sector != 1)

   errata will manifest;

Setting the request buffer to 15 (7.5) prevents multiple of 15 sector requests (or something like that) but kills performance.  This is another way to handle the errata, but it requires more effort.

You should test your drive with request buffer set to 128 sometime, but do so at your own risk.  I hope you don't have anything important that's not backed up.  If you were already running a 15KB request buffer, then you shouldn't be having any problems other than slow performance.  Again, stay away from PIO, you want UDMA.  Don't manually set your hdparms.

----------

## barnie

I'm using gs-sources 2.4.23_pre8-r1 with your fix at the moment and my SATA drive is set to pio at detection. At least the output on the screen says so.

So I installed hdparm in runlevel boot to change it to udma2. Higher levels aren't supported yet. (Says Alan Cox)

Excerpt from dmesg:

```
SiI3112 Serial ATA: IDE controller at PCI slot 01:0b.0

SiI3112 Serial ATA: chipset revision 2

SiI3112 Serial ATA: not 100% native mode: will probe irqs later

    ide2: MMIO-DMA , BIOS settings: hde:pio, hdf:pio

    ide3: MMIO-DMA , BIOS settings: hdg:pio, hdh:pio
```

Settings for hdparm (/etc/conf.d/hdparm):

```
all_args="-d1 -X udma2 -c1 -m16"
```

----------

## Heretic

 *barnie wrote:*   

> Excerpt from dmesg:
> 
> ```
> SiI3112 Serial ATA: IDE controller at PCI slot 01:0b.0
> 
> ...

 

Read after ide2 carefully "ide2: MMIO-DMA": Memory Mapped I/O, Direct Memory Access.  It works.  The BIOS defaulted to PIO, the driver increased the settings to the optimal love level.  Memory Mapped I/O is the fastest.  You want that.  Don't set your hdparms.  I fixed the error that made Alan Cox's statement true when he said it.

However, if you use a Seagate drive, beware.  Some models have errata.  There is a fix in the works.  Not all Seagate drives are affected.  

all_args="-d1"

That's all you need.

----------

## Hey!

Heretic-

I've used your patch on a pair of ST320026AS's and have seen a real increase in disk reads (from 23MB/s to 50-55MB/s).  

Increasing my max_kb_requests:64 to 128 does little, infact decreases both cache and disk reads by around 1MB/s.

I'm using 2.6 test 11 love sources on an a7n8x-dlx with Sil. Image bios 4.1.50 and hdparm @ -d -X70 settings.  

I've had two hard hangs and both were during hdparm tests and specifically on disk reads.

I'm still getting things locked down here, but if you'd like anything I'm willing to help out.

----------

## Heretic

 *Hey! wrote:*   

> Heretic-
> 
> I've used your patch on a pair of ST320026AS's and have seen a real increase in disk reads (from 23MB/s to 50-55MB/s).  
> 
> Increasing my max_kb_requests:64 to 128 does little, infact decreases both cache and disk reads by around 1MB/s.
> ...

 

First, don't run hdparm on the harddrive with -X70.  My hdparm has:

```
all_args="-d1"
```

 in it, make sures that's all yours has too.

Secondly, try these patches: ftp://ftp.kernel.org/pub/linux/kernel/people/bart/2.6.0-test11-bart1/  This has my stack fix plus other fixes in it.  It will lower you max_kb_per_request to 15, but you can play with it if you want.

And lastly, Kesereti confirmed that he attained stable results from his ST3120026AS.  Assuming you have the same model with a higher density, you should be able to get yours working.  Please tell me your results.  I'm going to modify the Seagate patch in a bit.

----------

## Hey!

I get errors when applying the patch with "patch -p0 < patch-2.6.0-test11-bart1"

and these errors when trying to make my kernel:

```
<snip>  

  CC      drivers/ide/pci/piix.o

  CC      drivers/ide/pci/rz1000.o

  CC      drivers/ide/pci/siimage.o

drivers/ide/pci/siimage.c:1073: redefinition of `is_dev_seagate_sata'

drivers/ide/pci/siimage.c:1052: `is_dev_seagate_sata' previously defined here

drivers/ide/pci/siimage.c:1052: warning: `is_dev_seagate_sata' defined but not used

make[3]: *** [drivers/ide/pci/siimage.o] Error 1

make[2]: *** [drivers/ide/pci] Error 2

make[1]: *** [drivers/ide] Error 2

make: *** [drivers] Error 2

bash-2.05b#
```

----------

## Heretic

Re-emerge the development kernel and then apply.

----------

## esson

Hi, you guys are to much... hehe 

I like it.  But what do i do as a noob. Because i guess that this is the solution for the problem that i'm going to have or is it fixed in the gentoo kernel?

So is there i file that i can download and patch or do i have to go in and edit the kernel ??

Please respond.

----------

## Heretic

 *esson wrote:*   

> Hi, you guys are to much... hehe 
> 
> I like it.  But what do i do as a noob. Because i guess that this is the solution for the problem that i'm going to have or is it fixed in the gentoo kernel?
> 
> So is there i file that i can download and patch or do i have to go in and edit the kernel ??
> ...

 

```
emerge development-sources 

cd /usr/src/linux-2.6.0-test11/

wget http://www.kernel.org/pub/linux/kernel/people/bart/2.6.0-test11-bart1/patch-2.6.0-test11-bart1

patch -p1 < patch-2.6.0-test11-bart1
```

----------

## esson

tnx

----------

## Hey!

Heretic-

I took a couple days off to get my math class in order and in the mean time I've let bart1 set in. All runs stable (love that anti-CPU Disconnect).  Some tests do show a little improvement in disk reads over love3, but its fairly inconsistant.  It looks like 55Mb/s is my max (for now).  Oh yeah, and for the record my SATA drives are ST3120026AS (was an earlier typo).

Have you spoken to Tom Horsten, the author of the medley drivers?  I wrote him about a week ago, but his mailbox bounced back.  There are links to a 2.5 driver,  here , which might work with for a "2.6" raid array and I might give them a try.  

Thanks for the tweak, pm me whenever!

----------

## Hey!

My bad!  I just realized that the 2.5 drivers are actually not for the 3112.  

They are totally an unrelated program for compiling Athlon options in kernels. 

Hah probably wishful thinking got the notion in my head in the first place!

----------

## lunatc

 *Heretic wrote:*   

> 
> 
> ...
> 
> ```
> ...

 

THANKS!!! Heretic  :Very Happy:   :Very Happy: 

I've recently bought an A7N8X dlx with a MAXTOR 120G SATA and my half-installed gentoo-system was freezing everytime. I even couldn't  do hdparm -Tt /dev/hde. 

Now....

```

2.6.0-test11-bk5-bart1

01:0b.0 RAID bus controller: CMD Technology Inc Silicon Image SiI 3112 SATARaid Controller (rev 02)

/dev/hde:

 Timing buffer-cache reads:   1536 MB in  2.00 seconds = 767.35 MB/sec

 Timing buffered disk reads:  168 MB in  3.01 seconds =  55.80 MB/sec

/dev/hde:

 Model=Maxtor 6Y120M0, FwRev=YAR51EW0, SerialNo=Y3K85XXE

 Config={ Fixed }

 RawCHS=16383/16/63, TrkSize=0, SectSize=0, ECCbytes=4

 BuffType=DualPortCache, BuffSize=7936kB, MaxMultSect=16, MultSect=16

 CurCHS=16383/16/63, CurSects=16514064, LBA=yes, LBAsects=240121728

 IORDY=on/off, tPIO={min:120,w/IORDY:120}, tDMA={min:120,rec:120}

 PIO modes:  pio0 pio1 pio2 pio3 pio4

 DMA modes:  mdma0 mdma1 mdma2

 UDMA modes: udma0 udma1 udma2

 AdvancedPM=yes: disabled (255) WriteCache=enabled

 Drive conforms to: (null):

 * signifies the current active mode

name                    value           min             max             mode

----                    -----           ---             ---             ----

acoustic                0               0               254             rw

address                 0               0               2               rw

bios_cyl                65535           0               65535           rw

bios_head               16              0               255             rw

bios_sect               63              0               63              rw

bswap                   0               0               1               r

current_speed           69              0               70              rw

failures                0               0               65535           rw

init_speed              69              0               70              rw

io_32bit                0               0               3               rw

keepsettings            0               0               1               rw

lun                     0               0               7               rw

max_failures            1               0               65535           rw

multcount               16              0               16              rw

nice1                   1               0               1               rw

nowerr                  0               0               1               rw

number                  0               0               3               rw

pio_mode                write-only      0               255             w

slow                    0               0               1               rw

unmaskirq               0               0               1               rw

using_dma               1               0               1               rw

wcache                  0               0               1               rw

```

THANKS AGAIN!!!

----------

## pellas

Nice work... I think this controller seems to be pretty popular so improvments should be appreciated by lots of users. 

I'm wondering though, if this improvement will suit us Raid users also. I'm using two Seagate B IV 60GB in a striped setup, and using the silraid module with 2.4 kernel.

I think the problems are kinda simiral wheather using single or raid setup.

But I don't know if the solution would fix the raid probelms.

Please give me your thoughts about this.

----------

## Heretic

 *pellas wrote:*   

> Nice work... I think this controller seems to be pretty popular so improvments should be appreciated by lots of users. 
> 
> I'm wondering though, if this improvement will suit us Raid users also. I'm using two Seagate B IV 60GB in a striped setup, and using the silraid module with 2.4 kernel.
> 
> I think the problems are kinda simiral wheather using single or raid setup.
> ...

 

RAID is just another block device on top of a block device.  Yes, of course, it will absolutely help RAID users.  The entire reason I did it was so that I could use a RAID1 mirror setup on my server.  However, we can't hot-swap SATA yet.  The libata silicon image driver isn't stable.  It locked midway through a 6 hour disk benchmark on my system.

Post your raid benchmarks.  I use this script:

```
#!/bin/bash

/usr/sbin/bonnie++ -u heretic -d /tmp -x 10 -s 2g -n 16:10000:5:250 -m aeryn > /root/bonnie-128-2G-scale

/usr/sbin/bonnie++ -u heretic -d /tmp -x 10 -s 4g -n 32:20000:5:500 -m aeryn > /root/bonnie-128-4G-scale

/usr/sbin/bonnie++ -u heretic -d /tmp -x 10 -s 8g -n 64:40000:5:1000 -m aeryn > /root/bonnie-128-8G-scale

/usr/sbin/bonnie++ -u heretic -d /tmp -x 10 -s 12g -n 128:80000:1:2000 -m aeryn > /root/bonnie-128-12G-scale
```

You might want to add -f to the last three runs or it can take a day or more to complete.  

I've found my RAID1 setup doesn't perform completely as expected.  It has no higher sequential read throughput.  Nor does hdparm -tT show any gains, but it almost doubles the number of random seeks it can do.

----------

## spigaz

I have to step up a raid 1 box with:

a7n8x si3112 2*seagate 160GB

As I understood, you have a raid1 setup working?

How do I do it to install? Is there a live cd that can be used?

Is your patch still necessary with the latest kernel 2.6.0?

Can I use the box for production?

Hey, If its testing the driver time, I can offer my box free time, all of it for now, as I can't use it till I have this properly running.  :Smile: 

So, beam me up Scotty...

Thanks,

----------

## Heretic

 *spigaz wrote:*   

> I have to step up a raid 1 box with:
> 
> a7n8x si3112 2*seagate 160GB

 

What model number?

 *Quote:*   

> As I understood, you have a raid1 setup working?  How do I do it to install? Is there a live cd that can be used?

 

I used a third harddrive connected to my motherboard's PATA controller.  I setup the RAID1 array from a current Gentoo installation on the 3rd harddrive.  The livecd has the bad siimage driver.

 *Quote:*   

> Is your patch still necessary with the latest kernel 2.6.0?

 

Yes.  My patch has been picked up by the IDE maintainer and renamed the siimage-stack-fix.patch which can be found at kernel.org.  However, the latest 2.6.0 release did not include his patches.  It still has version 1.06 of the driver, bart's patches raise the revision of siimage.c to 1.09.  You can grab the current 1.09 driver source from my server and put the under linux-2.6.0/drivers/ide/pci/ to have the proper code compiled.

 *Quote:*   

> Can I use the box for production?

 

That's what I'm trying to do.  However, you might want to consider buying a cheap $40 Promise SATA card.  The libata drivers for these are pretty good if you're using 2.6, plus they don't have problems with any of the Seagate drives and libata will support hot-swap in the future.

 *Quote:*   

> Hey, If its testing the driver time, I can offer my box free time, all of it for now, as I can't use it till I have this properly running. 

 

I could use that for some batch tests if you can get it setup properly.

----------

## spigaz

Greatings...

I'm using an asus a7n8x deluxe 2.0.

Ok, when is it expected to be included in the main kernel?

Hey, man, If my help can make this driver work, lets do it...

I know it will cost me more, but hey I love to help out too...

But for the moment, are there any problem with the seagates?

Mine are ST3160023AS.

But being realistic how is the driver going?

Ok, I'll try to create a bootable cd with gentoo first from another machine, but I have to install linux in it first. So my best guess is that I might be able to go for it after Christmas.

Or

I'm going to try suse, I can use it to install too... It detects ok with the si driver.

Ok...

But keep me updated on the status of the driver, ok?

I hope to help out quite soon...  :Smile: 

Thanks

----------

## pellas

ok...

I tried the patch on my Slack 9.1 installation which I run for the moment.

I applied it on the 2.6.0 kernel... but then when I booted it newer detected my array, only the single drives.

Am I right when guessing that the 2.6 series doesn't have ataraid support by default?

Or maybe it is hidden somewhere?

Keep up the good work!

----------

## gsurbey

No atariad  :Sad: 

But it might not be that bad of a thing, I think my md0 goes faster than when I used software raid through the card.  And OMG since the 2.6 kernel my desktop "feels" so much faster.  Nautilus pops now, sweet...

----------

## Heretic

 *gsurbey wrote:*   

> No atariad 
> 
> But it might not be that bad of a thing, I think my md0 goes faster than when I used software raid through the card.  And OMG since the 2.6 kernel my desktop "feels" so much faster.  Nautilus pops now, sweet...

 

Right.  2.6 has many performance enhancements.  Software RAID is the fastest RAID you can do for just 2 drives.

----------

## Heretic

 *spigaz wrote:*   

> Ok, when is it expected to be included in the main kernel?
> 
> Hey, man, If my help can make this driver work, lets do it...
> 
> I know it will cost me more, but hey I love to help out too...
> ...

 

You can do it on the same machine, just put in a third harddrive on the built in PATA controller.  Install Gentoo on the third harddrive.  If you live near Fry's, you can "rent" one--ie 15 return policy on harddrives.  Pick up a cheap harddrive.

OK, limme tell you specifically how mine is setup to illustrate it better:

RAID1

/dev/hda -> WD360GD SATA

/dev/hdc -> WD360GD SATA 

/dev/hde -> WD1200JB PATA

I have hde as my boot device.  I installed everything there first.  I didn't even partition hda or hdc until I had installed a desktop to hde.  In fact, I did this on a computer I already ran gentoo on, however you don't have to go that far.  Just get all the newest system utilities and use a patched siimage binary.  Once you have a working Gentoo system, then you can setup booting from a RAID1 SATA array.

I used the default livecd to install to the PATA drive, fixed the driver, reloaded the kernel, and then setup the RAID1 setup.  Then I mounted the array, and then cp -a over everything in / save for /proc, /sys and /mnt.  Once you have a working siimage driver, you can setup the SATA drives and it'll work stably.

I've moved tarabytes of data around.  Just install the latest 2.6.0 tree-- I'm using gentoo-dev-sources because I use broadcom gige--and put in those two source files I linked.  That should work.  Use md.  I'm actually running LVM2 on top of RAID1.  I need to take backup snapshots of my volumes on a production server.  I really want hot-swap though, which is why I may move to a PDCXXXX chipset (promise).  

However, I'd like to test it on your drives.  They don't appear to be on the baddrive list:

```
+

+ 

+ #if !defined( BUGGY_HARDWARE ) 

+       /* Seagate users be warned, the follow drives need a fix: 

+        * ST320012AS 

+        * ST330013AS 

+        * ST340017AS 

+        * ST360015AS 

+        * ST380023AS 

+        * ST3120023AS 

+        * ST340014ASL 

+        * ST360014ASL 

+        * ST380011ASL 

+        * ST3120022ASL 

+        * ST3160021ASL 

+        */ 

```

----------

## spigaz

I have used a suse boot cd with the si driver...

I can use it to configure ok, but it detects the array as sda, so I'm not sure of what you mean by "use md", as I installed as a normal hdd.

the only problem is that I had to keep the suse kernel.

But if the kernel works ok, I don't have too...

Thanks... 

Merry Christmas...

----------

## Heretic

 *spigaz wrote:*   

> I have used a suse boot cd with the si driver...
> 
> I can use it to configure ok, but it detects the array as sda, so I'm not sure of what you mean by "use md", as I installed as a normal hdd.
> 
> the only problem is that I had to keep the suse kernel.
> ...

 

You want RAID right?  md = multiple devices.  /dev/mdX or /dev/md/X = RAIDs.

----------

## spigaz

Yup, I really want raid...

It's just after all I a rookie on this, and with suse like I said, it when like a normal hard disk to /dev/sda. I had to do no other stuff.

Are there any special ops I have to do to configure a md device? 

Or does the kernel detects it automaticly to /dev/mdX?

thanks, but it seems I getting into a unknow area...  :Sad: 

Thanks...

----------

## gsurbey

Create the file /etc/raidtab

Mine looks as follows:

```
raiddev /dev/md0      # raid device name

raid-level 0         # raid 0

nr-raid-disks 2         # number of disks in the array

chunk-size 32         # stripe size in kilobytes

persistent-superblock 1      # helps when you forget which drive plugs in where

device /dev/hde2      # device that comprises the raid array

raid-disk 0         # disk positing index in array

device /dev/hdg2      # device that comprises the raid array

raid-disk 1         # disk position index in array
```

My setup is /dev/hde1 is my boot partition with ext3, and my /dev/hdg1 is my swap (type 82).  They are both the same size partitions becuase as I understand it md will only use the same amount of partition space on each drive.  When you use fdisk to create /dev/hde2 and /dev/hdg2 change their type fd Linux raid auto.  Then run mkraid /dev/md0 and you have md0 ready to format.  I like reiserfs cuz it's fast and stuff... can't wait 'til version 4 it's gonna make it survive more power outages without having to do a rebuild of the file system tree (taking atomic thingy ideas from XFS).  XFS is pretty cool too, but is intended for larger files like a server for a database, etc.

My 2.6 kernel is configured with the following:

```
[*] Multiple devices driver support (RAID and LVM)

<*>   RAID support

< >     Linear (append) mode

<*>     RAID-0 (striping) mode

< >     RAID-1 (mirroring) mode

< >     RAID-4/RAID-5 mode

< >     Multipath I/O support

< >   Device mapper support
```

----------

## spigaz

It seems I'm entering a grey area.

But in this case, I have to destroy the raid setup from the controller bios, wright? It's 100% linux software raid.  :Sad: 

I have excanged a mail with Mr. Alan Cox (yup THE Alan Cox) and he said that si's driver is a software raid also, but only its proprietary. And that it should work fine...

My question is, does the si chip do anything more than a serial controller?

Is there anyone working in detecting the bios configuration and enabling automaticly the driver to ease the process. To show the disk as just one driver, as it does with si's driver?

Thanks.

----------

## Moled

 *lunatc wrote:*   

> 
> 
> /dev/hde:
> 
>  Timing buffer-cache reads:   1536 MB in  2.00 seconds = 767.35 MB/sec
> ...

 

well I have a very similar setup

 *Quote:*   

> Model=Maxtor 6Y120M0, FwRev=YAR51BW0,

 

I guess you have a newer drive :/

anybody have any idea on how to update the firmware? (I think thats what it seems to be) :/

anyways I now get:

 *Quote:*   

> 
> 
>  /dev/hde:
> 
>  Timing buffer-cache reads:   4140 MB in  2.00 seconds = 2070.31 MB/sec
> ...

 

5mb/sec difference is quite a lot since we have the same drive/controller

 *dmesg wrote:*   

> SiI3112 Serial ATA: IDE controller at PCI slot 0000:03:0b.0
> 
> SiI3112 Serial ATA: chipset revision 2
> 
> SiI3112 Serial ATA: 100% native mode on irq 19
> ...

 

what chipset revision does it claim you to have?

this fix is included in 2.6.0-mm1 btw

 *Quote:*   

> ide-siimage-seagate.patch
> 
> ide-siimage-stack-fix.patch
> 
> ide-siimage-sil3114.patch

 

----------

## Heretic

 *spigaz wrote:*   

> It seems I'm entering a grey area.
> 
> But in this case, I have to destroy the raid setup from the controller bios, wright? It's 100% linux software raid. 
> 
> I have excanged a mail with Mr. Alan Cox (yup THE Alan Cox) and he said that si's driver is a software raid also, but only its proprietary. And that it should work fine...
> ...

 

The only reason you use the silraid driver (Medley Software Raid) is to dual boot into other OSen that use it.  If all you use is Linux--say for a production server--using Linux software RAID is better.  Linux software RAID is incredibly high-performance, and much more efficient than ataraid which doesn't even exist in linux-2.6.  Plus you can use different ATA interfaces.  You could use the same disks if you upgrade to a motherboard with SATA built into the southbridge.

I am personally moving to linux-2.6.0-gentoo with the 1.09 siimage driver running software raid for my my production server.  Search these forums for "software RAID" and search google for the Software RAID HOWTO.

----------

## Heretic

 *Moled wrote:*   

> this fix is included in 2.6.0-mm1 btw
> 
>  *Quote:*   ide-siimage-seagate.patch
> 
> ide-siimage-stack-fix.patch
> ...

 

Awesome.  I have need of the Broadcom 5700-series driver though, which comes with in the gentoo-dev-packages.  Maybe I can just find the source for that.

EDIT: Yup, I found them on Broadcom's site.  I'll try out the -mm1 sources.

----------

## lunatc

 *Moled wrote:*   

> 
> 
> what chipset revision does it claim you to have?
> 
> 

 

I have only one Maxtor SATA plus only one 80G Seagate ST380021A PATA drive attached to the primary IDE interface.

(BTW, I had to select "SCSI" from the BOOT menú in the bios to boot from the SATA drive instead of the PATA drive  :Question:  )

 *dmesg wrote:*   

> 
> 
> SiI3112 Serial ATA: IDE controller at PCI slot 0000:01:0b.0
> 
> SiI3112 Serial ATA: chipset revision 2
> ...

 

 *lspci -vv wrote:*   

> 
> 
> 01:0b.0 RAID bus controller: CMD Technology Inc Silicon Image SiI 3112 SATARaid Controller (rev 02)
> 
>         Subsystem: CMD Technology Inc: Unknown device 6112
> ...

 

----------

## behd

 *Heretic wrote:*   

> 
> 
> Right.  2.6 has many performance enhancements.  Software RAID is the fastest RAID you can do for just 2 drives.

 

Is there any way to boot a kernel 2.6.0 in raid0 (ataraid) ?

```
VFS cannot open root device "720a" or unknown-block(114,10)
```

(with this lilo settings: root = /dev/ataraid/d0p10)

Config:

```

P4G8X Deluxe (i7205 w/ Silraid 3112)

Only 2 Seagate SATA disk (ST380023AS)

```

I've read somewhere that there's no more /dev/ataraid/ support in kernel 2.6.0. So does it means that we are forced to use software raid with such kernel ? is the software raid compatible with the hw raid array created with the SiliconImage controller ?

Thanks for any info !

----------

## Heretic

No, you were already using inefficient software RAID, and no.

The SI3112 never did hardware RAID, it was always BIOS assisted software RAID, and it was really slow at that.  ataraid is gone for that reason.

----------

## behd

So it would means that people which have installed their OS with SI3112 raid won't be able to switch to a 2.6.n kernel ? (or wil have to re-install every OS hosted on such config, aaaargh... )

> The SI3112 never did hardware RAID, it was always BIOS assisted software RAID, 

> and it was really slow at that. ataraid is gone for that reason.

What do you mean by really slow at that ? almost the same as using only one disk ?

(isn't there any boost  when dealing with large files ?? NB. I directly setuped my computer with raid0, so I can't say if there's a lot of difference with or without the raid...). btw. do you have any benchmark ?

Thanks anyway for your answer  :Very Happy: 

----------

## Heretic

 *behd wrote:*   

> So it would means that people which have installed their OS with SI3112 raid won't be able to switch to a 2.6.n kernel ? (or wil have to re-install every OS hosted on such config, aaaargh... )

 

You need a temporary harddrive.  Boot into 2.4, cp -a all the files under root (besides /proc /mnt and /sys) to /mnt/tempdisk.  Boot 2.6 off of the temp disk, redo the RAIDs, cp -a everything back.

 *Quote:*   

> What do you mean by really slow at that ? almost the same as using only one disk ?
> 
> (isn't there any boost  when dealing with large files ?? NB. I directly setuped my computer with raid0, so I can't say if there's a lot of difference with or without the raid...). btw. do you have any benchmark ?
> 
> Thanks anyway for your answer 

 

I mean ataraid was half as efficient as linux software raid.  Linux software raid is a highly tuned machine, the ataraid stuff had a shitty disk layout.  As for benchmarks, I've benched software RAID1 and RAID0 on the SI3112A with 2 WD360GDs.

RAID1 performance is near optimal.  I'm getting 50MB/s sequential write throughput, and 100MB/s parallel sequential read throughput--50MB/s max per sequential read.  RAID1 increased average seeks/sec by 80% over a single harddrive and reduces overall read latency.  The RAID1 code tracks head locality on drives and uses the drive with heads positioned closest to the requested sector for lowest latency.  It's absolutely perfect for my mission critical database.

RAID0 performance was not as good as it could have been (75MB/s v 100MB/s on ICH5s).  I suspect this is do to limitations of the PCI bus and raw speed of the harddrives with their large caches.  On RAID0, I think the overhead of stripping small blocks saturates the PCI bus with ATA overhead.

----------

## taskara

this has been a great read - thanks Ryan and Bart  :Wink: 

----------

## ktech

hello.

I thinks it's off-topic, but perhaps any of you can help me. I have an nforce-2 motherboard with pata and sata support. The sata is throught the SI 3112 controller.

It's an Athlon 2500+ and I have my Seagate Barracuda V ST380023A (PATA) HD connected to the PATA controller and I get this in hdparm:

/dev/hda:

 Timing buffer-cache reads:   1780 MB in  2.00 seconds = 889.25 MB/sec

 Timing buffered disk reads:   98 MB in  3.02 seconds =  32.42 MB/sec

I think 32 MB/sec in this drive is very little, don't you think that?

The motherboard cames with a PATA to SATA adapter. Do you think I can gain any speed if I connect my HD to SATA in this way?

Thanks a lot!

----------

## taskara

hi,

the converter will give you ZERO performance gain.

it's probably more an issue of running in the correct dma mode, and having the right driver installed etc.

what kernel are you using

and can u post 

```
hdparm /dev/hda

hdparm -i /dev/hda
```

----------

## Heretic

 *taskara wrote:*   

> hi, the converter will give you ZERO performance gain.

 

You'll actually take a performance hit from a PATA<->SATA converter.

----------

## ktech

Hello

I was not talking again gaining performance with the converter, but with the "more advanced" controller.

The motherboard is an nforce-2 so I think the "amd and nvidia ide" is the correct.

I have enabled in kernel config the options:

* ATAPI support

* Enhanced IDE....

* Include IDE / ATA2 DISK support

* Use multi-mode by default

* Include IDE/ATAPI cdrom support

* PCI ide chipset support

* Generic PCI Bus-Master DMA support

* Use PCI DMA by default when available

* AMD and nVidia IDE support

* Silicon Image chipset support

bash-2.05b# hdparm -i /dev/hda

/dev/hda:

 Model=ST380023A, FwRev=3.53, SerialNo=3KA140JH

 Config={ HardSect NotMFM HdSw>15uSec Fixed DTR>10Mbs RotSpdTol>.5% }

 RawCHS=16383/16/63, TrkSize=0, SectSize=0, ECCbytes=4

 BuffType=unknown, BuffSize=2048kB, MaxMultSect=16, MultSect=16

 CurCHS=16383/16/63, CurSects=16514064, LBA=yes, LBAsects=156301488

 IORDY=on/off, tPIO={min:240,w/IORDY:120}, tDMA={min:120,rec:120}

 PIO modes:  pio0 pio1 pio2 pio3 pio4 

 DMA modes:  mdma0 mdma1 mdma2 

 UDMA modes: udma0 udma1 udma2 udma3 udma4 *udma5 

 AdvancedPM=no WriteCache=enabled

 Drive conforms to: ATA/ATAPI-6 T13 1410D revision 2: 

 * signifies the current active mode

----------

## ktech

sorry.... I forget this:

bash-2.05b# hdparm /dev/hda

/dev/hda:

 multcount    = 16 (on)

 IO_support   =  1 (32-bit)

 unmaskirq    =  1 (on)

 using_dma    =  1 (on)

 keepsettings =  0 (off)

 readonly     =  0 (off)

 readahead    = 256 (on)

 geometry     = 65535/16/63, sectors = 156301488, start = 0

bash-2.05b# 

I think I followed the suggestion by one guy that say setting the Read-ahead to 4K but nothing improved.

Thanks!

----------

## ktech

And I gorgot mentioning that I'm running 2.6-mm2 kernel.

I have tried with 2.6.0 test-x in the past.... even 2.6.0.... no improvements...

I'm using 2.6.0-mm2 because someone says me it improves performance in nforce2 motherboards because in this kernel I can enable APIC / LAPCI.

Thanks and sorry for all of this posts...

----------

## taskara

ahh ok.. well I think that's prob about right.

2.4 kernel is faster than 2.6 for amd ide.

under 2.4 you'd prob get 40-45 or so

also your drive only has 2mb cache.. and people with 7200rpm with 8mb cache get about 40-45..

everything is set correctly... 

oh one final thought, do u have something on hdb? if so, move it and try again..

----------

## ktech

No, I have nothing in hdb... only hdc...

Then... do you suggest me something more to try?

Have you heard something about _why_ is 2.4 fastest that 2.6? Or perhaps any plan to improve the driver?

Do you think I can get faster speeds with SATA controller throught PATA-SATA adapter?

Thanks!

----------

## taskara

no idea.. I remember switching from 2.4 to 2.6 and got slower speeds on the ide controller - it may be because the old driver (at faster speeds) was causing some problems, no idea.

and I don't think you will get any performance increase from the converter, like someone else said it will prob run slower.

----------

## sneakerski

well, i'm using the same kernel and this patch is included, i've got 2 maxtor 160GB plus 9s in RAID 0. performance is around 110MB/s on the sil 3112 controller, it's atleast worth giving a shot removing the converter. incidentally i've got the nf7-s too (v2)

----------

## ktech

What set of patches do you recommends me in order to run a Seagate drive in the Si 3112 chip?

it's not that I don't believe you, but I must try this because my transfer speeds suck so much.

Thanks!

P.S.: I'm using now 2.6.0-mm2

----------

## taskara

 *ktech wrote:*   

> What set of patches do you recommends me in order to run a Seagate drive in the Si 3112 chip?
> 
> it's not that I don't believe you, but I must try this because my transfer speeds suck so much.
> 
> Thanks!
> ...

 

latest mm sources is the best I believe because it includes the latest patch-fix

----------

## PrakashP

@Heretic

Nice work you did, I just saw this thread now. Checked siimage 1.09 and so far the best driver I had. Nevertheless a few issues:

I have a Samsung pata drive connected to siimage with bios 4.2.43 via pata->sata converter (has some benefits for me).

With all older drivers I could not do hdparm -d1 /dev/hde. (Nevertheless the drive was in fast dma mode from boot onwards, so only issue for me was unability to use swsusp.) Then I would get controller reset and crapping up, so that I would have press the reset button. Now this doesn't happen, but my drive (or controller) doesn't get into DMA mode. hdparm -t just gives me a few miserable mb/sec. dmesg (tried -d1 twice):

hde: dma_intr: status=0xd0 { Busy }

hde: DMA disabled

ide2: reset phy, status=0x00000113, siimage_reset

ide2: reset: success

hde: sata_error = 0x00000000, watchdog = 0, siimage_mmio_ide_dma_test_irq

hde: dma_intr: status=0xd0 { Busy }

hde: DMA disabled

ide2: reset phy, status=0x00000113, siimage_reset

ide2: reset: success

 But using -d1 -X69 gives me back my speed. So far so good.

But nevertheless I am constantly getting this error/warning on drive access:

hde: sata_error = 0x00000000, watchdog = 0, siimage_mmio_ide_dma_test_irq

Any ideas how to fix this? This one is really nasty as I have to comment it out in the driver.

Below a few infos which might be useful. Would be great if you could help me or at least advise me how to fix it.

dmesg:

SiI3112 Serial ATA: IDE controller at PCI slot 0000:01:0b.0

SiI3112 Serial ATA: chipset revision 2

SiI3112 Serial ATA: 100% native mode on irq 18

    ide2: MMIO-DMA , BIOS settings: hde:DMA, hdf:DMA

    ide3: MMIO-DMA , BIOS settings: hdg:pio, hdh:pio

hde: SAMSUNG SP1614N, ATA DISK drive

ide2 at 0xf981c080-0xf981c087,0xf981c08a on irq 18

hde: max request size: 64KiB

hde: 312581808 sectors (160041 MB) w/8192KiB Cache, CHS=19457/255/63, UDMA(100)

 /dev/ide/host2/bus0/target0/lun0: p1 p2 p3 < p5 p6 p7 >

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

/dev/hde:

 Model=SAMSUNG SP1614N, FwRev=TM100-24, SerialNo=0735J1FW702444

 Config={ HardSect NotMFM HdSw>15uSec Fixed DTR>10Mbs }

 RawCHS=16383/16/63, TrkSize=34902, SectSize=554, ECCbytes=4

 BuffType=DualPortCache, BuffSize=8192kB, MaxMultSect=16, MultSect=16

 CurCHS=16383/16/63, CurSects=16514064, LBA=yes, LBAsects=268435455

 IORDY=on/off, tPIO={min:240,w/IORDY:120}, tDMA={min:120,rec:120}

 PIO modes:  pio0 pio1 pio2 pio3 pio4

 DMA modes:  mdma0 mdma1 mdma2

 UDMA modes: udma0 udma1 udma2

 AdvancedPM=no WriteCache=enabled

 Drive conforms to: (null):

 * signifies the current active mode

ATA device, with non-removable media

        Model Number:       SAMSUNG SP1614N

        Serial Number:      0735J1FW702444

        Firmware Revision:  TM100-24

Standards:

        Supported: 7 6 5 4

        Likely used: 7

Configuration:

        Logical         max     current

        cylinders       16383   65535

        heads           16      1

        sectors/track   63      63

        --

        CHS current addressable sectors:    4128705

        LBA    user addressable sectors:  268435455

        LBA48  user addressable sectors:  312581808

        device size with M = 1024*1024:      152627 MBytes

        device size with M = 1000*1000:      160041 MBytes (160 GB)

Capabilities:

        LBA, IORDY(can be disabled)

        Queue depth: 1

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

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

        Recommended acoustic management value: 254, current value: 0

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

             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

                Automatic Acoustic Management 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

                supported: enhanced erase

        96min for SECURITY ERASE UNIT. 96min for ENHANCED SECURITY ERASE UNIT.

HW reset results:

        CBLID- below Vih

        Device num = 0 determined by the jumper

Checksum: correct

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

/dev/hde:

 Timing buffer-cache reads:   2040 MB in  2.00 seconds = 1019.14 MB/sec

 Timing buffered disk reads:  184 MB in  3.03 seconds =  60.74 MB/sec

----------

## ballyn

 *PrakashKC wrote:*   

> @Heretic
> 
> Nice work you did, I just saw this thread now. Checked siimage 1.09 and so far the best driver I had. Nevertheless a few issues:

 

What kernel are you using?

----------

## GTVincent

I have tried the patch, but with it my computer hangs during read/write mounting of the file systems.

/dev/hda: 120 GB WD SATA

/dev/hdc: 36GB Raptor SATA

A7N8X Deluxe/SiI3112

kernel 2.6.1

without the patch:

/dev/hda:

 Timing buffer-cache reads:   1420 MB in  2.00 seconds = 708.34 MB/sec

 Timing buffered disk reads:   60 MB in  3.08 seconds =  19.50 MB/sec

/dev/hdc:

 Timing buffer-cache reads:   1380 MB in  2.00 seconds = 689.42 MB/sec

 Timing buffered disk reads:   86 MB in  3.02 seconds =  28.49 MB/sec

I'm not unhappy, but faster would be nicer...

----------

## taskara

 *GTVincent wrote:*   

> I have tried the patch, but with it my computer hangs during read/write mounting of the file systems.
> 
> /dev/hda: 120 GB WD SATA
> 
> /dev/hdc: 36GB Raptor SATA
> ...

 

you could try mm-sources 2.6-r1 it has the patch included I believe.

emerge it and see what speed u get.

----------

## PrakashP

@ballyn

2.6.1-love1

----------

## Heretic

 *PrakashKC wrote:*   

> 
> 
> dmesg:
> 
> SiI3112 Serial ATA: IDE controller at PCI slot 0000:01:0b.0
> ...

 

I find it very interesting that the BIOS defaults to DMA on the first channel...  and the imaginary slave channel.  Neither my development 3112A board, nor the P4G8X Deluxe with 3112A onboard defaulted to anything but PIO.

 *Quote:*   

> 
> 
>  IORDY=on/off, tPIO={min:240,w/IORDY:120}, tDMA={min:120,rec:120}
> 
>  PIO modes:  pio0 pio1 pio2 pio3 pio4
> ...

 

What the hell?  You have no active mode set, and udma modes 3-5 don't show up.  udma5 = ATA100.  I would suggest flashing your BIOS to the newest revision if you have not done so yet.

 *Quote:*   

> Capabilities:
> 
>         LBA, IORDY(can be disabled)
> 
>         Queue depth: 1
> ...

 

Oh... now it shows up?

 *Quote:*   

> /dev/hde:
> 
>  Timing buffer-cache reads:   2040 MB in  2.00 seconds = 1019.14 MB/sec
> 
>  Timing buffered disk reads:  184 MB in  3.03 seconds =  60.74 MB/sec

 

That's not bad.  Why must you put this PATA drive on the SATA controller?  The only time I had problems like yours was when I turned off my SATA hot-swap enclosure.  Even after unmounting everything, when I turn it back on the drive does not get properly reprogrammed and will timeout.  You cannot hot-swap SATA yet on Linux yet, and especially not with the siimage driver.  Check your cables.  I also had a problem when one of my cable become a little unseated.

----------

## PrakashP

BIOS is latest (and AFAIK with older ones it was the same).

I put the drive to SATA, as I want my DVD-ROM and CD-RW have a channel for their own, so all devices are independant. SO I have maximum performance. I think my cable is OK (all firmly inserted). I am sure it is a driver issue. Only this hde: sata_error = 0x00000000, watchdog = 0, siimage_mmio_ide_dma_test_irq message is really annoying. Do you have an idea why it *constantly* appears? (If it wasn't clear: Every time data is transfered from hd, this message appears, thus dmesg gets flooded...)

Using libata siimage I have no annoying messages and everything seems fine (except that swsusp doesn't currently support scsi layer).

What is really strange: I cannot (well I don't want to;)) make the kernel to init my hd in pio mode, ie even if I don't select DMA on in the kernel compile options, the HD on siimage will be running in DMA mode, so I don't understand, which path the driver takes in my case.

----------

## Heretic

If I were you, I'd either share a channel or get a cheap PATA controller.  I, personally, wouldn't put my fast harddrive on the shared PCI bus if I could avoid it.

----------

## PrakashP

? In which way do I share the PCI Bus? (And what would another card do better?) I think my configuration is already a very efficient one. Using APIC, every IDE controller has its own interrupt.

----------

## GTVincent

I tried the love1-r1 sources, but the computer still hangs at mounting filesystems read/write. This time, however, it got me this interesting bit of info:

```
 * Remounting rootystem read/write...

journal-601, buffer write failed

-------------[ cut here ]-----------

kernel BUG at fs/reiserfs/prints.c:339!

invalid operand: 0000 [#1]

PREEMPT

CPU:    0

EIP:    0060:[<c01cae07>]    Not tainted VLI

EFLAGS: 00010286

EIP is at reiserfs_panic+0x37/0x70

eax: 00000024   ebx: f7c57e00   ecx: c02eb970   edx: 00000282

esi: f880e0d8   edi: 00000000   ebp: f75f5dd0   esp: f75f5dc0

ds: 007b   es: 007b   ss: 0068

Process mount (pid: 183, threadinfo=f75f4000 task=f75f7980)

Stack: c02bb10c c037e220 f880e0d8 000005d9 f75f5e0c c01d6817 f7c57e00 c02c98e0

       00001000 f880e0b0 000005d9 00000005 00000003 00000000 00000002 f76c53f0

       00000000 00000000 f7511000 f75f5e74 c01db462 f7c57e00 f880e0d8 00000001

Call Trace:

 [<c01d6817>] flush_commit_list+0x2d7/0x460

 [<c01db462>] do_journal_end+0xa42/0xc70

 [<c01d9e57>] journal_end+0x27/0x30

 [<c01c8c5b>] reiserfs_remount+0x15b/0x230

 [<c0157ce9>] sync_blockdev+0x39/0x50

 [<c015d60a>] do_remount_sb+0xba/0x120

 [<c0173d5c>] do_remount+0xbc/0xf0

 [<c017441d>] do_mount+0x17d/0x190

 [<c013cf25>] __get_free_pages+0x35/0x40

 [<c017422e>] copy_mount_options+0x9e/0x110

 [<c01747f3>] sys_mount+0xc3/0x120

 [<c02a6a9f>] syscall_call+0x7/0xb

Code: e8 2f f3 00 00 8d 45 10 89 44 24 04 8b 45 0c 89 04 24 e8 0d fe ff ff c7 44

 24 04 20 e2 37 c0 c7 04 24 0c b1 2b c0 e8 99 27 f5 ff <0f> 0b 53 01 4c 04 2c c0

 b8 4f 00 2c c0 8d 93 18 01 00 00 85 db

 /sbin/rc: line 313:   183 Segmentation fault      mount / -n -o remount,rw >&/dev/null

 * Root filesystem could not be mounted read/write:(                      [!!]

en_request: I/O error, dev hda, sector 169475175

Buffer I/O error on device hda6, logical block 886923

end_request: I/O error, dev hda, sector 169475175

Buffer I/O error on device hda6, logical block 885923

/sbin/rc: line 66: /sbin/sulogin: Input/output error
```

So I think it's not a PCI error as much as it is a reiserfs error. Who would be interested in this backtrace?

----------

## Heretic

 *PrakashKC wrote:*   

> ? In which way do I share the PCI Bus? (And what would another card do better?) I think my configuration is already a very efficient one. Using APIC, every IDE controller has its own interrupt.

 

The IDE controller on your southbridge isn't on the slow, easily saturated 133MB/sec PCI bus.  What chipset do you use?  nforce2?  The north and south bridge are linked by a 533MB/sec to 1.06GB/sec connection.  The embedded IDe controller uses this faster connection so you get better performance.

----------

## PrakashP

Uh OK, now I undestand what you are saying. I think the speed difference can be neglected, as it only matters in burst transmissions. On the other hand, using WIn2k (have to do it sometimes) SATA has no problem with the 128GB barrier while w2k with ide has (at least in my case). I know some sp should fix it, but I had some troubles and was sick of it.

----------

## Heretic

 *PrakashKC wrote:*   

> ...using WIn2k (have to do it sometimes) SATA has no problem with the 128GB barrier while w2k with ide has (at least in my case)...

 

Yea, that sux.  Can't help you with Microsoft problems. I'd call their tech support, lol.

----------

## PrakashP

So coming back to my original problem. Do you think you could help me fixing the driver?

----------

## denials

Released today: Andrew Morton's 2.6.1-mm2 patch set (ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.1/2.6.1-mm2) included the following patches, which is that much closer to being in the vanilla kernel (and should make our lives a little easier):

ide-siimage-seagate.patch

 - limit requests to 15kB only for Seagate SATA drives

ide-siimage-stack-fix.patch

 - Heretic's patch, as discussed here (kudos again!)

ide-siimage-sil3114.patch 

 - recognizes a new 4-port Siimage controller

libata-update.patch

 - [libata sata_sil] add support for adaptec 1210sa, 4-port sii 3114

 - libata sata_svr] fix DRV_NAME to reflect actual driver filename  

 - [libata sata_sil] unmask interrupts during initialization

Haven't tried it yet, but looking forward to the results.

----------

## Heretic

 *denials wrote:*   

> ...much closer to being in the vanilla kernel...
> 
> ide-siimage-stack-fix.patch
> 
>  - Heretic's patch, as discussed here (kudos again!)
> ...

 

Linus doesn't believe my fix should work.  I still have to provide him more proof I think, despite all the success stores of my pactches.

Here's a couple emails from the exchange:

```
On Tue, 6 Jan 2004, Bartlomiej Zolnierkiewicz wrote:

>>> >

>>> > What kind of strange report was this? I don't see how the thing _possibly_

>>> > could make any difference at all.

>

>> 

>> /me thought the same first, but I couldn't verify this (lack of hardware).

Ok. I really can't see any way that "u32" -> "u16" change could change 

anything at all, if there isn't some compiler bug involved. The compiler 

definitely should be passing the value as a 16-bit thing regardless of 

what the variable type is.

Actually, in the x86 calling convention, it should always be _passed_ as a 

32-bit value, and it's really the callee that should always just read the 

16 bits.

Ryan, can you compile the drivers/ide/pci/siimage.c file to assembly

before and after your change, so that we can see what the difference is?  

Also, can you tell us what compiler version you're using?

      Linus

```

```

Here's the diff from my box:

--- siimage.s.16        2004-01-06 06:13:45.000000000 -0600

+++ siimage.s.32        2004-01-06 06:14:44.000000000 -0600

@@ -481,9 +481,8 @@

        movl    1036(%esi), %eax

        testl   %eax, %eax

        je      .L335

-       movzwl  %bp, %eax

        movl    %ebx, 4(%esp)

-       movl    %eax, (%esp)

+       movl    %ebp, (%esp)

        call    *976(%esi)

        movzwl  14(%esp), %eax

        movl    %edi, 4(%esp)

@@ -523,8 +522,7 @@

        movl    824(%esi), %eax

        movl    %eax, (%esp)

        call    pci_write_config_word

-       movzwl  %bp, %eax

-       movl    %eax, 8(%esp)

+       movl    %ebp, 8(%esp)

        movl    %edi, 4(%esp)

        movl    824(%esi), %eax

        movl    %eax, (%esp)

-ryan

>> Thanks. All my machines are gcc-3.3 by now, and the diff from changing the

>> u32 to a u16 is literally:

>>

>>    --- /home/torvalds/siimage.s    2004-01-05 17:19:27.860992398 -0800

>>    +++ drivers/ide/pci/siimage.s   2004-01-05 17:19:40.275187848 -0800

>>    @@ -474,8 +474,9 @@

>>            movl    1296(%esi), %eax

>>            testl   %eax, %eax

>>            je      .L79

>>    +       movzwl  %bp, %eax

>>            movl    %ebx, 4(%esp)

>>    -       movl    %ebp, (%esp)

>>    +       movl    %eax, (%esp)

>>            call    *1236(%esi)

>>            movzwl  18(%esp), %eax

>>            movl    %edi, 4(%esp)

>>    @@ -518,9 +519,10 @@

>>            movl    16(%edx), %eax

>>            movl    %eax, (%esp)

>>            call    pci_bus_write_config_word

>>    +       movzwl  %bp, %eax

>>            movl    1060(%esi), %edx

>>    -       movl    %ebp, 12(%esp)

>>            movl    %edi, 8(%esp)

>>    +       movl    %eax, 12(%esp)

>>            movl    32(%edx), %eax

>>            movl    %eax, 4(%esp)

>>            movl    16(%edx), %eax

>>

>> which _definitely_ can't matter, since the only difference is literally

>> the 16->32 zero expansion, but since "bp" is always in the 16-bit range,

>> that ends up being effectively just a regulal move.

>>

>> It is quite possible that some version of gcc-3.2 did the 16-bit argument

>> push wrong, though. I'd love to have that confirmed, because that would

>> definitely mean that the compiler is totally unusable for the kernel..

>>

>>       Linus
```

```

On Tue, 6 Jan 2004, J. Ryan Earl wrote:

>>>>

>>>> Here's the diff from my box:

>

>>

>> This _literally_ can't make any difference. Are you sure that diff makes

>> the difference? Maybe it was your other part - the one that disabled the

>> sector limits?

>>

>> Th eonly thing the u16/u32 thing does is zero-extension of a value that is

>> already zero-extended (and that the callee won't even look at the high

>> bits of:

>>

>>    ide_mm_outw:

>>            movl    4(%esp), %edx

>>            movl    8(%esp), %eax

>>            movw    %dx, (%eax)

>>            ret

>>

>>

>> It will load the full 32-bit value off the argument list, but it will only

>> use the low 16 bits.

>>

>>       Linus

I would suggest it has something to do with signed-ness.  The zero

expansion probably gaurantees proper signed/unsigned expansion.  I am

still out of town, so I can't load up the driver with printk's to see the

actual value of speedt as used, but I am absolutely sure this change is

what resulted in stability.  The difference is night and day.  I increased

the request buffer from 15->128 without the u32->u16 change which resulted

in equally if not worse stability.  I'm talking crash and burn, no HD

response within 5-10 minutes of stress testing.  With the patch it runs

for days moving terrabytes of data around with no problems and much higher

performance metrics.

-ryan

```

Everybody that has had the patches fix their problems should probably email me their `dmesg`, `lspci -vv`, and `hdparm -i` so that I can start compiling a list as proof/evidence of success.

mailto:heretic@clanhk.org?subject="siimage success"

----------

## PrakashP

Uhhhmm, does siimag.c v1.09 now contain Heretic's fix or not?   :Confused: 

----------

## Heretic

 *PrakashKC wrote:*   

> Uhhhmm, does siimag.c v1.09 now contain Heretic's fix or not?  

 

My fix was the change between 1.07 and 1.08.

----------

## PrakashP

OK, I checked it and it is in 1.09 though the seagate stuff a bit altered (smarter).

BTW, my CPU is 15% at linear reading.

----------

## GTVincent

Heretic, do you have more reports of this fix interfering with reiserfs, or, for that matter, with any other fs? Or am I the only one?

Since the performance gain using your patch will always come in handy, I would love to be able to see if it does anything for me. Preferably without reformatting, of course  :Smile: 

----------

## PrakashP

I am using 2.6.1-love1 and reiserfs and so far no probs.

----------

## Heretic

 *GTVincent wrote:*   

> Heretic, do you have more reports of this fix interfering with reiserfs, or, for that matter, with any other fs? Or am I the only one?
> 
> Since the performance gain using your patch will always come in handy, I would love to be able to see if it does anything for me. Preferably without reformatting, of course 

 

I run reiserfs.  No problems.

You might have problems if your reiserfs partition became corrupted before you installed the patch though...  did you reiserfsck it?

BTW, I stayed with the gs-sources kernel plus my patch on my production server: 2.4.23_pre8-gss

----------

## estebann

I seem to be in precisely the same boat as GTVincent.

reiserfs

Kernel: 2.6.1-mm2

HD: ST380013AS

MB: Leadtek Winfast k7ncr18d-proII

Any help you could give would be greatly appreciated.

----------

## ballyn

Try using the libata drivers (Device Drivers -> SCSI -> SCSI low-level drivers -> Serial ATA (SATA) support -> Silicon Image SATA support). You'll need to disable the "native" IDE driver ("Silicon Image chipset support" under IDE) and disable "Select only drivers expected to compile cleanly"... This seems to be a much more stable driver right now.

I think what Vincent mentioned was that sw suspend(?) doesn't work correctly with the scsi subsystem, however, so you might lose that functionality?

I'd love to hear the results of some tests with one driver vs. the other...

----------

## Heretic

 *ballyn wrote:*   

> Try using the libata drivers (Device Drivers -> SCSI -> SCSI low-level drivers -> Serial ATA (SATA) support -> Silicon Image SATA support). You'll need to disable the "native" IDE driver ("Silicon Image chipset support" under IDE) and disable "Select only drivers expected to compile cleanly"... This seems to be a much more stable driver right now.
> 
> I think what Vincent mentioned was that sw suspend(?) doesn't work correctly with the scsi subsystem, however, so you might lose that functionality?
> 
> I'd love to hear the results of some tests with one driver vs. the other...

 

Uhhh...  There's a reason sata_sil is listed as BROKEN.  It doesn't mask all the SATA PHY specific interrupts yet.  Try it, but don't be surprised when you lock up your system.  It failed under stress testing for me.  I tested the IDE version thoroughly as well; much more robust.

----------

## estebann

Thanks for the reply, I tried the scsi driver and it booted fine, but as heretic warned it would lock up the first time I did anything hd intensive.  So, If I can be of any further assistance to you or you to me, It would please me to provide or recieve it.

----------

## Heretic

 *GTVincent wrote:*   

> Heretic, do you have more reports of this fix interfering with reiserfs, or, for that matter, with any other fs? Or am I the only one?
> 
> Since the performance gain using your patch will always come in handy, I would love to be able to see if it does anything for me. Preferably without reformatting, of course 

 

I use reiserfs, and have had no problems.  Not even my tests on the 2.6 kernel have problems with reiserfs.

However, note the 2.6 kernel isn't as stable as 2.4 was.  I had to stay with 2.4 for my production server 'cause I need stability above all else.

----------

## ballyn

Update to libata:

Jeff Garzik (the developer working on libata) posted this yesterday... In general, he suggests using the ide driver instead (so I recant my earlier suggestion about using libata...  :Smile:  ).

List:       linux-kernel

Subject:    [SATA] libata update posted, and news

From:       Jeff Garzik <jgarzik () pobox ! com>

Date:       2004-01-15 0:34:53

Updates to the Silicon Image and ServerWorks drivers.

News:

* will freeze current codebase as libata 1.0, without queueing support. 

  libata 2.x development has already begun, and will support queueing, 

sata2, and will build upon the existing codebase.

* ServerWorks seems stable, will remove 'beta' label soon

Notes:

* Silicon Image support is still considered to be unstable. 

drivers/ide's siimage.c is preferred.

* Silicon Image users with Seagate SATA, particularly if you know if you 

have the "mod15write" bug, should make sure that the driver is properly 

applying the errata fix.

ChangeSet@1.1513, 2004-01-14 18:44:53-05:00, benh@kernel.crashing.org

  [libata sata_svw] cleanup, better probing

  * use fewer magic numbers

  * probe all 4 ports, using standard SATA SCRs

  * limit udma mask to 0x3f

  * clean up PPC-specific procfs stuff

ChangeSet@1.1512, 2004-01-14 18:34:48-05:00, arubin@atl.lmco.com

  [libata sata_sil] add pci id for Silicon Image 3512

ChangeSet@1.1511, 2004-01-14 18:19:36-05:00, normalperson@yhbt.net

  [libata sata_sil] cleaner, better version of errata workarounds

  No longer unfairly punishes non-errata Seagate and Maxtor drives.

ChangeSet@1.1474.72.3, 2004-01-06 04:26:01-05:00, marchand@kde.org

  [libata sata_sil] add support for adaptec 1210sa, 4-port sii 3114

ChangeSet@1.1474.72.2, 2004-01-06 04:22:09-05:00, jgarzik@redhat.com

  [libata sata_svr] fix DRV_NAME to reflect actual driver filename

ChangeSet@1.1474.61.1, 2003-12-30 19:46:09-05:00, jgarzik@redhat.com

  [libata sata_sil] unmask interrupts during initialization

  Prudent in general, and needed for Adaptec BIOSes.

----------

## Tony420

does anyone know why my nf7-s 2.0 (3112) shows up as two drives? and will this effect it meaning its not raid0?

----------

## taskara

 *Tony420 wrote:*   

> does anyone know why my nf7-s 2.0 (3112) shows up as two drives? and will this effect it meaning its not raid0?

 

that means you are not using a raid driver under linux

but linux is detecting the drives seperately, in NONraid status

----------

## Tony420

i striped them...do I need to format them in windows first or somthing?

----------

## taskara

 *Tony420 wrote:*   

> i striped them...do I need to format them in windows first or somthing?

 

no - it means linux is not using the raid driver, just the silicon ide driver.

you need to load the silicon image raid driver, then you will see /dev/ataraid/disc device, instead of two seperate drives.

are you booting with 2004.0 livecd? I don't know if it supports ataraid, but you can try booting to it with

gentoo doataraid

and see if that works.. someone else here can probably tell you

----------

## Tony420

I am booting with doataraid...

----------

## taskara

then I suggest that the livecd does not actually support RAID for yoursilicon image controller.

in which case you will need to find some other way to achieve the gentoo install.

perhaps you can install a stage3 on a seperate NONraided disk, then create your own kernel which supports silicon image raid, then you shoudl be able to use that stage3 install like a livecd and start installing gentoo to the raid device.

other than that not much I can help with. you'll need to talk to people who actually have a silicon image raid controller, and ask how they got it working.

you might need to start a new thread asking about silicon raid and 2004.0 livecd.

good luck!

----------

## Tony420

im using gentoo right now on IDE   :Twisted Evil:    i have sata support compiled already and everything...can you elaborate on what I need to do? I can setup my fstab properly i think

----------

## Tony420

on another note, i havent mounted the sata or even booted with the drives spiinning yet, i will get it working while you tell me what to do  :Smile: 

----------

## taskara

oh ok.. well you'll need to give me more details.

what drive is your linux installed on?

what drives are connected to silicon image? are they in raid0?

what kernel are you using?

are you also dual booting with windows?

----------

## slycordinator

This is too confusing...

Ok, I'm building a computer (just have a couple parts to go but am saving at the moment) but I will be using a WD2000JD SATA drive through a GA-7NNXP (which uses the 3112 controller).

All I want to do is dual-boot gentoo and XP Pro, both installed on this drive.

And if it matters, I'll be using knoppix 3.3 (which uses kernel 2.4.23-xfs) to do the install.

So what do I need to do to have this happen?  And sorry if this was answered earlier... my head aches too much right now for me to read through everything.

edit: and I won't be doing anything special like RAID

----------

## teknik0s

Ok, linux nub here.  I have some sata problems, heres my setup.

Athlon Xp 3200+

1gb Corsair DDR400

Abit NF7-S Mobo

WD Raptor 36GB Sata (hde)

60GB Maxtor IDE (goning to try to connect via the ABIT IDE-2-Serial connector, which would make this hdg)

I got the 2.6.5 development sources, hdg=noprobe, acpi is ON, and when i boot up it freezes (sometimes).  I've read you guys posts about the 15kb transfer needing to be 128 or w/e, kinda confusing, im just skimming.  Also i see this patch.  Its been 4 months or so since this post was started, the patch that you made still hasnt made it into effect?  How do i get my hdd speed.  Also, it was a PAIN to get this working, is there a way to increase my hdd speed, minimize my freeze times.  I have NO clue how to patch, im not even sure if the patch is in effect by now.  What can i do??

i take that back, it freezes EVERY time there is moderate to heavy cpu usage.

Thanks!

----------

## ktech

Hello.

Even with this is not completly related to this thread... any of you knows why I'm getting so slow speeds with this hd? It's a Paralel ATA, but I think lots of people is getting better results that this. I have even tried to connect it to S-ATA with an adaptator I have, but the same results:

/dev/hda:

 Timing buffer-cache reads:   2020 MB in  2.00 seconds = 1009.14 MB/sec

 Timing buffered disk reads:  106 MB in  3.01 seconds =  35.19 MB/sec

ATA device, with non-removable media

        Model Number:       ST380023A

Could this drive has a bug, as the model is similar to ST380023AS or something like that, or this is only in SATA models?

I have preempt enabled.

----------

## Boworr

I've been banging my head against a tree with this one. I can't get the 2.6.gentoo-r3 sources to pick up my sata disks. If someone that has an Asus A7N8X Deluxe board with this working, can the PM their .config file so I can do a diff against it?

----------

## Smoothhound

@ktech:

You probably want to check out  this thread

It seems hdparm does not give accurate results in this situation.

----------

## lucif3r

Thanks for the patch, it is working great for me.  Although I had to make the changes manually in 2.4.27.  It appears the line numbers are different.  Perhaps new comments have been added.

Also note that 2.4.28 seems to be broken.  I only got it to boot by copying the siimage.c and siimage.h from 2.4.27 into the source tree.  I have not done a diff to find out what has changed yet.

----------

## lucif3r

Ok this seems to be the diff with 2.4.28

*** 1198,1203 ****

--- 1195,1202 ----

  static struct pci_device_id siimage_pci_tbl[] __devinitdata = {

        { PCI_VENDOR_ID_CMD, PCI_DEVICE_ID_SII_680,  PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0},

+ #ifdef CONFIG_BLK_DEV_IDE_SATA

        { PCI_VENDOR_ID_CMD, PCI_DEVICE_ID_SII_3112, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 1},

        { PCI_VENDOR_ID_CMD, PCI_DEVICE_ID_SII_1210SA, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 2},

+ #endif

        { 0, },

  };

I am not entirely sure why this would be a problem.  Can anyone enlighten me?  

The effect of not having the two lines with the '+' is that the driver doesn't load on boot, but why?

----------

