Can someone please explain what's wrong here. And how to solve it.
I run CentOS-4.1 MSI K8N Neo Platinum Athlon 3000 Seagate Barracuda 7200.7 S-ATA disc
[root@amd64 kai]# /sbin/hdparm -tT /dev/sda
/dev/sda: Timing cached reads: 2808 MB in 2.00 seconds = 1402.81 MB/sec HDIO_DRIVE_CMD(null) (wait for flush complete) failed: Inappropriate ioctl for device Timing buffered disk reads: 166 MB in 3.01 seconds = 55.07 MB/sec HDIO_DRIVE_CMD(null) (wait for flush complete) failed: Inappropriate ioctl for device [root@amd64 kai]# [root@amd64 kai]# /sbin/hdparm -i /dev/sda
/dev/sda: HDIO_GET_IDENTITY failed: Inappropriate ioctl for device [root@amd64 kai]#
On Wednesday 07 September 2005 09:44, Kai wrote:
Can someone please explain what's wrong here. And how to solve it.
[root@amd64 kai]# /sbin/hdparm -tT /dev/sda
hdparm is only for IDE devices:
DESCRIPTION hdparm provides a command line interface to various hard disk ioctls supported by the stock Linux ATA/IDE device driver subsystem.
-- Jason
Does it exist a tool for sata? Or are there no need?
kai
Jason McCormick wrote:
On Wednesday 07 September 2005 09:44, Kai wrote:
Can someone please explain what's wrong here. And how to solve it.
[root@amd64 kai]# /sbin/hdparm -tT /dev/sda
hdparm is only for IDE devices:
DESCRIPTION hdparm provides a command line interface to various hard disk ioctls supported by the stock Linux ATA/IDE device driver subsystem.
-- Jason
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Kai centos.newsgroup@sandsengen.com wrote:
Does it exist a tool for sata? Or are there no need?
Has nothing to do with SATA (although libata does, see below).
hdparm _only_ works when the Integrated Drive Electronics (IDE) are talking directly to the system over the AT Attachment (ATA) arbitrator.
IN OTHER WORDS: That means the device _must_ appear as a /dev/hd* block device so hdparm can work.
When the device is supported via the SCSI subsystem, which is typical of newer ATA/SATA drivers that are not yet feature complete, all bets are off. They _may_ be supported via various SCSI-2 commands, but most of the time, they are not.
YOUR BEST BET: Use "modinfo -p" on the vendor's SCSI driver to see what options are supported at load time.
Understand that ATA is typically statically compiled in for all ATA device support, and hdparm is a way to control individual ATA channels. Unlike SCSI modules, which can have individual module options, and therefore can be individually controlled.
Now there is the libata support library. I haven't investigated it much, let alone I don't know if it requires ATA (hd) or it can also support SCSI (sd). I think it can support both, but I haven't gotten into it yet to even know what it features.
IN THE END: SATA requires _little_ optimization. There is no "EIDE" or other "PIO" IDE backward compatibility AFAIK, only full UltraATA compliant modes. SATA was designed to _avoid_ a lot of the issues ATA had with EIDE and other backward compatibility, while still be backward compatible with newer ATA specifications.
So, are you having a particular issue with SATA? If so, have you investigated the SATA module's options yet? If not, then that's your first move.
Thank you very much for your apply. No there's no specific issue, I am doing studies on linux and now, optimizing the linux system. Started on the disc's, I'm also trying to customizing a kernel for my system's. Just digging in, and digging my own grave I guess. :)
kai
Bryan J. Smith wrote:
Kai centos.newsgroup@sandsengen.com wrote:
Does it exist a tool for sata? Or are there no need?
Has nothing to do with SATA (although libata does, see below).
hdparm _only_ works when the Integrated Drive Electronics (IDE) are talking directly to the system over the AT Attachment (ATA) arbitrator.
IN OTHER WORDS: That means the device _must_ appear as a /dev/hd* block device so hdparm can work.
When the device is supported via the SCSI subsystem, which is typical of newer ATA/SATA drivers that are not yet feature complete, all bets are off. They _may_ be supported via various SCSI-2 commands, but most of the time, they are not.
YOUR BEST BET: Use "modinfo -p" on the vendor's SCSI driver to see what options are supported at load time.
Understand that ATA is typically statically compiled in for all ATA device support, and hdparm is a way to control individual ATA channels. Unlike SCSI modules, which can have individual module options, and therefore can be individually controlled.
Now there is the libata support library. I haven't investigated it much, let alone I don't know if it requires ATA (hd) or it can also support SCSI (sd). I think it can support both, but I haven't gotten into it yet to even know what it features.
IN THE END: SATA requires _little_ optimization. There is no "EIDE" or other "PIO" IDE backward compatibility AFAIK, only full UltraATA compliant modes. SATA was designed to _avoid_ a lot of the issues ATA had with EIDE and other backward compatibility, while still be backward compatible with newer ATA specifications.
So, are you having a particular issue with SATA? If so, have you investigated the SATA module's options yet? If not, then that's your first move.
Kai centos.newsgroup@sandsengen.com wrote:
Thank you very much for your apply. No there's no specific issue, I am doing studies on linux and now, optimizing the linux system.
As with any SCSI host adapter, the optimizations can be done at the module (driver) itself. Again, run "modinfo -p" on the SCSI host adapter driver (e.g., for nVidia's SATA, "modinfo -p nv_sata"). Unlike WD/ESDI/IDE/ATA, which is typically one large portion of the static kernel, the SCSI subsystem is a modular and flexible stack of support.
Started on the disc's, I'm also trying to customizing a kernel for my system's. Just digging in, and digging my own grave I guess. :)
Except for embedded, I haven't rebuilt a kernel since Red Hat Linux 6.1. By Red Hat Linux 6.2, everything was so well done, modular-wise, I just started building initrds, as well as kernels from .src.rpm when I needed to patch.
-
Bryan J. Smith -
Jason McCormick -
Kai