Re: panic(cpu 1 caller ...): vnode_put(...): iocount < 1
Re: panic(cpu 1 caller ...): vnode_put(...): iocount < 1
- Subject: Re: panic(cpu 1 caller ...): vnode_put(...): iocount < 1
- From: Terry Lambert <email@hidden>
- Date: Mon, 3 Oct 2005 17:55:27 -0700
You will need two machines; you will also need to set the flags for
debugging (I usually use 0x14e, to get kernel printf's as well).
When a machine with these settings panics, you will need to attach to
it to debug. Note that the power button will no longer sleep the
machines with these settings; instead it will NMI them to permit
attaching a debugger to a live system.
http://developer.apple.com/devicedrivers/download/
http://developer.apple.com/documentation/Darwin/Conceptual/
KernelProgramming/build/chapter_18_section_5.html#//apple_ref/doc/uid/
TP30000905-CH221-CIHBJCGC
The basic procedure you will want is:
gdb mach_kernel.sys
source kgmacros
kdp-reattach <ip address of victim machine>
paniclog
bt
showallstacks
Right now, from the addresses in backtrace you posted, I will tell
you it's crashing in a call to lstat; most likely, you have a forced
unmount in progress and/or your program that's causing the problem is
a multithreaded program that's closing the fd out from under a
blocked lstat in progress (usually the lstat is against a network
file server that's gone away or is not responding, and you've issued
an explicit kill to kill the process (and it's multithreaded)).
You should really file a bug once you've gathered all the information
you can.
You will probably want to switch to the frame number from the bt for
the vnode_put_locked frame, and do a:
frame 3 (or whatever the frame number is from the bt)
print *vp
as well; this will narrow down the issue for your bug report.
If the mount point isn't dead:
p vp->v_mount
p dead_vnodeop_p
and v_mount is not 0 or the same value as dead_vnodeop_p, then also
do this:
p *vp->v_mount
If you are just interested in avoiding the problem, or want to avoid
it until there's a fixed release (it may already be fixed by the next
update), the showallstacks will report the process name of all the
processes, and you will see the panic in one of them; the print *vp
will give a v_name field, which will be the name of the file
(probably a symbolic link). You can look at the vp pointed to by the
v_parent, and print it's v_name, and so on, to assemble the path to
the vp. If it's dead because of a forced unmount, the value of
v_mount will be 0; it might also be that the vp->v_op has the same
address in it as the symbol dead_vnodeop_p; you could check both of
those.
I really would recommend filing a bug, though, including all the
above information:
<http://bugreporter.apple.com>
PS: Say "hi" to North Physics for me... I started my college career
at the UofU majoring in high energy physics and applied math. 8-).
-- Terry
On Oct 3, 2005, at 3:50 PM, James Reynolds wrote:
I manage a lab of about 300 Macs. Since I've upgraded them to
Tiger, I've had various problems I've been chasing without
success. The latest version of the problem is that about 120 of my
Macs (nearly all of my dual 2.0 G5's) kernel panic daily with: panic
(cpu 1 caller ...): vnode_put(...): iocount < 1
The only place I have seen anything on vnode_put is this list...
thus I post my question here.
I think this is related to my previous problems because my old
problems were also file system problems, which consisted of fsck
failing at startup (resulting in /etc/rc calling halt--which I had
to change to reboot to keep my machines up--and they worked
relatively fine after a reboot, until the kernel panics started).
I'm trying to do the closest I can come to a clean install of my
OS, but I have hundreds of other apps that are layered on top of
the OS and I can't rebuild them all quickly, especially since I'm
not even sure that will fix it, and since the new school term is
roaring at full speed. And I'm not sure the clean install will
actually fix the error. So I would like to figure out what exactly
is going on while I prep my new OS.
Also, these errors don't occur on my non-dual 2.0 G5's (G5 iMacs &
G4 iMacs and towers). And the file systems of all machines are
pretty much clones, and are maintained with radmind (www.radmind.org).
In fact, I'm wondering if radmind could be causing these problems.
But because of the hardware uniqueness, I'm also wondering if Tiger
is just more picky than Panther was to my dual G5 hardware. But
because this all seems to have something to do with file system
problems... I'm not sure what direction I should be looking.
Anyway, I'm assuming the kernel panic below means something like a
vnode is missing its file.
My question is, is there any way I can figure out what file this is
dying on (or is there any other way to figure out what is going on):
panic(cpu 1 caller 0x000E6D70): vnode_put(191e084): iocount < 1
Latest stack backtrace for cpu 1:
Backtrace:
0x00095544 0x00095A5C 0x0002683C 0x000E6D70 0x000E6D1C
0x000ED6D0 0x000EDA50 0x000EDAF0
0x002A7A94 0x000ABCB0 0x797A6F46
Proceeding back via exception chain:
Exception state (sv=0x2A74BC80)
PC=0x9002218C; MSR=0x0000D030; DAR=0x12D89000;
DSISR=0x42000000; LR=0x9003FDD0; R1=0xF02023B0; XCP=0x00000030
(0xC00 - System call)
Kernel version:
Darwin Kernel Version 8.2.0: Fri Jun 24 17:46:54 PDT 2005;
root:xnu-792.2.4.obj~3/RELEASE_PPC
--
Thanks,
James Reynolds
University of Utah
Student Computing Labs
email@hidden
801-585-9811
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-kernel mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
40apple.com
This email sent to email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-kernel mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden