Re: ia64 r235474 panic on dump 0aLuf - / | restore -rf - : exclusive sleep mutex vnode interlock (vnode interlock) r = 0 (0xe00000001238f6e8) locked @ /usr/src/sys/kern/vfs_hash.c:79

On Jun 29, 2012, at 3:40 AM, Anton Shterenlikht wrote:

> # newfs /dev/da2p2
> /dev/da2p2: 16384.0MB (33554432 sectors) block size 32768, fragment size 4096
>        using 27 cylinder groups of 626.09MB, 20035 blks, 80256 inodes.
> super-block backups (for fsck -b #) at:
> 192, 1282432, 2564672, 3846912, 5129152, 6411392, 7693632, 8975872, 10258112, 11540352, 12822592,
> 14104832, 15387072, 16669312, 17951552, 19233792, 20516032, 21798272, 23080512, 24362752,
> 25644992, 26927232, 28209472, 29491712, 30773952, 32056192, 33338432
> # mount /dev/da2p2 /mnt
> # cd /mnt
> # dump 0aLuf - / | restore -rf -
> 
> results in this panic:
> 
> KDB: stack backtrace:
> getenv with the following non-sleepable locks held:
> exclusive sleep mutex vnode interlock (vnode interlock) r = 0 (0xe00000001238f6e8) locked _at_ /usr/src/sys/kern/vfs_hash.c:79
> KDB: stack backtrace:
> getenv with the following non-sleepable locks held:
> exclusive sleep mutex vnode interlock (vnode interlock) r = 0 (0xe00000001238f6e8) locked _at_ /usr/src/sys/kern/vfs_hash.c:79
> KDB: stack backtrace:
> getenv with the following
> non-sleepablefatal kernel trap (cpu 0):
> locks held:

I think you're kernel is seriously screwed-up. Do you have any
non-standard (for ia64) kernel configuration options?

-- 
Marcel Moolenaar
marcel_at_xcllnt.net