[lkml]   [2001]   [Jul]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: >128 MB RAM stability problems (again)
    >>>>> "Ragnar" == Ragnar Hojland Espinosa <> writes:

    Ragnar> And here's a counter claim: At home have 128 + 64, both of
    Ragnar> different speeds and brands. Of course, to run properly you
    Ragnar> have to force the pc100 to run at 66, but other than that
    Ragnar> they're happy (96MB swap)


    Yes, I imagine Linux does work ;-) The fact is that SDRAM is
    problematic (from a hardware perspective). For the OP, it could be a
    bus capacitance problem. If the boards are older, they might not be
    designed for larger memories with have a higher capacitance. Slowing
    down the accesses will stop the problem. You would do this by going
    to the BIOS and changing the CAS and RAS timings (or maybe you can
    change the SDRAM clock). SDRAM has a `NOP' state so that you can run
    at a higher clock speed, but delay a command. Anyways, I don't think
    that Linux is messing with the SDRAM controllers, but I am not an
    authority. Also, a single stick is always better than several
    smaller memory sizes.

    I was looking at the memtest86 web sight ""
    and I didn't see anything that test for SDRAM cache lines. Single
    beat SDRAM read/writes are less stressful than BURSTS. It is typical
    for single beats read/write to work while bursts fail as four 32 bit
    values are written and read in quick succession. The `algorithm'
    description on the web page doesn't seem to test for this issue from
    what I see... of course I have been wrong before!

    Bill Pringlemeir

    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2005-03-22 12:56    [W:0.022 / U:5.156 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site