9 Nov
2018
9 Nov
'18
12:09 a.m.
I hadn't started this DEC Alpha 3000-300 since last summer, and booted
it up so I could load the new PAK's the other day.
The result was that it completes almost the entire OpenVMS startup, but
then crashes with the following:
%SET-I-INTSET, login interactive limit = 64, current interactive value = 0
**** OpenVMS Alpha Operating System V8.4???? - BUGCHECK ****
** Bugcheck code = 000001CC: INVEXCEPTN, Exception while above ASTDEL
** Crash CPU: 00000000??? Primary CPU: 00000000??? Node Name: A300
** Highest CPU number:??? 00000000
** Active CPUs:?????????? 00000000.00000001
** Current Process:?????? DECW$STARTUP
** Current PSB ID:??????? 00000001
** Image Name: A300$DKA0:[SYS0.SYSCOMMON.][SYSEXE]DECW$CONFIG.EXE;1
**** Starting selective memory dump at? 8-NOV-2018 21:57...
The disk is a SCSI2SD board with an 8 GB SD card.? It had been running
just fine, until now.
Does this crash point to a hardware or software problem?
9 Nov
9 Nov
12:59 p.m.
On 11/08/2018 11:09 PM, Douglas Taylor via cctalk wrote:
I hadn't started this DEC Alpha 3000-300 since
last
summer, and booted it up so I could load the new PAK's the
other day.
The result was that it completes almost the entire OpenVMS
startup, but then crashes with the following:
%SET-I-INTSET, login interactive limit = 64, current
interactive value = 0
**** OpenVMS Alpha Operating System V8.4 - BUGCHECK ****
** Bugcheck code = 000001CC: INVEXCEPTN, Exception while
above ASTDEL
** Crash CPU: 00000000 Primary CPU: 00000000 Node
Name: A300
** Highest CPU number: 00000000
** Active CPUs: 00000000.00000001
** Current Process: DECW$STARTUP
** Current PSB ID: 00000001
** Image Name:
A300$DKA0:[SYS0.SYSCOMMON.][SYSEXE]DECW$CONFIG.EXE;1
**** Starting selective memory dump at 8-NOV-2018 21:57...
The disk is a SCSI2SD board with an 8 GB SD card. It had
been running just fine, until now.
Does this crash point to a hardware or software problem?
ASTDEL indicates that something in the OS caused a machine
check interrupt. Does DECW$CONFIG mean it is the DecWindows
config process that bombed? Can you get the OS to boot in
non-windows mode, and try to log in from a serial terminal?
If DecWindows is blowing up, it could be that the graphics
adapter has a problem, is set to the wrong address, or is a
different type than the software is expecting. You might
unplug and reseat all mezzanine boards and cycle all DIP
switches to make sure it is not just a bad connection.
Jon
11:24 p.m.
On 11/9/2018 12:59 PM, Jon Elson via cctalk wrote:
On 11/08/2018 11:09 PM, Douglas Taylor via cctalk
wrote:
I was able to boot the system using a serial console only by setting the
jumper listed as 'W2' so that pins 2-3 were connected rather than 1-2.?
It did complete the system startup and I was able to log in to the
system account.
This 3000-300 has no mezzanine boards, the system consists of a
motherboard with a cpu board the rides on a mezzanine type of
connector.? The video comes off the motherboard.? I did try wiggling the
memory dimm cards.? I'll look and reseat any jumpers that are there.
The last time I tried to bring up the system using only the serial
console I got the bugcheck crash, which had only occurred when I tried
to boot into graphics mode.
It maybe that the DECW$Config.exe image is bad, since that is where the
bugcheck always occurs.? Although this is confusing because it did
successfully boot in console mode previously.
So, the choices now seem to be; (1) replace the hardware (I think I have
another 3000-300) or (2) reinstall the software.? Don't like either one.
I hadn't started this DEC Alpha 3000-300
since last summer, and
booted it up so I could load the new PAK's the other day.
The result was that it completes almost the entire OpenVMS startup,
but then crashes with the following:
%SET-I-INTSET, login interactive limit = 64, current interactive
value = 0
**** OpenVMS Alpha Operating System V8.4???? - BUGCHECK ****
** Bugcheck code = 000001CC: INVEXCEPTN, Exception while above ASTDEL
** Crash CPU: 00000000??? Primary CPU: 00000000??? Node Name: A300
** Highest CPU number:??? 00000000
** Active CPUs:?????????? 00000000.00000001
** Current Process:?????? DECW$STARTUP
** Current PSB ID:??????? 00000001
** Image Name: A300$DKA0:[SYS0.SYSCOMMON.][SYSEXE]DECW$CONFIG.EXE;1
**** Starting selective memory dump at? 8-NOV-2018 21:57...
The disk is a SCSI2SD board with an 8 GB SD card.? It had been
running just fine, until now.
Does this crash point to a hardware or software problem?
ASTDEL indicates that something in the OS caused a machine check
interrupt.? Does DECW$CONFIG mean it is the DecWindows config process
that bombed?? Can you get the OS to boot in non-windows mode, and try
to log in from a serial terminal?? If DecWindows is blowing up, it
could be that the graphics adapter has a problem, is set to the wrong
address, or is a different type than the software is expecting.? You
might unplug and reseat all mezzanine boards and cycle all DIP
switches to make sure it is not just a bad connection.
Jon 
10 Nov
10 Nov
6:17 a.m.
It maybe that the DECW$Config.exe image is bad, since that is where the
bugcheck always occurs.? Although this is confusing because it did
successfully boot in console mode previously.
While it's not impossible, I doubt the problem is in the DECW$Config.exe
image. I think it is more likely to be in a device driver image which
is exercised because of an I/O done by DECW$Config.exe. It may be that
the bugcheck always happens when DECW$Config.exe is running because
DECW$Config.exe is the first thing to touch the I/O device in question.
Regards,
Peter Coghlan.
12 Nov
12 Nov
12:36 a.m.
On 11/10/2018 6:17 AM, Peter Coghlan via cctalk wrote:
This is most likely correct.? I re-installed the OS on a different SD
card/SCSI2SD device and got a successful graphics boot up.? Do SD cards
drop bits or go bad?
I was happy to get it running again, I was afraid it was a hardware
issue.? The one spare 3000-300 I have didn't start up at all.
Doug
It maybe that the DECW$Config.exe image is bad, since that is where
the bugcheck always occurs.? Although this is confusing because it
did successfully boot in console mode previously.
While it's not impossible, I doubt the problem is in the DECW$Config.exe
image.? I think it is more likely to be in a device driver image which
is exercised because of an I/O done by DECW$Config.exe.? It may be that
the bugcheck always happens when DECW$Config.exe is running because
DECW$Config.exe is the first thing to touch the I/O device in question.
Regards,
Peter Coghlan. 
3:33 a.m.
On Mon, 12 Nov 2018, Douglas Taylor wrote:
This is most likely correct.? I re-installed the OS on
a different SD
card/SCSI2SD device and got a successful graphics boot up.? Do SD cards drop
bits or go bad?
Yes, very easily. That is why I absolutely dislike solutions based on SD
cards (or on any kind of flash memory cards).
Christian
7:28 a.m.
On Mon, Nov 12, 2018 at 9:33 AM Christian Corti via cctalk
<cctalk at classiccmp.org> wrote:
Yes, very easily. That is why I absolutely dislike solutions based on SD
cards (or on any kind of flash memory cards).
At least it is quite easy to make (image-based) backups of SD-cards,
which might be helpful if the system you are using it in doesn't have
a working backup solution.
As always: make backups, and test that they work. Every storage medium
breaks down sooner or later.
HTH
--
Regards,
Torfinn Ingolfsen
12:22 p.m.
On 11/11/2018 11:36 PM, Douglas Taylor via cctalk wrote:
This is most likely correct. I re-installed the OS on a
different SD card/SCSI2SD device and got a successful
graphics boot up. Do SD cards drop bits or go bad?
UGH! Yes, they can. It SHOULD cause a device parity error,
but I guess some of their coverage is less than 100%
perfect. But, there are LOTS of reports of bad SD cards,
cards with dramatically less capacity than stated on the
outside, early failure after just a few hundred writes, lots
of reports of total corruption when power is dropped without
warning, etc. Just read the horror stories online.
Jon
1:30 p.m.
On Mon, Nov 12, 2018 at 12:22 PM Jon Elson via cctalk
<cctalk at classiccmp.org> wrote:
On 11/11/2018 11:36 PM, Douglas Taylor via cctalk wrote:
You can buy "industrially rated" flash memory cards such as the
"SanDisk Industrial" labelled ones, which seems to help based on my
experience with SD cards in industrial controls systems at work.
Absolutely avoid cheap SD cards though, they aren't usually good for
more than a few re-writes in a digital camera type situation (linearly
write the card, and then erase the whole thing, repeat). Things like
swap files on SD/CF cards may wear them out in a couple of hours of
use.
Pat
This is most likely correct. I re-installed the OS on a
different SD card/SCSI2SD device and got a successful
graphics boot up. Do SD cards drop bits or go bad?
UGH! Yes, they can. It SHOULD cause a device parity error,
but I guess some of their coverage is less than 100%
13 Nov
13 Nov
12:15 p.m.
On 11/12/2018 1:30 PM, Patrick Finnegan via cctalk wrote:
On Mon, Nov 12, 2018 at 12:22 PM Jon Elson via cctalk
<cctalk at classiccmp.org> wrote:
And I was under the impression that my hardware problems were coming
On 11/11/2018 11:36 PM, Douglas Taylor via cctalk
wrote:
You can buy
"industrially rated" flash memory cards such as the
"SanDisk Industrial" labelled ones, which seems to help based on my
experience with SD cards in industrial controls systems at work.
Absolutely avoid cheap SD cards though, they aren't usually good for
more than a few re-writes in a digital camera type situation (linearly
write the card, and then erase the whole thing, repeat). Things like
swap files on SD/CF cards may wear them out in a couple of hours of
use.
Pat This is most likely correct. I re-installed the
OS on a
different SD card/SCSI2SD device and got a successful
graphics boot up. Do SD cards drop bits or go bad?
UGH! Yes, they can. It SHOULD cause a device parity error,
but I guess some of their coverage is less than 100% from the 20 year old Vax!? Thanks for informing me.
9 Nov
9 Nov
6:38 p.m.
I hadn't started this DEC Alpha 3000-300 since
last summer, and booted
it up so I could load the new PAK's the other day.
The result was that it completes almost the entire OpenVMS startup, but
then crashes with the following:
%SET-I-INTSET, login interactive limit = 64, current interactive value = 0
**** OpenVMS Alpha Operating System V8.4???? - BUGCHECK ****
** Bugcheck code = 000001CC: INVEXCEPTN, Exception while above ASTDEL
** Crash CPU: 00000000??? Primary CPU: 00000000??? Node Name: A300
** Highest CPU number:??? 00000000
** Active CPUs:?????????? 00000000.00000001
** Current Process:?????? DECW$STARTUP
** Current PSB ID:??????? 00000001
** Image Name: A300$DKA0:[SYS0.SYSCOMMON.][SYSEXE]DECW$CONFIG.EXE;1
**** Starting selective memory dump at? 8-NOV-2018 21:57...
The disk is a SCSI2SD board with an 8 GB SD card.? It had been running
just fine, until now.
Does this crash point to a hardware or software problem?
I think "Exception while above ASTDEL" refers to an exception encountered
while processing an interrupt in kernel mode, probably in device driver code.
I think this leans more in the direction of a sofware problem while something
like "Machine check in kernel mode" would lean more in the direction of a
hardware problem.
Having said that, I think a software problem is very unlikely unless you
were running a bleeding edge version of VMS on bleeding edge hardware or
performing some highly unusual operation, not just booting a well proven
version of VMS on a mature system which worked perfectly well before this.
If the copy of VMS on your emulated disk got damaged, I think it would be
unusual to get almost all the way through the boot procedure and then fail
right at the end, although I suppose very slight damage only to a DECWindows
specific device driver might somehow manage to cause this.
Bizarrely, I have had a faulty mouse suddenly cause all sorts of strange
issues on a DEC 3000-300. It might be worth trying it without the mouse
plugged in.
Regards,
Peter Coghlan.
10:46 p.m.
On 11/09/2018 05:38 PM, Peter Coghlan via cctalk wrote:
Well, most of my deeper experience in the driver level is
VAX and not Alpha, I think a memory exception is still a
machine check, and so trying to access a memory or device
location that does not exist/respond is still a machine
check at the very lowest level.
Jon
I hadn't
started this DEC Alpha 3000-300 since last
summer, and booted it up so I could load the new PAK's
the other day.
The result was that it completes almost the entire
OpenVMS startup, but then crashes with the following:
%SET-I-INTSET, login interactive limit = 64, current
interactive value = 0
**** OpenVMS Alpha Operating System V8.4 - BUGCHECK ****
** Bugcheck code = 000001CC: INVEXCEPTN, Exception while
above ASTDEL
** Crash CPU: 00000000 Primary CPU: 00000000 Node
Name: A300
** Highest CPU number: 00000000
** Active CPUs: 00000000.00000001
** Current Process: DECW$STARTUP
** Current PSB ID: 00000001
** Image Name:
A300$DKA0:[SYS0.SYSCOMMON.][SYSEXE]DECW$CONFIG.EXE;1
**** Starting selective memory dump at 8-NOV-2018 21:57...
The disk is a SCSI2SD board with an 8 GB SD card. It had
been running just fine, until now.
Does this crash point to a hardware or software problem?
I think "Exception while above ASTDEL" refers to an
exception encountered
while processing an interrupt in kernel mode, probably in
device driver code.
I think this leans more in the direction of a sofware
problem while something
like "Machine check in kernel mode" would lean more in the
direction of a
hardware problem.
2040
days inactive
2044
days old
11 comments
6 participants
participants (6)
-
cc＠informatik.uni-stuttgart.de -
cctalk＠beyondthepale.ie -
dj.taylor4＠comcast.net -
elson＠pico-systems.com -
pat＠vax11.net -
tingox＠gmail.com