1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56
|
Please report any bugs you find to me. Here is a list of KNOWN bugs. (Also,
anything listed in TODO is not worth reporting.)
Serious bugs:
x) NetBSD/pmax in the emulator sometimes crashes when running X. It is very
uncommon with -CR3000, a bit more common with -CR4000. Reason and
solution are unknown at this point.
x) An unknown math coprocessor bug. (Ultrix' dxclock sometimes looks
weird.)
x) Linux/DECstation (Debian) oopses extremely often unless -U is used
at run-time. I'm not sure yet why it bugs out. With -U, the risk is
lower, but not completely gone. _Maybe_ this is a bug in Linux. Why?
Because the oops message contains things like ANSI escape codes and
characters in registers (including the pc and return address register);
this looks like a buffer overflow in the serial driver. (Another thing
that gives weight to this theory is that the serial driver in Linux is
still being developed.) But this is just a guess.
x) Newer NetBSD/pmax 2.0_BETA snapshots from releng.netbsd.org, and the
official 2.0 release, sometimes crash.
Host\Snapshot: 20040606 20040707
Linux/i386: ok crash
FreeBSD/Alpha: ok ok
OpenBSD/sparc64: ok ok
crash = core dump when doing malloc(), so maybe some memory control
blocks are overwritten by some code.
This only seems to affect Linux. By doing a 'setenv MALLOC_CHECK_ 1'
before running the emulator, it seems that the bug isn't triggered.
(OpenBSD/arc 2.3 on an i386 host also triggers this bug sometimes.)
Less serious bugs / issues:
o) the ssnop instruction doesn't align on a cycle boundary
o) hardware device ticks are done at cycle specific intervals, not
instruction intervals, so sometimes a fraction of a cycle can be
"lost".
o) running Linux/DECstation 2.4.26 with no scsi disks attached causes
a warning message to be printed by Linux.
o) UDP packets that are too large are not handled well by the Lance
device.
o) bintranslated 64-bit stuff checks to see if the top 32 bits are
all zeroes or all ones, and then uses 32-bit tables and such. This
is a bug. It should check the top 33 bits, not 32.
o) NetBSD/arc 2.0 uses the ASC controller in a way which mips64emul
cannot yet handle. (NetBSD 1.6.2 works ok.)
|