upstream/0.3.5/BUGS

$Id: BUGS,v 1.36 2005/08/15 07:01:55 debug Exp $

  x)  An unknown math coprocessor bug. (Ultrix' dxclock sometimes looks
      weird.)

  x)  Enabling cache emulation (./configure --enable-caches) triggers bugs.

  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.

  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)  Colors in X11 framebuffers on MacOS X hosts are wrong. (I'm not sure
      how to solve this; the code works on both little-endian (Alpha) and
      big-endian (UltraSPARC) X-servers...)

  o)  Binary-translated 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. (Alpha only, already
      fixed for i386?)

  o)  NetBSD/arc 2.0 uses the ASC controller in a way which GXemul cannot yet
      handle. (NetBSD 1.6.2 works ok.)

1	dpavlin	12	$Id: BUGS,v 1.36 2005/08/15 07:01:55 debug Exp $
2	dpavlin	2
3			x) An unknown math coprocessor bug. (Ultrix' dxclock sometimes looks
4			weird.)
5
6			x) Enabling cache emulation (./configure --enable-caches) triggers bugs.
7
8			x) Linux/DECstation (Debian) oopses extremely often unless -U is used
9			at run-time. I'm not sure yet why it bugs out. With -U, the risk is
10			lower, but not completely gone. _Maybe_ this is a bug in Linux. Why?
11			Because the oops message contains things like ANSI escape codes and
12			characters in registers (including the pc and return address register);
13			this looks like a buffer overflow in the serial driver. (Another thing
14			that gives weight to this theory is that the serial driver in Linux is
15			still being developed.) But this is just a guess.
16
17	dpavlin	12	o) Hardware device ticks are done at cycle specific intervals, not
18	dpavlin	2	instruction intervals, so sometimes a fraction of a cycle can be
19			"lost".
20
21	dpavlin	12	o) Running Linux/DECstation 2.4.26 with no scsi disks attached causes
22	dpavlin	2	a warning message to be printed by Linux.
23
24			o) UDP packets that are too large are not handled well by the Lance device.
25
26			o) Colors in X11 framebuffers on MacOS X hosts are wrong. (I'm not sure
27			how to solve this; the code works on both little-endian (Alpha) and
28			big-endian (UltraSPARC) X-servers...)
29
30	dpavlin	12	o) Binary-translated 64-bit stuff checks to see if the top 32 bits are
31	dpavlin	2	all zeroes or all ones, and then uses 32-bit tables and such. This
32			is a bug. It should check the top 33 bits, not 32. (Alpha only, already
33			fixed for i386?)
34
35			o) NetBSD/arc 2.0 uses the ASC controller in a way which GXemul cannot yet
36			handle. (NetBSD 1.6.2 works ok.)
37