HPE 9000 and HPE e3000 Servers
1752794 Members
6612 Online
108789 Solutions
New Discussion юеВ

Processor timeout in incoming GSP log, normal or not?

 
SOLVED
Go to solution

Processor timeout in incoming GSP log, normal or not?

Hi there.

I'm getting lots of logs in the GSP Incoming log like the ones below (nothing is in the Error log). I noticed the logs when looking at a N4000 machine where it was acting strangely and became very slow although no reason could be found from the OS.

Is this logging normal or could it point to failing hardware? On another N4000 machine I don't see these incoming logs.

Notice that the "PROBLEM DETAIL" varies between "timeout" and "no problem detail". Could this be a failing CPU?

Log Entry # 0 :
SYSTEM NAME: vofacon
DATE: 01/08/2004 TIME: 15:15:46
ALERT LEVEL: 0 = No failure detected, forward progress

SOURCE: 1 = processor
SOURCE DETAIL: 1 = processor general SOURCE ID: 0
PROBLEM DETAIL: 4 = timeout

CALLER ACTIVITY: F = display_activity() update STATUS: 0
CALLER SUBACTIVITY: 00 = implementation dependent
REPORTING ENTITY TYPE: E = HP-UX REPORTING ENTITY ID: 00

0x78E008041100F000 00000002 00000004 type 15 = Activity Level/Timeout
0x58E008041100F000 00006800 080F0F2E type 11 = Timestamp 01/08/2004 15:15:46
Type CR for next entry, Q CR to escape.



Log Entry # 1 :
SYSTEM NAME: vofacon
DATE: 01/08/2004 TIME: 15:15:46
ALERT LEVEL: 0 = No failure detected, forward progress

SOURCE: 1 = processor
SOURCE DETAIL: 1 = processor general SOURCE ID: 0
PROBLEM DETAIL: 0 = no problem detail

CALLER ACTIVITY: F = display_activity() update STATUS: F
CALLER SUBACTIVITY: 48 = implementation dependent
REPORTING ENTITY TYPE: E = HP-UX REPORTING ENTITY ID: 03

0xF8E038001100F48F 00000000 0000F48F type 31 = legacy PA HEX chassis-code
0x58E038001100F48F 00006800 080F0F2E type 11 = Timestamp 01/08/2004 15:15:46
Type CR for next entry, - CR for previous entry, Q CR to escape.



Log Entry # 2 :
SYSTEM NAME: vofacon
DATE: 01/08/2004 TIME: 15:15:41
ALERT LEVEL: 0 = No failure detected, forward progress

SOURCE: 1 = processor
SOURCE DETAIL: 1 = processor general SOURCE ID: 0
PROBLEM DETAIL: 4 = timeout

CALLER ACTIVITY: F = display_activity() update STATUS: 0
CALLER SUBACTIVITY: 00 = implementation dependent
REPORTING ENTITY TYPE: E = HP-UX REPORTING ENTITY ID: 00

0x78E008041100F000 00000002 00000004 type 15 = Activity Level/Timeout
0x58E008041100F000 00006800 080F0F29 type 11 = Timestamp 01/08/2004 15:15:41
Type CR for next entry, - CR for previous entry, Q CR to escape.



Log Entry # 3 :
SYSTEM NAME: vofacon
DATE: 01/08/2004 TIME: 15:15:41
ALERT LEVEL: 0 = No failure detected, forward progress

SOURCE: 1 = processor
SOURCE DETAIL: 1 = processor general SOURCE ID: 0
PROBLEM DETAIL: 0 = no problem detail

CALLER ACTIVITY: F = display_activity() update STATUS: F
CALLER SUBACTIVITY: 48 = implementation dependent
REPORTING ENTITY TYPE: E = HP-UX REPORTING ENTITY ID: 04

0xF8E048001100F48F 00000000 0000F48F type 31 = legacy PA HEX chassis-code
0x58E048001100F48F 00006800 080F0F29 type 11 = Timestamp 01/08/2004 15:15:41
Type CR for next entry, - CR for previous entry, Q CR to escape.
2 REPLIES 2
Todd McDaniel_1
Honored Contributor

Re: Processor timeout in incoming GSP log, normal or not?

I think the key is your ALERT LEVEL:0. It shows no alert.

I tried to do a google search to find a similar error, but found nothing relevant.

I think checking cstm will show you error messages for cpu. I would check there as well.


Unix, the other white meat.
Stefan Stechemesser
Honored Contributor
Solution

Re: Processor timeout in incoming GSP log, normal or not?

Hi Ingimar,

the OS updates the Front Panel of HP9000 Servers with Chassis codes in regular intervals. Because the N4000 has no LCD front panel, the display of the Chassis codes is done via the "Virtual Front Panel" which is accessible via the GSP "vfp" command. The chassis code updated is done via the Alert Level 0 events you have seen.├В┬┤
The "Reporting Entity Type" is HP-UX => The operating System. I don't know why the Firmware creators decided to implement these timeout Events, but it is normal. If the OS is not running, you will only see the timeout Events. If the OS is running, you see additionally the "no problem detail" entries. You can see the HPUX Chassis code in the first of the two lines with HEX numbers ("legacy PA HEX chassis code"). The Chassis code that was displayed on the LCD panel of the older K- or D-Class Servers are the last 4 digits of this HEX line. In your case it is "F48F". This means HPUX is running (first digit F) with 4 processors (2nd digit 4) and a load level of "8" (3rd digit) which is afairly high load level. I think your machine is slowly because the machine is either overloaded by too much processes or overloaded by too much I/O (maybe due to an I/O problem). The above chassis codes does not help you in finding the root cause of the bad performance. Check with top/glance/syslog/diagnostics for the real problem cause. The GSP will not help you in this case.

Best regards

Stef