Eagle problem, help needed (long)

[Hannes Lubich]

Hi,
is anybody using Fujitsu M2351A-Eagle disks with Emulex controllers on a Vax?
We've got such a beast (474.2 MB unformatted) on an Emulex QD32 controller
for our uVax II running Ultrix V2.0-1. We are running an Emulex QD21 with 
two smaller Fujitsu disks on the same machine already without problems.
I can format and verify the Eagle (45 bad blocks) by talking to the diagnostic
software on the controller NOVRAM and I have verified that the strapping is
correctly set for 48 sectors. I've added

controller     uda2      at  uba0
controller     uq2       at  uda2      csr 0160344   vector uqintr
disk           ra8       at  uq2       drive 0

to the kernel config file. When booting, uq2 and ra8 are shown as being
present on the bus - no problems so far.

I'm using the standard eagle disktab entry:
eagle|Eagle|Fujitsu Eagle (48 sectors):\
	    :ty=winchester:ns#48:nt#20:nc#842:rm#3900:\
        :pa#15884:ba#8192:fa#1024:\
        :pb#66880:bb#4096:fb#512:\
        :pc#808320:bc#8192:fc#1024:\
        :pd#15884:bd#8192:fd#1024:\
        :pe#307200:be#4096:fe#512:\
        :pf#109248:bf#4096:ff#1024:\
        :pg#432768:bg#4096:fg#1024:\
        :ph#291346:bh#4096:fh#512:

So I've tried to run "newfs -v /dev/rra8a eagle" which produces the following 
output:

/etc/mkfs /dev/rra8a 15884 48 20 8192 1024 16 10 65 2048
Warning: inode blocks/cyl group (36) >= data blocks (32) in last
    cylinder group. This implies 512 sector(s) cannot be allocated.
/dev/rra8a:     15360 sectors in 16 cylinders of 20 tracks, 48 sectors
        7.9Mb in 1 cyl groups (16 c/g, 7.86Mb/g, 1856 i/g)
super-block backups (for fsck -b#) at:
 32,
installing boot code
sector 0 boot + 1st level boot = /usr/mdec/vaxboot

Then I try to fsck it with "fsck /dev/rra8a" which results in:

** /dev/rra8a
BAD SUPER BLOCK: TRASHED VALUES IN SUPER BLOCK
USE -b OPTION TO FSCK TO SPECIFY LOCATION OF AN ALTERNATE
SUPER-BLOCK TO SUPPLY NEEDED INFORMATION; SEE fsck(8).

I then use "fsck -b32 /dev/rra8a" which finds lots and lots of partially
allocated inodes, beginning with inode 5. When trying to clear them
using "fsck -b32 -y /dev/rra8a" they get cleared in ther first phase,
but then I get the following:

** Phase 2 - Check Pathnames
DIRECTORY CORRUPTED  I=3  OWNER=root MODE=40755
SIZE=8192 MTIME=Aug 22 03:28 1990 
DIR=/lost+found

SALVAGE?  yes
 
It seems to me as if the newfs works ok (sort of) but I can't figure out
why the fsck doesn't get along with the superblock. 
The problem is there for all partitions, not only for a. I've tried a smaller
number for the cylinders/group with newfs, "newfs -v -c 8 /dev/rra8a eagle"
The result looks different:

/etc/mkfs /dev/rra8a 15884 48 20 8192 1024 8 10 65 2048
Warning: 448 sector(s) in last cylinder unallocated
/dev/rra8a:     15872 sectors in 17 cylinders of 20 tracks, 48 sectors
        8.1Mb in 3 cyl groups (8 c/g, 3.93Mb/g, 1216 i/g)
super-block backups (for fsck -b#) at:
 32, 7760, 15488,
installing boot code
sector 0 boot + 1st level boot = /usr/mdec/vaxboot

but fsck still gives the same error "BAD SUPER BLOCK" and specifying any
of the alternate boot blocks again results in this enormous amount of
error messages about partially allocated inodes. The next phases of fsck,
however, are different:

** Phase 2 - Check Pathnames
** Phase 3 - Check Connectivity
** Phase 4 - Check Reference Counts
** Phase 5 - Check Cyl groups
CG 1: BAD MAGIC NUMBER
EXCESSIVE BAD BLKS IN BIT MAPS.
CONTINUE?  yes

BAD CYLINDER GROUPS
SALVAGE?  yes

** Phase 6 - Salvage Cylinder Groups

**** FILE SYSTEM MODIFIED, VERIFYING

** /dev/rra8a

BAD SUPER BLOCK: TRASHED VALUES IN SUPER BLOCK
USE -b OPTION TO FSCK TO SPECIFY LOCATION OF AN ALTERNATE
SUPER-BLOCK TO SUPPLY NEEDED INFORMATION; SEE fsck(8).

Following the advice of our disk supplier, I changed the disktab entry
from
:ty=winchester:ns#48:nt#20:nc#842:rm#3900:\
to
:ty=winchester:ns#46:nt#20:nc#842:rm#3961:\
which didn't help much.

I'd appreciate any help or pointers.
Thanks a lot in advance
	--HaL
-- 
~ UUCP/Usenet 	       : {known world}!mcvax!cernvax!ethz!lubich
~ or                   : lubich at ethz.uucp
~ CSNET/ARPA/BITNET    : lubich at inf.ethz.ch / lubich%inf.ethz.ch at relay.cs.net
~ The usual disclaimer : No, it wasn't me, somebody must have used my account.