SATA very slow Mepis 3.4.3 and 6.0 ..
Posts: 7
I've got a machine with Mepis 2004.02 and a Seagate SATA drive (/dev/hde) running at 55MB/sec.
I brought up another machine (similar MB and Drive) with Mepis 3.4.3 (also tried 6.0) .. drive mounts
as /dev/sda and gets a blinding 14MB/sec
I tried booting 3.4.3 (LiveCD) on my old machine (the 55MB/sec guy)
and it gets .. .. 14MB/sec
This implies drivers / kernel ..
I know there have been a lot of Sil Image 3112 / Seagate / blacklisting /libata / sata_sil
problems but I thought that had all worked out ..
'messages' implies that everyone is happy ..
Jul 29 17:23:12 localhost kernel: ata1: SATA max UDMA/100 cmd 0xF8802080 ctl 0xF880208A bmdma 0xF8802000 irq 177
Jul 29 17:23:12 localhost kernel: ata2: SATA max UDMA/100 cmd 0xF88020C0 ctl 0xF88020CA bmdma 0xF8802008 irq 177
Jul 29 17:23:12 localhost kernel: ata1: dev 0 ATA-6, max UDMA/133, 234441648 sectors: LBA48
Jul 29 17:23:12 localhost kernel: ata1(0): applying Seagate errata fix
Jul 29 17:23:12 localhost kernel: ata1: dev 0 configured for UDMA/100
Jul 29 17:23:12 localhost kernel: scsi0 : sata_sil
------
Jul 29 17:23:12 localhost kernel: Vendor: ATA Model: ST3120026AS Rev: 3.18
Jul 29 17:23:12 localhost kernel: Type: Direct-Access ANSI SCSI revision: 05
Jul 29 17:23:12 localhost kernel: SCSI device sda: 234441648 512-byte hdwr sectors (120034 MB)
Jul 29 17:23:12 localhost kernel: SCSI device sda: drive cache: write back
Jul 29 17:23:12 localhost kernel: SCSI device sda: 234441648 512-byte hdwr sectors (120034 MB)
Jul 29 17:23:12 localhost kernel: SCSI device sda: drive cache: write back
Jul 29 17:23:12 localhost kernel: sda: sda1 sda2 sda3
Jul 29 17:23:12 localhost kernel: sd 0:0:0:0: Attached scsi disk sda
Jul 29 17:23:12 localhost kernel: sd 0:0:0:0: Attached scsi generic sg0 type 0
The drivers look like they're in the kernel .. I thought I might revert to the siimage
driver since as an IDE (/dev/hde) it worked better ..
Anyone else seen this problem .. or better yet anyone have any suggestions?
Thanks,
Tom
SATA still slow ..
Posts: 7
Jim,
Tried the hdparm -d /dev/sda
and it returned nothing ..
hdparm -d1 /dev/sda
said 'Invalid IOCTL' ..
Your suggestion was for /dev/hdxx .. any thought on
how I can get it to be /hdxx instead of /dev/sda?
I think recompiling the kernel is the only way ..
Almost ready to buy a Western Digital drive ..
Tom
SATA still slow ..
Posts: 2280
The only thing i can think of is keep trying {hdparm -d ]with other /dev/sdx combos till maybe the system will give you a little more to go on. The first part of the command seems to be written in stone its after -d thats unknown with those drives to me, Hopefully if you play with it a while the system will helpout. Or try hdparm --help and see what you get .
jim
SATA still slow ..
Posts: 2280
Ya know after thinking a bit im wondering in your case if it might just be DMA needs to be turned on in the bios. Its something you could have a look at, and it would cause a major problem . Bios is the begenning of all things & should be checked just make sure its not the culprit if you havent allready done so .
jim
Took easy way out ..
Posts: 7
Jim,
I played around a bit more .. no luck ..
I bought a WD3200JD (320GB SATA) .. plugged it in ..
62MB/sec .. I'll just put the old drive in my other machine ..
I think that it was the blacklisting of the Seagate drive
in the sata_sil driver that was the problem .. I would have
had to revert to the siimage driver to get it to mount as
/dev/hdxx which would have meant a kernel recompile .. and
I'm under the gun to get this guy working ..
Thanks very much for the suggestions ..
Tom
Took easy way out ..
Posts: 2280
Probably the best way bad drivers allmost as bad as snafud hardware. Anyway im glad you got it going 14meg/sec isnt too swift these days. But in the right rig it'll come alive.
On the other hand i was thinking hdparm would fix er up but it goes to show ya never know when playin with these buggers it seems they get more complicated & keeping up is a chore.
jim
SATA very slow
Posts: 2280
We just went through this the other day on another rig thinking dma was off but yours sounds like a more likely candidate. Try hdparm -d /dev/hdxxx and see what you get. If its off or set to zero set it to one or on.
jim