On Sunday, April 08, 2012 at 9:00 AM, Arpadffy Zoltan wrote:
> Hello,
> 
> I have recently installed a NetBSD version 5.1.2 and realized that it takes
> 100% of the CPU.
> 
> I have tried with
> set cpu idle=NETBSD
> 
> as well as with the
> set cpu idle=ALL
> 
> ...without any success.
> Could anybody help me; what I am doing wrong?

Hi Zoltan,

The only thing you are doing wrong is trying to run a recent version of NetBSD 
on a VAX.  Why are you doing that?  Why not run an x86/x64 the recent version 
of NetBSD under VirtualBox or other x86 hypervisor?

The challenge for idle detection for any particular operating system is to 
determine a set of conditions which uniquely exist only when the OS is in the 
idle state.  For example, for older VMS Versions, the Idle loop was:

                   $1:      br{b,w}  $1                             ; While the 
CPU was at IPL 0.

More recent VMS Versions have an idle loop which does a BBS instruction at IPL 
3 on the interrupt stack, with the BBS branch taken.  This is the only case 
where the BBS instruction is used at IPL 3 on the interrupt stack in VMS, so 
that condition causes simh to idle.
Older versions of Ultrix, as well as the older versions of OpenBSD, NetBSD, and 
FreeBSD have a common idle detection condition which is common due to the fact 
that they all have common BSD roots.  The condition which describes the OS idle 
here is a TSTL instruction which is running at IPL 0 from a low addresses in 
system space (8000000-80003FFF) which is a 6 byte TSTL instruction.  Later 
versions of Ultrix had different conditions (BITL instruction, 8 bytes long, 
running on interrupt stack, at IPL 24, in system space between 
8000000-80005ffff).
These conditions uniquely describe the respective guest OS idling state.  They 
have been determined by a combination of examining the instructions which are 
executing when the OS isn't doing anything useful (leveraging the simh VAX set 
cpu history command), and then verified by looking at the OS source for the 
relevant code. 
This was easy enough to do with the older 'legacy' (non changing) guest OSes.  
Meanwhile, the *BSD OSes are a moving target since they're still being 
developed.  They have each diverged in different ways from their older BSD 
roots and due to their idling redesigns to work better on newer hardware 
(Multi-Core and power efficient).  I was unable to detect a useful pattern 
which uniquely described the guest OS idle condition in the current VAX code.

My recommendation to run the x86/amd64 version of NetBSD comes down to the fact 
that the x86 platform specific parts of NetBSD will try to put the CPU into a 
low power state when the NetBSD OS is idling.  Taking this approach will also 
get you a much quicker NetBSD OS environment since the x86 instructions will be 
running mostly directly by the host processor instead of having the simh 
simulation overhead.

Alternative, Feel free to see if you can come up with a reasonable set of 
conditions which uniquely describe the guest NetBSD idling under simh.  If you 
do we'll consider adding it to the VAX idling conditions.

Good Luck,

- Mark


_______________________________________________
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Reply via email to