[Silicon Image&Seagate] ontzettend traag

[robbert]

Hoi,

in mijn server zit een Asus a7n8x deluxe moederbord met een Silicon Image Sil 3112A Controller. Ik heb hier nu twee Seagate ST3160023AS 160 gb schrijven op aan gesloten. Op het eerste gezicht leek alles te werken, de controller werd direct herkent en de schrijven kregen mooi /dev/sda en /dev/sdb toegewezen.
Hardeschijven gepartitioneert (bijde een grote 160 gb partitie), een voor allerlei data en de andere voor backups. Tot zo verre werkt het allemaal, alleen kwam ik er achter dat het ontzettend traag gaat. Eens hdparm gedaan:

code:

server:~# hdparm -tT /dev/sda
/dev/sda:
 Timing cached reads:   1200 MB in  2.00 seconds = 599.49 MB/sec
 Timing buffered disk reads:   44 MB in  3.04 seconds =  14.49 MB/sec
server:~# hdparm -tT /dev/hda
/dev/hda:
 Timing cached reads:   1224 MB in  2.01 seconds = 609.96 MB/sec
 Timing buffered disk reads:  170 MB in  3.03 seconds =  56.08 MB/sec

Zoals je ziet haalt de sata schijf de 15 MB/s nog niet eens terwijl een pata schrijf (hitachi) bijna 60 MB/s haalt.

Ik had wat gezocht op google en kwam tot de conclusie dat er problemen waren met seagate schrijven en die sil controller.
Een oplossing zou zijn om in plaats van de sata_sil module siimage te gebruiken. Met modconf sata_sil verwijderd, siimage geinstalleerd. Helaas nu werd er helemaal geen schijf gevonden. Reboot dan maar eens, echter werden nu gewoon weer sata_sil geladen (en siimage maar die doet naar mijn idee niks).

Zou iemand hier een oplossing voor weten? Of kan ik net zo goed een andere controller kopen? De Promise SATA150 TX4 (4x SATA150, PCI32/66) leek me wel wat. Alleen wil ik dan wel weten of het probleemloos zou moeten werken, niet dat ik dan 70 euro aan een kaart uit geef die weer problemen blijkt te geven.

Server specs:
Debian 3.1 Sarge met 2.6.8-1-k7 kernel
AMD Athlon 1800+
512 MB pc2100 ddr RAM
Asus a7n8x deluxe met Silicon Image Sil 3112A
hda: HDS722580VLAT20
hdb: ST3120026A
hdc: ST3120023A
2 x Seagate 7200.7 sata 160 gb ST3160023AS

[JaQ]

er is een patch uit voor de 2.4.22 kernel, die een hoop problemen met deze chipset oplost. Ik ben nu zelf al een dag op onderzoek omdat ik een machine wil upgraden van RedHat 9 naar Fedora Core 3. Deze machine heeft dezelfde chipset (en SATA disks dus). Ik ga er maar vanaf zien omdat:

1. de 2.6 kernel nog steeds geen goede ondersteuning bied
2. ik geen enorme downtime wil (een dag is ok, maar ik ben bang dat er meer tijd nodig is)
3. ik er geen vertrouwen in heb dat ik dit eenvoudig op kan lossen (te veel vragen via google, te weinig antworoden).

Een draadje dat voor jou misschien nuttig is, is deze. Als klopt waar hier staat zou je dus en een optie aan hdparm mee moeten geven, en een kernel parameter voor je idebus moeten meegeven.

succes.

[robbert]

Ik wil het liefste 2.6 kernel draaien, desnoods koop ik een andere controller. Om terug te gaan naar de 2.4.x kernel met een patch lijkt mijn helaas geen optie.
Met google zijn inderdaad erg veel vragen te vinden, helaas zijn er weinig/geen antwoorden te vinden
Ik heb die thread nog niet helemaal gelezen, maar staan daar ook oplossingen voor de 2.6 kernel?

Ik ga eerst maar eens die thread verder lezen.

[robbert]

^ kick ^, iemand nog een idee hoe die controller werkend te krijgen onder de 2.6 kernel met seagate schijven?

Ik denk dat ik maar de Promise SATA150 TX4 (4x SATA150, PCI32/66) bestel, ik kon met google weinig/geen problemen vinden met die controller icm met seagate schrijven en linux.

[_JGC_]

Wat is de output van dmesg?

code:

libata version 1.02 loaded.
ata1: SATA max UDMA/133 cmd 0xD800 ctl 0xD402 bmdma 0xC800 irq 17
ata2: SATA max UDMA/133 cmd 0xD000 ctl 0xCC02 bmdma 0xC808 irq 17
ata1: dev 0 cfg 49:2f00 82:346b 83:7f01 84:4003 85:3c68 86:3c01 87:4003 88:00ff
ata1: dev 0 ATA, max UDMA7, 234493056 sectors: lba48
ata1: dev 0 configured for UDMA/133
scsi0 : sata_sis
ata2: dev 0 cfg 49:2f00 82:346b 83:7f01 84:4003 85:3c68 86:3c01 87:4003 88:00ff
ata2: dev 0 ATA, max UDMA7, 234493056 sectors: lba48
ata2: dev 0 configured for UDMA/133
scsi1 : sata_sis
  Vendor: ATA       Model: SAMSUNG SP1213C   Rev: SV10
  Type:   Direct-Access                      ANSI SCSI revision: 05
  Vendor: ATA       Model: SAMSUNG SP1213C   Rev: SV10
  Type:   Direct-Access                      ANSI SCSI revision: 05

Bovenstaande is wat ik krijg met een SiS controller gebruikmakend van de libata sata_sis driver. Overigens draait die bak op 2.6.7, welke perfect werkt met SiS SATA controllers.

Edit:
Ik zie net dat je harddisks in de blacklist staan voor Silicon Image controllers. Reden: silicon image controllers sturen data pakketjes over de SATA bus die niet altijd 512 bytes zijn, iets wat gewoon klopt volgens de SATA specs. Wat het probleem nou is, is dat veel seagate disks, waaronder de jouwe, altijd uitgaan van 512byte packets. Andere controllers zoals de promise die je noemt of mijn SIS onboard controller op mijn el-cheapo asrock bord hebben zeer waarschijnlijk geen problemen, omdat deze gewoon 512byte pakketjes de bus op sturen.

Wat je kunt doen is de oudere siimage driver gebruiken, waarbij je niet /dev/sda krijgt als devices, maar iets in de trant van /dev/hde.

Edit2:
Ik heb even de source van siimage doorgelezen, maar je zult met die driver ook soortgelijke performance krijgen ben ik bang. De "Seagate fixup" wordt op dezelfde manier in die drivers gedaan. Je hebt dus een aantal opties:
- Vervang de seagates door WD, IBM of Samsung
- Vervang de Silicon Image controler door een willekeurige andere controler

[ Voor 36% gewijzigd door _JGC_ op 19-12-2004 18:42 ]

[robbert]

relevante stuk van dmesg

code:

SCSI subsystem initialized
libata version 1.02 loaded.
sata_sil version 0.54
ACPI: PCI interrupt 0000:01:0b.0[A] -> GSI 11 (level, low) -> IRQ 11
ata1: SATA max UDMA/100 cmd 0xE0845080 ctl 0xE084508A bmdma 0xE0845000 irq 11
ata2: SATA max UDMA/100 cmd 0xE08450C0 ctl 0xE08450CA bmdma 0xE0845008 irq 11
ata1: dev 0 cfg 49:2f00 82:346b 83:7d01 84:4003 85:3469 86:3c01 87:4003 88:207f
ata1: dev 0 ATA, max UDMA/133, 312581808 sectors: lba48
ata1(0): applying Seagate errata fix
ata1: dev 0 configured for UDMA/100
scsi0 : sata_sil
ata2: dev 0 cfg 49:2f00 82:346b 83:7d01 84:4003 85:3469 86:3c01 87:4003 88:207f
ata2: dev 0 ATA, max UDMA/133, 312581808 sectors: lba48
ata2(0): applying Seagate errata fix
ata2: dev 0 configured for UDMA/100
scsi1 : sata_sil
  Vendor: ATA       Model: ST3160023AS       Rev: 3.18
  Type:   Direct-Access                      ANSI SCSI revision: 05
  Vendor: ATA       Model: ST3160023AS       Rev: 3.18
  Type:   Direct-Access                      ANSI SCSI revision: 05
Capability LSM initialized

Ik had al geprobeerd om siimage te gebruiken in plaats van sata_sil. Ik had met modconf sata_sil uit gezet en siimage aangezet. Hierna vond ik geen enkele sata harddisk meer. Naar een reboot gebruikte die ook gewoon weer sata_sil.

[robbert]

_JGC_ schreef op zondag 19 december 2004 @ 17:59:
Edit2:
Ik heb even de source van siimage doorgelezen, maar je zult met die driver ook soortgelijke performance krijgen ben ik bang. De "Seagate fixup" wordt op dezelfde manier in die drivers gedaan. Je hebt dus een aantal opties:
- Vervang de seagates door WD, IBM of Samsung
- Vervang de Silicon Image controler door een willekeurige andere controler

Als ik het goed begrijp is de combinatie Seagate, Silicon Image en Linux (vrijwel) niet voor elkaar te krijgen? Dan bestel ik denk ik maar die Promise controller.

[ Voor 5% gewijzigd door robbert op 19-12-2004 18:45 ]

[_JGC_]

Je kunt nog proberen de held uit te hangen en je disk in scsi/sata_sil.c uit de blacklist te halen, ik heb het een en ander gelezen over gefixte 3.18 firmware, maar daarvan ben ik niet zeker.

De blacklist kijkt alleen naar modelnummers, niet naar revisies van schijven, je hebt dus kans dat het gaat werken. Mocht het zooitje niet werken: heb een goede backup van je SATA disks, want je seagate disks hangen zichzelf op aan een silicon image controler als de bug getriggerd wordt, wat resulteert in filesystem corruptie.

[robbert]

_JGC_ schreef op zondag 19 december 2004 @ 18:54:
Je kunt nog proberen de held uit te hangen en je disk in scsi/sata_sil.c uit de blacklist te halen, ik heb het een en ander gelezen over gefixte 3.18 firmware, maar daarvan ben ik niet zeker.

De blacklist kijkt alleen naar modelnummers, niet naar revisies van schijven, je hebt dus kans dat het gaat werken. Mocht het zooitje niet werken: heb een goede backup van je SATA disks, want je seagate disks hangen zichzelf op aan een silicon image controler als de bug getriggerd wordt, wat resulteert in filesystem corruptie.

Om de de schijf uit de blacklist te gaan halen lijkt me niet zo'n goed idee, want in een corrupt filesystem heb ik niet echt veel zin in. Want die data verlies ik niet graag, dan geef ik liever wat geld uit aan een andere controller.
Toch hartstikke bedankt voor je hulp!