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
wrote:
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
graphic
On Mon, Nov 12, 2018 at 12:22 PM Jon Elson via cctalk
wrote:
>
> 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 ba
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 gues
On Mon, Nov 12, 2018 at 9:33 AM Christian Corti via cctalk
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 syste
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 a
On 11/10/2018 6:17 AM, Peter Coghlan via cctalk wrote:
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
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
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 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 start
On 11/09/2018 05:38 PM, Peter Coghlan 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-
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
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
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
12 matches
Mail list logo