Re: 4.8 panic "ffs_clusteralloc: map mismatch"

From: Andrew L. Neporada (andr_at_dgap.mipt.ru)
Date: 07/16/03

  • Next message: k.j.koster_at_telecom.tno.nl: "RE: 4.8 panic "ffs_clusteralloc: map mismatch""
    Date: Wed, 16 Jul 2003 18:15:38 +0400
    To: Avleen Vig <lists-freebsd@silverwraith.com>
    
    

    On Wed, Jul 16, 2003 at 05:57:44AM -0700, Avleen Vig wrote:
    >
    > Andrew,
    >
    > I spend about two to three years fighting with a system trying to figure
    > out what was wrong, and why these errors were caused. I got the very
    > same crashes you're seeing now.
    > I'm sure others are too, and I think this reply would be useful for the
    > archives.
    >
    > My Solution:
    > I eventually realised that my problem was with one of three things:
    > 1) bit flips in main memory
    > 2) bit flips in cache
    > 3) bad hard drive
    >
    > I replaced all of the memory after a few months. The problems stopped
    > for a few weeks but quickly returned. So I don't think it was main
    > memory, unless the new set or the sockets were damaged.
    > I couldn't replace the cache because I couldn't find any more. The
    > system was an old P1 (originally 75Mhz). This could have been the
    > problem.

    My system has brand new MB (supermicro dual proc mainbord with U160 SCSI &
    fxp NIC integrated), P3 processor & memory (btw, ECC memory).
    Other components are not-so-new, but they worked flawlessly for about a
    year with another MB.

    > I did once try turning off L2 cache in the BIOS, and I think the crashes
    > *might* have continued. So it's possible the problems were here.
    >
    > Finally I didn't replace the hard drive, but I did find that moving load
    > off the original drive to a second drive helpped reduce the number of
    > crashes, although they still continued to happen.
    >
    > HTH.
    >
    > --
    > Avleen Vig "Say no to cheese-eating surrender-monkeys"
    > Systems Admin "Fast, Good, Cheap. Pick any two."
    > www.silverwraith.com "Move BSD. For great justice!"

                                    Andrew.
    _______________________________________________
    freebsd-hackers@freebsd.org mailing list
    http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
    To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org"


  • Next message: k.j.koster_at_telecom.tno.nl: "RE: 4.8 panic "ffs_clusteralloc: map mismatch""

    Relevant Pages

    • Re: 4.8 panic "ffs_clusteralloc: map mismatch"
      ... bit flips in main memory ... I replaced all of the memory after a few months. ... I couldn't replace the cache because I couldn't find any more. ... I did once try turning off L2 cache in the BIOS, and I think the crashes ...
      (freebsd-hackers)
    • Re: Cached memory never gets released
      ... Stock linux 2.4.26 kernel. ... Due to flash bug 3M of memory gets lost due to font memory getting lost ... The output of "free" cache number steadily grows. ... longer to exhaust all of system memory with the cache. ...
      (Linux-Kernel)
    • Re: Problem: Creating a raw binary string
      ... > While its true that a 64-bit cpu will move twice the data per instruction it ... > Memory bus width plays an important role here and unless it too is widened / ... You are forgetting the two levels of cache in the processor. ... The memory chips are addressed in Row col fashion. ...
      (alt.comp.lang.borland-delphi)
    • Re: Is Greenspun enough?
      ... Most OSes memory map executables directly from the file system so code doesn't pollute the file cache or swap space. ...
      (comp.lang.lisp)
    • Re: Superstitious learning in Computer Architecture
      ... Without a LOT of logic or some other better approach, re-executing the instructions requires re-decoding and it ties up the cache memory bus transferring more data as instructions than the instructions are working on. ... The concept of cache is fundamentally flawed in that it STILL restricts access to one word per clock cycle, when a single modern ALU can easily use 5 plus whatever is eaten up with instruction accesses. ... The size of an optimizing compiler is proportional to the SQUARE of the size of the language times the SQUARE of the complexity of the machine - because all interactions must be considered. ...
      (comp.arch.arithmetic)