On Jun 22, 11:59am, Patrick Welche wrote:
> Subject: Re: panic message ?
> Perry E. Metzger wrote:
> >
> > Jason Thorpe writes:
> > > This happens when the mode bits on the inode aren't cleared for some
reason,
> > > indicating that the inode is still allocated.
> > >
> > > I have heard of this when going from 1.2 -> current from a few people...
> > > I'm guessing that this is something that fsck is somehow missing...
> >
> > When doing upgrades, I do fsck -f -- I've institutionalized this in
> > the latest set of i386 upgr scripts, in fact.
> >
> > Perry
> >
>
> Actually, fsck does find and correct the error every time. It most
> often is UNKNOWN FILE TYPE I=7840. The question is why is it happening
> so often? Stating from a clean, checked disk, suddenly a panic
> occurs. It happened again just now while running a script to create a
> bunch of directories. Everything is OK as long as disk access is
> low. This is via an Adaptec 1542B, on a P133, running a sup from 2
> days ago.

This reminds me of a problem that we've seen in the arm32 port but completely
failed to track down where inodes get corrupted in a well-defined way on a
regular basis. We have a check built into the arm32 port which detects this
corruption and attempts to fix it up but we have had no joy in tracking down
where the corruption is coming from. We had assumed that one of our common
device drivers must be overwriting memory after freeing it or something. If you
run the arm32 port on a RiscPC with an IDE harddisk for several days and do a
lot of compilation you are almost bound to see a log message saying that an
inode trash has been located and fixed. IIRC the symptom is a particular
bit-pattern (with a single bit set) appearing in one of the indirect inode
fields.

Cheers

Rob