23 May
2014
23 May
'14
5:30 a.m.
On 5/22/14, 8:15 PM, Mark Pizzolato - Info Comm wrote:
On Thursday, May 22, 2014 at 1:21 PM, Brad Parker
wrote:
Right. the mscp emulation code is not returning an error, near as I can
tell. That was the first thing I looked for (i.e. is the request lbn >
maxlbn)
...
It looks like the driver is trying to write past the end of the disk;
but the rq code in simh is not seeing that.
It does not seem to be throwing any errors.
A driver which trys to write beyond
the end of the disk will cause the simulation to return an error to the driver, but
won't blow up in the simulator. Real software could have done the same thing and the
hardware would merely have returned an error just like the simulated device does.
Debugging within the simh device simulation generally
requires significant detailed knowledge of how the guts of thing are working. That said,
you can always learn.
yes. I've done a lot of work with simh internals in the
past. I've used
it for co-simulation with RTL on about 4 projects. I've just never used
the debug feature.
I'll try the set dev debug; I guess I was hoping to learn exactly which
bits to set to monitor the disk i/o.
I tried creating different size disk images with "dd", even ones which
were too big. It didn't help or change anything. I tried using an
ra82, but the 4.3 release I have won't accept that, only an ra81.
Near as I can tell the UWisc 4.3BSD has a hard coded partition table and
the kernel driver is seeing something that is causing it to return an
error. I know something about MSCP and I know how the kernel driver
works, so worst case I'll create a new kernel with some printf's in it
and figure it out. I guess I was hoping I could crib off someone else's
work :-)
Your comment about vmb.exe is interesting. I'm not having any problem
bootstrapping, so I'm going to guess that's not the issue.
My current guess is that the ra driver (MSCP) is getting confused based
on something which pdp11_rq.c is telling it.
-brad
see "HELP dev SET" (i.e. HELP RQ SET)
If you think the newfs command is trying to write beyond the end of the disk, you could
avoid that by using a bigger disk than what you mention in the 'newfs' command
(i.e. make rq0 a RA82...
I also tried a stock 4.3BSD distribution and I
see exactly the same
behavior.
My memory is dim on where the partition info is, but I think in this
case it's hard coded in the unix kernel.
I might go back and try some very old simh vax releases, since it seems
like this use to work. If anyone has any ideas or insight, I'm all ears.
As
it turns out, there were issues with some newer BSD variants on older VAX models. No one
had actually done an install on one of these older machines once they started working with
MicroVAX systems (MicroVAX II and MicroVAX III (CVAX)). We discovered a bug in the newer
versions of boot block code when booting an older VAX. I have a version of VMB.exe which
can work with either the old paradigm or the broken one and let these older systems boot
these various versions. You haven't gotten that far, so even if the problem I'm
talking about actually affects the 4.3 system you're working with you wouldn't
have noticed yet.
- Mark
23 May
23 May
6:40 a.m.
New subject: [Simh] write errors attempting to install 4.3BSD on vax; simh from git
On Friday, May 23, 2014 at 5:31 AM, Brad Parker wrote:
On 5/22/14, 8:15 PM, Mark Pizzolato - Info Comm
wrote:
Well, even though I added all the debug details, I still have to look at the code to try
and determine which debug bits are interesting for any particular problem. Since there
probably isn't a ton of I/O going on when the error issue is encountered, turning on
everything probably won't generate too much output. Each line of debug output has a
fingerprint in the output which tells which flag caused that output. You shouldn't
have too much stuff to wade through.
sim> set rq debug
turns on all the debug bits for the rq device.
You don't have to turn the debug bits on before booting. You can ^E just before you
enter the newfs command and enable debugging and where it is to go before typing
"C" to continue and then enter the newfs command. From the faint details I
remember about the install process, you're running from a RAM disk at that point, so
loading the newfs binary won't produce any disk traffic, only the disk activities that
newfs requests...
There exists a possibility that the code in pdp11_rq and the current simh framework Is
negatively influencing things here. The current simh versions perform rq disk I/O
operations asynchronously, while prior simh implementations performed them synchronously
between executing simulated instructions. The current model is designed such that I/O
will seem to complete in no fewer instructions than the prior synchronous approach took,
but the actual amount of instructions the CPU gets to execute will, by default, vary on
the current codebase where previously they were always constant. If you want to avoid any
potential confusion in this area you can run with "SET NOASYNC" executed early
in your configuration file.
By the way, what host system are you running on?
On Thursday, May 22, 2014 at 1:21 PM, Brad Parker
wrote:
simulation to return an error to the driver, but
won't blow up in the
simulator. Real software could have done the same thing and the hardware
would merely have returned an error just like the simulated device does.
Right. the mscp emulation code is not returning an error, near as I can tell.
That was the first thing I looked for (i.e. is the request lbn >
maxlbn)
...
It looks like the driver is trying to write past the end of the disk;
but the rq code in simh is not seeing that.
It does not seem to be throwing any errors.
A driver which trys to write beyond
the end of the disk will cause the Debugging within the simh device simulation
generally requires significant
detailed knowledge of how the guts of thing are
working. That said, you can
always learn.
yes. I've done a lot of work with simh internals in the past. I've used it for
co-
simulation with RTL on about 4 projects. I've just never used the debug
feature.
I'll try the set dev debug; I guess I was hoping to learn exactly which bits to
set to monitor the disk i/o. I tried creating different size disk images with
"dd", even ones which were
too big. It didn't help or change anything. I tried using an ra82, but the 4.3
release I have won't accept that, only an ra81.
You mean it won't accept that as an argument to newfs? As I recall, the disk type
argument to newfs was actually a value which was used when parsing a file (/etc/disktab I
think). The details in this file described the disk and/or partition limits existed.
I'm sure you'll let me know if I can make any more suggestions.
- Mark
Near as I can tell the UWisc 4.3BSD has a hard coded
partition table and the
kernel driver is seeing something that is causing it to return an error. I know
something about MSCP and I know how the kernel driver works, so worst
case I'll create a new kernel with some printf's in it and figure it out. I
guess I
was hoping I could crib off someone else's work :-)
Your comment about vmb.exe is interesting. I'm not having any problem
bootstrapping, so I'm going to guess that's not the issue.
My current guess is that the ra driver (MSCP) is getting confused based on
something which pdp11_rq.c is telling it.
-brad
VAX
models. No one had actually done an install on one of these older
machines once they started working with MicroVAX systems (MicroVAX II
and MicroVAX III (CVAX)). We discovered a bug in the newer versions of
boot block code when booting an older VAX. I have a version of VMB.exe
which can work with either the old paradigm or the broken one and let these
older systems boot these various versions. You haven't gotten that far, so
even if the problem I'm talking about actually affects the 4.3 system you're
working with you wouldn't have noticed yet.
see "HELP dev SET" (i.e. HELP RQ
SET)
If you think the newfs command is trying to write beyond the end of the
disk, you
could avoid that by using a bigger disk than what you mention in the
'newfs' command (i.e. make rq0 a RA82...
I also tried a stock 4.3BSD distribution and I
see exactly the same
behavior.
My memory is dim on where the partition info is, but I think in this
case it's hard coded in the unix kernel.
I might go back and try some very old simh vax releases, since it
seems like this use to work. If anyone has any ideas or insight, I'm all ears.
As it turns out, there were issues with some newer BSD variants on older
- Mark
24 May
24 May
8:23 a.m.
New subject: [Simh] write errors attempting to install 4.3BSD on vax; simh from git
On 5/23/14, 9:40 AM, Mark Pizzolato - Info Comm wrote:
I'm sure you'll let me know if I can make any
more suggestions. - Mark
Your suggestions were very helpful - thanks!
It turns out that the real problem is/was the /etc/disktab in the UWisc
4.3 distribution. The entry for the RA81 is wrong or bad or somehow
incorrect. It bears no resemblance to the one in the 4.3BSD release tapes.
I discovered this because the 4.3BSD release installs on /dev/ra0h
cleanly. So I compared the output of "newfs -N -v ra0h ra81" and found
the partition size value was very different.
I changed my expect script to edit the disktab and now it works fine.
The whole goal here was to get a version of 4.3BSD with NFS. I wish I
could find a copy of Mt. Xinu's MORE/BSD, but I have not been able to
find one anywhere. I have a 3MB 11/730 with an ethernet card and it's
too slow for netbsd. I want to use NFS so 4.3BSD/UWisc seems like the
only alternative.
So in summary:
4.3BSD - installs fine to MSCP disk with latest simh
4.3Quasijarus - installs fine to MSCP disk with latest simh
4.3UWisc - fails to install to MSCP disk due to incorrect /etc/disktab
thanks again
-brad
1:15 p.m.
New subject: BSD on VAX-11/730, was Re: [Simh] write errors attempting to install 4.3BSD on vax; simh from git
On 05/24/2014 08:23 AM, Brad Parker wrote:
... I have a 3MB 11/730 with an ethernet card and
it's too slow for
netbsd. I want to use NFS so 4.3BSD/UWisc seems like the only
alternative.
So in summary:
4.3BSD - installs fine to MSCP disk with latest simh
4.3Quasijarus - installs fine to MSCP disk with latest simh
4.3UWisc - fails to install to MSCP disk due to incorrect /etc/disktab
Brad -- Too slow? Say it ain't so! I assume this is what you found for
whatever version is current? I wonder how many of the earliest low-end
VAXen are in that boat...
What are you using for a system disk on your 730? Or are you looking to
run it diskless from a SIMH server? I have more than an academic
interest as mine no longer has it's R80...
Thanks,
--Steve.
1:34 p.m.
On 24 May 2014 16:23, Brad Parker <brad at heeltoe.com> wrote:
The whole goal here was to get a version of 4.3BSD
with NFS. I wish I
could find a copy of Mt. Xinu's MORE/BSD, but I have not been able to find
one anywhere. I have a 3MB 11/730 with an ethernet card and it's too slow
for netbsd. I want to use NFS so 4.3BSD/UWisc seems like the only
alternative.
Have you tried NetBSD-1.1 Back then I think the vax port even used the same
libc and binary format as BSD4.4. It might be light enough for a '730 :)
3647
days inactive
3648
days old
4 comments
4 participants
participants (4)
-
abs＠absd.org -
brad＠heeltoe.com -
classiccmp＠crash.com -
Mark＠infocomm.com