Description of problem:
The server panicked and after recovery the logs had messages regarding a bug
in fs/lockd/host.c line 252
Version-Release number of selected component (if applicable):
It has happened twice now in about a month and a half span.
Steps to Reproduce:
Attached file has the kernel messages before the 5 second panic.
Created attachment 152008 [details]
Log Messages right before the panic
In taking a look at this case, it looks like the machine paniced due to this:
BUG_ON(atomic_read(&host->h_count) < 0);
So the h_count here was too low at the time this function was called. The big
question is why. Unfortunately, it's hard to tell much from the oops here. What
can you tell me about the conditions under which this is occuring? Would it be
possible to get a crash dump?
The first time it happened, the main campus's IT department was having a big
outage of network services. So I had written it off to some severe delay in
name resolution or something.
But this last time, it seemed to be a regular day and then all of a sudden the
calls started coming in and when I got to the console it had panicked.
Setup is nothing out of the ordinary. Redhat server, fedora 5 clients, a few
What does h_count keep track of? Maybe that will give me a clue to some more
info I can provide.
I looked in /var/crash and did not see any files. Are they saved somewhere else?
Thanks for your time and efforts.
h_count is a reference count for the nlm_host structure. The kernel crashed
because after it went to decrement this count, it was less than 0, and so it
should not have been being used in the first place. This may mean that we have a
case of too many "releases" and not enough "gets" on this struct, or it may mean
some sort of memory corruption is occuring. Unfortunately, I can't tell much
from just the oops messages here. I've seen some upstream reports of panics that
look similar to this, but nothing that points me to whether they were ever resolved.
If you can get a core, that may help answer some questions. Our support people
should be able to help you do this. There are also some kbase articles on how to
set up diskdump and netdump. It would also be good to open a support case anyway
so that we can track this as an actual customer issue internally.
If you do so, reference this BZ case number so they're aware of it.
Setting to needinfo until we can get some more info on how this is reproduced,
or a vmcore...
Sounds good here.
I am not sure I will be able to provide much more info. I have since upgraded
to a newer kernel. This is on a production machine and I can't really shutdown
for testing and such.
Fair enough. I've not heard of anyone else hitting this issue and it sounds like
you've worked around it by using a different kernel. I'm going to close this
case with a resolution of INSUFFICIENT_DATA. If you find you're able to
reproduce it (and optimally, get a vmcore), then please reopen this case and
I'll have another look.