Compiling the _POSIX_SOURCE version of sim_os_ms_sleep_init() fixes my
cpu idling issues.
RSTS/E v10.1 idles down the cpu properly.
Chris
On Mon, Apr 9, 2012 at 7:14 PM, Christopher Redmon <credmons...@gmail.com>wrote:
> I am seeing some issues with cpu idling on NetBSD 5.1.2 amd64 platform as
> well.
> It doesn't appear to be the guest OS, but the idle loop calibration in
> simh itself.
>
> When setting the "set cpu idle" command, it returns idle not supported.
> After
> probing some into the code, it appears the sim_os_ms_sleep_init, non posix
> source version is being used, and it is calculating a time greater than
> SIM_IDLE_MAX.
>
> % uname -a
>
> NetBSD fx 5.1.2 NetBSD 5.1.2 (GENERIC) #0: Thu Feb 2
> 12:12:28 UTC 2012
> bui...@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
> % simh-pdp11
>
>
> PDP-11 simulator V3.8-1
> sim> set cpu idle
> Command not allowed
> sim>
>
> 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
