Alpha Core 0.9

[Richard Irving]

Mike Barnes wrote:
> On Tue, 28 Sep 2004 19:49:32 -0500, Richard Irving <rirving at antient.org> wrote:
> 
>>   I am jealous, as the 5300 of which I spoke, (not 5003 as posted)
>>can't make it. I think that is because these kernels are being compiled on
>>newer CPU's than we (at least I) expect.
> 
> 
> What's the CPU type in the 5300? I've booted the current kernel on an
> old AlphaStation 200, but nothing much before that. I know it's OK on
> EV5, EV56 and EV6.

   This is a dual EV56. (21164) The 5300 is the twin brother of the
1200, but had an AlphaBios for booting Windows NT, which BTW is turned off,
and is using SRM, instead.... making it act like a 1200.

     So there goes that theory... it stack dumps so fast, and
so hard, collecting information is going to be a challenge.

  I get a brief moment of what appears to be a register dump, scrolling
by.... and then back to "Number 9".

  It happens about as fast as you read that line.

    Is uses the internal NCR controllers for the SCSI... and fairly
standard video (S3 compliant Trio64)... it could be the multiple CPU's, but it
doesn't seem likely...

   This is a mere fraction of a second into the boot sequence.

  SRM and AlphaBios are updated to the latest 6.0  series of the
software, post "relocation" code.

   I could try making about 3 copies of CD 1, and see if I have a
corruption, or something. Just to eliminate variables.

>>  Mine made it past bootstrap, aboot, and into the kernel for about 4 lines,
>>or so, and wham...
> 
> You might see some more enlightening information if you remove the
> "quiet" parameter from the aboot.conf line for the kernel you're
> booting.

   I 'll give that a shot... I have also debated on trying to
hook something serial on the console, to see if I can get a
more "lasting impression" of the output.

     There also is information I can glean from SRM, I just wanted
to hear it is of interest. Upon returning to SRM, SRM yields hints
about two diagnostics, both of which are essentially register dumps.

> Actually - is that when booting the install CD, or after installation?
> The install CD and the final installation should be using exactly the
> same kernel. Might be something else setting it off.

   It is booting the CD itself.

   The Kernel never even made it up far enough to register the drives,
or for that matter, the bogoMips delay calibration.

   The stack dump was so immediate and brutal, my first impression was an
instruction it didn't recognize... it could be a vector it doesn't like, as well,
I guess.


  _______________________________________________
> axp-list mailing list
> axp-list at redhat.com
> https://www.redhat.com/mailman/listinfo/axp-list