File: BUGS

package info (click to toggle)
mips64emul 0.2.4-1
  • links: PTS
  • area: main
  • in suites: sarge
  • size: 3,260 kB
  • ctags: 11,173
  • sloc: ansic: 43,056; sh: 535; asm: 326; makefile: 58
file content (56 lines) | stat: -rw-r--r-- 2,433 bytes parent folder | download
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.)