Skip to content

L
linux
Switch branch/tag
  1. 07 Oct, 2007 2 commits
  3. 06 Oct, 2007 17 commits
  5. 24 Sep, 2007 5 commits
  7. 30 Aug, 2007 3 commits
    • David S. Miller's avatar
      [MATH-EMU]: Fix underflow exception reporting. · 64840966
      David S. Miller authored 
      The underflow exception cases were wrong.

This is one weird area of ieee1754 handling in that the underflow
behavior changes based upon whether underflow is enabled in the trap
enable mask of the FPU control register.  As a specific case the Sparc
V9 manual gives us the following description:

--------------------
If UFM = 0:     Underflow occurs if a nonzero result is tiny and a
                loss of accuracy occurs.  Tininess may be detected
                before or after rounding.  Loss of accuracy may be
                either a denormalization loss or an inexact result.

If UFM = 1:     Underflow occurs if a nonzero result is tiny.
                Tininess may be detected before or after rounding.
--------------------

What this amounts to in the packing case is if we go subnormal,
we set underflow if any of the following are true:

1) rounding sets inexact
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
3) underflow is set in FPU control register trap-enable mask

The initially discovered example was "DBL_MIN / 16.0" which
incorrectly generated an underflow.  It should not, unless underflow
is set in the trap-enable mask of the FPU csr.

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.

However, if underflow is set in the trap enable mask, only underflow
should be set and reported as a trap.  That is handled properly by the
prioritization logic in

arch/sparc{,64}/math-emu/math.c:record_exception().

Based upon a report and test case from Jakub Jelinek.
Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
Signed-off-by: default avatarAdrian Bunk <bunk@kernel.org>
      64840966
    • Mark Fortescue's avatar
      [SPARC32]: Fix rounding errors in ndelay/udelay implementation. · eb845a0b
      Mark Fortescue authored 
      __ndelay and __udelay have not been delayung >= specified time.
The problem with __ndelay has been tacked down to the rounding of the
multiplier constant. By changing this, delays > app 18us are correctly
calculated.
The problem with __udelay has also been tracked down to rounding issues.
Changing the multiplier constant (to match that used in sparc64) corrects
for large delays and adding in a rounding constant corrects for trunctaion
errors in the claculations.
Many short delays will return without looping. This is not an error as there
is the fixed delay of doing all the maths to calculate the loop count.
Signed-off-by: default avatarMark Fortescue <mark@mtfhpc.demon.co.uk>
Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
Signed-off-by: default avatarAdrian Bunk <bunk@kernel.org>
      eb845a0b
    • Alexander Shmelev's avatar
      [SPARC32]: Fix bug in sparc optimized memset. · 7380487e
      Alexander Shmelev authored 
      Sparc optimized memset (arch/sparc/lib/memset.S) does not fill last
byte of the memory area, if area size is less than 8 bytes and start
address is not word (4-bytes) aligned.

Here is code chunk where bug located:
/* %o0 - memory address, %o1 - size, %g3 - value */
8:
     add    %o0, 1, %o0
    subcc    %o1, 1, %o1
    bne,a    8b
     stb %g3, [%o0 - 1]

This code should write byte every loop iteration, but last time delay
instruction stb is not executed because branch instruction sets
"annul" bit.

Patch replaces bne,a by bne instruction.

Error can be reproduced by simple kernel module:

--------------------
#include <linux/module.h>
#include <linux/config.h>
#include <linux/kernel.h>
#include <linux/errno.h>
#include <string.h>

static void do_memset(void **p, int size)
{
        memset(p, 0x00, size);
}

static int __init memset_test_init(void)
{
    char fooc[8];
    int *fooi;
    memset(fooc, 0xba, sizeof(fooc));

    do_memset((void**)(fooc + 3), 1);

    fooi = (int*) fooc;
    printk("%08X %08X\n", fooi[0], fooi[1]);

    return -1;
}

static void __exit memset_test_cleanup(void)
{
    return;
}

module_init(memset_test_init);
module_exit(memset_test_cleanup);

MODULE_LICENSE("GPL");
EXPORT_NO_SYMBOLS;
--------------------
Signed-off-by: default avatarAlexander Shmelev <ashmelev@task.sun.mcst.ru>
Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
Signed-off-by: default avatarAdrian Bunk <bunk@kernel.org>
      7380487e
  9. 23 Aug, 2007 1 commit
    • Neil Brown's avatar
      md: avoid possible BUG_ON in md bitmap handling · 646edb4b
      Neil Brown authored 
      md/bitmap tracks how many active write requests are pending on blocks
associated with each bit in the bitmap, so that it knows when it can clear
the bit (when count hits zero).

The counter has 14 bits of space, so if there are ever more than 16383, we
cannot cope.

Currently the code just calles BUG_ON as "all" drivers have request queue
limits much smaller than this.

However is seems that some don't.  Apparently some multipath configurations
can allow more than 16383 concurrent write requests.

So, in this unlikely situation, instead of calling BUG_ON we now wait
for the count to drop down a bit.  This requires a new wait_queue_head,
some waiting code, and a wakeup call.

Tested by limiting the counter to 20 instead of 16383 (writes go a lot slower
in that case...).
Signed-off-by: default avatarNeil Brown <neilb@suse.de>
Signed-off-by: default avatarAdrian Bunk <bunk@kernel.org>
      646edb4b
  11. 22 Aug, 2007 7 commits
    • Neil Brown's avatar
      md: fix a few problems with the interface (sysfs and ioctl) to md · 4d5eb09c
      Neil Brown authored 
      While developing more functionality in mdadm I found some bugs in md...

- When we remove a device from an inactive array (write 'remove' to
  the 'state' sysfs file - see 'state_store') would should not
  update the superblock information - as we may not have
  read and processed it all properly yet.

- initialise all raid_disk entries to '-1' else the 'slot sysfs file
  will claim '0' for all devices in an array before the array is
  started.

- all '\n' not to be present at the end of words written to
  sysfs files

- when we use SET_ARRAY_INFO to set the md metadata version,
  set the flag to say that there is persistant metadata.

- allow GET_BITMAP_FILE to be called on an array that hasn't
  been started yet.
Signed-off-by: default avatarNeil Brown <neilb@suse.de>
Signed-off-by: default avatarAdrian Bunk <bunk@kernel.org>
      4d5eb09c
    • Neil Brown's avatar
      md: assorted md and raid1 one-liners · b3188291
      Neil Brown authored 
      Fix few bugs that meant that:
  - superblocks weren't alway written at exactly the right time (this
    could show up if the array was not written to - writting to the array
    causes lots of superblock updates and so hides these errors).

  - restarting device recovery after a clean shutdown (version-1 metadata
    only) didn't work as intended (or at all).

1/ Ensure superblock is updated when a new device is added.
2/ Remove an inappropriate test on MD_RECOVERY_SYNC in md_do_sync.
   The body of this if takes one of two branches depending on whether
   MD_RECOVERY_SYNC is set, so testing it in the clause of the if
   is wrong.
3/ Flag superblock for updating after a resync/recovery finishes.
4/ If we find the neeed to restart a recovery in the middle (version-1
   metadata only) make sure a full recovery (not just as guided by
   bitmaps) does get done.
Signed-off-by: default avatarNeil Brown <neilb@suse.de>
Signed-off-by: default avatarAdrian Bunk <bunk@kernel.org>
      b3188291
    • Neil Brown's avatar
      md: allow SET_BITMAP_FILE to work on 64bit kernel with 32bit userspace · 7524619e
      Neil Brown authored 
      ..  so that you can use bitmaps with 32bit userspace on a 64 bit kernel.
Signed-off-by: default avatarNeil Brown <neilb@suse.de>
Signed-off-by: default avatarAdrian Bunk <bunk@kernel.org>
      7524619e
    • Neil Brown's avatar
      md: fix some small races in bitmap plugging in raid5 · 5405a10e
      Neil Brown authored 
      The comment gives more details, but I didn't quite have the sequencing write,
so there was room for races to leave bits unset in the on-disk bitmap for
short periods of time.
Signed-off-by: default avatarNeil Brown <neilb@suse.de>
Signed-off-by: default avatarAdrian Bunk <bunk@kernel.org>
      5405a10e
    • Neil Brown's avatar
      md: fix a plug/unplug race in raid5 · cc49f099
      Neil Brown authored 
      When a device is unplugged, requests are moved from one or two (depending on
whether a bitmap is in use) queues to the main request queue.

So whenever requests are put on either of those queues, we should make sure
the raid5 array is 'plugged'.  However we don't.  We currently plug the raid5
queue just before putting requests on queues, so there is room for a race.  If
something unplugs the queue at just the wrong time, requests will be left on
the queue and nothing will want to unplug them.  Normally something else will
plug and unplug the queue fairly soon, but there is a risk that nothing will.
Signed-off-by: default avatarNeil Brown <neilb@suse.de>
Signed-off-by: default avatarAdrian Bunk <bunk@kernel.org>
      cc49f099
    • Neil Brown's avatar
      md: fix resync speed calculation for restarted resyncs · 26d0764d
      Neil Brown authored 
      We introduced 'io_sectors' recently so we could count the sectors that causes
io during resync separate from sectors which didn't cause IO - there can be a
difference if a bitmap is being used to accelerate resync.

However when a speed is reported, we find the number of sectors processed
recently by subtracting an oldish io_sectors count from a current
'curr_resync' count.  This is wrong because curr_resync counts all sectors,
not just io sectors.

So, add a field to mddev to store the curren io_sectors separately from
curr_resync, and use that in the calculations.
Signed-off-by: default avatarNeil Brown <neilb@suse.de>
Signed-off-by: default avatarAdrian Bunk <bunk@kernel.org>
      26d0764d
    • Neil Brown's avatar
      md: Allow re-add to work on array without bitmaps · 32b26819
      Neil Brown authored 
      When an array has a bitmap, a device can be removed and re-added and only
blocks changes since the removal (as recorded in the bitmap) will be resynced.

It should be possible to do a similar thing to arrays without bitmaps.  i.e.
if a device is removed and re-added and *no* changes have been made in the
interim, then the add should not require a resync.

This patch allows that option.  This means that when assembling an array one
device at a time (e.g.  during device discovery) the array can be enabled
read-only as soon as enough devices are available, but extra devices can still
be added without causing a resync.
Signed-off-by: default avatarNeil Brown <neilb@suse.de>
Signed-off-by: default avatarAdrian Bunk <bunk@kernel.org>
      32b26819
  13. 11 Aug, 2007 5 commits
GitLab Nexedi Edition | About GitLab | About Nexedi | 沪ICP备2021021310号-2 | 沪ICP备2021021310号-7