Gentoo Forums
Gentoo Forums
Gentoo Forums
Quick Search: in
Silicon Image 3112 SerialATA FIX! (kernel patch inside)
View unanswered posts
View posts from last 24 hours

Goto page 1, 2, 3, 4, 5  Next  
Reply to topic    Gentoo Forums Forum Index Kernel & Hardware
View previous topic :: View next topic  
Author Message
Heretic
Tux's lil' helper
Tux's lil' helper


Joined: 03 Jul 2002
Posts: 114
Location: Austin, TX USA

PostPosted: Tue Dec 02, 2003 9:36 am    Post subject: Silicon Image 3112 SerialATA FIX! (kernel patch inside) Reply with quote

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:

Code:
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:
Code:
*** /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.
Back to top
View user's profile Send private message
barlad
l33t
l33t


Joined: 22 Feb 2003
Posts: 673

PostPosted: Tue Dec 02, 2003 9:53 am    Post subject: Reply with quote

Nice one. What kernel does it apply to?
I have not seen any problem with SiI & 2.6.0 - test 10 kernel.
Back to top
View user's profile Send private message
Heretic
Tux's lil' helper
Tux's lil' helper


Joined: 03 Jul 2002
Posts: 114
Location: Austin, TX USA

PostPosted: Tue Dec 02, 2003 10:03 am    Post subject: Reply with quote

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.
Back to top
View user's profile Send private message
barlad
l33t
l33t


Joined: 22 Feb 2003
Posts: 673

PostPosted: Tue Dec 02, 2003 5:34 pm    Post subject: Reply with quote

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
ide2: MMIO-DMA at 0xf8806000-0xf8806007, BIOS settings: hde:pio, hdf:pio
ide3: MMIO-DMA at 0xf8806008-0xf880600f, BIOS settings: hdg:pio, hdh:pio
hde: Maxtor 6Y160M0, ATA DISK drive
ide2 at 0xf8806080-0xf8806087,0xf880608a on irq 21
hdg: no response (status = 0xfe)
hdg: no response (status = 0xfe), resetting drive
hdg: no response (status = 0xfe)
hde: max request size: 64KiB
hde: 320173056 sectors (163928 MB) w/7936KiB Cache, CHS=19929/255/63
/dev/ide/host2/bus0/target0/lun0: p1 p2
Back to top
View user's profile Send private message
Kesereti
Guru
Guru


Joined: 07 Nov 2002
Posts: 520

PostPosted: Tue Dec 02, 2003 6:14 pm    Post subject: Reply with quote

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:

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


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

Code:

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
Back to top
View user's profile Send private message
Heretic
Tux's lil' helper
Tux's lil' helper


Joined: 03 Jul 2002
Posts: 114
Location: Austin, TX USA

PostPosted: Tue Dec 02, 2003 9:12 pm    Post subject: Reply with quote

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.
Back to top
View user's profile Send private message
i_hate_your_os
Tux's lil' helper
Tux's lil' helper


Joined: 29 Aug 2002
Posts: 128
Location: Manhattan Beach, CA

PostPosted: Tue Dec 02, 2003 10:59 pm    Post subject: Cool. Reply with quote

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

"All laws which are repugnant to the constitution are null and void."
-Marbury vs. Madison, 5 US (2 Cranch) 137, 174, 176, (1803)
Back to top
View user's profile Send private message
Heretic
Tux's lil' helper
Tux's lil' helper


Joined: 03 Jul 2002
Posts: 114
Location: Austin, TX USA

PostPosted: Tue Dec 02, 2003 11:07 pm    Post subject: Re: Cool. Reply with quote

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.
Back to top
View user's profile Send private message
Kesereti
Guru
Guru


Joined: 07 Nov 2002
Posts: 520

PostPosted: Wed Dec 03, 2003 2:49 am    Post subject: Reply with quote

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 =\
Back to top
View user's profile Send private message
Kesereti
Guru
Guru


Joined: 07 Nov 2002
Posts: 520

PostPosted: Wed Dec 03, 2003 5:25 am    Post subject: Reply with quote

Code:

/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 ^_^
Back to top
View user's profile Send private message
Heretic
Tux's lil' helper
Tux's lil' helper


Joined: 03 Jul 2002
Posts: 114
Location: Austin, TX USA

PostPosted: Wed Dec 03, 2003 12:19 pm    Post subject: Reply with quote

Kesereti wrote:
Code:

/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 ^_^


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:

Code:
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:

Code:
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:

Code:
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
Back to top
View user's profile Send private message
archimedelemalin
n00b
n00b


Joined: 05 Aug 2003
Posts: 15

PostPosted: Thu Dec 04, 2003 1:54 am    Post subject: Reply with quote

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)
Code:
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

Code:
/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

:(
Back to top
View user's profile Send private message
Heretic
Tux's lil' helper
Tux's lil' helper


Joined: 03 Jul 2002
Posts: 114
Location: Austin, TX USA

PostPosted: Thu Dec 04, 2003 3:09 am    Post subject: Reply with quote

Here is the 2.6.0-test11 diff.

Code:
# 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++:

Code:
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.
Back to top
View user's profile Send private message
Kesereti
Guru
Guru


Joined: 07 Nov 2002
Posts: 520

PostPosted: Thu Dec 04, 2003 7:56 am    Post subject: Reply with quote

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

Code:

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 ^_^
Back to top
View user's profile Send private message
archimedelemalin
n00b
n00b


Joined: 05 Aug 2003
Posts: 15

PostPosted: Thu Dec 04, 2003 10:36 am    Post subject: Reply with quote

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.
Back to top
View user's profile Send private message
Heretic
Tux's lil' helper
Tux's lil' helper


Joined: 03 Jul 2002
Posts: 114
Location: Austin, TX USA

PostPosted: Thu Dec 04, 2003 10:45 am    Post subject: Reply with quote

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.
Back to top
View user's profile Send private message
Heretic
Tux's lil' helper
Tux's lil' helper


Joined: 03 Jul 2002
Posts: 114
Location: Austin, TX USA

PostPosted: Thu Dec 04, 2003 12:27 pm    Post subject: Reply with quote

archimedelemalin wrote:
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.


What command are you using to patch? You can just do it by hand, it's pretty simple. test11?
Back to top
View user's profile Send private message
Kesereti
Guru
Guru


Joined: 07 Nov 2002
Posts: 520

PostPosted: Thu Dec 04, 2003 3:07 pm    Post subject: Reply with quote

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.


Code:

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


^_^
Back to top
View user's profile Send private message
barnie
n00b
n00b


Joined: 04 Jul 2003
Posts: 21

PostPosted: Fri Dec 05, 2003 3:56 pm    Post subject: doesn't cure the problem Reply with quote

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?
Back to top
View user's profile Send private message
barnie
n00b
n00b


Joined: 04 Jul 2003
Posts: 21

PostPosted: Fri Dec 05, 2003 4:18 pm    Post subject: success Reply with quote

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.
Back to top
View user's profile Send private message
Heretic
Tux's lil' helper
Tux's lil' helper


Joined: 03 Jul 2002
Posts: 114
Location: Austin, TX USA

PostPosted: Fri Dec 05, 2003 11:28 pm    Post subject: Reply with quote

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.
Back to top
View user's profile Send private message
barnie
n00b
n00b


Joined: 04 Jul 2003
Posts: 21

PostPosted: Sun Dec 07, 2003 9:41 am    Post subject: pio by default Reply with quote

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:
Code:
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):
Code:
all_args="-d1 -X udma2 -c1 -m16"
Back to top
View user's profile Send private message
Heretic
Tux's lil' helper
Tux's lil' helper


Joined: 03 Jul 2002
Posts: 114
Location: Austin, TX USA

PostPosted: Sun Dec 07, 2003 10:37 am    Post subject: Re: pio by default Reply with quote

barnie wrote:
Excerpt from dmesg:
Code:
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):
Code:
all_args="-d1 -X udma2 -c1 -m16"


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.
Back to top
View user's profile Send private message
Hey!
n00b
n00b


Joined: 07 Dec 2003
Posts: 20

PostPosted: Mon Dec 08, 2003 12:48 am    Post subject: Reply with quote

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.
Back to top
View user's profile Send private message
Heretic
Tux's lil' helper
Tux's lil' helper


Joined: 03 Jul 2002
Posts: 114
Location: Austin, TX USA

PostPosted: Mon Dec 08, 2003 4:04 am    Post subject: Reply with quote

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.

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.


First, don't run hdparm on the harddrive with -X70. My hdparm has:
Code:
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.
Back to top
View user's profile Send private message
Display posts from previous:   
Reply to topic    Gentoo Forums Forum Index Kernel & Hardware All times are GMT
Goto page 1, 2, 3, 4, 5  Next
Page 1 of 5

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum