1. 02 Nov, 2008 2 commits
  2. 31 Oct, 2008 1 commit
  3. 29 Oct, 2008 4 commits
  4. 23 Oct, 2008 6 commits
    • David S. Miller's avatar
      math-emu: Fix thinko in _FP_DIV · 60b82673
      David S. Miller authored
      In commit 48d6c643 ("math-emu: Add
      support for reporting exact invalid exception") code was added to
      set the new FP_EX_INVALID_{IDI,ZDZ} exception flag bits.
      
      However there is a missing break statement for the
      _FP_CLS_COMBINE(FP_CLS_INF,FP_CLS_INF) switch case, the
      code just falls into _FP_CLS_COMBINE(FP_CLS_ZERO,FP_CLS_ZERO)
      which then proceeds to overwrite all of the settings.
      
      Fix by adding the missing break.
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      60b82673
    • Kumar Gala's avatar
      math-emu: Fix signalling of underflow and inexact while packing result. · 930cc144
      Kumar Gala authored
      I'm trying to move the powerpc math-emu code to use the include/math-emu bits.
      
      In doing so I've been using TestFloat to see how good or bad we are
      doing.  For the most part the current math-emu code that PPC uses has
      a number of issues that the code in include/math-emu seems to solve
      (plus bugs we've had for ever that no one every realized).
      
      Anyways, I've come across a case that we are flagging underflow and
      inexact because we think we have a denormalized result from a double
      precision divide:
      
      000.FFFFFFFFFFFFF / 3FE.FFFFFFFFFFFFE
      	soft: 001.0000000000000 .....  syst: 001.0000000000000 ...ux
      
      What it looks like is the results out of FP_DIV_D are:
      
      D:
      sign:	  0
      mantissa: 01000000 00000000
      exp:	 -1023 (0)
      
      The problem seems like we aren't normalizing the result and bumping the exp.
      
      Now that I'm digging into this a bit I'm thinking my issue has to do with
      the fix DaveM put in place from back in Aug 2007 (commit
      40584961):
      
      [MATH-EMU]: Fix underflow exception reporting.
      
          2) we ended up rounding back up to normal (this is the case where
             we set the exponent to 1 and set the fraction to zero), this
             should set inexact too
      ...
      
          Another example, "0x0.0000000000001p-1022 / 16.0", should signal both
          inexact and underflow.  The cpu implementations and ieee1754
          literature is very clear about this.  This is case #2 above.
      
      Here is the distilled glibc test case from Jakub Jelinek which prompted that
      commit:
      
      --------------------
      #include <float.h>
      #include <fenv.h>
      #include <stdio.h>
      
      volatile double d = DBL_MIN;
      volatile double e = 0x0.0000000000001p-1022;
      volatile double f = 16.0;
      int
      main (void)
      {
        printf ("%x\n", fetestexcept (FE_UNDERFLOW));
        d /= f;
        printf ("%x\n", fetestexcept (FE_UNDERFLOW));
        e /= f;
        printf ("%x\n", fetestexcept (FE_UNDERFLOW));
        return 0;
      }
      --------------------
      
      It looks like the case I have we are exact before rounding, but think it
      looks like the rounding case since it appears as if "overflow is set".
      
      000.FFFFFFFFFFFFF / 3FE.FFFFFFFFFFFFE = 001.0000000000000
      
      I think the following adds the check for my case and still works for the
      issue your commit was trying to resolve.
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      930cc144
    • Martin Habets's avatar
      sparc: Add checkstack support · d41e2d73
      Martin Habets authored
      Add sparc support to checkstack.
      Signed-off-by: default avatarMartin Habets <errandir_news@mph.eclipse.co.uk>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      d41e2d73
    • Frederic Weisbecker's avatar
      sparc: correct section of current_pc() · 8dd94537
      Frederic Weisbecker authored
      Latest mainline gives this section mismatch on sparc:
      
      The function current_pc() references
      the variable __init no_sun4u_here.
      This is often because current_pc lacks a __init
      annotation or the annotation of no_sun4u_here is wrong.
      
      Since current_pc() is used only in early time, it is correct to
      put it in .init section.
      Signed-off-by: default avatarFrederic Weisbecker <fweisbec@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      8dd94537
    • Frederic Weisbecker's avatar
      sparc: correct section of apc_no_idle · a1731e5b
      Frederic Weisbecker authored
      The latest mainline gives this section mismatch on sparc:
      
      The function __devinit apc_probe() references
      a variable __initdata apc_no_idle.
      If apc_no_idle is only used by apc_probe then
      annotate apc_no_idle with a matching annotation.
      
      Since the commit 7e7e2f03,
      apc_probe() is on __devinit so we have to correct apc_no_idle
      which is referenced by this function.
      Signed-off-by: default avatarFrederic Weisbecker <fweisbec@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      a1731e5b
    • Andrea Shepard's avatar
      sparc64: Fix race in arch/sparc64/kernel/trampoline.S · e0037df3
      Andrea Shepard authored
      Make arch/sparc64/kernel/trampoline.S in 2.6.27.1 lock prom_entry_lock
      when calling the PROM.  This prevents a race condition that I observed
      causing a hang on startup on a 12-CPU E4500.
      
      I am not subscribed to this list, so please CC me on replies.
      Signed-off-by: default avatarAndrea Shepard <andrea@persephoneslair.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      e0037df3
  5. 21 Oct, 2008 1 commit
  6. 20 Oct, 2008 26 commits