[lkml]   [1998]   [Feb]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: fs corruption w/ 2.0.33, AHA 2940
    Oliver Mai wrote:
    > Hi!
    > I've been using Linux since kernel v. 0.99pl15, and now
    > it's the first time I've had troubles. I'm not sure if
    > my problems are HW or SW related, but maybe the experts
    > have an idea.
    > Setup: plain 2.0.33 UP kernel (i586), 32MB, Adaptec 2940 UW,
    > 2 SCSI hard disks (the outer one actively terminated),
    > 1 SCSI CD-ROM, 1 IDE disk not used by Linux, SB16, ISDN card,
    > 53c810 SCSI controller only for scanner (module not in kernel
    > at that time)
    > When the computer had run unattended under
    > relatively high load (system load about 2) for some hours
    > the filesystem got completely inconsistent: ls only showed
    > nonsense in any directory and serveral processes (e.g. xdm)
    > crashed when they were about to be paged in.
    > After rebooting, running e2fsck (from e2fsprogs 1.07) manually
    > repaired most of the files and directories.
    > I found the following messages in /var/log/messages:

    OK...the errors you saw are not the result of normal corruption such as bit
    rot during a transfer. They usually indicate something is totally out of
    bounds instead of a bit or two out (at least as it relatest to the aic7xxx
    driver). Now, as I posted in my comments concerning my release of the 5.0.5
    version of my patch, there is a bug in the current aic7xxx code in the
    2.0.33 kernel that could cause this kind of problem. Specifically, if you
    had been using the CD-ROM prior to these errors, especially, if you had
    changed disks a few times, then that could have been the cause of your
    problem. This has been fixed in my 5.0.5 patch and subsequent later patches
    (my current patch is 5.0.7). I would strongly urge you to upgrade to that
    version of the driver, as it tends *not* to do any memory scribbling where
    it isn't suppossed to. If the problems re-occur after an upgrade, then
    there is something else that needs checked into (such as any possible
    cabling problems, etc). As for the files you can't remove, try going to the
    parent of that particular directory and doing an "rm -rf
    /full/path/to/directory" to get rid of it. Who knows, you may have to do a
    few special things like "chattr -i *" in the bad directory before the files
    can be removed though.


    Doug Ledford <>
    Opinions expressed are my own, but
    they should be everybody's.

    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to

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