lkml.org 
[lkml]   [1998]   [Feb]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
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 <dledford@dialnet.net>
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 majordomo@vger.rutgers.edu

\
 
 \ /
  Last update: 2005-03-22 13:41    [from the cache]
©2003-2011 Jasper Spaans