Re: [Simh] Recent build crashes on OSX

[Henry Bent]

PTE not SYS abort, ptead = 7fffe4, ptidx = E4, d_p0br = 8034DC00,
d_p1br = FF80

Process PTE in P0 or P1 space, PC: 8002B82F (XORW3
@-7035(R8),@D0FF6436,@-70B0(R1))
sim> ex P0BR
P0BR:   8034DC00
sim> ex P1BR
P1BR:   
sim> ex SBR
SBR:00044C68

-Henry

On 18 February 2016 at 10:20, Bob Supnik  wrote:

> Okay, it's a P1 reference. VA is 7200 to 73FF, a perfectly
> legitimate P1 top-of-stack reference. ptidx + d_p1br yields (1)007FFFE4,
> which is NOT a system virtual address, so the abort triggers. The question
> is why d_p1br is wrong.
>
> After the simulator stops, please print out the value of these memory
> management registers:
>
> >ex P0BR, P1BR, SBR
>
> The transform between dynamic (d_) values and public values is done in
> this routine:
>
> extern void set_map_reg (void)
> {
> d_p0br = P0BR & ~03;
> d_p1br = (P1BR - 0x80) & ~03; /* VA<30> >> 7 */
> d_sbr = (SBR - 0x100) & ~03; /* VA<31> >> 7 */
> d_p0lr = (P0LR << 2);
> d_p1lr = (P1LR << 2) + 0x80;/* VA<30> >> 7 */
> d_slr = (SLR << 2) + 0x100; /* VA<31> >> 7 */
> return;
> }
>
> Reversing the transform yields P1BR = 0, which is wrong, wrong, wrong. It
> indicates that P1BR still has its initial value and has never been loaded.
>
> Normally, I'd debug this myself, but I don't have a Mac.
>
> /Bob Supnik
>
>
> On 2/18/2016 7:57 AM, simh-requ...@trailing-edge.com wrote:
>
>> Message: 6
>> Date: Thu, 18 Feb 2016 07:57:13 -0500
>> From: Henry Bent
>> Cc:"simh@trailing-edge.com"  
>> Subject: Re: [Simh] Recent build crashes on OSX
>> Message-ID:
>> > kmkm4...@mail.gmail.com>
>> Content-Type: text/plain; charset="utf-8"
>>
>> I'll admit that this is a little over my head, but the code was easy
>> enough
>> to add:
>>
>> PTE not SYS abort, ptead = 7fffe4, ptidx = E4, d_p0br = 8034DC00,
>> d_p1br = FF80
>>
>> -Henry
>>
>>
> ___
> 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

Re: [Simh] Recent build crashes on OSX

[Bob Supnik]

Okay, it's a P1 reference. VA is 7200 to 73FF, a perfectly 
legitimate P1 top-of-stack reference. ptidx + d_p1br yields (1)007FFFE4, 
which is NOT a system virtual address, so the abort triggers. The 
question is why d_p1br is wrong.


After the simulator stops, please print out the value of these memory 
management registers:


>ex P0BR, P1BR, SBR

The transform between dynamic (d_) values and public values is done in 
this routine:


extern void set_map_reg (void)
{
d_p0br = P0BR & ~03;
d_p1br = (P1BR - 0x80) & ~03; /* VA<30> >> 7 */
d_sbr = (SBR - 0x100) & ~03; /* VA<31> >> 7 */
d_p0lr = (P0LR << 2);
d_p1lr = (P1LR << 2) + 0x80;/* VA<30> >> 7 */
d_slr = (SLR << 2) + 0x100; /* VA<31> >> 7 */
return;
}

Reversing the transform yields P1BR = 0, which is wrong, wrong, wrong. 
It indicates that P1BR still has its initial value and has never been 
loaded.


Normally, I'd debug this myself, but I don't have a Mac.

/Bob Supnik


On 2/18/2016 7:57 AM, simh-requ...@trailing-edge.com wrote:

Message: 6
Date: Thu, 18 Feb 2016 07:57:13 -0500
From: Henry Bent
Cc:"simh@trailing-edge.com"  
Subject: Re: [Simh] Recent build crashes on OSX
Message-ID:

Content-Type: text/plain; charset="utf-8"

I'll admit that this is a little over my head, but the code was easy enough
to add:

PTE not SYS abort, ptead = 7fffe4, ptidx = E4, d_p0br = 8034DC00,
d_p1br = FF80

-Henry



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

Re: [Simh] Recent build crashes on OSX

[Henry Bent]

I'll admit that this is a little over my head, but the code was easy enough
to add:

PTE not SYS abort, ptead = 7fffe4, ptidx = E4, d_p0br = 8034DC00,
d_p1br = FF80

-Henry

On 17 February 2016 at 17:31, Bob Supnik  wrote:

> The code path to get to this problem is quite short:
>
> TLBENT fill (uint32 va, int32 lnt, int32 acc, int32 *stat)
> {
> int32 ptidx = (((uint32) va) >> 7) & ~03;
> int32 tlbpte, ptead, pte, tbi, vpn;
> static TLBENT zero_pte = { 0, 0 };
>
> if (va & VA_S0) { /* system space? */
> if (ptidx >= d_slr) /* system */
> MM_ERR (PR_LNV);
> ptead = (d_sbr + ptidx) & PAMASK;
> }
> else {
> if (va & VA_P1) { /* P1? */
> if (ptidx < d_p1lr)
> MM_ERR (PR_LNV);
> ptead = d_p1br + ptidx;
> }
> else {  /* P0 */
> if (ptidx >= d_p0lr)
> MM_ERR (PR_LNV);
> ptead = d_p0br + ptidx;
> }
> if ((ptead & VA_S0) == 0)
> ABORT (STOP_PPTE);  /* ppte must be
> sys */
>
> ANSI C (and old C) both define right shifts on unsigned integers as doing
> zero fills from the left. Therefore, ptidx must have seven leading 0's and,
> by the mask operation, 2 trailing 0's. Note that ptidx passes the length
> checks, or the abort wouldn't be reached.
>
> At the stop, the console is still active, and it should be possible to
> dump P0BR and P1BR. Note that the internal form (d_p0br and d_p1br) has
> been modified from the visible form. So put a breakpoint on the ABORT or a
> print statement beforehand (the joys of open sauce) to check that the
> internal values are all right.
>
> if ((ptead & VA_S0) == 0){
> printf ("PTE not SYS abort, ptead = %x, ptidx = %X, d_p0br = %X,
> d_p1br = %X\r\n", ptead, ptidx, d_p0br, d_p1br);
> ABORT (STOP_PPTE);  /* ppte must be
> sys */
> }
>
> The cr-lf is needed because the console is still in raw mode at that point.
>
> /Bob
>
> On 2/17/2016 3:22 PM, simh-requ...@trailing-edge.com wrote:
>
>> Message: 3
>> Date: Wed, 17 Feb 2016 15:14:04 -0500
>> From: Paul Koning
>> To: Howard Bussey
>> Cc: simh mailing list
>> Subject: Re: [Simh] Recent build crashes on OSX
>> Message-ID:<2884b212-b6d6-4c86-81c4-937fdddbd...@comcast.net>
>> Content-Type: text/plain; charset=utf-8
>>
>>
>> >On Feb 17, 2016, at 3:01 PM, Howard Bussey
>>> wrote:
>>> >
>>> >Googling “Process PTE …” shows this occurred before:
>>> >
>>> >http://mailman.trailing-edge.com/pipermail/simh/2010-May/010760.html
>>> >
>>> >The suggestion was to try turning off optimization when compiling simh…
>>>
>> In that case, gcc is the compiler.  In the case Michael mentioned, it's
>> LLVM.  So the conclusion is that it's a SimH bug, non-compliant code that
>> gets caught by modern optimizing compilers.
>>
>> Turning on GCC warnings may help; a lot of issues of this kind are
>> reported as warnings if you build with -Wall.  I don't see anything
>> interesting when I try that on OSX, but that's LLVM.  When I try it on
>> Linux, I get a bunch of possible uninitialized variables -- those are
>> sometimes false warnings but worth looking at.  More interesting is a bunch
>> of "does break strict-aliasing rules".  Those indicate incorrect (not ANSI
>> compliant) code that you used to be able to get away with, but can't any
>> longer when optimization is enabled.  The correct way to handle those
>> errors is to fix the code, not to disable the warning or the optimization
>> (as is done by some other software teams).
>>
>> More info can be found here:
>> https://homes.cs.washington.edu/~akcheung/papers/apsys12.pdf  -- a very
>> good article that all C programmers should read.
>>
>>
> ___
> 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

Re: [Simh] Recent build crashes on OSX

[Bob Supnik]

The code path to get to this problem is quite short:

TLBENT fill (uint32 va, int32 lnt, int32 acc, int32 *stat)
{
int32 ptidx = (((uint32) va) >> 7) & ~03;
int32 tlbpte, ptead, pte, tbi, vpn;
static TLBENT zero_pte = { 0, 0 };

if (va & VA_S0) { /* system space? */
if (ptidx >= d_slr) /* system */
MM_ERR (PR_LNV);
ptead = (d_sbr + ptidx) & PAMASK;
}
else {
if (va & VA_P1) { /* P1? */
if (ptidx < d_p1lr)
MM_ERR (PR_LNV);
ptead = d_p1br + ptidx;
}
else {  /* P0 */
if (ptidx >= d_p0lr)
MM_ERR (PR_LNV);
ptead = d_p0br + ptidx;
}
if ((ptead & VA_S0) == 0)
ABORT (STOP_PPTE);  /* ppte must be 
sys */


ANSI C (and old C) both define right shifts on unsigned integers as 
doing zero fills from the left. Therefore, ptidx must have seven leading 
0's and, by the mask operation, 2 trailing 0's. Note that ptidx passes 
the length checks, or the abort wouldn't be reached.


At the stop, the console is still active, and it should be possible to 
dump P0BR and P1BR. Note that the internal form (d_p0br and d_p1br) has 
been modified from the visible form. So put a breakpoint on the ABORT or 
a print statement beforehand (the joys of open sauce) to check that the 
internal values are all right.


if ((ptead & VA_S0) == 0){
printf ("PTE not SYS abort, ptead = %x, ptidx = %X, d_p0br = 
%X, d_p1br = %X\r\n", ptead, ptidx, d_p0br, d_p1br);
ABORT (STOP_PPTE);  /* ppte must be 
sys */

}

The cr-lf is needed because the console is still in raw mode at that point.

/Bob

On 2/17/2016 3:22 PM, simh-requ...@trailing-edge.com wrote:

Message: 3
Date: Wed, 17 Feb 2016 15:14:04 -0500
From: Paul Koning
To: Howard Bussey
Cc: simh mailing list
Subject: Re: [Simh] Recent build crashes on OSX
Message-ID:<2884b212-b6d6-4c86-81c4-937fdddbd...@comcast.net>
Content-Type: text/plain; charset=utf-8



>On Feb 17, 2016, at 3:01 PM, Howard Bussey  wrote:
>
>Googling “Process PTE …” shows this occurred before:
>
>http://mailman.trailing-edge.com/pipermail/simh/2010-May/010760.html
>
>The suggestion was to try turning off optimization when compiling simh…

In that case, gcc is the compiler.  In the case Michael mentioned, it's LLVM.  
So the conclusion is that it's a SimH bug, non-compliant code that gets caught 
by modern optimizing compilers.

Turning on GCC warnings may help; a lot of issues of this kind are reported as warnings 
if you build with -Wall.  I don't see anything interesting when I try that on OSX, but 
that's LLVM.  When I try it on Linux, I get a bunch of possible uninitialized variables 
-- those are sometimes false warnings but worth looking at.  More interesting is a bunch 
of "does break strict-aliasing rules".  Those indicate incorrect (not ANSI 
compliant) code that you used to be able to get away with, but can't any longer when 
optimization is enabled.  The correct way to handle those errors is to fix the code, not 
to disable the warning or the optimization (as is done by some other software teams).

More info can be found 
here:https://homes.cs.washington.edu/~akcheung/papers/apsys12.pdf  -- a very 
good article that all C programmers should read.



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

Re: [Simh] Recent build crashes on OSX

[Michael Huff]

On 2/17/16 11:32 AM, Mark Pizzolato wrote:

Hi Michael,


Based on other discussion which has already taken place about this,
I would appreciate it if you could create an issue at 
https://github.com/simh/simh/issues
In your description please provide the above AND:
1) The contents configuration file you are running the simulator with

$ cat boot.ini
set cpu idle=32v
set rq0 ra81
att rq0 rq.dsk
set rq1 dis
set rq2 dis
set rq3 dis
set rp dis
set lpt dis
set rl dis
set tq dis
set tu dis
att ts 43.tap
set tti 7b
set tto 7b
load -o boot42 0
d r10 9
d r11 0
set dz lines=8
att dz 
set dz 7b
run 2


2) The output of:
sim> SHOW VERSION
  on both your failing OSX environment AND the succeeding Linux Mint 
environment

OSX:
sim> show version
VAX 11/780 simulator V4.0-0 Beta
Simulator Framework Capabilities:
64b data
64b addresses
Ethernet Packet transports:PCAP:TAP:VDE:NAT:UDP
Idle/Throttling support is available
Virtual Hard Disk (VHD) support
Asynchronous I/O support
FrontPanel API Version 2
Host Platform:
Compiler: GCC 4.2.1 Compatible Apple LLVM 7.0.2 (clang-700.1.81)
Simulator Compiled: Feb 16 2016 at 11:09:07
Memory Access: Little Endian
Memory Pointer Size: 64 bits
Large File (>2GB) support
SDL Video support: No Video Support
RegEx support for EXPECT commands
OS clock resolution: 1ms
Time taken by msleep(1): 2ms
OS: Darwin Michaels-iMac.local 15.3.0 Darwin Kernel Version 
15.3.0: Thu Dec 10 18:40:58 PST 2015; 
root:xnu-3248.30.4~1/RELEASE_X86_64 x86_64

git commit id: aadd66c7
sim>

Linux:
sim> show version
VAX 11/780 simulator V4.0-0 Beta
Simulator Framework Capabilities:
64b data
64b addresses
Ethernet Packet transports:PCAP:TAP:VDE:NAT:UDP
Idle/Throttling support is available
Virtual Hard Disk (VHD) support
RAW disk and CD/DVD ROM support
Asynchronous I/O support
FrontPanel API Version 2
Host Platform:
Compiler: GCC 4.8.4
Simulator Compiled: Feb 16 2016 at 15:41:18
Memory Access: Little Endian
Memory Pointer Size: 64 bits
Large File (>2GB) support
SDL Video support: No Video Support
RegEx support for EXPECT commands
OS clock resolution: 1ms
Time taken by msleep(1): 4ms
OS: Linux michael-VirtualBox 3.13.0-24-generic #47-Ubuntu SMP 
Fri May 2 23:30:00 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux

git commit id: aadd66c7

3) Possibly a pointer to the disk image you're booting (compressed and visible 
in a Google
Drive or other publically accessible file exchange environment (web site, Sky 
Drive, DropBox, etc...).

https://drive.google.com/open?id=0B1H__PYsoMRtaTdkODh3cjNncDg

4) As complete a description of your OSX system and compiler version as you
can easily put together.
It's a mid-2011 21.5 inch imac, 12 gigs of ram, i5 quadcore cpu running 
at 2.4ghz, OSX 10.11.3, 2015 XCode (I'm not sure where the version info 
for that is), gcc -v shows:

gcc -v
Configured with: --prefix=/Applications/Xcode.app/Contents/Developer/usr 
--with-gxx-include-dir=/usr/include/c++/4.2.1

Apple LLVM version 7.0.2 (clang-700.1.81)
Target: x86_64-apple-darwin15.3.0
Thread model: posix

I'm going to copy and paste your questions and my answers into a comment 
on the github issue for reference.

If I can reproduce the problem it certainly can be fixed.  Paul's observations 
about
"does break strict-aliasing rules" might be relevant.

Thanks.

- Mark


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

Re: [Simh] Recent build crashes on OSX

[Timothe Litt]

On 17-Feb-16 15:22, Henry Bent wrote:
>
> I can reproduce this on OS X 10.11.3:
>
>  sim> show version
> VAX 11/780 simulator V4.0-0 Beta
> Simulator Framework Capabilities:
> 64b data
> 64b addresses
> Ethernet Packet transports:PCAP:TAP:NAT:UDP
> Idle/Throttling support is available
> Virtual Hard Disk (VHD) support
> Asynchronous I/O support
> FrontPanel API Version 2
> Host Platform:
> Compiler: GCC 4.2.1 Compatible Apple LLVM 7.0.2
> (clang-700.1.81)
> Simulator Compiled: Feb 17 2016 at 15:01:37
> Memory Access: Little Endian
> Memory Pointer Size: 64 bits
> Large File (>2GB) support
> SDL Video support: No Video Support
> RegEx support for EXPECT commands
> OS clock resolution: 1ms
> Time taken by msleep(1): 2ms
> OS: Darwin Shibaers-Mini.westell.com
>  15.3.0 Darwin Kernel Version
> 15.3.0: Thu Dec 10 18:40:58 PST 2015;
> root:xnu-3248.30.4~1/RELEASE_X86_64 x86_64
> git commit id: aadd66c7
>
> Switching to -O1 instead of -O2 doesn't make a difference.  Switching
> to -O0 gives a different error:
>
> VAX 11/780 simulator V4.0-0 Betagit commit id: aadd66c7
> libpcap version 1.5.3 - Apple version 54
> Abort trap: 6
>
> I'll see if I can narrow things down a little bit more.  Michael,
> maybe it's easiest to open a github issue for this so it can be
> tracked there?
-O0 still leaves some optimizations on.

You need to fuss with -fno-* to get even fewer.

But if simh has an issue, it really ought to be tracked down fixed.  
Shutting off 'optimization' is a really hard thing to do across multiple
platforms - the definition of what's an optimization varies, as does the
ability to shut it off.

Not to mention that wasted performance out to be a crime.

I tend to go the other way - Wall doesn't turn on ALL warnings.  Often
turning on every sensible warning -- and fixing them - is a faster
route.  For GCC, you pretty much need the man page for that version to
find them all.

-Wall -Wextra are a start.

gcc -Q --help=warning

will give a list - but you have to review it to see which ones actually
make sense.

overflow, signed/unsigned, loop optimizations and aliasing are the usual
suspects that come immediately to mind.

Annoying things were GCC thinks something is uninitialized because it
can't see that all paths do set it to something are worth fixing (just
explicitly set to 0); you never know what the optimizer will do.

Good hunting.

(I don't have a Mac)



smime.p7s
Description: S/MIME Cryptographic Signature
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] Recent build crashes on OSX

[Michael Huff]

Hi, Mark,

I just opened an issue (https://github.com/simh/simh/issues/277) and 
I'll post a comment to it with the information you requested.


I made this VM following a tutorial on gunkies, but the folder has a lot 
of junk, so while I wait for gcc to compile I'll make, test and then 
upload a pristine copy of the VM somewhere, and post that as a comment 
to the issue I opened.


-Michael

On 2/17/16 11:32 AM, Mark Pizzolato wrote:

Hi Michael,

On Wednesday, February 17, 2016 at 11:48 AM, Michael Huff wrote:

I grabbed simh_master.zip from github yesterday and compiled it on OSX and
in a virtualbox instance of Linux Mint 17. OSX is the native OS, Linux is in a
VM.

I have a 43BSD machine accessible to both on a shared drive. It will boot
normally when I run vax780 inside of the Linux VM, but  when I run the
vax780 binary I compiled in OSX it crashes.

I'm assuming I should file a bug report on the OSX build? Should I post that
over at github and what do I need to include in the report?

I realize this is a very noob-ish mail, but I don't want to submit something
long and involved and find it's entirely irrelevant, so I'm asking here first.

if it helps, this is what the crash looks like:
---
Michaels-iMac:43BSD michael$ uname -a
Darwin Michaels-iMac.local 15.3.0 Darwin Kernel Version 15.3.0: Thu Dec
10 18:40:58 PST 2015; root:xnu-3248.30.4~1/RELEASE_X86_64 x86_64
Michaels-iMac:43BSD michael$ !va
vax780 boot.ini.default

VAX 11/780 simulator V4.0-0 Betagit commit id: aadd66c7
loading ra(0,0)boot
Boot
: ra(0,0)vmunix
279844+80872+100324 start 0x12f8

Process PTE in P0 or P1 space, PC: 8002B82F (XORW3
@-7035(R8),@D0FF6436,@-70B0(R1))
sim> q
Goodbye
---
When I run that under my linux VM, I get:
---
michael@michael-VirtualBox ~/simh/43BSD $ uname -a Linux michael-
VirtualBox 3.13.0-24-generic #47-Ubuntu SMP Fri May 2
23:30:00 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux michael@michael-
VirtualBox ~/simh/43BSD $ vax780 boot.ini.default

VAX 11/780 simulator V4.0-0 Betagit commit id: aadd66c7
loading ra(0,0)boot
Boot
: ra(0,0)vmunix
279844+80872+100324 start 0x12f8
4.3 BSD UNIX #1: Fri Jun  6 19:55:29 PDT 1986
  kar...@monet.berkeley.edu:/usr/src/sys/GENERIC
real mem  = 8388608
SYSPTSIZE limits number of buffers to 140 avail mem = 7187456 using 140
buffers containing 524288 bytes of memory
mcr0 at tr1
mcr1 at tr2

Based on other discussion which has already taken place about this,
I would appreciate it if you could create an issue at 
https://github.com/simh/simh/issues
In your description please provide the above AND:
1) The contents configuration file you are running the simulator with
2) The output of:
sim> SHOW VERSION
  on both your failing OSX environment AND the succeeding Linux Mint 
environment
3) Possibly a pointer to the disk image you're booting (compressed and visible 
in a Google
Drive or other publically accessible file exchange environment (web site, Sky 
Drive, DropBox, etc...).
4) As complete a description of your OSX system and compiler version as you
can easily put together.

If I can reproduce the problem it certainly can be fixed.  Paul's observations 
about
"does break strict-aliasing rules" might be relevant.

Thanks.

- Mark


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

Re: [Simh] Recent build crashes on OSX

[khandy21yo]

Tou ca n also try llvm on the Linux side,

 Original message 
From Michael Huff  
Date: 02/17/2016  1:15 PM  (GMT-07:00) 
To simh@trailing-edge.com 
Subject Re: [Simh] Recent build crashes on OSX 
 
On 2/17/16 11:07 AM, Timothe Litt wrote:
> On 17-Feb-16 14:59, Paul Koning wrote:
>>> On Feb 17, 2016, at 2:53 PM, Timothe Litt  wrote:
>>>
>>> On 17-Feb-16 14:48, Michael Huff wrote:
>>>> I grabbed simh_master.zip from github yesterday and compiled it on OSX
>>>> and in a virtualbox instance of Linux Mint 17. OSX is the native OS,
>>>> Linux is in a VM.
>>>>
>>>> I have a 43BSD machine accessible to both on a shared drive. It will
>>>> boot normally when I run vax780 inside of the Linux VM, but  when I
>>>> run the vax780 binary I compiled in OSX it crashes.
>>>>
>>> If I had to guess, it would be that the shared drive is not presenting
>>> the same data to both environments.
>>>
>>> Perhaps it's treating the binary file as text and adding s -- or
>>> some such.
>>>
>>> I'd checksum the file from both sides before assuming it's a SimH issue.
>> That is a good test, certainly.  But OSX is Unix, so it shouldn't suffer 
>> from the sort of Windows-style misbehavior you mentioned.
> I know.  But it does depend on how the file is shared, and from where.
> Is the real file on OSX?  On Windows?  On an NAS?  Shared over SMB?  NFS?
The file is on an external hard disk formatted as NTFS; I have a device 
driver installed on OSX to make the filesystem read/write, and it's 
mounted as a shared folder in virtualbox.
> Especially SMB has been known to do very strange things.
>
> Well, I see that md5sums match, so it's not that this time.
>> I wonder if it might be a compiler bug.  It would be instructive to download 
>> gcc and use that to build the OSX based SIMH, to see if it behaves 
>> differently.
> Yup.
>
> The symptom looks like data corruption.  The instruction at the faulting
> PC is not likely a real one.
>
>> paul
>>
>>
I built it in Linux with gcc 4.8; I'm trying to install gcc 4.8 in 
macports on OSX but it has to compile which will probably take some 
time. After it's done I'll recompile simh and see if it works then.

___
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

Re: [Simh] Recent build crashes on OSX

[Mark Pizzolato]

Hi Michael,

On Wednesday, February 17, 2016 at 11:48 AM, Michael Huff wrote:
> I grabbed simh_master.zip from github yesterday and compiled it on OSX and
> in a virtualbox instance of Linux Mint 17. OSX is the native OS, Linux is in a
> VM.
> 
> I have a 43BSD machine accessible to both on a shared drive. It will boot
> normally when I run vax780 inside of the Linux VM, but  when I run the
> vax780 binary I compiled in OSX it crashes.
> 
> I'm assuming I should file a bug report on the OSX build? Should I post that
> over at github and what do I need to include in the report?
> 
> I realize this is a very noob-ish mail, but I don't want to submit something
> long and involved and find it's entirely irrelevant, so I'm asking here first.
> 
> if it helps, this is what the crash looks like:
> ---
> Michaels-iMac:43BSD michael$ uname -a
> Darwin Michaels-iMac.local 15.3.0 Darwin Kernel Version 15.3.0: Thu Dec
> 10 18:40:58 PST 2015; root:xnu-3248.30.4~1/RELEASE_X86_64 x86_64
> Michaels-iMac:43BSD michael$ !va
> vax780 boot.ini.default
> 
> VAX 11/780 simulator V4.0-0 Betagit commit id: aadd66c7
> loading ra(0,0)boot
> Boot
> : ra(0,0)vmunix
> 279844+80872+100324 start 0x12f8
> 
> Process PTE in P0 or P1 space, PC: 8002B82F (XORW3
> @-7035(R8),@D0FF6436,@-70B0(R1))
> sim> q
> Goodbye
> ---
> When I run that under my linux VM, I get:
> ---
> michael@michael-VirtualBox ~/simh/43BSD $ uname -a Linux michael-
> VirtualBox 3.13.0-24-generic #47-Ubuntu SMP Fri May 2
> 23:30:00 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux michael@michael-
> VirtualBox ~/simh/43BSD $ vax780 boot.ini.default
> 
> VAX 11/780 simulator V4.0-0 Betagit commit id: aadd66c7
> loading ra(0,0)boot
> Boot
> : ra(0,0)vmunix
> 279844+80872+100324 start 0x12f8
> 4.3 BSD UNIX #1: Fri Jun  6 19:55:29 PDT 1986
>  kar...@monet.berkeley.edu:/usr/src/sys/GENERIC
> real mem  = 8388608
> SYSPTSIZE limits number of buffers to 140 avail mem = 7187456 using 140
> buffers containing 524288 bytes of memory
> mcr0 at tr1
> mcr1 at tr2

Based on other discussion which has already taken place about this, 
I would appreciate it if you could create an issue at 
https://github.com/simh/simh/issues
In your description please provide the above AND:
1) The contents configuration file you are running the simulator with
2) The output of:
sim> SHOW VERSION
 on both your failing OSX environment AND the succeeding Linux Mint 
environment
3) Possibly a pointer to the disk image you're booting (compressed and visible 
in a Google 
Drive or other publically accessible file exchange environment (web site, Sky 
Drive, DropBox, etc...).
4) As complete a description of your OSX system and compiler version as you 
can easily put together.

If I can reproduce the problem it certainly can be fixed.  Paul's observations 
about 
"does break strict-aliasing rules" might be relevant.

Thanks.

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

Re: [Simh] Recent build crashes on OSX

[Henry Bent]

On 17 February 2016 at 14:48, Michael Huff  wrote:

> I grabbed simh_master.zip from github yesterday and compiled it on OSX and
> in a virtualbox instance of Linux Mint 17. OSX is the native OS, Linux is
> in a VM.
>
> I have a 43BSD machine accessible to both on a shared drive. It will boot
> normally when I run vax780 inside of the Linux VM, but  when I run the
> vax780 binary I compiled in OSX it crashes.
>
> I'm assuming I should file a bug report on the OSX build? Should I post
> that over at github and what do I need to include in the report?
>
> I realize this is a very noob-ish mail, but I don't want to submit
> something long and involved and find it's entirely irrelevant, so I'm
> asking here first.
>
> if it helps, this is what the crash looks like:
> ---
> Michaels-iMac:43BSD michael$ uname -a
> Darwin Michaels-iMac.local 15.3.0 Darwin Kernel Version 15.3.0: Thu Dec 10
> 18:40:58 PST 2015; root:xnu-3248.30.4~1/RELEASE_X86_64 x86_64
> Michaels-iMac:43BSD michael$ !va
> vax780 boot.ini.default
>
> VAX 11/780 simulator V4.0-0 Betagit commit id: aadd66c7
> loading ra(0,0)boot
> Boot
> : ra(0,0)vmunix
> 279844+80872+100324 start 0x12f8
>
> Process PTE in P0 or P1 space, PC: 8002B82F (XORW3
> @-7035(R8),@D0FF6436,@-70B0(R1))
> sim> q
> Goodbye
> ---
> When I run that under my linux VM, I get:
> ---
> michael@michael-VirtualBox ~/simh/43BSD $ uname -a
> Linux michael-VirtualBox 3.13.0-24-generic #47-Ubuntu SMP Fri May 2
> 23:30:00 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux
> michael@michael-VirtualBox ~/simh/43BSD $ vax780 boot.ini.default
>
> VAX 11/780 simulator V4.0-0 Betagit commit id: aadd66c7
> loading ra(0,0)boot
> Boot
> : ra(0,0)vmunix
> 279844+80872+100324 start 0x12f8
> 4.3 BSD UNIX #1: Fri Jun  6 19:55:29 PDT 1986
> kar...@monet.berkeley.edu:/usr/src/sys/GENERIC
> real mem  = 8388608
> SYSPTSIZE limits number of buffers to 140
> avail mem = 7187456
> using 140 buffers containing 524288 bytes of memory
> mcr0 at tr1
> mcr1 at tr2
> ---
> and it continues to the login prompt and acts normally.
>
> Thank you for your time and advice.
> -Michael
> ___
> Simh mailing list
> Simh@trailing-edge.com
> http://mailman.trailing-edge.com/mailman/listinfo/simh


I can reproduce this on OS X 10.11.3:

 sim> show version
VAX 11/780 simulator V4.0-0 Beta
Simulator Framework Capabilities:
64b data
64b addresses
Ethernet Packet transports:PCAP:TAP:NAT:UDP
Idle/Throttling support is available
Virtual Hard Disk (VHD) support
Asynchronous I/O support
FrontPanel API Version 2
Host Platform:
Compiler: GCC 4.2.1 Compatible Apple LLVM 7.0.2
(clang-700.1.81)
Simulator Compiled: Feb 17 2016 at 15:01:37
Memory Access: Little Endian
Memory Pointer Size: 64 bits
Large File (>2GB) support
SDL Video support: No Video Support
RegEx support for EXPECT commands
OS clock resolution: 1ms
Time taken by msleep(1): 2ms
OS: Darwin Shibaers-Mini.westell.com 15.3.0 Darwin Kernel
Version 15.3.0: Thu Dec 10 18:40:58 PST 2015;
root:xnu-3248.30.4~1/RELEASE_X86_64 x86_64
git commit id: aadd66c7

Switching to -O1 instead of -O2 doesn't make a difference.  Switching to
-O0 gives a different error:

VAX 11/780 simulator V4.0-0 Betagit commit id: aadd66c7
libpcap version 1.5.3 - Apple version 54
Abort trap: 6

I'll see if I can narrow things down a little bit more.  Michael, maybe
it's easiest to open a github issue for this so it can be tracked there?

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

Re: [Simh] Recent build crashes on OSX

[Michael Huff]

On 2/17/16 11:07 AM, Timothe Litt wrote:

On 17-Feb-16 14:59, Paul Koning wrote:

On Feb 17, 2016, at 2:53 PM, Timothe Litt  wrote:

On 17-Feb-16 14:48, Michael Huff wrote:

I grabbed simh_master.zip from github yesterday and compiled it on OSX
and in a virtualbox instance of Linux Mint 17. OSX is the native OS,
Linux is in a VM.

I have a 43BSD machine accessible to both on a shared drive. It will
boot normally when I run vax780 inside of the Linux VM, but  when I
run the vax780 binary I compiled in OSX it crashes.


If I had to guess, it would be that the shared drive is not presenting
the same data to both environments.

Perhaps it's treating the binary file as text and adding s -- or
some such.

I'd checksum the file from both sides before assuming it's a SimH issue.

That is a good test, certainly.  But OSX is Unix, so it shouldn't suffer from 
the sort of Windows-style misbehavior you mentioned.

I know.  But it does depend on how the file is shared, and from where.
Is the real file on OSX?  On Windows?  On an NAS?  Shared over SMB?  NFS?
The file is on an external hard disk formatted as NTFS; I have a device 
driver installed on OSX to make the filesystem read/write, and it's 
mounted as a shared folder in virtualbox.

Especially SMB has been known to do very strange things.

Well, I see that md5sums match, so it's not that this time.

I wonder if it might be a compiler bug.  It would be instructive to download 
gcc and use that to build the OSX based SIMH, to see if it behaves differently.

Yup.

The symptom looks like data corruption.  The instruction at the faulting
PC is not likely a real one.


paul


I built it in Linux with gcc 4.8; I'm trying to install gcc 4.8 in 
macports on OSX but it has to compile which will probably take some 
time. After it's done I'll recompile simh and see if it works then.


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

Re: [Simh] Recent build crashes on OSX

[Paul Koning]

> On Feb 17, 2016, at 3:01 PM, Howard Bussey  wrote:
> 
> Googling “Process PTE …” shows this occurred before:
> 
> http://mailman.trailing-edge.com/pipermail/simh/2010-May/010760.html
> 
> The suggestion was to try turning off optimization when compiling simh…

In that case, gcc is the compiler.  In the case Michael mentioned, it's LLVM.  
So the conclusion is that it's a SimH bug, non-compliant code that gets caught 
by modern optimizing compilers.

Turning on GCC warnings may help; a lot of issues of this kind are reported as 
warnings if you build with -Wall.  I don't see anything interesting when I try 
that on OSX, but that's LLVM.  When I try it on Linux, I get a bunch of 
possible uninitialized variables -- those are sometimes false warnings but 
worth looking at.  More interesting is a bunch of "does break strict-aliasing 
rules".  Those indicate incorrect (not ANSI compliant) code that you used to be 
able to get away with, but can't any longer when optimization is enabled.  The 
correct way to handle those errors is to fix the code, not to disable the 
warning or the optimization (as is done by some other software teams).

More info can be found here: 
https://homes.cs.washington.edu/~akcheung/papers/apsys12.pdf -- a very good 
article that all C programmers should read.

paul


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

Re: [Simh] Recent build crashes on OSX

[Timothe Litt]

On 17-Feb-16 14:59, Paul Koning wrote:
>> On Feb 17, 2016, at 2:53 PM, Timothe Litt  wrote:
>>
>> On 17-Feb-16 14:48, Michael Huff wrote:
>>> I grabbed simh_master.zip from github yesterday and compiled it on OSX
>>> and in a virtualbox instance of Linux Mint 17. OSX is the native OS,
>>> Linux is in a VM.
>>>
>>> I have a 43BSD machine accessible to both on a shared drive. It will
>>> boot normally when I run vax780 inside of the Linux VM, but  when I
>>> run the vax780 binary I compiled in OSX it crashes.
>>>
>> If I had to guess, it would be that the shared drive is not presenting
>> the same data to both environments.
>>
>> Perhaps it's treating the binary file as text and adding s -- or
>> some such.
>>
>> I'd checksum the file from both sides before assuming it's a SimH issue.
> That is a good test, certainly.  But OSX is Unix, so it shouldn't suffer from 
> the sort of Windows-style misbehavior you mentioned.
I know.  But it does depend on how the file is shared, and from where. 
Is the real file on OSX?  On Windows?  On an NAS?  Shared over SMB?  NFS?

Especially SMB has been known to do very strange things.

Well, I see that md5sums match, so it's not that this time.
> I wonder if it might be a compiler bug.  It would be instructive to download 
> gcc and use that to build the OSX based SIMH, to see if it behaves 
> differently.
Yup. 

The symptom looks like data corruption.  The instruction at the faulting
PC is not likely a real one.

>   paul
>
>




smime.p7s
Description: S/MIME Cryptographic Signature
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] Recent build crashes on OSX

[Michael Huff]

I don't have any optimizations turned on; my first compile was with -J 3 
but I re-ran it without that and still had the same result.


I'm going to follow Paul's hint, OSX appears to use CLang for it's gcc, 
I'm going to try to install a real gcc from ports.


On 2/17/16 11:01 AM, Howard Bussey wrote:

Googling “Process PTE …” shows this occurred before:

http://mailman.trailing-edge.com/pipermail/simh/2010-May/010760.html

The suggestion was to try turning off optimization when compiling simh…

—Howard


On Feb 17, 2016, at 2:48 PM, Michael Huff  wrote:

I grabbed simh_master.zip from github yesterday and compiled it on OSX and in a 
virtualbox instance of Linux Mint 17. OSX is the native OS, Linux is in a VM.

I have a 43BSD machine accessible to both on a shared drive. It will boot 
normally when I run vax780 inside of the Linux VM, but  when I run the vax780 
binary I compiled in OSX it crashes.

I'm assuming I should file a bug report on the OSX build? Should I post that 
over at github and what do I need to include in the report?

I realize this is a very noob-ish mail, but I don't want to submit something 
long and involved and find it's entirely irrelevant, so I'm asking here first.

if it helps, this is what the crash looks like:
---
Michaels-iMac:43BSD michael$ uname -a
Darwin Michaels-iMac.local 15.3.0 Darwin Kernel Version 15.3.0: Thu Dec 10 
18:40:58 PST 2015; root:xnu-3248.30.4~1/RELEASE_X86_64 x86_64
Michaels-iMac:43BSD michael$ !va
vax780 boot.ini.default

VAX 11/780 simulator V4.0-0 Betagit commit id: aadd66c7
loading ra(0,0)boot
Boot
: ra(0,0)vmunix
279844+80872+100324 start 0x12f8

Process PTE in P0 or P1 space, PC: 8002B82F (XORW3 
@-7035(R8),@D0FF6436,@-70B0(R1))
sim> q
Goodbye
---
When I run that under my linux VM, I get:
---
michael@michael-VirtualBox ~/simh/43BSD $ uname -a
Linux michael-VirtualBox 3.13.0-24-generic #47-Ubuntu SMP Fri May 2 23:30:00 
UTC 2014 x86_64 x86_64 x86_64 GNU/Linux
michael@michael-VirtualBox ~/simh/43BSD $ vax780 boot.ini.default

VAX 11/780 simulator V4.0-0 Betagit commit id: aadd66c7
loading ra(0,0)boot
Boot
: ra(0,0)vmunix
279844+80872+100324 start 0x12f8
4.3 BSD UNIX #1: Fri Jun  6 19:55:29 PDT 1986
kar...@monet.berkeley.edu:/usr/src/sys/GENERIC
real mem  = 8388608
SYSPTSIZE limits number of buffers to 140
avail mem = 7187456
using 140 buffers containing 524288 bytes of memory
mcr0 at tr1
mcr1 at tr2
---
and it continues to the login prompt and acts normally.

Thank you for your time and advice.
-Michael
___
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

Re: [Simh] Recent build crashes on OSX

[Howard Bussey]

Googling “Process PTE …” shows this occurred before:

http://mailman.trailing-edge.com/pipermail/simh/2010-May/010760.html

The suggestion was to try turning off optimization when compiling simh…

—Howard

> On Feb 17, 2016, at 2:48 PM, Michael Huff  wrote:
> 
> I grabbed simh_master.zip from github yesterday and compiled it on OSX and in 
> a virtualbox instance of Linux Mint 17. OSX is the native OS, Linux is in a 
> VM.
> 
> I have a 43BSD machine accessible to both on a shared drive. It will boot 
> normally when I run vax780 inside of the Linux VM, but  when I run the vax780 
> binary I compiled in OSX it crashes.
> 
> I'm assuming I should file a bug report on the OSX build? Should I post that 
> over at github and what do I need to include in the report?
> 
> I realize this is a very noob-ish mail, but I don't want to submit something 
> long and involved and find it's entirely irrelevant, so I'm asking here first.
> 
> if it helps, this is what the crash looks like:
> ---
> Michaels-iMac:43BSD michael$ uname -a
> Darwin Michaels-iMac.local 15.3.0 Darwin Kernel Version 15.3.0: Thu Dec 10 
> 18:40:58 PST 2015; root:xnu-3248.30.4~1/RELEASE_X86_64 x86_64
> Michaels-iMac:43BSD michael$ !va
> vax780 boot.ini.default
> 
> VAX 11/780 simulator V4.0-0 Betagit commit id: aadd66c7
> loading ra(0,0)boot
> Boot
> : ra(0,0)vmunix
> 279844+80872+100324 start 0x12f8
> 
> Process PTE in P0 or P1 space, PC: 8002B82F (XORW3 
> @-7035(R8),@D0FF6436,@-70B0(R1))
> sim> q
> Goodbye
> ---
> When I run that under my linux VM, I get:
> ---
> michael@michael-VirtualBox ~/simh/43BSD $ uname -a
> Linux michael-VirtualBox 3.13.0-24-generic #47-Ubuntu SMP Fri May 2 23:30:00 
> UTC 2014 x86_64 x86_64 x86_64 GNU/Linux
> michael@michael-VirtualBox ~/simh/43BSD $ vax780 boot.ini.default
> 
> VAX 11/780 simulator V4.0-0 Betagit commit id: aadd66c7
> loading ra(0,0)boot
> Boot
> : ra(0,0)vmunix
> 279844+80872+100324 start 0x12f8
> 4.3 BSD UNIX #1: Fri Jun  6 19:55:29 PDT 1986
>kar...@monet.berkeley.edu:/usr/src/sys/GENERIC
> real mem  = 8388608
> SYSPTSIZE limits number of buffers to 140
> avail mem = 7187456
> using 140 buffers containing 524288 bytes of memory
> mcr0 at tr1
> mcr1 at tr2
> ---
> and it continues to the login prompt and acts normally.
> 
> Thank you for your time and advice.
> -Michael
> ___
> 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

Re: [Simh] Recent build crashes on OSX

[Michael Huff]

On 2/17/16 10:53 AM, Timothe Litt wrote:

On 17-Feb-16 14:48, Michael Huff wrote:

I grabbed simh_master.zip from github yesterday and compiled it on OSX
and in a virtualbox instance of Linux Mint 17. OSX is the native OS,
Linux is in a VM.

I have a 43BSD machine accessible to both on a shared drive. It will
boot normally when I run vax780 inside of the Linux VM, but  when I
run the vax780 binary I compiled in OSX it crashes.


If I had to guess, it would be that the shared drive is not presenting
the same data to both environments.

Perhaps it's treating the binary file as text and adding s -- or
some such.

I'd checksum the file from both sides before assuming it's a SimH issue.

But that's only a guess

It's a good idea. OSX has md5 and Linux has md5sum; I'm going to assume 
that they're the same tool with different names.


OSX output:
$ md5 rq.dsk
MD5 (rq.dsk) = f29cdac56ede456dcba7e30fc7d9dd6c
Linux output:
$ md5sum rq.dsk
f29cdac56ede456dcba7e30fc7d9dd6c  rq.dsk

The checksum appears to be the same in both.
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] Recent build crashes on OSX

[Paul Koning]

> On Feb 17, 2016, at 2:53 PM, Timothe Litt  wrote:
> 
> On 17-Feb-16 14:48, Michael Huff wrote:
>> I grabbed simh_master.zip from github yesterday and compiled it on OSX
>> and in a virtualbox instance of Linux Mint 17. OSX is the native OS,
>> Linux is in a VM.
>> 
>> I have a 43BSD machine accessible to both on a shared drive. It will
>> boot normally when I run vax780 inside of the Linux VM, but  when I
>> run the vax780 binary I compiled in OSX it crashes.
>> 
> If I had to guess, it would be that the shared drive is not presenting
> the same data to both environments.
> 
> Perhaps it's treating the binary file as text and adding s -- or
> some such.
> 
> I'd checksum the file from both sides before assuming it's a SimH issue.

That is a good test, certainly.  But OSX is Unix, so it shouldn't suffer from 
the sort of Windows-style misbehavior you mentioned.

I wonder if it might be a compiler bug.  It would be instructive to download 
gcc and use that to build the OSX based SIMH, to see if it behaves differently.

paul


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

Re: [Simh] Recent build crashes on OSX

[Timothe Litt]

On 17-Feb-16 14:48, Michael Huff wrote:
> I grabbed simh_master.zip from github yesterday and compiled it on OSX
> and in a virtualbox instance of Linux Mint 17. OSX is the native OS,
> Linux is in a VM.
>
> I have a 43BSD machine accessible to both on a shared drive. It will
> boot normally when I run vax780 inside of the Linux VM, but  when I
> run the vax780 binary I compiled in OSX it crashes.
>
If I had to guess, it would be that the shared drive is not presenting
the same data to both environments.

Perhaps it's treating the binary file as text and adding s -- or
some such.

I'd checksum the file from both sides before assuming it's a SimH issue.

But that's only a guess

> I'm assuming I should file a bug report on the OSX build? Should I
> post that over at github and what do I need to include in the report?
>
> I realize this is a very noob-ish mail, but I don't want to submit
> something long and involved and find it's entirely irrelevant, so I'm
> asking here first.
>
> if it helps, this is what the crash looks like:
> ---
> Michaels-iMac:43BSD michael$ uname -a
> Darwin Michaels-iMac.local 15.3.0 Darwin Kernel Version 15.3.0: Thu
> Dec 10 18:40:58 PST 2015; root:xnu-3248.30.4~1/RELEASE_X86_64 x86_64
> Michaels-iMac:43BSD michael$ !va
> vax780 boot.ini.default
>
> VAX 11/780 simulator V4.0-0 Betagit commit id: aadd66c7
> loading ra(0,0)boot
> Boot
> : ra(0,0)vmunix
> 279844+80872+100324 start 0x12f8
>
> Process PTE in P0 or P1 space, PC: 8002B82F (XORW3
> @-7035(R8),@D0FF6436,@-70B0(R1))
> sim> q
> Goodbye
> ---
> When I run that under my linux VM, I get:
> ---
> michael@michael-VirtualBox ~/simh/43BSD $ uname -a
> Linux michael-VirtualBox 3.13.0-24-generic #47-Ubuntu SMP Fri May 2
> 23:30:00 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux
> michael@michael-VirtualBox ~/simh/43BSD $ vax780 boot.ini.default
>
> VAX 11/780 simulator V4.0-0 Betagit commit id: aadd66c7
> loading ra(0,0)boot
> Boot
> : ra(0,0)vmunix
> 279844+80872+100324 start 0x12f8
> 4.3 BSD UNIX #1: Fri Jun  6 19:55:29 PDT 1986
> kar...@monet.berkeley.edu:/usr/src/sys/GENERIC
> real mem  = 8388608
> SYSPTSIZE limits number of buffers to 140
> avail mem = 7187456
> using 140 buffers containing 524288 bytes of memory
> mcr0 at tr1
> mcr1 at tr2
> ---
> and it continues to the login prompt and acts normally.
>
> Thank you for your time and advice.
> -Michael
> ___
> Simh mailing list
> Simh@trailing-edge.com
> http://mailman.trailing-edge.com/mailman/listinfo/simh




smime.p7s
Description: S/MIME Cryptographic Signature
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh