[others: this is a bit long/technical, the summary is that it
is both easy and safe to use shallow drive power management.]

> The problem is "WHERE" does UIDE or any other driver wait for
> a sleeping, i.e. "stand-by" hard disk to awaken again??   The
> ATA specs do not make this clear.   Can UIDE simply issue a
> drive-select command to the disk and await "ready" for it?
> Or, does UIDE actually have to issue a "seek" or "read", and
> then retry that command when first it fails??

As far as I remember, DOS always considers retrying the read.

I seem to remember that MS DOS would "crash" by showing a non-
useful variant of the critical error dialog if it runs out of
retries, e.g. when using a TSR to make writes always fail, as
opposed to failures which go away when retrying.

> If you can determine a reliable way for ALL disks to "come out
> of stand-by" mode, i.e. at what point UIDE should have a long
> time-out value, I can program that.   But, it must be COMMON
> to all drives, NO exceptions, or it might cause just as much
> TROUBLE as it resolves!

You can use FDAPM to spin down disks at once: It sends the raw
command (e0, standby) for that to the first 4 disks when you
select spin down and sends "immediate idle" (e1, idle) to wake
up disks explicitly. However, the latter is not needed as the
disk will automatically spin up when accessed again. BIOS, DOS
(FreeDOS) and lbacache seem to have no problem with this but
of course it would be better to first check the disk self-id,
to only send those commands to drives which care for them.

The I/O sequence for the primary controller is:
out 0x1f6,0xa0 for master or b0 for slave (non-lba command here)
wait (just a tiny bit)
out 0x1f7,command (0xe0 standby/spin down - 0xe1 idle/spin up)
wait (again)
... repeat for port 0x176 / 0x177 for secondary controller.

Related commands:  e6 suspend/sleep (you want to avoid this,
as waking up would need a drive reset), e5 check power state
(does not cause a wake up), ec read self-id (read port 0x1f0
many times to get 512 bytes of data as soon as drive ready?)
and last but not least e3 set idle / spin-down timer :-)

My notes say Seagate Barracuda use 8-12 Watts between idle
and working-and-seeking while using 25 Watts for a few secs
while spinning up, 1 Watt in standby and even less in sleep.

The fact that I cannot "grep" standby-specific error handlers
in lbacache probably means two things: Lbacache does not have
to retry I/O itself, because DOS does that already and second
neither DOS nor BIOS try to reset harddisks when I/O fails,
nor does lbacache do that for them. I think if your disk is
in sleep / suspend or even bus tri-state mode, it would be as
if it is not really there at all and the BIOS would run in a
bad timeout or similar as it just does not expect that case.

In short: Please check whether "fdapm spindown" has adverse
effects on anything in UIDE context and implement sending a
"0xe3 set idle timer to X minutes" UIDE command line option
(where you convert X to a suitable byte of N*12 if N at most
20, otherwise X = 240 + round(N/30) with a maximum N = 330),
at your choice either for sending the 0xe3 to all drives or
only to certain drives based on a choice of the user or 3rd
only to drives for which setting the idle timer is useful,
based on checking the drive's self-id at UIDE driver start.

To already answer some possible questions: CD/DVD drives do
not seem to have problems with the "immediate standby" or
"immediate idle", but "hdparm -I" does not list anything on
this topic for my DVD drive (only lists supported PIO / DMA
modes) while the report for my harddisk is far more verbose:

>       Queue depth: 32
>       Standby timer values: spec'd by Standard, no device specific minimum
>       Recommended acoustic management value: 254, current value: 128
(this is about how fast and noisy seeks should be done etc)

Supported features for the harddisk:

SMART, Power Management, Write Cache, Look-Ahead, Automatic
Acoustic Management, 48-bit LBA, Cache Flush, SMART Logging
and SMART Self-Test, NCQ, 3Gb/s SATA, Host-initiated bus(?)
(says "interface") Power Management, (optional) Persistent
Settings (preserve over reboot etc), various SMART SCT I/O
and a number of other features.

No power saving related features are reported for my CD/DVD
drive and running  "smartctl -d ata -a"  for it for example
just returns the model, support for ATA7, no SMART support.
Trying with -d sat (SCSI to ATA layer, 16 byte variant) is
even worse, the drive does not even give a model name then.

As I am evil, I just sent -y standby, --idle-immediately as
well as --idle-unload (also "parks heads"?) and -Y sleep to
my CD/DVD drive via hdparm anyway. Drive reactions/symptoms:

None that I noticed at all for --idle-*, a tiny delay for -y
and a bigger delay together with a kernel log message saying
that the SATA link got reset when I used the -Y command :-p

Setting the "idle timeout" (hdparm -S) for my CD/DVD drive,
which as mentioned claims to not support any power saving,
does not upset anything. The debug output from hdparm is:

>  setting standby to 120 (10 minutes)
> outgoing cdb:  85 06 20 00 00 00 78 00 00 00 00 00 00 40 e3 00
> SG_IO: ATA_16 status=0x2, host_status=0x0, driver_status=0x8
> SG_IO: sb[]:  72 00 00 00 00 00 00 0e 09 0c 00 00 00 78 00 00 00 00 00 00 40 
> 50 00 00 00 00 00 00 00 00 00 00
> SG_IO: desc[]:  09 0c 00 00 00 78 00 00 00 00 00 00
>       ATA_16 stat=50 err=00 nsect=78 lbal=00 lbam=00 lbah=00 dev=40

For comparison, a similar command for my harddisk reports:

>  setting standby to 228 (19 minutes)
> outgoing cdb:  85 06 20 00 00 00 e4 00 00 00 00 00 00 40 e3 00
> SG_IO: ATA_16 status=0x2, host_status=0x0, driver_status=0x8
> SG_IO: sb[]:  72 00 00 00 00 00 00 0e 09 0c 00 00 00 e4 00 00 00 00 00 00 40 
> 50 00 00 00 00 00 00 00 00 00 00
> SG_IO: desc[]:  09 0c 00 00 00 e4 00 00 00 00 00 00
>       ATA_16 stat=50 err=00 nsect=e4 lbal=00 lbam=00 lbah=00 dev=40

If I understand the output correctly, it confirms my assumption
that the CD/DVD drive, while not caring about spin-down timers,
has no problem with receiving commands about them and does not
even return an error status for the command itself. So in short:

Why does FDAPM not care for which drives it is (not) appropriate
to send power mgmt commands? Because the drives don't either ;-)


PS: FreeDOS Read1LBASector and LBA_Transfer both use N_RETRY=5,
the former function is only used to read partition tables using
the BIOS directly, the latter uses disk devices. In both cases
int 13 function 0 is used to reset disks before a retry, if any.

Achieve unprecedented app performance and reliability
What every C/C++ and Fortran developer should know.
Learn how Intel has extended the reach of its next-generation tools
to help boost performance applications - inlcuding clusters.
Freedos-user mailing list

Reply via email to