Bug 17163 - Patch for EV4 FP Emulation
Summary: Patch for EV4 FP Emulation
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: kernel
Version: 6.2
Hardware: alpha
OS: Linux
high
high
Target Milestone: ---
Assignee: Richard Henderson
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks: 17009 17045
TreeView+ depends on / blocked
 
Reported: 2000-09-01 03:48 UTC by Simon Hill
Modified: 2008-05-01 15:37 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2002-12-15 01:29:03 UTC
Embargoed:


Attachments (Terms of Use)
EV4 FPE Patch (523 bytes, patch)
2000-09-01 03:51 UTC, Simon Hill
no flags Details | Diff

Description Simon Hill 2000-09-01 03:48:19 UTC
Kernel does not handle FP trap properly on EV4 architecture. PC is not
incremented at the time of the exception, causing kernel to look at the
wrong instruction over and over again!

--- linux/arch/alpha/kernel/traps.c.old Wed Jun  7 16:26:42 2000
+++ linux/arch/alpha/kernel/traps.c     Thu Aug 31 22:37:32 2000
@@ -417,8 +417,12 @@
                        /* EV4 does not implement anything except normal
                           rounding.  Everything else will come here as
                           an illegal instruction.  Emulate them.  */
-                       if (alpha_fp_emul(regs.pc - 4))
-                               return;
+                       if (alpha_fp_emul(regs.pc))
+                         {
+                           /* Increment the PC on EV4 */
+                           regs.pc += 4;
+                           return;
+                         }
                }
                send_sig(SIGILL, current, 1);
                break;

Comment 1 Simon Hill 2000-09-01 03:51:37 UTC
Created attachment 3159 [details]
EV4 FPE Patch

Comment 2 Simon Hill 2000-10-26 15:04:38 UTC
EV4 and EV5+ architectures handle floating point traps differently:

On EV5 PC is incremented before the trap is executed. On EV4, PC is not
incremented before the trap is executed. So on EV5 PC is pointing to the
instruction AFTER the one needing emulation. On EV4, PC is pointing TO the
instruction needing emulation. The bug here is that the EV4 code is assuming the
conditions of the EV5 architecture, and so is attempting to emulate the
instruction PREVIOUS to the one needing emulation. Also, the code does not
increment the PC, and so returns to the same FP instruction again, rather than
the next instruction to be executed, again causing an exception, emulating the
wrong instruction, ad infinitum.


Comment 3 Simon Hill 2001-02-20 16:07:03 UTC
I see there is some activity on this bug. I have just recently seen indications
that this bug only occurs when the UDB is booted from the SRM console, but *not*
when it is booted from the ARC console. Which I find bizarre and inexplicable. I
should be able to do some testing tonight to verify whether this is really the
case...


Comment 4 Richard Henderson 2001-02-20 18:27:16 UTC
What SRM version?

This is not a generic EV4 problem -- it does not happen on Avanti or Cabriolet
for instance.
My only guess is a PALcode bug, which would explain why MILO works and SRM
doesn't.
As such, the patch would break existing working systems.  Perhaps we can come up
with a
patch to detect and work around the breakage though.

Comment 5 Need Real Name 2001-02-21 03:38:50 UTC
The problem is showing up on the Multia (VX40) with 166Mhz CPU, 80MB Memory, 
330MB SCSI Drive.

The SRM version: BL5 V3.8-3, built Aug 10 1995 at 03:22:55

Comment 6 Alan Cox 2002-12-15 01:29:03 UTC
Resolved in later base kernels dependant on SRM and other Alpha magic but resolved



Note You need to log in before you can comment on or make changes to this bug.