Hello, I have used Mark's master originally - that did not really cope with the newest NetBSD v5.1.2 idle handling.
Now I have tried to apply Christopher's patch against SIMH V3.8-1. Tested with NETBSD, OPENBSD etc idle settings without any result. I guess the best way would be, indeed, to suggest adding an idle detection pattern, as Mark suggested, to the NetBSD kernel. I'll give a try, but because I am not the most competent in this area, it would be much more efficient if the NetBSD core developers could negotiate with Mark directly. Thank you. Regards, Z -----Original Message----- From: Christopher Redmon [mailto:credmons...@gmail.com] Sent: den 10 april 2012 03:07 To: simh@trailing-edge.com Subject: Re: [Simh] cpu idle with NetBSD Try "cpu idle=OpenBSD". Available options are VMS, NetBSD, OpenBSD, Ultrix, and 32V. Off all those, the OpenBSD option throttled down my NetBSD/vax 5.0.2 simulation the best. Chris On Mon, Apr 9, 2012 at 3:02 PM, Mark Pizzolato - Info Comm <m...@infocomm.com> wrote: > On Monday, April 09, 2012 at 10:44 AM, Arpadffy Zoltan wrote: >> Hello Mark, >> >> Thank you for the detailed description. >> >> Running x86/amd64 version of NetBSD is not an option in my case (in fact I do >> already) because the only way of the lifting forward the vax architecture >> specific development is to run NetBSD on vax. > > 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. > >> Definitely, the right way to go is to find that specific reasonable set of >> conditions which uniquely describe the guest NetBSD idling under simh. >> I'll do my best. > > 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: > Vax_idle() > { > Int oldipl = getipl(); > Setipl(unused_ipl); > Setipl(oldipl); > } > > 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. > > - Mark > >> ________________________________________ >> From: Mark Pizzolato - Info Comm [m...@infocomm.com] >> Sent: Monday, April 09, 2012 6:12 PM >> To: Arpadffy Zoltan; simh@trailing-edge.com >> Subject: RE: cpu idle with NetBSD >> >> 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 > > > _______________________________________________ > Simh mailing list > Simh@trailing-edge.com > http://mailman.trailing-edge.com/mailman/listinfo/simh _______________________________________________ Simh mailing list Simh@trailing-edge.com http://mailman.trailing-edge.com/mailman/listinfo/simh _______________________________________________ Simh mailing list Simh@trailing-edge.com http://mailman.trailing-edge.com/mailman/listinfo/simh
