Matthew Dillon wrote:
>
> :
> :> Try this patch with the latest kernel. The failure case is odd,
> :> because it looks like the underlying lock is somehow entering the
> :> system
> :> shutdown code. The code in linux_util appears to have some severe
> :> leaks: a vnode reference count leak and a memory leak, which thi
> :> s patch fixes.
> :>
> :> Does running clearcase crash it immediately or does it take a
> :> number of runs?
> :
> :It's very close but not quite instant - the command appears to pause for
> :5-10 seconds before the actual panic.
> :
> :Andrew.
>
> Ok, so try it with the patch and see if it still crashes. If it
> does try to get a kernel core dump out of it.
>
> -Matt
> Matthew Dillon
> <dillon@backplane.com>
Okay, tried the patch and it panics, a bit differently ..
db> trace
Debugger(c0418131,6,6,6,14) at Debugger+0x3e
boot(100,c04af480,c041793d,d5aa08ec,10) at boot+0x265
poweroff_wait(c041793d,c042be50,cec8e728,1,1) at poweroff_wait
trap_fatal(d5aa0980,1d,1,0,cec8e680) at trap_fatal+0x41b
trap_pfault(d5aa0980,0,1d,d5aa0b28,1d) at trap_pfault+0x142
trap(18,10,10,d2ae9c00,2) at trap+0x3e8
calltrap() at calltrap+0x18
--- trap 0xc, eip = 0xc0619551, esp = 0xd5aa09c0, ebp = 0xd5aa0b64 ---
linux_copyin_path(80a0017,d5aa0b84,2,bfc201d8,cc415980) at
linux_copyin_path+0x1b1
linux_open(d5aa0c24,d5aa0d0c,d5aa0c1c,d5aa0c20,3) at linux_open+0x65
syscall2(2f,2f,2f,80b32fe,8) at syscall2+0x25f
Xint0x80_syscall() at Xint0x80_syscall+0x2a