/[gxemul]/trunk/BUGS
This is repository of my old source code which isn't updated any more. Go to git.rot13.org for current projects!
ViewVC logotype

Diff of /trunk/BUGS

Parent Directory Parent Directory | Revision Log Revision Log | View Patch Patch

revision 12 by dpavlin, Mon Oct 8 16:18:38 2007 UTC revision 22 by dpavlin, Mon Oct 8 16:19:37 2007 UTC
# Line 1  Line 1 
1  $Id: BUGS,v 1.36 2005/08/15 07:01:55 debug Exp $  $Id: BUGS,v 1.41 2006/02/18 13:15:20 debug Exp $
2    
3    x)  An unknown math coprocessor bug. (Ultrix' dxclock sometimes looks  If you experience a CRASH, then please run gdb on the core dump, do a back
4        weird.)  trace, and send it to me.
5    
6    x)  Enabling cache emulation (./configure --enable-caches) triggers bugs.  Some of the known bugs are:
7    
8    x)  Linux/DECstation (Debian) oopses extremely often unless -U is used    x)  Floating point coprocessor stuff is buggy. Writing a new (portable)
9        at run-time. I'm not sure yet why it bugs out. With -U, the risk is        framework for fp emulation is in the TODO.
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    x)  Linux/DECstation (Debian) oopses extremely often unless -U is used at
12        characters in registers (including the pc and return address register);        run-time. I'm not sure yet why it bugs out. With -U, the risk is lower,
13        this looks like a buffer overflow in the serial driver. (Another thing        but not completely gone. _Maybe_ this is a bug in Linux. Why? Because the
14        that gives weight to this theory is that the serial driver in Linux is        oops message contains things like ANSI escape codes and characters in
15        still being developed.)  But this is just a guess.        registers (including the pc and return address register); this looks like
16          a buffer overflow in the serial driver. (Another thing that gives weight
17          to this theory is that the serial driver in Linux is still being
18          developed.)  But this is just a guess.
19    
20    o)  Hardware device ticks are done at cycle specific intervals, not    x)  Binary-translated 64-bit stuff checks to see if the top 32 bits are
       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  
21        all zeroes or all ones, and then uses 32-bit tables and such. This        all zeroes or all ones, and then uses 32-bit tables and such. This
22        is a bug. It should check the top 33 bits, not 32. (Alpha only, already        is a bug. It should check the top 33 bits, not 32. (Alpha only, already
23        fixed for i386?)        fixed for i386?)
24    
25    o)  NetBSD/arc 2.0 uses the ASC controller in a way which GXemul cannot yet    x)  NetBSD/arc 2.0 uses the ASC controller in a way which GXemul cannot yet
26        handle. (NetBSD 1.6.2 works ok.)        handle. (NetBSD 1.6.2 works ok.) (Possibly a problem in NetBSD itself,
27          http://mail-index.netbsd.org/source-changes/2005/11/06/0024.html suggests
28          that.)
29    
Legend:
Removed from v.12  
changed lines
  Added in v.22
  ViewVC Help
Powered by ViewVC 1.1.26