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 V2.6.4.598 on a Win10 64bit host.
(1)
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.
(2)
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.
Please have a look at http://dmesgd.nycbug.org/index.cgi?do=view&id=3019, this is a dmesg output from another type, my DEC 3000. I can also provide a complete log up to login, the machine is sitting on my desk.
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.
flxd wrote:
Please have a look at http://dmesgd.nycbug.org/index.cgi?do=view&id=3019, this is a dmesg output from another type, my DEC 3000. I can also provide a complete log up to login, the machine is sitting on my desk.
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
------------------------------------------------------------
Devnam Devstat
-------- -------
CPU OK KN15-BA -V7.0-S887-I21F-sV2.1-DECchip 21064 P3.0
OSC 133 MHz
ASIC OK
MEM OK 96MB
NVR OK
SCC OK ptr(0) = Present keybd(2) = Present
NI OK Ethernet Address: 08-00-2B-XX-XX-XX , TENBT
SCSI OK
ISDN OK
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
11704368+261568 [633744+413157]=0xc696c0
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
mainbus0 (root)
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
kern.module.path=/stand/alpha/7.99.42/modules
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
Starting network.
Hostname: dec3400.home
IPv6 mode: host
Configuring network interfaces: le0.
Adding interface aliases:.
Waiting for DAD to complete for statically configured addresses...
Starting dhcpcd.
Building databases: dev, utmp, utmpx.
Starting syslogd.
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
Starting virecover.
Checking for core dump...
savecore: no core dump
Starting local daemons:.
Updating motd.
Starting inetd.
Starting cron.
Wed Nov 30 19:20:24 CET 2016
NetBSD runs fine on the real machine and starts the menu-driven installer after entering the terminal type, FreeAXP ends in a processor machine check as previously posted.
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
abrsvc wrote:
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 processor machine check probably has an emulation issue. And the real machine (AS 200) very close to the emulated hardware is fine.
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:
http://gnats.netbsd.org/8216
http://gnats.netbsd.org/8939 --- Indicates a possible PAL_CODE issue.
http://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.
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 ...
See also:
http://gnats.netbsd.org/8216
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).
malmberg August 04 2022 No more VAX hobbyist licenses.
Community licenses for Alpha/IA64/X86_64 VMS Software Inc.
Commercial VMS software licenses for VAX available from HPE.
ozboomer July 20 2022 Just re-visiting.. No more hobbyist licenses? Is that from vmssoftware.com, no 'community' licenses?
valdirfranco July 01 2022 No more hobbyist license...sad
mister_wavey February 12 2022 I recall that the disks failed on the public access VMS systems that included Fafner
parwezw January 03 2022 Anyone know what happened to FAFNER.DYNDS.ORG?
I had a hobbyist account here but can longer access the site.
gtackett October 27 2021 Make that DECdfs _2.1A_ for Vax
gtackett October 27 2021 I'm looking for DECdfs V2.4A kit for VAX.
Asking here just in case anyone is still listening.
MarkRLV September 17 2021 At one time, didn't this web site have a job board? I would love to use my legacy skills one last time in my career.
malmberg January 18 2021 New Hobbyist PAKs for VAX/VMS are no longer available according to reports. Only commercial licenses are reported to be for sale from HPE
dfilip January 16 2021 Can someone please point me to hobbyist license pak? I'm looking for VAX/VMS 7.1, DECnet Phase IV, and UCX/TCPIP ... have the 7.1 media, need the license paks ... thanks!