Jack, > I read through and understood all your comments about hard-disk > power management, etc. > > My problem is: I am not-interested in being "the one" who does > power management. If DOS or the BIOS wants to save power thru > putting disks into "stand-by" mode, let them do it...
There is not much to "do" there, as you only tell the disk once and then the disk itself does the rest. But it would be good to know from you that UIDE is (as predicted) happy to wait a moment for idle disks to spin back up as that in fact does not need any explicit handling by UIDE anyway. However, I would be happy if UIDE could "do" the sending of the idle timer config command to the disk because: It already does raw drive I/O anyway and it already has some command line parser anyway so it would only take a few more (non-resident) bytes to let UIDE send this command when the user puts the corresponding command line option during UIDE start-up. That way, no separate tool would be needed which would duplicate existing UIDE logics. > UIDE is a disk "I-O driver", not a power-management tool, and > I desire to keep such things OUT of UIDE's logic! Yet UIDE already probably does "drive setup" communication with the disk for selection of the right communication speed so my point is it would be only a small step to make it possible to send other drive (e.g. "idle timer") setup commands with it. > relatively easy. UIDE's CD/DVD logic currently allows 7 secs. > for spin-up and 3 seconds for track-to-track seeks, which I had > forgotten -- I had not looked at that logic for almost 5 years! Interesting. So it can in fact report a time-out, but that should simply make DOS try again. As FreeDOS tries 5 times, you get much more than 3 or 7 seconds in the end, depending on which timeouts are used for int 13 functions 0, 2, 3, 42 and 43. Long enough :-) > Assuming 7 seconds "should be long enough!" for a hard disk, as > well, I can simply use that value as a timeout during disk I-O, > not the current 400-msec timeout. Shall "experiment" re: this Thanks - and see above. > idea. Might cause some "confusion" among UIDE users, who will > now see a 7-second delay in some error handling. Good question. This would only make delays longer for errors that would never end without explicit error handling but I understand that users could still notice. For example I remember that using CompactFlash CF cards with a (purely mechanical) IDE adapter plug can have such "hangs" for low quality cards - in particular when you combine that plug with a SATA-IDE adapter with cheap chipset. So I guess such hangs would get longer with longer timeouts, as it might take the driver longer to "give up" the access attempt and decide to "give the drive a smack of reset" to reactivate it no matter whether it is the driver or just DOS which says reset. > But, if UIDE > needs only a timeout change to handle "sleeping" hard disks, it > might be worth updating only 1 byte in its "DoIO" subroutine! Nice, thanks :-) Eric PS: Of course a stall/crash of a CF/SD/... card affects any OS. ------------------------------------------------------------------------------ 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. http://p.sf.net/sfu/intel-dev2devmay _______________________________________________ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
