NetBSD on FreeAXP

< class='quote'>[b:]abrsvc wrote:[/b:]
At first glance, I see a difference that may or may not be important. The failing log shows the bootflags = 0 where the one above that works shows bootflags=-a

Could this be a contributing factor in the crash?

Dan

No, a processor machine check would indicate a severe hardware problem on a real machine, different bootflags shouldn't provoke that.
I tested FreeAXP with bootflags=-a just to be sure: same machine check.

To put it simply (from my point of view): An emulator throwing a [i:]processor machine check[/i:] probably has an emulation issue. And the real machine (AS 200) very close to the emulated hardware is fine.

Felix

h20564.www2.hpe.com/hpsc/doc/public/disp...docId=mmr_kc-0105943
h20564.www2.hpe.com/hpsc/doc/public/disp...docId=mmr_kc-0111867

It states that the Machine Check 670 is a D-Cache Parity Error.

Can you isolate what NetBSD is doing that triggers this bug-check?


See also:

gnats.netbsd.org/8216
gnats.netbsd.org/8939 --- Indicates a possible PAL_CODE issue.
gnats.netbsd.org/25788 --- Have you tried different emulated Ethernet adapters?

In device drivers, you can trigger a machine check from bugs in the code.

Doing a reset on a I/O chip that is doing a bus transfer is one operation that will succeed over 99.9% of the time, yet if you manage to do the reset as a block transfer is actually running, that can cause a machine check.

So what is really needed to find out what the code was doing at the time of the crash, and that usually needs someone that is familiar with the code or who can add instrumentation to the code to get better diagnostics.

Just to make things fun, there can be a small delay between the event that caused the machine check and the signaling of the event.

< class='quote'>[b:]malmberg wrote:[/b:]
h20564.www2.hpe.com/hpsc/doc/public/disp...docId=mmr_kc-0105943
h20564.www2.hpe.com/hpsc/doc/public/disp...docId=mmr_kc-0111867

It states that the Machine Check 670 is a D-Cache Parity Error.

Can you isolate what NetBSD is doing that triggers this bug-check?


We end up in ddb after the machine check (no useful info then), but I'll try to break before and single-step or ...

< class='quote'>
See also:

gnats.netbsd.org/8216
gnats.netbsd.org/8939 --- Indicates a possible PAL_CODE issue.
gnats.netbsd.org/25788 --- Have you tried different emulated Ethernet adapters?


The first two reports are over 17 years old and could be fixed by now probably...
Yes, I tried all ethernet adapters available for emulation. DE435 and DE500 (21143) are correctly attached, DE500 (21140) is not due to MII problems:

< class='quote' style='width:400px;white-space:nowrap;overflow:auto'><code style='white-space:nowrap'>tlp0: unable to configure MII
tlp0: no media found!<br><br><br></code>

In all cases the machine check happens.

Please still keep in mind that the real machine works. If we find a problem in NetBSD, I'll gladly fix it though.

Testing will the different hardware adapters enabled/disabled could also be interesting, and booting over network with SCSI disabled...

Felix

I'm not sure if this is an issue or not, but the DEC 300 M400 was a Turbochannel system. I'm not sure the FreeAXP emulates the Turbochannel. Either way, I'm not sure this is your problem. I have noticed that some emulations have a tendency to borrow from multiple alpha implementations. The one I'm playing with says that it emulates the "Tsunami" EV6 CPU, but there is code that is emulating the "Typhoon" EV6 CPU (every similar chips, differing only in how internal registers and cache are utilized).

JonB

FreeAXP emulates an AlphaServer 400 right down to the firmware. It has extension to support EV5 and EV6 code extensions.