diagipmid -- process takes up 1 CPU -- how to not start?

[Tin Che Ko]

Hi,

Recently I upgraded STM version to 11.B.11.11.14.15 and I noticed that diagipmid process takes up whole CPU.
Is there any way not to start this process when the server reboots?

I looked in the configuration files but no indication about this process.
Please advice.

Thanks,

Raj

[RAC_1]

You can stop whole of the stm.
/sbin/init.d/diagnostics stop

Now check what might be causing it. Start with all stm/ems patches.

Anil

[Tin Che Ko]

I do not want to stop all of the STM processes ..just the diagipmid process.
Also, all I have installed is just the product but no patches -- are there any new patches out for "Sup-Tool-Mgr B.11.11.14.15 Support Tools Manager for HPUX systems"??
If so how do you find out and where to look.

Thanks for your reply.


-Raj

[Andrew Merritt_2]

Hi Raj,
Does the diagipmid run forever, or just for a while following reboot?

The problem has been seen on some systems where the /dev/ipmi device file exists, but ipmi is not configured in the kernel. (This can happen if Ignite is used, for example.) The fix would be to either install the ipmi module in the kernel, if required, or remove the device file.

There is also a performance issue on cellular systems, whereby diagipmid can take a long time at start-up time, particularly when there are many vPars on an nPar. This will be addressed in future releases of the OnlineDiags (starting with the 11.23 HWE0505 release which has just become available).

To answer your other question, the latest patch for HWE0406 OnlineDiags which you have is PHSS_31986.

Andrew

[Tin Che Ko]

Hi Andrew,

I installed the patch you mentioned but now the
diagipmid process does not even come up.. strange..

I have a few questions:
1 - How to install the ipmi module in the kernel? When i do strings /stand/vmunix i see ipmi listed
2 - How to remove the device file?
Just rm /dev/ipmi? Is it safe to remove the device file?

Please advice

Thanks

Raj

[Andrew Merritt_2]

Well, the diagipmid process is just gathering data, and should exit once it's done this.

Sounds like your system may have been one affected by the problem described, and it may not even be being run on your system following the change. Doesn't sound like there's anything else you need to do.

Andrew

[Andrew Merritt_2]

Oops, that patch doesn't fix the problem, it will be fixed in future, sorry, ignore that response.

How often do you see the problem, is it only once, or every time you restart?

It will be easier to give recommendations on /dev/ipmi etc. if you can give details of the system type and CPUs installed.

Andrew

[Tin Che Ko]

Andrew,
Below is the info you requested.

As I understand from your reply that this process diagipmid starts up to collect data and onces finished it terminates itself?

Also, the patch does not fix CPU utilization?
Has HP come out with a fix yet?

Please let me know if you need more info.

Thanks,

Raj



--------------------------------
Model 9000/800/rp3410
Processor Speed: 799
CPU Version 532
----------------------------------
# strings /stand/vmunix |grep -i ipmi
ipmi
ipmi_psm
ipmi
ipmi_psm
------------------------------------------
# ll /dev/ipmi
crw------- 1 root root 95 0x000000 May 19 23:10 /dev/ipmi
-------------------------------------
In SAM--Drivers:
â ipmi In In Driver Static N/A
â ipmi_psm In In Driver Static

[Andrew Merritt_2]

Ok, the rp3410 has the new PA8800 chips, which do have the IPMI interface, so diagipmid should be running on that system. Also, you appear to have ipmi in the kernel, and /dev/ipmi exists.

So, that rules out the problem seen when diagipmid runs on non-IPMI hardware.

Yes, as I said earlier, the fix is not yet available for the performance problem.

The latest patch, PHSS_31986, doesn't have an explicit fix for what you are seeing, as I don't think that problem has been reported, if it's not a performance problem (I don't think you get many vPars on an rp3410!). However, the patch does have a couple of changes to the ipmi access library, which might have an effect.

All I can suggest is to see what happens the next time you reboot. If the problem returns, open a support call with HP.

Andrew

[Tin Che Ko]

One more question

Does this process terminate itself once it collects the data or it should be running all the time?

Thanks

Raj