Bart Oldeman escreveu:
On Sat, 27 Mar 2004, Luchezar Georgiev wrote:
On Sat, 27 Mar 2004 17:32:19 +0100 (MET), Eric Auer wrote:
while you are in an interrupt handler you are in CLI state. So an HLT without a STI before it would hang the system. The _int28_handler is only an iret as far as I remember, and it is shared with int 22 and 2a. I do not think that ALL three interrupts should contain HLT (which usually waits up to 0.05 seconds until the next timer tick happens). So please check that suggestion again...
You're right of course, but that was just a rough idea of mine. The labels must be reordered so only _int28_handler goes through the HLT and a STI must be added before it. When Bart fixes the fnodes bug, it will be the right time to start adding little nice features like this one... ;-)
I don't know -- there must be a reason why other DOSes don't have this, even while having more comprehensive power saving utilities. Perhaps to guard against TSRs that hook int28 by chaining -- in that case if the HLT comes after the TSR then it may be superfluous...
And RBIL is very clear: the default handler is an IRET instruction
Certainly not something to implement without a second thought. Also for as long as I can remember Linux kernels check whether HLT actually works as intended, so there may even be broken CPUs out there, and our init code would also need such a check.
I'll leave it to FDAPM for now (or if you like a custom small TSR).
Yes, better not have neww problems added to the ones we already have.
About HLT: nome motherboards (new ones) have a too sudden power consuption drop after a HLT, than the power suply goes crazy and the system hangs...
Alain
------------------------------------------------------- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click _______________________________________________ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
