> Ah, OK. So I get some PUA0: errors ticking up every so often, most
> of which are right after the system has had some "hiccup" of non-
> interactivity for several minutes. Some initial research indicates
> that the PU device is the UDA controller, which is what I believe
> the CQD-220 masquerades as (more or less). Right now, after three
> hours of sitting basically idle, it's logged 26 errors.
>
> So I'll have to check that out. It could be something as simple as
> balky SCSI termination, since I do have 4 devices in the chain and
> the terminator is a Jaz drive using internal termination. I'll
> play with it some. Hopefully it's not the hard drive going bad,
> since my supply of SCSI drives is essentially dry. It's a bit
> worrisome that it's the PU device going bad rather than the DU
> device, but I'm not 100% sure how VMS logs the errors, so it could
> be what I suspect.
>
VMS has a process called ERRFMT which logs errors in a binary file called
sys$errorlog:errlog.sys - the way to get a detailed human readable report of
the contents of that file used to be ANALYZE /ERROR but I don't think that
works any more. Maybe someone else can chime in and suggest what the current
way is.
Keep an eye out also for operator messages relating to the PU and DU devices
after doing a REPLY /ENABLE, SET TERMINAL, SET BROADCAST etc.
Regards,
Peter Coghlan.
> > With VAX/VMS, having lots of physical memory is neither necessary nor
> > sufficient. More important is how the virtual memory system is configured.
> > Perhaps you are low on pagefile space or non-paged pool or something like
> > that?
>
> I was musing on this while reviewing the install manual and it does
> mention that at least 24 MB physical memory is necessary for TCP/IP
> 5.1. I don't know how hard and fast that is, but it's possible that
> the changes I made to the pool allocation per the manual have
> destabilized the system. Since I don't have much running on there,
> I've reinstalled from scratch to see if I have the same problem with
> no TCP/IP installed/running.
>
I would worry more about DECWindows needing large amounts of memory rather
than TCP/IP but having said that, I've always used Multinet rather than TCP/IP
services so I don't know a lot about it.
I suspect the manual is saying that a typical workload on a more capable VAX
than an MVII would need 24 MB for good performance. I think you should be able
to get by with rather less memory than that, particularly if you don't have a
graphics card.
It should not be necessary to reinstall to see the effect of not running TCP/IP
services. Just comment out the command to start it
(probably in sys$manager:systartup_vms.com) and reboot.
Regards,
Peter Coghlan.
I thought I was going to acquire an RS/6000 so I started buying spare
parts. Plans changed ...
Let me know if you need P/N 68X6356 (FRU 70F9976) which are 8MB SIMMs or
P/N 32G8212 which are 16MB SIMMs. These came in a 'Bag O' Memory' so
they are untested, but they were properly stored.
They are not free - shipping cost and beer money will do fine though.
Mike
Date: Sat, 4 May 2013 22:04:38 -0400
From: David Riley <fraveydank at gmail.com>
To: "General Discussion: On-Topic and Off-Topic Posts"
<cctalk at classiccmp.org>
Subject: uVAX 3900 out to lunch after inactivity
Message-ID: <0315AF5D-BB77-464C-9BD6-FE312DDCE21A at gmail.com>
Content-Type: text/plain; charset=us-ascii
The long saga of making my recent KA655 acquisition work
continues! It's been mostly smooth sailing since I got
a decent Plextor drive, but there's one persistent problem.
Under VMS 7.3, after a longish period of inactivity (I've
seen it after a few hours, but I've not been able to
narrow it down beyond that), it seems to just kind of go
out to lunch. VMS is still *running*... if I have a
Telnet session running MONITOR, the clock will still update
and the activity meters still move (a little; they show
very little activity, but that's expected since there's not
a lot going on on the machine yet). But if I terminate
MONITOR (it responds interactively to ctrl-C, etc) and try
to run anything else (say, HELP), it stops responding.
Other terminals are totally unresponsive. If I try to
open a Telnet session, TCP connects but no other traffic
happens.
This also happens if I turn TCP/IP off. I'm running with
16 MB RAM, which should be enough for a machine that's not
really running much yet, and if I were having memory issues
I would expect things like existing MONITOR sessions to
have serious problems.
If anyone has any idea what might be going on here, I'm
all ears.
I have seen this behavior a number of times when the disk
has gone offline for some reason. I'm not sure there
is a simple way to tell when the drive can no longer
be accessed. Obviously, there will be no error logging
of the condition, except that VMS may write some buffered
error messages on the next boot that may offer a clue.
Jon
>
> The long saga of making my recent KA655 acquisition work
> continues! It's been mostly smooth sailing since I got
> a decent Plextor drive, but there's one persistent problem.
> Under VMS 7.3, after a longish period of inactivity (I've
> seen it after a few hours, but I've not been able to
> narrow it down beyond that), it seems to just kind of go
> out to lunch. VMS is still *running*... if I have a
> Telnet session running MONITOR, the clock will still update
> and the activity meters still move (a little; they show
> very little activity, but that's expected since there's not
> a lot going on on the machine yet). But if I terminate
> MONITOR (it responds interactively to ctrl-C, etc) and try
> to run anything else (say, HELP), it stops responding.
> Other terminals are totally unresponsive. If I try to
> open a Telnet session, TCP connects but no other traffic
> happens.
>
> This also happens if I turn TCP/IP off. I'm running with
> 16 MB RAM, which should be enough for a machine that's not
> really running much yet, and if I were having memory issues
> I would expect things like existing MONITOR sessions to
> have serious problems.
>
> The only other correlation I can think of is that this
> seems to happen most when I've just installed a layered
> product, so it could have something to do with the CD
> still being mounted. On the other hand, I tend to leave
> the machine alone and unattended for long periods of time
> for product installs, so correlation is necessarily not
> very trustworthy here.
>
> I can still issue a break from the terminal and boot again
> from the console firmware, so that still seems fine.
>
> If anyone has any idea what might be going on here, I'm
> all ears.
>
Do either of:
$ REPLY /ENABLE
$ SHOW ERROR
show up any problems? You might need:
$ SET TERMINAL /BROADCAST
and/or
$ SET BROADCAST=ALL
with REPLY /ENABLE if you are doing this on the console and something has
disabled broadcasts on the console.
In older versions of VMS,
$ ANALYZE /ERROR
used to be very useful for spotting behind-the-scenes hardware problems and
worked straight out of the box but it was replaced in later versions (on Alpha
at least - I'm not sure about VAX) by
$ DIAGNOSE /TRANSLATE
which required extra software to be installed and possibly licensed first.
I lost track of what happened after that but I think that was replaced
again by something else equally difficult to make use of :-(
Your disk could be going to sleep but it seems unlikely that it would
recover by just halting and rebooting the system.
With VAX/VMS, having lots of physical memory is neither necessary nor
sufficient. More important is how the virtual memory system is configured.
Perhaps you are low on pagefile space or non-paged pool or something like
that?
Use
$ SHOW MEMORY /FILES
to check how much free pagefile space you have.
$ SHOW MEMORY /POOL /FULL
will give a vast number of figures. If "Free space" is low and "Current size"
is much bigger than "Initial size" and approaching "Maximum size", you may be
running into problems with non-paged pool.
If there are no hardware problems, an AUTOGEN might well help. For best
results, it should be done after whatever activity that might have used up
resources but it's obviously no good if the machine stops responding in the
middle of the AUTOGEN procedure. Tell AUTOGEN to save feedback and use it
when calculating new system parameters. It will complain that the machine
wasn't up for 24 hours but tell it to do it anyway.
$ @SYS$UPDATE:AUTOGEN HELP
for further details.
Regards,
Peter Coghlan.
> > Do either of:
> >
> > $ REPLY /ENABLE
> > $ SHOW ERROR
> >
> > show up any problems? You might need:
> >
> > $ SET TERMINAL /BROADCAST
> >
> > and/or
> >
> > $ SET BROADCAST=ALL
> >
> > with REPLY /ENABLE if you are doing this on the console and something has
> > disabled broadcasts on the console.
>
> Any of these would probably be great, but I should probably be a little
> more clear; it's not really responding at all to input after I respond
> to a prompt. After the carriage return, it just sits there and doesn't
> even echo anything, though as I mentioned, anything running elsewhere
> (like MONITOR) still seems to keep going.
>
It's me who should have been clearer.
Do the REPLY /ENABLE and friends before the problem shows up in the hope of
seeing a message giving details about the problem when it does show up.
You might see something like "Mount verification is in progress." for example.
Do the SHOW ERROR anytime and if anything (other than a tape drive, terminal
or any sort of virtual device) shows a non-zero error count, investigate the
reason for it. Particularly watch for MEMORY or CPU errors. If your disk
device starts clocking errors just before the system stalls, that would tend
to point the finger in its direction.
$ SHOW SYSTEM
is the one command I know of that will usually execute when almost all others
fail for reasons of resource starvation. Using it to look at what states
processes are in will give clues about what resources they might be waiting for.
> > $ SHOW MEMORY /POOL /FULL
> >
> > will give a vast number of figures. If "Free space" is low and "Current size"
> > is much bigger than "Initial size" and approaching "Maximum size", you may be
> > running into problems with non-paged pool.
>
> The free space numbers seem fine and always have, but I haven't run
> it while doing something like an install. I'll have to try that.
> The pool space numbers don't seem terribly large, but I'm not quite
> sure what nominal ones are.
The numbers will vary depending on your hardware and configuration. What
matters is that that "Free space" is not approaching zero when "Current size"
is already as big as "Maximum size" which means there is no scope for further
automatic expansion of the pool size. If you have plenty of free space, you
are ok. If you don't have any free space but "Current size" is less than
"Maximum size", you are still ok.
Another approach to this sort of thing is to crash the system when it becomes
unresponsive and analyse the resultant crash dump afterwards. Probably easier
to try the AUTOGEN first though.
Regards,
Peter Coghlan.
Hi!
Here is an update on available S-100 board PCBs! I've sent out many of the
PCBs and they are almost gone.
There are 21 of the S-100 IDE V2 reorder PCBs and 2 of the new S-100 bus
terminator/prototyping board PCBs.
There are 2 of the S-100 LAVA PCBs available.
http://s100computers.com/My%20System%20Pages/IDE%20Board/My%20IDE%20Card.htmhttp://n8vem-sbc.pbworks.com/w/browse/#view=ViewFolder¶m=S-100%20bus%20t
erminator
http://s100computers.com/My%20System%20Pages/Lava-10%20Board/LAVA-10%20Board
.htm
The S-100 PCBs cost the same as before ($20 each).? However due to
unforeseen extreme price increases in shipping by USPS I am forced to change
shipping costs.
Shipping in the US will be $3 for a single PCB and $2 for each additional
PCB.? Shipping internationally will be $10 for a single PCB and $3 for each
additional PCB.? This is for the bare basics USPS first class postage with
no tracking or insurance.? The builder assumes all risk of delivery as per
usual arrangement.
I apologize for the large price increase on shipping but this is out of my
hands.? The USPS is in dire financial trouble and is raising prices on
shipping.? It affects us all and is most unfortunate.? These boards are
provided "at cost" so there is no margin to absorb any shipping price
increases.? I have to pass them along.
If you would like one or more S-100 PCBs please send a PayPal to
LYNCHAJ at YAHOO.COM
Thanks and have a nice day!
Andrew Lynch
WOW - a lot of response in just 1/2 day!
Just a few notes to clear up a few things:
I am NOT "giving away" the collection - I will no doubt give away some
parts of it, but I know local (to me) collectors who will take those bits, so
please only ask for freebies if you are very close to Ottawa, Ontario.
It also doesn't do much good to ask me "how much do you want for xxx"
as I really don't know, as I have never made a point of placing values on
the items in the collection - better to let me know what it is worth to you.
Ultimately any particular item will go to whomever places the highest
offer, or in some cases places where I know the particular bit of equipment
will do the most good or have beneficial effect.
At present I am planning to keep at least one of the Altairs, the Imsai, the
Vector, the Horizon, the H8. one of the "chicklet" Pet 2001s the VLC VAX,
the D6809 (or course) and a probably couple of others I have not decided on ***.
*** I'll willing to entertain offers on these systems, but don't expect them
to be cheap - I'm just as happy to hang on to them.
I'm not keen to ship - I know this lets out many (most) of you, but preference
will definately be given to people who can arrange pickup or take care of
most of the shipping hassles remotely. In particular, I can't easily tell you
what shipping will cost - most of this stuff is heavy, and it is a lot of work to
pack something, measure it, weigh it and get a quote - which will likely be
too high (as you all know, much of this stuff isn't worth the cost to ship).
I'm happy to work with you to figure out ways to get things to you - perhaps
piggybacking transport on someone already planning to come here etc..
(You might be able to coordinate such things through the list as well).
Thanks,
Dave
--
dave13 (at) Dave Dunfield
dunfield System/Firmware development services: www.dunfield.com
(dot) com Classic computers: http://www.classiccmp.org/dunfield
I've long thought that my pdp2011 would run just about anything pdp11.
However, it was recently brought to my attention that RSX-11Mplus will not
boot from an rp06 disk image. I mean, an rp06 image created on simh, based on
the rd54 image in rsx11mpbl87.dsk.bz2, sysgenned to support rp06 drives, and
working without any problem on simh.
The first steps in the boot on the fpga appear to work fine - several reads are
done, and the first message appears: "RSX-11M-PLUS V4.6 BL87 1024.KW
System:"RSXMPL". So far exactly the same as when I run simh on the same image.
However, after a brief pause in which the cpu is busy, a difference appears:
simh will continue with a few reads and finish the boot process; however, my
fpga will start reading sectors from each cylinder of the disk in ascending
order - ie, beginning at cyl 0 and ending at the last one. When at the last
cylinder, the message "SAV -- Cannot find Home Block" appears.
Strangely, if I google that, it comes up with a reference to Ersatz-11 from
1994 which appears to describe exactly the same behaviour - only then on RL,
apparently. See
ftp://minnie.tuhs.org/pub/PDP-11/Sims/Ersatz-1.1beta/Old/e11beta.txt
I've spent most of my free time last week chewing on this problem, looking at
many details in my controller vhdl. However, I've not come any closer to a
solution. At this point, I'm not even completely sure that the problem
actually is in the controller - since E11 had the same thing in it's RL, and
that is a completely different thing.
So, I'm hoping that someone on this list can help me understand what the
trigger(s) for the "SAV -- Cannot find Home Block" could be. Is there maybe
someone who remembers the original issue in E11, and how it was fixed? Or is
there someone with access to the source code who could explain what happens?
