From nobody  Wed Dec  3 08:52:52 1997
Received: (from nobody@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id IAA24196;
          Wed, 3 Dec 1997 08:52:52 -0800 (PST)
          (envelope-from nobody)
Message-Id: <199712031652.IAA24196@hub.freebsd.org>
Date: Wed, 3 Dec 1997 08:52:52 -0800 (PST)
From: kpielorz@tdx.co.uk
To: freebsd-gnats-submit@freebsd.org
Subject: fsck fails at boot time with sig11: segmentation fault when checking a 5gb partition.
X-Send-Pr-Version: www-1.0

>Number:         5199
>Category:       bin
>Synopsis:       fsck fails at boot time with sig11: segmentation fault when checking a 5gb partition.
>Confidential:   no
>Severity:       serious
>Priority:       high
>Responsible:    freebsd-bugs
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Wed Dec  3 09:00:00 PST 1997
>Closed-Date:    Fri May 8 13:50:56 PDT 1998
>Last-Modified:  Fri May  8 13:51:42 PDT 1998
>Originator:     Karl Pielorz
>Release:        2.2.2-RELEASE
>Organization:
D.M.Priest & Company Ltd.
>Environment:
FreeBSD viper.dmpriest.com 2.2.2-RELEASE FreeBSD 2.2.2-RELEASE #0: Tue Nov 25 14:21:22 GMT 1997     root@viper.dmpriest.com:/usr/src
/sys/compile/VIPER  i386
>Description:

Filesystems were setup as follows:-

Filesystem  1K-blocks     Used    Avail Capacity  Mounted on
/dev/sd0a       63567    14646    43836    25%    /
/dev/sd0s1f   1017327     6328   929613     1%    /tmp
/dev/sd0s1g    536351   107623   385820    22%    /usr
/dev/sd0s1h   5736293   373117  4904273     7%    /usr2
/dev/sd0s1e   1017327    24303   911638     3%    /var

All were on a Quantum Atlas-II 9.1Gb UltraWide SCSI hard drive running
off an Adaptec 2940UW controller.

First noticed a problem in the morning just after running a TAR'd
backup of the system - running 'du' in Squid's Cache directory (which
has a lot of directories) generated a 'FE directory not found' error
(it couldn't do a DU of a certain directory).

About 4 hours later the system panic'd with:

"panic: allocbuf; buffer too small"

Though I don't know if that's related. When the system autobooted fsck
failed when checking /dev/rsd0s1h (/usr2) filesystem (i.e. it found
errors other than those that are fixable when running fsck -p etc.) -
going single user and running fsck produces:-

viper> fsck /usr2
** /dev/rsd0s1h
** Last Mounted on /usr2
** Phase 1 - Check Blocks and Sizes

** Phase 2 - Check Pathnames
DIRECTORY CORRUPTED  I=122891  OWNER=squid MODE=40700
SIZE=3584 MTIME=Dec  3 16:03 1997
DIR=?

SALVAGE? [yn] SALVAGE? [yn] y

pid 7 (fsck), uid 0: exited on signal 11
Segmentation fault

--------

Running fsck and saying 'NO' to SALVAGE [yn]: also results in a
Segmentation fault.

--------

Bringing the system backup up multi user without the /usr2 partition
mounted and runninf fsck on it produces the same - and a core dump
(which I have saved).

I tried modifying the /etc/login.conf profiles for daemon to allow more
memory / stack space etc. (having seem a recent similar article with
fsck reporting "annot alloc 7730626 bytes for lncntp" - this made no
difference.
>How-To-Repeat:
I'd rather not... The machine has a 'twin sister' with exactly the
same config, installed packages etc. - but has no problems. The sister
machine also runs the Squid package and so also has a large directory
structure on it's /usr2 partition.
>Fix:
No known solution - I am in the process of nuking the /usr2 partition
and restoring from an earlier backup.
>Release-Note:
>Audit-Trail:
State-Changed-From-To: open->closed 
State-Changed-By: phk 
State-Changed-When: Fri May 8 13:50:56 PDT 1998 
State-Changed-Why:  
I belive this was caused by the "loginc-class" code, and it is 
my impression that it is fixed now. 
>Unformatted:
