<div>I am seeing some issues with cpu idling on NetBSD 5.1.2 amd64 platform as well.</div><div>It doesn't appear to be the guest OS, but the idle loop calibration in simh itself.</div><div><br></div><div>When setting the "set cpu idle" command, it returns idle not supported. After</div>
<div>probing some into the code, it appears the sim_os_ms_sleep_init, non posix</div><div>source version is being used, and it is calculating a time greater than</div><div>SIM_IDLE_MAX.</div><div><br></div><div><div>% uname -a NetBSD fx 5.1.2 NetBSD 5.1.2 (GENERIC) #0: Thu Feb 2 12:12:28 UTC 2012 builds@b7.netbsd.org:/home/builds/ab/netbsd-5-1-2-RELEASE/amd64/201202021012Z-obj/home/builds/ab/netbsd-5-1-2-RELEASE/src/sys/arch/amd64/compile/GENERIC amd64</div>
<div>% simh-pdp11 </div><div>PDP-11 simulator V3.8-1</div><div>sim> set cpu idle</div>
<div>Command not allowed</div><div>sim> </div></div><div><br></div><div>Chris</div><div><br><br><div class="gmail_quote">On Mon, Apr 9, 2012 at 3:02 PM, Mark Pizzolato - Info Comm <span dir="ltr"><<a href="mailto:Mark@infocomm.com">Mark@infocomm.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Monday, April 09, 2012 at 10:44 AM, Arpadffy Zoltan wrote:<br>
> Hello Mark,<br>
><br>
> Thank you for the detailed description.<br>
><br>
> Running x86/amd64 version of NetBSD is not an option in my case (in fact I do<br>
> already) because the only way of the lifting forward the vax architecture<br>
> specific development is to run NetBSD on vax.<br>
<br>
The existing issue (with detecting idle), exists due to some of the prior 'lifting' efforts which changed how the VAX specific code was doing things while idle.<br>
<br>
> Definitely, the right way to go is to find that specific reasonable set of<br>
> conditions which uniquely describe the guest NetBSD idling under simh.<br>
> I'll do my best.<br>
<br>
If you're actually influencing the content of the VAX specific code for NetBSD, then you could probably create a specific signature.... For example, there probably is a relatively low IPL which is not used by NetBSD. Let's say that is IPL4. You could have a routine:<br>
Vax_idle()<br>
{<br>
Int oldipl = getipl();<br>
Setipl(unused_ipl);<br>
Setipl(oldipl);<br>
}<br>
<br>
The mere use of the setipl to the known to be unused IPL would be a sufficient condition which you could add in the code and could then be detected in the simulator, but would still run fine on real hardware as well.<br>
<br>
- Mark<br>
<br>
> ________________________________________<br>
> From: Mark Pizzolato - Info Comm [<a href="mailto:Mark@infocomm.com">Mark@infocomm.com</a>]<br>
> Sent: Monday, April 09, 2012 6:12 PM<br>
> To: Arpadffy Zoltan; <a href="mailto:simh@trailing-edge.com">simh@trailing-edge.com</a><br>
> Subject: RE: cpu idle with NetBSD<br>
><br>
> On Sunday, April 08, 2012 at 9:00 AM, Arpadffy Zoltan wrote:<br>
> > Hello,<br>
> ><br>
> > I have recently installed a NetBSD version 5.1.2 and realized that it<br>
> > takes 100% of the CPU.<br>
> ><br>
> > I have tried with<br>
> > set cpu idle=NETBSD<br>
> ><br>
> > as well as with the<br>
> > set cpu idle=ALL<br>
> ><br>
> > ...without any success.<br>
> > Could anybody help me; what I am doing wrong?<br>
><br>
> Hi Zoltan,<br>
><br>
> The only thing you are doing wrong is trying to run a recent version of<br>
> NetBSD on a VAX. Why are you doing that? Why not run an x86/x64 the<br>
> recent version of NetBSD under VirtualBox or other x86 hypervisor?<br>
><br>
> The challenge for idle detection for any particular operating system is to<br>
> determine a set of conditions which uniquely exist only when the OS is in the<br>
> idle state. For example, for older VMS Versions, the Idle loop was:<br>
><br>
> $1: br{b,w} $1 ; While the CPU was at IPL 0.<br>
><br>
> More recent VMS Versions have an idle loop which does a BBS instruction at<br>
> IPL 3 on the interrupt stack, with the BBS branch taken. This is the only case<br>
> where the BBS instruction is used at IPL 3 on the interrupt stack in VMS, so<br>
> that condition causes simh to idle.<br>
> Older versions of Ultrix, as well as the older versions of OpenBSD, NetBSD,<br>
> and FreeBSD have a common idle detection condition which is common due<br>
> to the fact that they all have common BSD roots. The condition which<br>
> describes the OS idle here is a TSTL instruction which is running at IPL 0 from a<br>
> low addresses in system space (8000000-80003FFF) which is a 6 byte TSTL<br>
> instruction. Later versions of Ultrix had different conditions (BITL instruction,<br>
> 8 bytes long, running on interrupt stack, at IPL 24, in system space between<br>
> 8000000-80005ffff).<br>
> These conditions uniquely describe the respective guest OS idling state.<br>
> They have been determined by a combination of examining the instructions<br>
> which are executing when the OS isn't doing anything useful (leveraging the<br>
> simh VAX set cpu history command), and then verified by looking at the OS<br>
> source for the relevant code.<br>
> This was easy enough to do with the older 'legacy' (non changing) guest<br>
> OSes. Meanwhile, the *BSD OSes are a moving target since they're still being<br>
> developed. They have each diverged in different ways from their older BSD<br>
> roots and due to their idling redesigns to work better on newer hardware<br>
> (Multi-Core and power efficient). I was unable to detect a useful pattern<br>
> which uniquely described the guest OS idle condition in the current VAX<br>
> code.<br>
><br>
> My recommendation to run the x86/amd64 version of NetBSD comes down<br>
> to the fact that the x86 platform specific parts of NetBSD will try to put the<br>
> CPU into a low power state when the NetBSD OS is idling. Taking this<br>
> approach will also get you a much quicker NetBSD OS environment since the<br>
> x86 instructions will be running mostly directly by the host processor instead<br>
> of having the simh simulation overhead.<br>
><br>
> Alternative, Feel free to see if you can come up with a reasonable set of<br>
> conditions which uniquely describe the guest NetBSD idling under simh. If<br>
> you do we'll consider adding it to the VAX idling conditions.<br>
><br>
> Good Luck,<br>
><br>
> - Mark<br>
><br>
><br>
><br>
> _______________________________________________<br>
> Simh mailing list<br>
> <a href="mailto:Simh@trailing-edge.com">Simh@trailing-edge.com</a><br>
> <a href="http://mailman.trailing-edge.com/mailman/listinfo/simh" target="_blank">http://mailman.trailing-edge.com/mailman/listinfo/simh</a><br>
<br>
<br>
_______________________________________________<br>
Simh mailing list<br>
<a href="mailto:Simh@trailing-edge.com">Simh@trailing-edge.com</a><br>
<a href="http://mailman.trailing-edge.com/mailman/listinfo/simh" target="_blank">http://mailman.trailing-edge.com/mailman/listinfo/simh</a><br>
</blockquote></div><br></div>