This message is from the T13 list server.
Last week David F. wrote:
I'm not sure if this has been addressed but this was something I came across
quite a while ago that was annoying.
Yes, it is but my suggestion is to relax and learn to live with it - it
is only going to get worse.
Using the SET FEATURES to set the various modes, such as PIO mode, doesn't
seem to have any affect unless you reprogram the host - which requires
figuring out the chipset.
Absolutely correct. While there is a "basic" standard for a PCI bus
based PATA host controller (also emulated by some SATA host controllers)
that standard, T13's 1510 Host Controller Standard, does not say
anything about how a controller's PIO and DMA modes are set. I have lots
of people asking me all the time "how can I test all the PIO and DMA
modes?"... The answer is: You need the detailed host controller
documentation, usually in the format of some very poorly written
"chipset reference manual" and usually not available publically (many
under NDA).
It seems to me there should be a standard that
the host automatically syncs to whatever mode the device gets set too (or
vise-versa) or that there be a well defined standard of setting up the host
mode as well. (Including RAID "controllers").
It will never happen. Every host controller vendor "has a better idea".
However their are a few PATA host controllers that monitor for SET
FEATURES commands that change the PIO or DMA mode and the host
controller will also make the appropriate change to its modes. But this
has never been widely documented and certainly not implemented in a
common way.
When is someone going to design a "TrueRAID" controller that hides the
devices when programming at the ATA command/ports level?
There are several on the market for years. Of course they have
proprietary host programming interfaces so they only work on the OSs for
which the vendor supplies a device driver.
For the chipset/BIOS guys, It would be nice if the RAID controller could
have two modes - RAID / Non-RAID in which the PCI class codes reflect the
mode it's in. (Also be sure to use UDMA on your int 13h interface - many
highpoint based implementations use PIO 0 via int 13h)
Why put all that complexity into a BIOS that is used only for some very
basic device "identification" and reading of a few blocks from the disk
to load the OS's boot loader into memory?
When is SMART going to be standardized so that recovery / security tools
have one standard to work from to get key information like relocation table
size, number of bad sectors relocated, which sectors have been relocated to
where, ability to enable/disable relocation, sectors that are starting to
encounter errors, device level problems like temp, spin up problems, etc.
Right now, it's not standard.
This too will never be standardized. SMART is nothing but smoke and
mirrors and the disk drive vendors have little incentive to make it
anything more than that.
Hale
--
++ Hale Landis ++ www.ata-atapi.com ++
