5 May
2013
5 May
'13
10:05 a.m.
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.
$ 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. 
5 May
5 May
12:35 p.m.
On May 5, 2013, at 1:05 PM, Peter Coghlan wrote:
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.
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.
- Dave
2:01 p.m.
On Sun, 5 May 2013, David Riley wrote:
On May 5, 2013, at 1:05 PM, Peter Coghlan wrote:
How long is the SCSI chain? The first thing that came to mind for me was
the possibility of a SCSI bus issue since I've seen similar behavior with
other systems. In fact, since you just mentioned the Jaz drive, it could
very well be the culprit. I had major compatibility issues with Jaz drives
in a non-PC application back when they were current products and I ended
up having to connect them to a PC to update their firmware and change
their internal settings. A quick Google search turned up this link too:
http://www.linux-m68k.org/faq/howjaz.html
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.
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.
6 May
6 May
9:02 a.m.
On May 5, 2013, at 5:01 PM, Tothwolf <tothwolf at concentric.net> wrote:
I'm familiar with the general problems with Jaz drives, but this particular
one has never given me much trouble. Having workable disks around is a
problem, though; they all seem to die over time, even disused (unlike Zip
disks, which have always been fine for me). I got 10 off eBay and they all
failed a long format, which I hope doesn't actually mean the drive in the
Mac I was formatting them has gone off (not impossible). At this point, I
don't think I even have any Jaz disks that pass the long format.
In any case, the SCSI chain isn't hideously long; 4 devices, all connected
with 3-foot cables, so it should be well within spec. Nice, thick cables
as well. Disconnecting the Jaz drive doesn't seem to have solved the
problem; next I'll try the Zip drive. It's also altogether possible that
the update to the latest firmware on the CQD-220 has introduced some
instability in the card itself, since the error logs seem to be indicating
that the controller needs to get reset.
Specifically, I'm getting this error once in a while:
******************************* ENTRY 40. *******************************
ERROR SEQUENCE 44. LOGGED ON: SID 0A000006
DATE/TIME 6-MAY-2013 11:49:18.76 SYS_TYPE 01530302
SYSTEM UPTIME: 0 DAYS 02:38:10
SCS NODE: GONDOR VAX/VMS V7.3
ERL$LOGMSCP KA655 CPU FW REV# 7. CONSOLE FW REV# 5.3
MESSAGE TYPE 0010
IMMEDIATE MODE COMMAND TIMEOUT
_ CONTROLLER RESET
CLASS DRIVER 4B534944
/DISK/
CDDB$Q_CNTRLID 00D60000
010D0000
UNIQUE IDENTIFIER, 000000D60000(X)
MASS STORAGE CONTROLLER
KDA50-Q
CDDB$B_SYSTEMID 80C18E68
8000
It's followed by a few other entries documenting the reset and init sequence.
My thinking is that the controller shouldn't be timing out on MSCP commands
just because of some balky devices on the SCSI bus, though having seen some
of the failure modes of the firmware of the CQD-220, I wouldn't be entirely
surprised.
I wonder if Glen ever ended up updating the firmware on his, and whether
similar problems began to manifest. I might try dropping down to the A8 rev
tonight to see if that improves the situation; now that I have a better CD
drive, I don't really need the updated firmware (though it does have some
nice features).
- Dave
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.
How long is the SCSI chain? The first thing that came to mind for me was the possibility
of a SCSI bus issue since I've seen similar behavior with other systems. In fact,
since you just mentioned the Jaz drive, it could very well be the culprit. I had major
compatibility issues with Jaz drives in a non-PC application back when they were current
products and I ended up having to connect them to a PC to update their firmware and change
their internal settings. A quick Google search turned up this link too:
http://www.linux-m68k.org/faq/howjaz.html
7:51 p.m.
On Mon, 6 May 2013, David Riley wrote:
On May 5, 2013, at 5:01 PM, Tothwolf <tothwolf at
concentric.net> wrote:
How long is the SCSI chain? The first thing that
came to mind for me
was the possibility of a SCSI bus issue since I've seen similar
behavior with other systems. In fact, since you just mentioned the Jaz
drive, it could very well be the culprit. I had major compatibility
issues with Jaz drives in a non-PC application back when they were
current products and I ended up having to connect them to a PC to
update their firmware and change their internal settings. A quick
Google search turned up this link too:
http://www.linux-m68k.org/faq/howjaz.html
I'm familiar with the general problems with Jaz drives, but this
particular one has never given me much trouble. Having workable disks
around is a problem, though; they all seem to die over time, even
disused (unlike Zip disks, which have always been fine for me). I got
10 off eBay and they all failed a long format, which I hope doesn't
actually mean the drive in the Mac I was formatting them has gone off
(not impossible). At this point, I don't think I even have any Jaz
disks that pass the long format.
In any case, the SCSI chain isn't hideously long; 4 devices, all
connected with 3-foot cables, so it should be well within spec. Nice,
thick cables as well. Disconnecting the Jaz drive doesn't seem to have
solved the problem; next I'll try the Zip drive. It's also altogether
possible that the update to the latest firmware on the CQD-220 has
introduced some instability in the card itself, since the error logs
seem to be indicating that the controller needs to get reset.
Specifically, I'm getting this error once in a while: MESSAGE TYPE 0010
IMMEDIATE MODE COMMAND TIMEOUT
_ CONTROLLER RESET
It's followed by a few other entries documenting
the reset and init sequence.
My thinking is that the controller shouldn't be timing out on MSCP commands
just because of some balky devices on the SCSI bus, though having seen some
of the failure modes of the firmware of the CQD-220, I wouldn't be entirely
surprised.
Resets are common when there is data corruption or noise on a SCSI bus.
With single-ended Fast SCSI, the recommended max cable length is 3 meters
(~10ft) so you are already close to the length limit, if all the devices
are well behaved. You might try using active terminators and/or shorter
cables and see if that helps too.
You don't happen to have a wide (16 bit) device attached to the SCSI bus
with an adapter do you?
4247
days inactive
4249
days old
4 comments
3 participants
participants (3)
-
cctech＠beyondthepale.ie -
fraveydank＠gmail.com -
tothwolf＠concentric.net