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