Bug 17163

Summary: Patch for EV4 FP Emulation
Product: [Retired] Red Hat Linux Reporter: Simon Hill <simon>
Component: kernelAssignee: Richard Henderson <rth>
Status: CLOSED CURRENTRELEASE QA Contact:
Severity: high Docs Contact:
Priority: high    
Version: 6.2   
Target Milestone: ---   
Target Release: ---   
Hardware: alpha   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2002-12-15 01:29:03 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
Bug Depends On:    
Bug Blocks: 17009, 17045    
Attachments:
Description Flags
EV4 FPE Patch none

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