23 May
2014
23 May
'14
9:40 a.m.
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