SYSTEM PANIC AFTER KERNEL REBUILD USING SAM

[KURT HARLESS]

Greetings,

Recently tried to lower my DBC_MAX_PCT using SAM and after it rebuilt the kernel and rebooted the system, crashed on a PANIC with VXFS and NO MOUNT POINTS??? (Sorry dont have the specific error message)

I was able to reboot off the previous kernel and noticed that the new kernal size was 12884032 and the old size was 13127432, which seems to me to be a rather large difference when changing a configurable parameter from 40 to 20????

Support had me apply the following patches on my K580, 11.0 system to try to correct this issue, which didnt help;

PHCO_20882
PHKL_17038
PHKL_20016
PHKL_20674
PHCO_21187
PHKL_18543
PHKL_20079

They had me create one depot from them and do the update, which seemed successful.

How to I diagnose this issue and resolve this issue? Is it really sam causing these problems? Should I change the parameter without using sam and if so, how?

Any and all help greatly appreciated!

Kurt

[James R. Ferguson]

Kurt:

PHCO_21187 is a SAM cumulative patch. You didn't mention patch PHKL_19169 (Correct VxFS process hangs). The patch database indicates that this is required by PHKL_18543. Do you have this one too?

In general, SAM is the preferred way of generating a new kernel. SAM "knows" of the valid ranges of the various parameters and protects one from generating an unusable kernel.

You indicate that the Support Center's recommendation didn't resolve your problem. YOU SHOULD CERTAINLY RE-OPEN YOUR CALL WITH THEM. Good Luck.

...JRF...

[Andy Monks]

If you didn't load the sam patch, it's going to be that. The patch PHKL_18543 did away with a driver called 'pa'. However, unless you loaded the latest sam patchm it still thinks it should be there. So, when it finds you that you don't want to use the 'pa' driver, it therefore assumes, that you won't want any of the child drivers. Things like, disc, tape, lan (so nothing important :-) )

The RC should have got this. Btw, the panic message should be 'VFS_MOUNTROOT: need drivers' if you saw it in time.

[CHRIS_ANORUO]

Hi Hurt,

Before you reduce the value of dbc_max_pct, use this line command to check the value of bufpages (echo "bufpages/D" |adb /stand/vmunix /dev/mem) or use sysdef.
Set nbuf and bufpages to zero from kernel parameter configurations, and swapmem_on=1.

[James R. Ferguson]

Kurt:

To make sure everything went as the Support Center expected, make sure the patches were actually configured:

# swlist -l fileset -a state|more

Make sure the state is "configured", not just "installed". Use swconfig if/as necessary.

...JRF...

[Rita C Workman]

Kurt,
I ran into something similar. Had a terrible time with this. Worked with HP Tech Support on it, and found it appeared to be a patch (PHKL_18543) that had overwritten the objects of some 34 other patches. By doing a check_patches and letting HP review the output, this is how what had been overwritten was identified. There was something written on this problem involving PHKL_18543, but I couldn't find the paper.
It seems there is a known problem with patch PHKL_18543 (which you also had loaded).
As far as diagnosing the error.... in my case, it was a matter of chipping away the layers to discover the problem. I do wish I had run the check_patches sooner though.
Below is the url ... at the bottom is where I noted the resolution.
http://my1.itrc.hp.com/cm/QuestionAnswer/1,1150,0xaa3249c5ae73d4118fef0090279cd0f9,00.html
Regards,

[KURT HARLESS]

Wow... Thanks everyone... Have several follow-up questions;

To: James R. Ferguson
1) All patches installed display configured
2) No I did not install PHKL_19169, which looks like it has been replaced by PHKL_21392. It seems like the patch PHCO_17058, which has been replaced by patch PHCO_21187, was a perfect match for my error, e.g. "...VFS_MOUNTROOT: need drivers"
Any comments or direction?

To: Andy Monks
1) I did load PHCO_21187, is this the "sam patch" you are speaking about?

To: Chris Anoruo
1) Issued your suggested command;
echo "bufpages/D" |adb /stand/vmunix /dev/mem
Error from elf64_getehdr(application core file)
Not an Elf file: No Elf header
bufpages:
bufpages: 104856
Not sure what this error message is;
Current configurable parm values are:
NBUF=0
BUFPAGES=NBUF*2 = 0
SWAPMEM_ON=1

To: Rita C Workman
1) Where do you find check_patches?

Again thanks to everyone, I will apply points
once my issue has been resolved.

Updated note: I was able to make the DBC_MAX_PCT change using the KMTUNE utility and manually rebuilding my kernel successfully, so this is definately a SAM issue.

[Rita C Workman]

I'm not sure if it is an HPUX 11.0 utility or if it comes with Ignite-UX.
The utility creates a report and puts the output to /tmp/check_patches.report.
This file is what I sent to HP Support for their analysis.

Regards,

[James R. Ferguson]

Kurt:

Hi! Yes, I see the same thing: PHKL_21392 superceds PHKL_19169 as clearly stated in the patch text for PHKL_21392. I also agree that PHCO_21187 includes PHCO_17058 fixes. Interestingly, your original post said PHKL_17038, not PHCO_17058 (a typo?).

I would go with the more recent patches as you have indicated. Hope this gets your problem resolved. If not, we're all happy to help some more!

...JRF...