See patch.
Having an extra file just for the tiny hlt() is really not required.
Btw, why does die() do an endless loop around hlt()? Is there a reason a hlt() will _not_ immediately halt the CPU? Can that happen?
If so, shall we move the loop into hlt() itself?
Uwe.
On Thu, Jul 12, 2007 at 03:44:23AM +0200, Uwe Hermann wrote:
Btw, why does die() do an endless loop around hlt()? Is there a reason a hlt() will _not_ immediately halt the CPU? Can that happen?
It should halt, but the CPU may wake up again and continue executing if an interrupt arrives. All should be masked, but you never know..
If so, shall we move the loop into hlt() itself?
I don't think so. hlt() is just a C wrapper around the instruction.
Eventually I imagine building a panic room into die() so that recovery can be made via console on fatal errors. Ideally with some kind of stub for debugging stage0 and definately one for initram.
Merge hlt() into cpu.h where it belongs. Add some documentation.
Signed-off-by: Uwe Hermann uwe@hermann-uwe.de
Acked-by: Peter Stuge peter@stuge.se
On Thu, Jul 12, 2007 at 04:27:46AM +0200, Peter Stuge wrote:
On Thu, Jul 12, 2007 at 03:44:23AM +0200, Uwe Hermann wrote:
Btw, why does die() do an endless loop around hlt()? Is there a reason a hlt() will _not_ immediately halt the CPU? Can that happen?
It should halt, but the CPU may wake up again and continue executing if an interrupt arrives. All should be masked, but you never know..
If so, shall we move the loop into hlt() itself?
I don't think so. hlt() is just a C wrapper around the instruction.
Hm, but given your above explanations that the hlt() may not really completely halt, I'd say that we really should move the loop into hlt(). When I call hlt() from my code I _expect_ a full halt, I don't want _any_ other code exectuted.
Or іs there some reason why you explicitly want that behaviour?
Eventually I imagine building a panic room into die() so that recovery can be made via console on fatal errors. Ideally with some kind of stub for debugging stage0 and definately one for initram.
Yep, surely a nice idea (should be a Kconfig option, though).
But maybe hlt() and die() should do just what they are supposed to do. It may be better to make an explicit panicroom() function or so...
Merge hlt() into cpu.h where it belongs. Add some documentation.
Signed-off-by: Uwe Hermann uwe@hermann-uwe.de
Acked-by: Peter Stuge peter@stuge.se
Thanks, r449.
Uwe.
* Uwe Hermann uwe@hermann-uwe.de [070712 15:06]:
Hm, but given your above explanations that the hlt() may not really completely halt, I'd say that we really should move the loop into hlt(). When I call hlt() from my code I _expect_ a full halt, I don't want _any_ other code exectuted.
It's hlt, not halt. This is the instruction that used to be called in the idle loop to make the cpu _sleep_ until new work occurs.
Please don't break the current, correct behavior.
Stefan
On Thursday 12 July 2007 15:23, Stefan Reinauer wrote:
- Uwe Hermann uwe@hermann-uwe.de [070712 15:06]:
Hm, but given your above explanations that the hlt() may not really completely halt, I'd say that we really should move the loop into hlt(). When I call hlt() from my code I _expect_ a full halt, I don't want _any_ other code exectuted.
It's hlt, not halt. This is the instruction that used to be called in the idle loop to make the cpu _sleep_ until new work occurs.
When no interrupt, reset, NMI or SMI occures the "hlt" opcode let the CPU sleep forever. Do we are using interrupts in LBv3?
Juergen
* Juergen Beisert juergen127@kreuzholzen.de [070712 15:57]:
When no interrupt, reset, NMI or SMI occures the "hlt" opcode let the CPU sleep forever. Do we are using interrupts in LBv3?
I guess we can not guarantee that there is no NMI.
On Thu, Jul 12, 2007 at 03:06:57PM +0200, Uwe Hermann wrote:
If so, shall we move the loop into hlt() itself?
I don't think so. hlt() is just a C wrapper around the instruction.
Hm, but given your above explanations that the hlt() may not really completely halt, I'd say that we really should move the loop into hlt().
Again, the function is a C interface to the instruction.
The instruction will always halt the CPU, but the CPU can wake up again. All by design. :)
When I call hlt() from my code I _expect_ a full halt, I don't want _any_ other code exectuted.
I think that's another function. Maybe it's die() or halt() but it sure isn't what the hlt instruction does.
Or ??s there some reason why you explicitly want that behaviour?
hlt can be used to sleep until further notice. I don't know if we do in LB yet, but Linux executes hlt all the time. (Less with dynamic clocks.)
There is definately a legitimate use of hlt() as it stands, but we may not actually need it in LB at the moment. We would probably be fine with just a halt().
Until we've looked into it further I think looping in die() is good.
Eventually I imagine building a panic room into die() so that
Yep, surely a nice idea (should be a Kconfig option, though).
Maybe an expert option that is enabled by default? Typically I'd like it to always be available. But discussion for later.
But maybe hlt() and die() should do just what they are supposed to do.
I think they do now.
It may be better to make an explicit panicroom() function or so...
Yep, definately.
//Peter
On Thu, Jul 12, 2007 at 05:47:16PM +0200, Peter Stuge wrote:
Until we've looked into it further I think looping in die() is good.
Yes, thanks for the clarifications.
Eventually I imagine building a panic room into die() so that
Yep, surely a nice idea (should be a Kconfig option, though).
Maybe an expert option that is enabled by default? Typically I'd like it to always be available. But discussion for later.
Depends a bit on how big this gets. 256 KB chips aren't all that big and if this feature takes up a lot of space, it's probably better to default to 'off'.
Uwe.
-
Juergen Beisert -
Peter Stuge -
Stefan Reinauer -
Uwe Hermann