Re: [Freedos-kernel] Re: FreeDOS idle HLT
On Mon, 29 Mar 2004 18:55:44 -0300, Alain wrote: New Power supplies are very cheap. For that they have simplified many important circuits. They don't handle current fluctuations vary well. Well, again from bad to worse... They must come with a BIG red sign "HLT forbidden!" then :-( Lucho --- 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
Re: [Freedos-kernel] Re: FreeDOS idle HLT
Arkady V.Belousov escreveu: What mean "choke"? You mean, they wrongly handle battery consumptions because CPU starts to eat less power? How this looks? New Power supplies are very cheap. For that they have simplified many important circuits. They don't handle current fluctuations vary well. 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
Re: [Freedos-kernel] Re: FreeDOS idle HLT
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
Re: [Freedos-kernel] Re: FreeDOS idle HLT
>> someone said EMM386 is incompatible with HLT instruction?
MD> EMM386 uses the HLT instruction for its own purposes, but it
MD> does a check if the HLT is coming from itself or externally.
MD> Other than that, it looks like HLT causes the expected HLT
MD> behavior when the exception handler is triggered (since HLT is V86
MD> illegal). Tom Ehlert would probably know the most about this if
MD> you need more info, since I believe it's his coding for the HLT
MD> mechanism in EMM386.
HLT is a protected instruction, which causes an illegal opcode
interrupt in VM86 mode - it's up to the handler to do whatever it
likes. BTW: mov bx,[] is an invalid instruction also on any 386
It's not my coding (or whatever michael left of it, I didn't check),
but the original implementation by harald albrecht used it as a way to
cummunicate from V86 mode to PM mode.
AFAIR, the emulated behaviour is similar to
if (opcode == HLT)
if (source is in EMM386 V86 device)
{
do something clever as commanded by V86 part
}
else
{
NOP
}
I may be wrong, but it probably never does HLT.
tom
---
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
Re: [Freedos-kernel] Re: FreeDOS idle HLT
At 10:31 PM 3/27/2004 +0100, Bernd Blaauw wrote:
> so this means?:
> *check once if CPU can handle HLT instruction properly ("choke" means
>"dies" -> crash!).
> *if so, set a variable or bit or whatever
> *int28 handler: if bit set, execute HLT instruction
>
> someone said EMM386 is incompatible with HLT instruction?
EMM386 uses the HLT instruction for its own purposes, but it does a check if the HLT
is coming from itself or externally. Other than that, it looks like HLT causes the
expected HLT behavior when the exception handler is triggered (since HLT is V86
illegal). Tom Ehlert would probably know the most about this if you need more info,
since I believe it's his coding for the HLT mechanism in EMM386.
---
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
Re: [Freedos-kernel] Re: FreeDOS idle HLT
so this means?:
*check once if CPU can handle HLT instruction properly ("choke" means
"dies" -> crash!).
*if so, set a variable or bit or whatever
*int28 handler: if bit set, execute HLT instruction
someone said EMM386 is incompatible with HLT instruction?
---
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
Re: [Freedos-kernel] Re: FreeDOS idle HLT
Hi! 27-Мар-2004 17:29 [EMAIL PROTECTED] (Bart Oldeman) wrote to FreeDOS-kernel <[EMAIL PROTECTED]>: BO> Certainly not something to implement without a second thought. Also for as BO> long as I can remember Linux kernels check whether HLT actually works as BO> intended, so there may even be broken CPUs out there, and our init code BO> would also need such a check. BTW, just found: __O\_/_\_/O__ Linux version 2.6.4 ([EMAIL PROTECTED]) (gcc version 3.3.1) #1 Thu Mar 25 CPU: Intel(R) Celeron(R) CPU 2.40GHz stepping 07 Enabling fast FPU save and restore... done. Enabling unmasked SIMD FPU exception support... done. Checking 'hlt' instruction... OK. _ O/~\ /~\O --- 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_id70&alloc_id638&op=click ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Re: FreeDOS idle HLT
Hi! 27-Мар-2004 19:50 [EMAIL PROTECTED] (tom ehlert) wrote to Luchezar Georgiev <[EMAIL PROTECTED]>: te> Although the CPU certainly handles this, some Athlon power te> supply/motherboard te> combinations seem to choke on HLT, due to the very different power te> requirements. What mean "choke"? You mean, they wrongly handle battery consumptions because CPU starts to eat less power? How this looks? --- 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_id70&alloc_id638&op=click ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Re: FreeDOS idle HLT
Hello Luchezar, >> 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. LG> Hmm... I didn't know that such CPUs exist. Too bad then :-( Although the CPU certainly handles this, some Athlon power supply/motherboard combinations seem to choke on HLT, due to the very different power requirements. >> I'll leave it to FDAPM for now (or if you like a custom small TSR). right. tom --- 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
Re: [Freedos-kernel] Re: FreeDOS idle HLT
Bart, you've fixed the "> 2 fnodes on tar zxvf" bug! Just checked - works! Congratulations! 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 Indeed, you're right. 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. Hmm... I didn't know that such CPUs exist. Too bad then :-( I'll leave it to FDAPM for now (or if you like a custom small TSR). OK. Let it be! Applications must employ HLTs at strategic places to cool down the CPU... Lucho --- 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
Re: [Freedos-kernel] Re: FreeDOS idle HLT
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). Bart --- 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
