[16448] in Athena Bugs
Weirdo vold lossage under 8.2.13
daemon@ATHENA.MIT.EDU (John Hawkinson)
Tue Oct 27 14:25:22 1998
Date: Tue, 27 Oct 1998 14:25:20 -0500
To: bugs@MIT.EDU
From: John Hawkinson <jhawk@MIT.EDU>
A user came into the sipb office reporting (as usual) that xmcd wasn't
working properly (it displayed a frame but the image wasn't
mapped). It's worth nothing that this is a bug in xmcd and someone
from bug-sipb should look at it. But that's not important ;-)
Not surprisingly, the problem was vold wasn't running. (not that xmcd
-debug said this in a particularly clear fashion, either).
Attempting to restart vold repeatedly showed:
14:16 Tue Oct 27 14:16:21 1998 fatal: svc_tli_create: Cannot create server handle
Examing the syslogs showed that:
Oct 26 23:56:53 w20-575-7.mit.edu unix: WARNING: /iommu@0,10000000/sbus@0,100010
00/espdma@5,8400000/esp@5,8800000/sd@6,0 (sd6):
Oct 26 23:56:53 w20-575-7.mit.edu unix:
Error for Command: read
Error Level: Fatal
Requested Block: 64
Error Block: 64
Vendor: TOSHIBA
Serial Number: 04/12/95
Sense Key: Blank Check
ASC: 0x64 (illegal mode for this track), ASCQ: 0x0, FRU: 0x0
Oct 26 23:57:38 w20-575-7.mit.edu unix: NFS server for volume management (/vol)
not responding still trying
And no more data about /vol. /vol shouldn't be mounted when vold isn't
running, of course. "mount" never shows /vol because Sun is lame, but
everyone's favorite version of the moutn command does:
athena% echo mount | crash
dumpfile = /dev/mem, namelist = /dev/ksyms, outfile = stdout
> FSTYP BSZ MAJ/MIN FSID VNCOVERED PDATA BCOUNT FLAGS
ufs 8192 32,24 800018 0 f5b62c90 0 notr
namefs 1024 181,0 2d40000 f61b4b10 f5925908 0 nolnk
nfs 8192 180,1 2d00001 f617b9d8 f5b62650 -1
namefs 1024 181,0 2d40000 f60f4b08 f59256c8 0 nolnk
afs 8192 8324,8193 1234 f5a7edb8 0 -1037426627
ufs 8192 32,27 80001b f5dffc78 f5b623d0 0 notr
ufs 8192 32,30 80001e f5dd8f08 f5b62510 0 notr
fd 1024 177,0 2c40000 f5c4e5d0 0 5787743
proc 512 174,0 2b80000 f5b55088 f592a688 339184
ufs 8192 32,29 80001d f5943340 f5b62790 0 notr
Of course I'm sure it's obvious that that "nfs" FSTYP is really /vol,
and it's happily mounted when it shouldn't be.
This is doubtless the sort of the problem.
I suggested the user use another workstation or reboot this one,
which I think should fix it.
Whee!
--jhawk
