lkml.org 
[lkml]   [2003]   [Mar]   [1]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: syslog full of kernel BUGS, frequent intermittent instability
    On Sat, 1 Mar 2003 14:55:58 +0000 (GMT)
    John Bradford <john@grabjohn.com> wrote:

    > As your machine is quite old, you would probably get a noticable speed
    > increase from mounting your filesystems with noatime, which is very
    > straightforward and shouldn't cause any problems - just edit
    > /etc/fstab, and add the option noatime after each disk partition, for

    Thanks for the tip. I applied it, but haven't noticed any
    immediately obvious benefits in the short time I've spent so far. Guess
    I won't be able to avoid the dreaded kernel recompile forever. ;-)

    > Are you sure there isn't a correct slot that it should be in? Most
    > motherboard manuals specify that the slots should be used in a
    > specific order.

    Guess I've got one of those unusual mobos - it's an MSI-5169. Here's an
    excerpt from my printed manual (typed manually);

    "2.2-3 Memory Population Rules

    1. This mainboard supports Table Free memory, so memory can be installed
    in DIMM1, DIMM2, or DIMM3 in any order."

    > It might have been disconnecting and reconnecting the RAM that
    > improved things, not the change of slot. Try both end slots.

    I've been testing it all day, and have collected more data (please see
    below)- it's definitely a huge improvement over what I had before,
    whatever the underlying reason may be. Looks like a whole order of
    magnitude to me. Still not perfect though.

    Tomorrow, I will try switching to an end slot as you suggest, and see if
    that gets me any further improvement. At this point, I'm thinking of
    taking the money and running because I am planning on upgrading my
    system in a few months anyway, and think I can tolerate a few crashes
    until then - just so long as they're not happening almost daily as they
    were before. After all, I'm coming from the world of windows, so I'm not
    exactly a virgin in this respect. ;-) I will demand perfection from
    the new system when I finally get it though.

    It may be more productive for me now to spend my time learning and
    investigating and tweaking other stuff, as I have a long list of things
    (like some performance issues I mentioned before) I would like to work
    on to get this installation working to my liking.

    When I get my new system this spring, it'll have a spacious 100 gig hard
    disk, which I plan to partition with a few different distros -
    probably mandrake again, along with debian and gentoo. I'd like to get
    my comfort factor up between now and then, and hope to gain experience
    in a lot of different aspects of administration and just plain
    understanding how stuff in the linux world works. Hopefully I'll have
    kernel recompile or two under my belt by then, and won't be so clueless
    about how the system all fits together.

    This experience and your advice and really helped me a lot. I can't
    thank you guys enough for your help, you've been great - not just in
    helping me solve my problem, but also in learning a great deal by
    walking me through it and taking the time to answer my dumb
    questions.

    My already high respect for the community has gone up yet another notch.
    I wish the rest of the world could always be this nice.

    best regards

    wyleus

    ....

    Here's an updated version of the notes I took;

    Friday, Feb 28 2003
    Results of burnMMX tests

    command: burnMMX x; echo $?

    where x represents memory size parameter passed to burnMMX as follows;

    <small excerpt from cpuburn readme>
    burnBX and burnMMX are essentially very intense RAM testers. They can
    also take an optional parameter indicating the RAM size to be tested:

    A = 2 kB E = 32 kB I = 512 kB M = 8 MB
    B = 4 F = 64 J = 1 MB N = 16
    C = 8 G = 128 K = 2 O = 32
    D = 16 H = 256 L = 4 P = 64

    the default memsize used when none is specified is F=64k

    exit codes for burnMMX are as follows;
    130 = process killed manually using ctl-c
    254 = integer/memory error
    255 = FP/MMX error

    mem runtime exit
    size (minutes) code

    A (2K) 26:00 130
    28:15 130
    F (64K) 2:00 254
    11:00 130
    6:00 130
    21:42 130
    G (128K) 6:00 130
    H (256K) 3:25 254
    2:40 254
    0:45 254 1 these
    1:35 254 1 are
    0:40 254 1 consecutive
    3:45 254 1 runs
    33:00 130 1
    7:00 254 1
    7:00 254 1
    5:16 254 1
    17:19 254 1
    I (512K) 6:00 254
    1:48 254
    5:34 254
    =====
    Total runtime ~197 minutes
    # of failures 14
    ave run/fail 14 minutes

    Sat, March 1, 2003

    Switched the RAM stick from the first slot (closest
    to CPU), to the middle slot;

    command: time burnMMX x; echo $?

    (using the time command, manual exits using
    ctl-c provide exit code 2, but I still list it
    as 130 in the table for consistency)

    mem runtime exit
    size (minutes) code

    F (64K) 22:42 130
    12:20 254
    23:37 130
    192:47 130
    G (128K) 2:46 254
    21:50 130
    30:55 130
    43:59 130
    H (256K) 20:12 130
    33:46 130
    24:33 130
    I (512K) 20:06 130
    21:58 130
    21:03 254
    J (1024K) 21:57 130
    28:46 130
    =====
    Total runtime ~543 minutes
    # of failures 3
    ave run/fail 181 minutes
    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2005-03-22 13:33    [W:0.028 / U:61.228 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site