as a NetBSD developer (with a collection of different VAX, Alpha, ...) I would be very interested in FreeAXP supporting NetBSD as guest operating system (at least inofficially), to gain broader platform support etc.
I ran into two problems when trying to boot NetBSD on FreeAXP V220.127.116.118 on a Win10 64bit host.
Our timer initialization routine seems problematic with the way FreeAXP emulates the hardware. It certainly works running on the "real thing".
With the default setting of FreeAXP's timing_window = 1000 (Expert properties), the timecounter frequency is determined to be zero, which will result in a kernel panic. I think it can be worked around by playing with the timing_window parameter, where 1M (1000000) seems to allow the emulated machine to boot further.
What is still noticeable is that detecting the "mc146818 compatible time-of-day clock" as below takes many seconds, while on a real machine judging from our code this should be done in a few milliseconds.
Unfortunately, the boot process will end in a processor machine check eventually, when reaching init. I understand this must be caused by the "emulated hardware", but probably triggered by the guest somehow. Is this another effect of (1) above, or completely different?
Bruce Claremont wrote:
A boot-up log from a real Alpha would be helpful to compare real hardware behavior to the emulator.
From which machine type, and what exactly do you want to see in such a boot-up log? Up to login?
The dmesg output I posted already shows all the hardware that I configured and that was also successfully detected, after that you will only see all services etc. starting.
I also have two AlphaStations 200 4/166, which should be very similar to the machine you emulate (same "CPU", chipset, subsystems I think).
I have never seen problems with these machines running NetBSD so far, they have been supported for many years.
The AlphaStations 200 are in storage, I could grab them tomorrow and give them a test run. I do not expect bad surprises however.
DEC 3000 - M400
Digital Equipment Corporation
System conducting power up tests
CPU OK KN15-BA -V7.0-S887-I21F-sV2.1-DECchip 21064 P3.0
OSC 133 MHz
MEM OK 96MB
SCC OK ptr(0) = Present keybd(2) = Present
NI OK Ethernet Address: 08-00-2B-XX-XX-XX , TENBT
TC0 OK - PMAGB-BA
System power up OK.
Enter B to boot software from DKA200,ESA0
VMS PAL rev: 0x100010538
OSF PAL rev: 0x2012d
Switch to OSF PAL code succeeded.
Boot flags: -a
Entering netbsd at 0xfffffc0000a01220...
Copyright (c) 1996, 1997, 1998, 1999, 2000, 2001, 2002, 2003, 2004, 2005,
2006, 2007, 2008, 2009, 2010, 2011, 2012, 2013, 2014, 2015, 2016
The NetBSD Foundation, Inc. All rights reserved.
Copyright (c) 1982, 1986, 1989, 1991, 1993
The Regents of the University of California. All rights reserved.
NetBSD 7.99.42 (GENERIC-$Revision: 1.371 $.201611262120Z)
DEC 3000 - M400, 133MHz, s/n
8192 byte page size, 1 processor.
total memory = 98304 KB
(2048 KB reserved for PROM, 96256 KB used by NetBSD)
avail memory = 82200 KB
cpu0 at mainbus0: ID 0 (primary), 21064-1
tcasic0 at mainbus0
tc0 at tcasic0: 25 MHz clock
ioasic0 at tc0 slot 7 offset 0x0: fast mode
le0 at ioasic0 offset 0xc0000: address 08:00:2b:xx:xx:xx
le0: 32 receive buffers, 8 transmit buffers
zsc0 at ioasic0 offset 0x100000
vsms0 at zsc0 channel 0
wsmouse0 at vsms0 mux 0
zstty0 at zsc0 channel 1
zsc1 at ioasic0 offset 0x180000
lkkbd0 at zsc1 channel 0
lkkbd0: no keyboard
wskbd0 at lkkbd0 mux 1
zstty2 at zsc1 channel 1 (console i/o)
mcclock0 at ioasic0 offset 0x200000: mc146818 compatible time-of-day clock
bba0 at ioasic0 offset 0x240000
audio0 at bba0: full duplex, playback, capture, mmap
tcds0 at tc0 slot 6 offset 0x0: TurboChannel Dual SCSI (baseboard)
tcds0: fast mode set for chip 0
asc0 at tcds0 chip 0: NCR53C94, 25MHz, SCSI ID 7
scsibus0 at asc0: 8 targets, 8 luns per target
tcds0: fast mode set for chip 1
asc1 at tcds0 chip 1: NCR53C94, 25MHz, SCSI ID 7
scsibus1 at asc1: 8 targets, 8 luns per target
sfb0 at tc0 slot 3 offset 0x0: 1280x1024, 8bpp
wsdisplay1 at sfb0 kbdmux 1
scsibus0: waiting 2 seconds for devices to settle...
scsibus1: waiting 2 seconds for devices to settle...
sd0 at scsibus0 target 2 lun 0: <DEC, RZ26 (C) DEC, 392A> disk fixed
sd0: 1001 MB, 2570 cyl, 14 head, 57 sec, 512 bytes/sect x 2050860 sectors
sd0: sync (200.00ns offset 15), 8-bit (5.000MB/s) transfers, tagged queueing
cd0 at scsibus0 target 4 lun 0: <DEC, RRD42 (C) DEC, 4.5d> cdrom removable
cd0: async, 8-bit transfers
root on sd0a dumps on sd0b
root file system type: ffs
Wed Nov 30 19:19:06 CET 2016
Starting root file system check:
/dev/rsd0a: file system is clean; not checking
swapctl: setting dump device to /dev/sd0b
swapctl: adding /dev/sd0b as swap device at priority 0
Starting file system checks:
Loaded entropy from /var/db/entropy-file.
Setting tty flags.
Setting sysctl variables:
ddb.onpanic: 1 -> 0
IPv6 mode: host
Configuring network interfaces: le0.
Adding interface aliases:.
Waiting for DAD to complete for statically configured addresses...
Building databases: dev, utmp, utmpx.
Setting date via ntp.
Mounting all file systems...
Clearing temporary files.
Checking quotas: done.
Setting securelevel: kern.securelevel: 0 -> 1
swapctl: setting dump device to /dev/sd0b
Checking for core dump...
savecore: no core dump
Starting local daemons:.
Wed Nov 30 19:20:24 CET 2016
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?
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 processor machine check probably has an emulation issue. And the real machine (AS 200) very close to the emulated hardware is fine.
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.
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 ...
http://gnats.netbsd.org/8939 --- Indicates a possible PAL_CODE issue.
http://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:
tlp0: unable to configure MII
tlp0: no media found!
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...
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).