On 6/4/2012 7:03 PM, Gregg Levine wrote:
Wow. Now I am impressed. You have managed to trigger a bug in Solaris... :-)
Send an SPR to Oracle... If they care...
I'm sure they don't. :)
Hello!
Oh they will. The big question is one of, what hardware is this
running on? And what build is this? That's easy to find out, use the
same command as on Linux.
No, the won't care. It's *really old* SXCE.
I need to upgrade this thing to current 11 anyway so that's the solution. :) (3.9 didn't crash the sol11 VM i have)
SunOS zaphod.4amlunch.net 5.11 snv_124 i86pc i386 i86pc
If that tells you anything. :)
-brian
On 6/4/2012 6:25 PM, Johnny Billquist wrote:
On 2012-06-04 16:14, Brian Hechinger wrote:
On 6/4/2012 7:55 AM, Dave McGuire wrote:
It detects the idle loop patterns in some OSs and throttles back the
simulator, so the host system isn't sitting there burning CPU to execute
the guest OS's idle loop.
Right, but I'm curious what it needs to know about the host OS to
accomplish that.
There is nothing that would be required that is special in the host OS. simh already needs to tweak things all the time to run. Just sitting still for a moment is what is needed. If one Unix can do it, so can all of them.
Hmmmmm.
I should look at the source but I'm not sure I'll know what I'm looking
at. :)
If you *really* want to know, I suppose I could go and dig through the code and locate the code...
Well it's not a huge deal although it would be nice. I'd be curious to know what it is that triggers this error on Solaris only.
-brian
On Mon, Jun 4, 2012 at 6:27 PM, Johnny Billquist <bqt at softjar.se> wrote:
On 2012-06-04 18:13, Brian Hechinger wrote:
SIMH 3.9 somehow kernel paniced my solaris server!
Wow.
-brian
ps: it's older solaris, but stil!
Wow. Now I am impressed. You have managed to trigger a bug in Solaris... :-)
Send an SPR to Oracle... If they care...
Johnny
Hello!
Oh they will. The big question is one of, what hardware is this
running on? And what build is this? That's easy to find out, use the
same command as on Linux.
-----
Gregg C Levine gregg.drwho8 at gmail.com
"This signature fought the Time Wars, time and again."
Mark,
We will take this offline...
-Steve
-----Original Message-----
From: owner-hecnet at Update.UU.SE
[mailto:owner-hecnet at Update.UU.SE] On Behalf Of Mark Benson
Sent: Monday, June 04, 2012 16:08
To: hecnet at Update.UU.SE
Subject: Re: [HECnet] Paging: Steve Davidson
On 4 Jun 2012, at 15:07, Steve Davidson wrote:
You paged??? I've been flat out lately. Sorry.
What's up? I will be around all day today.
I needed to bother you about a couple of things:
My Multinet tunnel to your network has died unrecoverable (or
so I can see).
I am gearing up to start work on a VMS cluster and need some
tips and tuition.
I'll be around for a while tonight.
--
Mark Benson
http://DECtec.info
Twitter: @DECtecInfo
HECnet: STAR69::MARK
Online Resource & Mailing List for DEC Enthusiasts.
On 2012-06-04 18:13, Brian Hechinger wrote:
SIMH 3.9 somehow kernel paniced my solaris server!
Wow.
-brian
ps: it's older solaris, but stil!
Wow. Now I am impressed. You have managed to trigger a bug in Solaris... :-)
Send an SPR to Oracle... If they care...
Johnny
On 2012-06-04 16:14, Brian Hechinger wrote:
On 6/4/2012 7:55 AM, Dave McGuire wrote:
It detects the idle loop patterns in some OSs and throttles back the
simulator, so the host system isn't sitting there burning CPU to execute
the guest OS's idle loop.
Right, but I'm curious what it needs to know about the host OS to
accomplish that.
There is nothing that would be required that is special in the host OS. simh already needs to tweak things all the time to run. Just sitting still for a moment is what is needed. If one Unix can do it, so can all of them.
I should look at the source but I'm not sure I'll know what I'm looking
at. :)
If you *really* want to know, I suppose I could go and dig through the code and locate the code...
Johnny
On 2012-06-04 13:52, Brian Hechinger wrote:
Anyone know how it works? I'd really like to get it working on Solaris.
Simple. For a VAX, simh tries to detect the instruction sequence that the OS do in the idle loop. That's why it depends on which OS you are running on the emulated machine.
For a PDP-11 it is (supposedly) simpler, since hopefully the idle loop of the OS uses the PDP-11 WAIT instruction, but that actually depends on which OS we're talking about. Not sure that RT-11 do, for instance. (I have some vague memory of discussing this with someone a few years ago, and coming to the realization that not all PDP-11 software might be using the WAIT.)
For other hardware and OS combinations, the answers might differ even more.
Johnny
I would suspect that the VM in reality is also accessing the network through the TAP interface in the end, so technology wise it ends up the same way, it's just a question how much of a middle layer you'll have. Running simh directly on Linux, or have a VirtualBox on Linux, on which you run simh.
Johnny
On 2012-06-04 13:25, Brian Hechinger wrote:
Wouldn't it be easier (and more efficient) to use TAP interfaces?
That's what I'm going to do as soon as I have time. (Well, Crossbow on Solaris instead of TAP but same idea)
-brian
On Jun 4, 2012, at 5:37, Sampsa Laine<sampsa at mac.com> wrote:
I configured a Linux box to automatically fire up VirtualBox from rc.local, and then run a stripped down Linux instance in the VM to run SIMH-VAX.
Point being that I could then access the network interface of the SIMH-VAX from the host running VirtualBox :)
The host also ran decnet-linux..
It was quite nifty, but too heavy-weight for a Pi..
Sampsa
On 4 Jun 2012, at 03:06, Boyanich, Alastair wrote:
Hi Rob,
There may be a super easy way. Try the /etc/rc.local script file. You
can think of it in old MS-DOS/Amiga terms as the AUTOEXEC.BAT or
S:user-startup files. This script usually gets run after the system has
entered muti-user mode and after the networking is up and running. Have
a go running your simh VAX executable from there :)
You can also get fancy with GNU Screen so that it saves and disconnects
the console so you can connect to it after an auto-startup.
Regards,
Al Boyanich
-----Original Message-----
From: owner-hecnet at Update.UU.SE [mailto:owner-hecnet at Update.UU.SE] On
Behalf Of Rob Jarratt
Sent: Monday, 4 June 2012 9:45 AM
To: hecnet at Update.UU.SE
Subject: RE: [HECnet] Raspberry Pi + SIMH VAX?
I got my Raspberry Pi a few days ago too. I too have had few problems,
although for some reason the download of libpcap took an extraordinary
amount of time. I have built the 780 emulation, along with two
modifications
of my own, difference disk files, and a DMC11 emulation.
I am running the Pi now 24 hours a day as my HECnet router (node
VAX780 at
5.8) using the bridge running on a server that I already run 24 hours
a day.
The virtual disk files are stored on the server and I use SMB to
access them
from the Raspberry Pi, partly because the 8GB SD card I planned to use
did
not work and I had to use a 4GB one, partly because I have heard that
SD
performance is poor.
I am not as good on unix these days as I used to be, is there an easy
way to
get SIMH to start up automatically on booting the Pi?
I like the idea of a cluster of Pis, might get a few more at some
point and
try that myself.
Regards
Rob
-----Original Message-----
From: owner-hecnet at Update.UU.SE [mailto:owner-
hecnet at Update.UU.SE] On Behalf Of Mark Benson
Sent: 03 June 2012 22:21
To: hecnet at Update.UU.SE
Subject: Re: [HECnet] Raspberry Pi + SIMH VAX?
On 4 May 2012, at 00:07, Boyanich, Alastair wrote:
Sampsa:
Interesting. Be sure to set up the idle detection in the simh.ini
for
your appropriate OS (netbsd/TheoLinux/VMS/Ultrix/etc..) or it'll
run
the CPU flat-out all the time and potentially get hot. I'm really
curious to hear how 'hot' the R-Pi's get under load. Mine's still
on
order.
Beautiful idea.
I got my Raspsberry Pi Thursday. It runs SimH 3.9.0 flawlessly under
the
provided Debian Linux 'squeeze' distribution from a SD Card. The I/O
on
the
RPi isn't fantastic from SD Card, it just about manages 5.5MB/s by
most
people's benchmarks which is rather slow.
libpcap and screen are installable from the provided arm6l
repositories so
no
need for compiling those. Once I did that I just downloaded the
source
zip,
unzipped it into a directory and used 'make' to build, just like
normal.
Built
fine and runs perfectly.
PDP-11 simulation is plenty snappy enough running RSX-11M Plus 4.2
on a
simulated 11/83 with 2048kW of RAM. I have DECNet 4.0 (Phase IV)
working
on there too and it works fine.
VAX KA655X simulation is... sluggish. I'm used to running it on
1.xGHz
x86_64
CPUs (Atom or AMD) with fast hard drives or SATA SSD. The CPU speed
makes it slow but imagine it's as fast or faster than a real late
model
VAX. It's
by no means perishingly annoying, it just takes a little thinking
between
operations. I think I may be spoilt as I've never used a real VAX.
Overall so far I'm very impressed with the RasPi and it will fulfil
the
roles I
need for it. When I get hold of a few more I am going to try and
build a
VMS
cluster that uses less than 6W :) I will also have one permanently
running
a
PDP-11 (something that I've not managed since I had my Cobalt Qube2
running) RSX-11MP system.
Oh and CPU Idle works just fine in PDP-11 and VMS-VAX simulations.
To be
honest even when I compiled all the simulator binaries for SimH (as
a
stress
test) and when I was running the SYSGEN in RSX-11M it barely got
much
worse temperature-wise than hot to touch a the CPU. On a board that
only
uses 300mA with no USB and Ethernet active it hardly has a lot of
energy
to
dissipate as heat in the first place!
I'm gonna have a LOT of fun with these :D
--
Mark Benson
http://DECtec.info
Twitter: @DECtecInfo
HECnet: STAR69::MARK
Online Resource& Mailing List for DEC Enthusiasts.
FYI - Update now have a Cisco box, which will be setup within a few days to be able to route DECnet over IP, so that will become another options to hook into HECnet at the Update site.
For people who don't need LAT and have a Cisco box, this is way better than the bridge program.
(If you really want LAT with other parts of HECnet, then there is no alternative to the bridge...)
Johnny
On 2012-06-03 23:23, Mark Benson wrote:
I tried ti do this a week back but somethings still broken. I'm trying to get Area 6 back to HECNet somehow but I am stuck because I can't reach Steve Davidson.
I may drop back to using the bridge for now, if that will still work.
On 13 Apr 2012, at 19:26, Steve Davidson wrote:
The following areas need to change their addresses for their link to SG1
to work:
3, 52, 59 and the two area 6 nodes.
In addition, the nodes in the 19.3xx range are still missing.
The new address is: 69.21.253.158 (bridge.declab.net)
-Steve
On 2012-06-03 23:21, Mark Benson wrote:
On 4 May 2012, at 00:07, Boyanich, Alastair wrote:
Sampsa:
Interesting. Be sure to set up the idle detection in the simh.ini for
your appropriate OS (netbsd/TheoLinux/VMS/Ultrix/etc..) or it'll run the
CPU flat-out all the time and potentially get hot. I'm really curious to
hear how 'hot' the R-Pi's get under load. Mine's still on order.
Beautiful idea.
I got my Raspsberry Pi Thursday. It runs SimH 3.9.0 flawlessly under the provided Debian Linux 'squeeze' distribution from a SD Card. The I/O on the RPi isn't fantastic from SD Card, it just about manages 5.5MB/s by most people's benchmarks which is rather slow.
libpcap and screen are installable from the provided arm6l repositories so no need for compiling those. Once I did that I just downloaded the source zip, unzipped it into a directory and used 'make' to build, just like normal. Built fine and runs perfectly.
PDP-11 simulation is plenty snappy enough running RSX-11M Plus 4.2 on a simulated 11/83 with 2048kW of RAM. I have DECNet 4.0 (Phase IV) working on there too and it works fine.
Nice.
VAX KA655X simulation is... sluggish. I'm used to running it on 1.xGHz x86_64 CPUs (Atom or AMD) with fast hard drives or SATA SSD. The CPU speed makes it slow but imagine it's as fast or faster than a real late model VAX. It's by no means perishingly annoying, it just takes a little thinking between operations. I think I may be spoilt as I've never used a real VAX.
It would be interesting to hear of a comparison. The "newer" VAXen are really not that bad. But of course, everything is relative...
Overall so far I'm very impressed with the RasPi and it will fulfil the roles I need for it. When I get hold of a few more I am going to try and build a VMS cluster that uses less than 6W :) I will also have one permanently running a PDP-11 (something that I've not managed since I had my Cobalt Qube2 running) RSX-11MP system.
Talk about doing a misread. I saw that as an RSX-11 MultiProcessor system. :-)
Oh and CPU Idle works just fine in PDP-11 and VMS-VAX simulations. To be honest even when I compiled all the simulator binaries for SimH (as a stress test) and when I was running the SYSGEN in RSX-11M it barely got much worse temperature-wise than hot to touch a the CPU. On a board that only uses 300mA with no USB and Ethernet active it hardly has a lot of energy to dissipate as heat in the first place!
I would suspect that is because the CPU will still be just waiting for I/O lots of the time. Compilations, as well as running something like SYSGEN in RSX, is really I/O intensive. Not much CPU work in there.
Johnny
On 4 Jun 2012, at 15:07, Steve Davidson wrote:
You paged??? I've been flat out lately. Sorry.
What's up? I will be around all day today.
I needed to bother you about a couple of things:
My Multinet tunnel to your network has died unrecoverable (or so I can see).
I am gearing up to start work on a VMS cluster and need some tips and tuition.
I'll be around for a while tonight.
--
Mark Benson
http://DECtec.info
Twitter: @DECtecInfo
HECnet: STAR69::MARK
Online Resource & Mailing List for DEC Enthusiasts.
On 6/4/2012 12:58 PM, Rob Jarratt wrote:
-----Original Message-----
From: owner-hecnet at Update.UU.SE [mailto:owner-
hecnet at Update.UU.SE] On Behalf Of Paul_Koning at Dell.com
Sent: 04 June 2012 17:26
To: hecnet at Update.UU.SE
Subject: Re: [HECnet] Speaking of IDLE
On Jun 4, 2012, at 12:04 PM, Brian Hechinger wrote:
Sadly the updates didn't fix it for me. :(
VAX simulator V3.9-0
/simh/rifter/vax.ini> set cpu idle
Command not allowed
-brian
Silly question, but is "set cpu idle" actually the first thing in your ini
file? Can you post the whole ini file?
I'd have to check, but if I just run it with no ini file I still get that issue (and this is on latest and greatest Sol 11)
wonko at larry:~/software/simh$ BIN/vax
VAX simulator V3.9-0
sim> set cpu idle
Command not allowed
sim>
-brian
-----Original Message-----
From: owner-hecnet at Update.UU.SE [mailto:owner-
hecnet at Update.UU.SE] On Behalf Of Paul_Koning at Dell.com
Sent: 04 June 2012 17:26
To: hecnet at Update.UU.SE
Subject: Re: [HECnet] Speaking of IDLE
On Jun 4, 2012, at 12:04 PM, Brian Hechinger wrote:
Sadly the updates didn't fix it for me. :(
VAX simulator V3.9-0
/simh/rifter/vax.ini> set cpu idle
Command not allowed
-brian
Silly question, but is "set cpu idle" actually the first thing in your ini
file? Can you post the whole ini file?
Regards
Rob
On 6/4/2012 12:26 PM, Paul_Koning at Dell.com wrote:
On Jun 4, 2012, at 12:04 PM, Brian Hechinger wrote:
Sadly the updates didn't fix it for me. :(
VAX simulator V3.9-0
/simh/rifter/vax.ini> set cpu idle
Command not allowed
-brian
That's odd. I just downloaded and built simh 3.9.0, and it accepts the command without any complaints, both in "vax" and "vax780":
pkoning:simhv39-0 pkoning$ BIN/vax780
VAX780 simulator V3.9-0
sim> set cpu idle
sim> show cpu idle
idle=VMS, idle enabled, stability wait = 20s
sim> set cpu idle=NETBSD
sim> show cpu idle
idle=NETBSD, idle enabled, stability wait = 20s
sim> q
Goodbye
pkoning:simhv39-0 pkoning$ BIN/vax
VAX simulator V3.9-0
sim> show cpu idle
idle disabled
sim> set cpu idle
sim> show cpu idle
idle=VMS, idle enabled, stability wait = 20s
sim> set cpu idle=OPENBSD
sim> show cpu idle
idle=OPENBSD, idle enabled, stability wait = 20s
sim> q
Goodbye
pkoning:simhv39-0 pkoning$
Yeah, works fine on linux, but Solaris not so much. :(
And now libpcap doesn't want to easily build on newest Solaris 11. Joy.
-brian
On Jun 4, 2012, at 12:04 PM, Brian Hechinger wrote:
Sadly the updates didn't fix it for me. :(
VAX simulator V3.9-0
/simh/rifter/vax.ini> set cpu idle
Command not allowed
-brian
That's odd. I just downloaded and built simh 3.9.0, and it accepts the command without any complaints, both in "vax" and "vax780":
pkoning:simhv39-0 pkoning$ BIN/vax780
VAX780 simulator V3.9-0
sim> set cpu idle
sim> show cpu idle
idle=VMS, idle enabled, stability wait = 20s
sim> set cpu idle=NETBSD
sim> show cpu idle
idle=NETBSD, idle enabled, stability wait = 20s
sim> q
Goodbye
pkoning:simhv39-0 pkoning$ BIN/vax
VAX simulator V3.9-0
sim> show cpu idle
idle disabled
sim> set cpu idle
sim> show cpu idle
idle=VMS, idle enabled, stability wait = 20s
sim> set cpu idle=OPENBSD
sim> show cpu idle
idle=OPENBSD, idle enabled, stability wait = 20s
sim> q
Goodbye
pkoning:simhv39-0 pkoning$
paul
On 6/4/2012 10:50 AM, Paul_Koning at Dell.com wrote:
On Jun 4, 2012, at 10:14 AM, Brian Hechinger wrote:
On 6/4/2012 7:55 AM, Dave McGuire wrote:
On 06/04/2012 07:52 AM, Brian Hechinger wrote:
Anyone know how it works? I'd really like to get it working on Solaris.
You mean it doesn't? I wonder why that would be.
/simh/rifter/vax.ini> set cpu idle=VMS
Command not allowed
It detects the idle loop patterns in some OSs and throttles back the
simulator, so the host system isn't sitting there burning CPU to execute
the guest OS's idle loop.
Right, but I'm curious what it needs to know about the host OS to accomplish that.
I should look at the source but I'm not sure I'll know what I'm looking at. :)
See vax_cpu.c.
My copy (SIMH 3.8.1) rejects that command with a different message: "Invalid argument". But to make things even stranger, it DOES accept the command -- "show cpu idle" shows that it paid attention.
Possibly the issue is that the VAX-specific command next passes control to the general command (in sim_timer.c) and that routine accepts an argument but requires it to be an integer!
You might try simply "set cpu idle" (without argument). The default seems to be VMS, with NETBSD, OPENBSD, ULTRIX, and 32V accepted as alternate values. The difference is in what the particular OS does when it is idle. That tends to change from one OS to another (even when the hardware seems to suggest a standard way to do it, as in the PDP11 with its WAIT instruction).
paul
Sadly the updates didn't fix it for me. :(
VAX simulator V3.9-0
/simh/rifter/vax.ini> set cpu idle
Command not allowed
-brian
On 6/4/2012 10:59 AM, Paul_Koning at Dell.com wrote:
On Jun 4, 2012, at 10:53 AM, Brian Hechinger wrote:
On 6/4/2012 10:50 AM, Paul_Koning at Dell.com wrote:
On Jun 4, 2012, at 10:14 AM, Brian Hechinger wrote:
On 6/4/2012 7:55 AM, Dave McGuire wrote:
On 06/04/2012 07:52 AM, Brian Hechinger wrote:
Anyone know how it works? I'd really like to get it working on Solaris.
You mean it doesn't? I wonder why that would be.
/simh/rifter/vax.ini> set cpu idle=VMS
Command not allowed
It detects the idle loop patterns in some OSs and throttles back the
simulator, so the host system isn't sitting there burning CPU to execute
the guest OS's idle loop.
Right, but I'm curious what it needs to know about the host OS to accomplish that.
I should look at the source but I'm not sure I'll know what I'm looking at. :)
See vax_cpu.c.
My copy (SIMH 3.8.1) rejects that command with a different message: "Invalid argument". But to make things even stranger, it DOES accept the command -- "show cpu idle" shows that it paid attention.
Possibly the issue is that the VAX-specific command next passes control to the general command (in sim_timer.c) and that routine accepts an argument but requires it to be an integer!
You might try simply "set cpu idle" (without argument). The default seems to be VMS, with NETBSD, OPENBSD, ULTRIX, and 32V accepted as alternate values. The difference is in what the particular OS does when it is idle. That tends to change from one OS to another (even when the hardware seems to suggest a standard way to do it, as in the PDP11 with its WAIT instruction).
Same thing:
/simh/rifter/vax.ini> set cpu idle
Command not allowed
-brian
Looks like you'll have to read the Fine Code to see what changed.
paul
Looks like there were some changes to IDLE for the VAX in 3.9
building that now.
-brian
On 6/4/2012 11:00 AM, Dave McGuire wrote:
On 06/04/2012 10:14 AM, Brian Hechinger wrote:
Anyone know how it works? I'd really like to get it working on Solaris.
You mean it doesn't? I wonder why that would be.
/simh/rifter/vax.ini> set cpu idle=VMS
Command not allowed
Oh my. I assume that's done by a #define somewhere. Have you looked?
Yes. The code is a little.............. tricky to follow.
I don't think I'm going to be able to sort this out. I just don't have the time it'll take to go through all his code. :(
-brian
On 06/04/2012 10:14 AM, Brian Hechinger wrote:
Anyone know how it works? I'd really like to get it working on Solaris.
You mean it doesn't? I wonder why that would be.
/simh/rifter/vax.ini> set cpu idle=VMS
Command not allowed
Oh my. I assume that's done by a #define somewhere. Have you looked?
-Dave
--
Dave McGuire, AK4HZ
New Kensington, PA
On Jun 4, 2012, at 10:53 AM, Brian Hechinger wrote:
On 6/4/2012 10:50 AM, Paul_Koning at Dell.com wrote:
On Jun 4, 2012, at 10:14 AM, Brian Hechinger wrote:
On 6/4/2012 7:55 AM, Dave McGuire wrote:
On 06/04/2012 07:52 AM, Brian Hechinger wrote:
Anyone know how it works? I'd really like to get it working on Solaris.
You mean it doesn't? I wonder why that would be.
/simh/rifter/vax.ini> set cpu idle=VMS
Command not allowed
It detects the idle loop patterns in some OSs and throttles back the
simulator, so the host system isn't sitting there burning CPU to execute
the guest OS's idle loop.
Right, but I'm curious what it needs to know about the host OS to accomplish that.
I should look at the source but I'm not sure I'll know what I'm looking at. :)
See vax_cpu.c.
My copy (SIMH 3.8.1) rejects that command with a different message: "Invalid argument". But to make things even stranger, it DOES accept the command -- "show cpu idle" shows that it paid attention.
Possibly the issue is that the VAX-specific command next passes control to the general command (in sim_timer.c) and that routine accepts an argument but requires it to be an integer!
You might try simply "set cpu idle" (without argument). The default seems to be VMS, with NETBSD, OPENBSD, ULTRIX, and 32V accepted as alternate values. The difference is in what the particular OS does when it is idle. That tends to change from one OS to another (even when the hardware seems to suggest a standard way to do it, as in the PDP11 with its WAIT instruction).
Same thing:
/simh/rifter/vax.ini> set cpu idle
Command not allowed
-brian
Looks like you'll have to read the Fine Code to see what changed.
paul
On 6/4/2012 10:50 AM, Paul_Koning at Dell.com wrote:
On Jun 4, 2012, at 10:14 AM, Brian Hechinger wrote:
On 6/4/2012 7:55 AM, Dave McGuire wrote:
On 06/04/2012 07:52 AM, Brian Hechinger wrote:
Anyone know how it works? I'd really like to get it working on Solaris.
You mean it doesn't? I wonder why that would be.
/simh/rifter/vax.ini> set cpu idle=VMS
Command not allowed
It detects the idle loop patterns in some OSs and throttles back the
simulator, so the host system isn't sitting there burning CPU to execute
the guest OS's idle loop.
Right, but I'm curious what it needs to know about the host OS to accomplish that.
I should look at the source but I'm not sure I'll know what I'm looking at. :)
See vax_cpu.c.
My copy (SIMH 3.8.1) rejects that command with a different message: "Invalid argument". But to make things even stranger, it DOES accept the command -- "show cpu idle" shows that it paid attention.
Possibly the issue is that the VAX-specific command next passes control to the general command (in sim_timer.c) and that routine accepts an argument but requires it to be an integer!
You might try simply "set cpu idle" (without argument). The default seems to be VMS, with NETBSD, OPENBSD, ULTRIX, and 32V accepted as alternate values. The difference is in what the particular OS does when it is idle. That tends to change from one OS to another (even when the hardware seems to suggest a standard way to do it, as in the PDP11 with its WAIT instruction).
Same thing:
/simh/rifter/vax.ini> set cpu idle
Command not allowed
-brian
On Jun 4, 2012, at 10:14 AM, Brian Hechinger wrote:
On 6/4/2012 7:55 AM, Dave McGuire wrote:
On 06/04/2012 07:52 AM, Brian Hechinger wrote:
Anyone know how it works? I'd really like to get it working on Solaris.
You mean it doesn't? I wonder why that would be.
/simh/rifter/vax.ini> set cpu idle=VMS
Command not allowed
It detects the idle loop patterns in some OSs and throttles back the
simulator, so the host system isn't sitting there burning CPU to execute
the guest OS's idle loop.
Right, but I'm curious what it needs to know about the host OS to accomplish that.
I should look at the source but I'm not sure I'll know what I'm looking at. :)
See vax_cpu.c.
My copy (SIMH 3.8.1) rejects that command with a different message: "Invalid argument". But to make things even stranger, it DOES accept the command -- "show cpu idle" shows that it paid attention.
Possibly the issue is that the VAX-specific command next passes control to the general command (in sim_timer.c) and that routine accepts an argument but requires it to be an integer!
You might try simply "set cpu idle" (without argument). The default seems to be VMS, with NETBSD, OPENBSD, ULTRIX, and 32V accepted as alternate values. The difference is in what the particular OS does when it is idle. That tends to change from one OS to another (even when the hardware seems to suggest a standard way to do it, as in the PDP11 with its WAIT instruction).
paul
On 6/4/2012 7:55 AM, Dave McGuire wrote:
On 06/04/2012 07:52 AM, Brian Hechinger wrote:
Anyone know how it works? I'd really like to get it working on Solaris.
You mean it doesn't? I wonder why that would be.
/simh/rifter/vax.ini> set cpu idle=VMS
Command not allowed
It detects the idle loop patterns in some OSs and throttles back the
simulator, so the host system isn't sitting there burning CPU to execute
the guest OS's idle loop.
Right, but I'm curious what it needs to know about the host OS to accomplish that.
I should look at the source but I'm not sure I'll know what I'm looking at. :)
-brian
You paged??? I've been flat out lately. Sorry.
What's up? I will be around all day today.
-Steve
-----Original Message-----
From: owner-hecnet at Update.UU.SE
[mailto:owner-hecnet at Update.UU.SE] On Behalf Of Mark Benson
Sent: Sunday, June 03, 2012 15:41
To: hecnet at Update.UU.SE
Subject: [HECnet] Paging: Steve Davidson
I'm trying to get in touch with Steve, is he around at the
moment? I e-mailed his address a while back but got no response.
--
Mark Benson
http://DECtec.info
Twitter: @DECtecInfo
HECnet: STAR69::MARK
Online Resource & Mailing List for DEC Enthusiasts.
