pr919 again, and machine drops into ddb...

[carson_(_dot_)_harding_(_at_)_home_(_dot_)_com]

I had the same problem described in PR-919 re vnd not working
on a Sun 4m (a sparcstation 20). The symptoms are identical,
the printout could be mine. Except I am not using mfs. And
this is 2.8-stable, I'd updated the source, built and
installed a new kernel, done make build, and was now
doing make release.

- mtree on /mnt fails
- df shows /dev/svnd0a on /mnt
- file exists in /tmp
- /mnt does not show up in ls of /
- umount /mnt, and /mnt comes back
- vnconfig -u svnd0a seems to work

I just now logged back on to collect the output as well as df,
dmesg etc. This time, however, the machine dropped into ddb once
the mtree started:

# cd /usr/src/distrib/sparc/ramdisk
# make
===> ../ramdisk
dd if=/dev/zero of=/tmp/image.12727 count=4352
4352+0 records in
4352+0 records out
2228224 bytes transferred in 1 secs (2228224 bytes/sec)
vnconfig -v -c svnd0 /tmp/image.12727
svnd0: 2228224 bytes on /tmp/image.12727
disklabel -w  svnd0 rdroot
newfs -t ffs -m 0 -o space -f 1024 -b 8192 -i 16384 -c 64 -s 4352
/dev/rsvnd0a || false
/dev/rsvnd0a:   4352 sectors in 272 cylinders of 2 tracks, 8
sectors
        2.1MB in 5 cyl groups (64 c/g, 0.50MB/g, 64 i/g)
super-block backups (for fsck -b #) at:
 32, 1072, 2080, 3120, 4128,
mount /dev/svnd0a /mnt
mtree -def /usr/src/distrib/ramdisk/mtree.conf -p /mnt/ -u

And it hung. I logged in through the serial console, and it
was sitting at ddb>. 

ddb> trace
_ufs_dirbad(0xf8445300, 0x0, 0xf8130da0, 0x0, 0xfa040c2c, 0x0) at
_ufs_dirbad+0x38
_ufs_lookup(0x0, 0x2, 0x200, 0x0, 0xf84d0a00, 0xfa040e20) at
_ufs_lookup+0x480_VOP_LOOKUP(0xf8438a00, 0xfa040e20, 0xfa040e34, 0xf8425801,
0x400, 0xffffffff) at _VOP_LOOKUP+0x2c
_lookup(0xfa040e10, 0x0, 0xf84d0a00, 0xfa040e28, 0xfa03f000,
0xf8425800) at _lookup+0x32c
_namei(0xf8438a00, 0x13140, 0x3020230, 0x80a41ac, 0x0,
0xf7fff4ac) at _namei+0x358
_sys_lstat(0xf84d0a00, 0xfa040f28, 0xfa040f20, 0xf807190c,
0xc080, 0x1) at _sys_lstat+0x24
_syscall(0xbe, 0xfa040fb0, 0x0, 0x3, 0x0, 0xf7fff5dc) at
_syscall+0x1f4
_kernel_text(0x13140, 0x13148, 0xf7fff5d8, 0x13140, 0xffed,0xffffffff) at _kernel_text+0x47b0


I'm not doing anything with the box at the moment other than
trying to make the OS, so I can leave it there. Is there any
more information I can provide at this point, other than
rebooting it to get the dmesg info?

Anything else helpful I can do?

--
Carson Harding - carson_(_dot_)_harding_(_at_)_home_(_dot_)_com