| View previous topic :: View next topic |
| Author |
Message |
RoundsToZero
Guru
Joined: 17 Nov 2003
Posts: 478
Location: New York, NY
|
 Posted: Fri Mar 31, 2006 1:24 am Post subject: How to enable ATA133 on SiS964? |
 |
|
I recently noticed that the hard drives on my new motherboard are only running at UDMA(33) when I know they should be faster. I have the kernel driver enabled for my IDE controller, so that's not the problem. What seems to be the problem is what I found in sis5513.c:
| Code: |
/*
* The original SiS5513 comes from a SiS5511/55112/5513 chipset. The original
* SiS5513 was also used in the SiS5596/5513 chipset. Thus if we see a SiS5511
* or SiS5596, we can assume we see the first MWDMA-16 capable SiS5513 chip.
*
* Later SiS chipsets integrated the 5513 functionality into the NorthBridge,
* starting with SiS5571 and up to SiS745. The PCI ID didn't change, though. We
* can figure out that we have a more modern and more capable 5513 by looking
* for the respective NorthBridge IDs.
*
* Even later (96x family) SiS chipsets use the MuTIOL link and place the 5513
* into the SouthBrige. Here we cannot rely on looking up the NorthBridge PCI
* ID, while the now ATA-133 capable 5513 still has the same PCI ID.
* Fortunately the 5513 can be 'unmasked' by fiddling with some config space
* bits, changing its device id to the true one - 5517 for 961 and 5518 for
* 962/963.
*/
|
It looks like mine is the last case. From the Googling I've done, it looks like setting the device ID to 5518 should work for my 964 as well. I just don't know what config space bits to "fiddle" with. |
|
| Back to top |
|
 |
Corona688
Veteran
Joined: 10 Jan 2004
Posts: 1204
|
| Posted: Fri Mar 31, 2006 2:13 am Post subject: |
|
|
I'm not sure it means "config space" in the /proc or /sys sense. It might be probing configuration registers on the chip to see if it changes it's device ID, detecting ata133 that way. I don't see anything in that particular driver exposing any userspace configuration... rechecking the source, I'm pretty sure that's what it's doing.
But try the obvious first, if you haven't already. Can hdparm change it to ata133? Are you sure it's the controller that's limiting it and not the drives?
_________________
Petition for Better 64-bit ATI Drivers - Sign Here
http://www.petitiononline.com/atipet/petition.html |
|
| Back to top |
|
|
RoundsToZero
Guru
Joined: 17 Nov 2003
Posts: 478
Location: New York, NY
|
| Posted: Fri Mar 31, 2006 2:23 am Post subject: |
|
|
| How would I do tihs? I've only used hdparm to check if DMA is enabled and to do -Tt. |
|
| Back to top |
|
|
Corona688
Veteran
Joined: 10 Jan 2004
Posts: 1204
|
| Posted: Fri Mar 31, 2006 2:34 am Post subject: |
|
|
'man hdparm'
| Code: | badassumptions ~ # hdparm -I /dev/hda
/dev/hda:
ATA device, with non-removable media
Model Number: Maxtor 6B200P0
Serial Number: B411WG4H
Firmware Revision: BAH41BM0
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: 398297088
device size with M = 1024*1024: 194481 MBytes
device size with M = 1000*1000: 203928 MBytes (203 GB)
Capabilities:
LBA, IORDY(can be disabled)
Queue depth: 32
Standby timer values: spec'd by Standard, no device specific minimum
R/W multiple sector transfer: Max = 16 Current = 16
Advanced power management level: unknown setting (0x0000)
Recommended acoustic management value: 192, current value: 0
DMA: mdma0 mdma1 mdma2 udma0 udma1 udma2 udma3 udma4 udma5 *udma6
Cycle time: min=120ns recommended=120ns
PIO: pio0 pio1 pio2 pio3 pio4
Cycle time: no flow control=120ns IORDY flow control=120ns
Commands/features:
Enabled Supported:
* NOP cmd
* 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
Advanced Power Management feature set
* DOWNLOAD MICROCODE cmd
* SMART self-test
* SMART error logging
Security:
Master password revision code = 65534
supported
not enabled
not locked
frozen
not expired: security count
not supported: enhanced erase
HW reset results:
CBLID- above Vih
Device num = 0 determined by CSEL
Checksum: correct |
It shows my maxtor drive as supporting udma6 and running at udma6 aka ata133.
If any of your drives don't support >ata66, I believe it will slow the entire channel it's attached to, to it's speed. Lots of CDROMS etc only work up to ata66.
_________________
Petition for Better 64-bit ATI Drivers - Sign Here
http://www.petitiononline.com/atipet/petition.html |
|
| Back to top |
|
|
RoundsToZero
Guru
Joined: 17 Nov 2003
Posts: 478
Location: New York, NY
|
| Posted: Fri Mar 31, 2006 2:51 am Post subject: |
|
|
Thank you very much. This is my configuration. As you can see I have not put CD drives on the same controller as the hard drive.
Mobo controller 1: one hard drive (hda)
amsa ~ # hdparm -I /dev/hda | grep DMA
DMA: mdma0 mdma1 mdma2 udma0 udma1 *udma2 udma3 udma4 udma5
This seems like a problem
Mobo controller 2: CD-ROM drive (hdc)
amsa ~ # hdparm -I /dev/hdc | grep DMA
DMA: mdma0 mdma1 mdma2 udma0 udma1 *udma2
So it looks like my other hard drive is performing only as well as the CD
My Promise card seems to be doing alright
amsa ~ # hdparm -I /dev/hde | grep DMA
DMA: mdma0 mdma1 mdma2 udma0 udma1 udma2 udma3 udma4 *udma5
amsa ~ # hdparm -I /dev/hdg | grep DMA
DMA: mdma0 mdma1 mdma2 udma0 udma1 udma2 udma3 udma4 udma5 *udma6
amsa ~ # hdparm -I /dev/hdf | grep DMA
DMA: mdma0 mdma1 mdma2 udma0 udma1 udma2 udma3 udma4 udma5 *udma6
This is correct I know one of those three hd's is only supposed to be ATA100 |
|
| Back to top |
|
|
Corona688
Veteran
Joined: 10 Jan 2004
Posts: 1204
|
| Posted: Fri Mar 31, 2006 7:02 am Post subject: |
|
|
Speaking of checking the obvious first, that drive is on an 80-conductor cable, right? Do you have another cable you could try? Anyway...
You can attempt to force the drive to use ata133 like so:
| Code: | | hdparm -d1 -X70 /dev/hda |
I think, since 'man hdparm' says the number is 64 plus the udma#... But second-guessing the hard drive controller is often a bad idea(setting it higher, anyway, setting it lower is probably safe enough) -- if the driver knew what it was doing, then you've put it into a mode which really can't work, so it may freeze, corrupt your data, set your dog on fire, whatever...
And if your kernel is truly failing to detect the chip's ata133-capability, that's a bug. Upgrading might fix it. I'd try that before I forced a faster DMA setting on my own computer...
Another point I'd like to make is that ata66 really isn't that bad. Upping it to ata133 will make hdparm's cache benchmark look better but won't really improve your drive's performance -- even at ata66, the bus is STILL probably faster than the drive. Two drives might saturate the channel, but one, no.
_________________
Petition for Better 64-bit ATI Drivers - Sign Here
http://www.petitiononline.com/atipet/petition.html |
|
| Back to top |
|
|
RoundsToZero
Guru
Joined: 17 Nov 2003
Posts: 478
Location: New York, NY
|
| Posted: Fri Mar 31, 2006 1:42 pm Post subject: |
|
|
Alright, thanks. Unfortunately I don't have any extra cables to try. I can try switching cables around the next time I open up my case, as I'm sure some are higher quality than others. I agree with you on not forcing a higher speed. However, according to dmesg the drive is running at 33 not 66:
| Code: |
hda: max request size: 128KiB
hda: Host Protected Area detected.
current capacity is 117187500 sectors (60000 MB)
native capacity is 117231408 sectors (60022 MB)
hda: Host Protected Area disabled.
hda: 117231408 sectors (60022 MB) w/2048KiB Cache, CHS=65535/16/63, UDMA(33)
hda: cache flushes not supported
hda: hda1 hda2 hda3
|
It's not like I noticed any glaring speed performance problems, it just kind of surprised me to see this in dmesg, and then when I read the comments in the source file, it seemed to confirm my thoughts that the kernel wouldn't detect the new chipset properly.
Thanks for looking into my case! |
|
| Back to top |
|
|
Corona688
Veteran
Joined: 10 Jan 2004
Posts: 1204
|
| Posted: Fri Mar 31, 2006 2:37 pm Post subject: |
|
|
One last thought. Unlike 40-conductor cables, 80-conductor cables won't work perfectly with the connectors reversed... I've sometimes had to plug the "wrong" end of the IDE cable in the board to make it reach all drives, but that's no good these days; unlike the old 40-conductors, 80-conductor cables are not straight-through cables. Plug the wrong end of the cable in the board and it will fail to detect the 80-conductor cable, throttling the speed down.
_________________
Petition for Better 64-bit ATI Drivers - Sign Here
http://www.petitiononline.com/atipet/petition.html |
|
| Back to top |
|
|
RoundsToZero
Guru
Joined: 17 Nov 2003
Posts: 478
Location: New York, NY
|
| Posted: Fri Mar 31, 2006 2:43 pm Post subject: |
|
|
| I think it is actually a two-connector cable but I'll check. If it is three-connector, how do I tell the connectors apart? |
|
| Back to top |
|
|
|
Kernel & Hardware
