/[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 21 by dpavlin, Mon Oct 8 16:19:23 2007 UTC revision 22 by dpavlin, Mon Oct 8 16:19:37 2007 UTC
# Line 1  Line 1 
1  $Id: BUGS,v 1.37 2005/11/13 12:34:02 debug Exp $  $Id: BUGS,v 1.41 2006/02/18 13:15:20 debug Exp $
2    
3  Hm. This file is pretty old. Some of these are still valid, though.  If you experience a CRASH, then please run gdb on the core dump, do a back
4    trace, and send it to me.
5    
6  ===================================================================  Some of the known bugs are:
7    
8    x)  An unknown math coprocessor bug. (Ultrix' dxclock sometimes looks    x)  Floating point coprocessor stuff is buggy. Writing a new (portable)
9        weird.)        framework for fp emulation is in the TODO.
10    
11      x)  Linux/DECstation (Debian) oopses extremely often unless -U is used at
12          run-time. I'm not sure yet why it bugs out. With -U, the risk is lower,
13          but not completely gone. _Maybe_ this is a bug in Linux. Why? Because the
14          oops message contains things like ANSI escape codes and characters in
15          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    x)  Enabling cache emulation (./configure --enable-caches) triggers bugs.    x)  Binary-translated 64-bit stuff checks to see if the top 32 bits are
   
   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  
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.21  
changed lines
  Added in v.22

  ViewVC Help
Powered by ViewVC 1.1.26