Eric, >> ... 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.
"Amen!", so let the user handle this thru the BIOS setup routines and let the BIOS "tell the disk" what to do during system "boot"! BIOS vendors have many more programmers than just "me by myself"! > 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. UIDE's CD/DVD logic is "happy to wait" for up to 7 seconds, and I will look into changing its disk logic from 400-msec to 7 seconds as well. > 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 logic. Actually, UIDE has NOT changed any disk-configuration settings by the BIOS since late 2005, when I "got into TROUBLE" doing so with some BIOS programs! UIDE now only "reads" I-O and DMA addresses for a disk from the BIOS, then "runs" a disk however the BIOS set it up. That, also, is something I want to LEAVE up to the BIOS, as I don't want any MORE trouble by changing BIOS settings again! >> 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. No, sir! UIDE does NOT change any communication-speeds nor ANY other BIOS settings for disks, not since 2005, as I noted above! >> 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 :-) Any hard-disk function but 2/3/42/43 (reads and writes) is "passed" to the BIOS, so function 0 would not be so timed-out by UIDE. Nor would UIDE ever declare a "timeout" -- CD/DVD errors currently post only "general error" in such cases, and hard-disk errors would post only whatever "hardware" error applies to that part of "DoIO" which noted the timeout, likely a "DMA error" for most cases. Not a big problem. Disk/CD/DVD errors are "few and far between", and people already know that a lot of DOS programs will only display "Error!", leaving exactly WHAT error it was for diagnostic programs, etc.! >> ... 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. If DOS does 5 retries, as you indicate, this would cost the user a maximum of 35 seconds (my 7 seconds * 5 tries) and thus is NOT any sort of an indefinite "hang"! I would indicate in UIDE's README that an actual [rare!] disk "error" may now take that long, before DOS gives-up on it and reports something to the user. >> 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 :-) That was only my "Thought while eating breakfast!" this morning, but I shall "test it out", later today! Jack R. Ellis ------------------------------------------------------------------------------ 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
