UNCLAIMED PCI BaseSystem

[Gabriel Muñoz_1]

We have a cluster with two L1000 nodes, and the node A has a unclaimed device:

unknown -1 0/0/4/0 UNCLAIMED UNKNOWN PCI BaseSystem (103c10ed)
tty 0 0/0/4/1 asio0 CLAIMED INTERFACE PCI Serial (103c1048)
/dev/GSPdiag1 /dev/mux0 /dev/tty0p1 /dev/tty0p4
/dev/diag/mux0 /dev/tty0p0 /dev/tty0p2
ba 1 0/1 lba CLAIMED BUS_NEXUS Local PCI Bus Adapter (782)

The node B has the same device claimed:

tty 0 0/0/4/0 asio0 CLAIMED INTERFACE PCI Serial (103c1048)
/dev/GSPdiag1 /dev/mux0 /dev/tty0p1 /dev/tty0p4
/dev/diag/mux0 /dev/tty0p0 /dev/tty0p2
tty 1 0/0/5/0 asio0 CLAIMED INTERFACE PCI Serial (103c1048)

Could anyone tell me how to solve it?

[Steve Steel]

Hi

The driver for the first port is unknown. To change the driver from unknown will require new GSP firmware and a patch to the O/S.


You should have your firmware checked

The patch is

Patch Name: PHNE_25603

Patch Description: s700_800 11.00 Cumulative Mux and Pty Patch

Creation Date: 01/11/30

Post Date: 01/12/11

Hardware Platforms - OS Releases:
s700: 11.00
s800: 11.00

Products: N/A

Filesets:
OS-Core.CORE2-KRN,fr=B.11.00,fa=HP-UX_B.11.00_32,v=HP
OS-Core.CORE2-KRN,fr=B.11.00,fa=HP-UX_B.11.00_64,v=HP

Automatic Reboot?: Yes

Status: General Release

Critical:
No (superseded patches were critical)
PHNE_25346: HANG
PHNE_21257: HANG
PHNE_20431: PANIC
PHNE_13801: HANG PANIC

Category Tags:
defect_repair hardware_enablement enhancement
general_release critical panic halts_system

Path Name: /hp-ux_patches/s700_800/11.X/PHNE_25603

Symptoms:
PHNE_25603:
"ioscan -f" reports UNCLAIMED for the "S/W State" field and
UNKNOWN for the "H/W Type" field.
For example: # ioscan -fnC tty
Class I H/W Path Drvr S/W State H/W Type Description
==========================================================
unknown -1 0/0/4/0 UNCLAIMED UNKNOWN PCIBaseSystem(103c128d)
tty 0 0/0/4/1 asio0 CLAIMED INTERFACE PCI Serial(103c1048)


Steve Steel

[Steve Steel]

Hi

Equivalnet 11.11 patch

Patch Name: PHNE_23594

Patch Description: s700_800 11.11 Cumulative Mux and Pty Patch

Creation Date: 01/09/18

Post Date: 01/11/05

Hardware Platforms - OS Releases:
s700: 11.11
s800: 11.11


Note

Only to fix the ioscan display about 0/0/4/0 "unknown""unclamed"
isn't it?

Yes this patch is only to fix the "unknown""unclamed" error
only.

The port 0/0/4/1 is useful. It's mean that new core I/O alter the
useful port from 0/0/4/0 to 0/0/4/1.



steve Steel

[Gabriel Muñoz_1]

This patch not solved my problem. The driver continues umclaimed.

[Sanjay_6]

Hi Gabriel,

Can you attach the ioscan output from both the servers for us to look at. Also what is the model / OS version of the servers.

Thanks

[Gabriel Muñoz_1]

Node A:

HP-UX: 11.11
GSP: Hardware Revision L5 Firmware Revision B.02.04 Jun 26 2001

Node B:

HP-UX: 11.11
GSP Hardware Revision 8 Firmware Revision A.01.09 Mar 20 2000

In Node A is where appears the "unclamed device" message. Node B is OK.

[Patrick Wessel]

Gabriel,
You included the solution in your last response. The GSPs of you L-Class server are different. The unclaimed device is nothing to worry, but as Steve already wrote, a patch and the right PDC version of the server will fix this. You installed the Patch but the device is unclaimed. What does it tells you? Right, the PDC of your L1000 doesn't handle this device in a way that it is shown in the ioscan in the appropriate way. But, the 'right' PDC isn't released yet.
You shouldn't worry about the unclaimed device. It does not influence the functionality of your server.

[Steve Steel]

Hi

Then it is firmware.SEE BELOW

New Revision B GSP firmware has been released for L and N-Class Servers that provides the following features, fixes and enhancements. The revision number for the new firmware is B.02.07.

- Added a forward progress indicator to the XU command and an option to abort update.

- On older firmware a CTRL-B was ignored on the Web Console after the enter key was pressed. Firmware B.02.07 corrects this issue.

- Added ???HELP??? and ??????? as aliases for the HE command.

- A 2 part problem exists where an unused port on the GSP shows up as UNKNOWN and UNCLAIMED in an ioscan. Firmware B.02.07 corrects the first part of the problem and the following HPUX patches correct the second half.

PHNE_23593 for HPUX 11.00

PHNE_23594 for HPUX 11.11

- Previous versions of firmware lost characters during read functions when running MPE NMMGR. Firmware B.02.07 corrects this problem.

- Added the ???EX??? command to exit out of the GSP.

- Earlier revisions of firmware do not send a ???break??? signal to the operating system, revision B.02.07 corrects this problem.


There are several methods available to install the firmware. The documentation below contains thesimplest.

Using the external HP FTP site





GSP firmware can be found at http://192.151.11.37 or ftp://docs.hp.com/dist/gspfirmware-A6696B via anonymous ftp.


The GSP (Guardian Service Processor) upgrade process assumes that the LAN of the GSP is operational. That is, the Network parameters were set up properly using the LC command in the GSP handler and that the GSP LAN can access the ftp server where the upgrade files reside. The upgrade process uses ftp to fetch the code from any server you choose. An upgrade file set consists of 3 files: B0207.bin, Resources.out and gsp_upg.cnf. They must be consistent with each other. Consistency means that the file sizes listed in gsp_upg.cnf are the actual sizes of the B0207.bin and Resources.out files. No consistency check is made between the files at this date.

The only supported method of upgrading the firmware is to obtain the files directly from the FTP server at HP. It is also the safest to use.

The upgrade is accomplished via the GSP's XU command. The XU command can be executed from any port local, remote, or LAN. The XU command will prompt for the IP address of the server containing the upgrade file set, the full path to those files and the login and password for that server. A default anonymous login is provided. The GSP will reset after a successful completion of the upgrade.


If the GSP returns to the GSP prompt, the upgrade did not complete. This may be because some of the information provided was incorrect or that the GSP LAN is not configured properly. Check all parameters and try the XU command again.




To verify the GSP firmware revision, access the GSP and type the HE command. The first sentence gives the revision and date of the firmware. If you don't know the revision of the files you've downloaded from this server, the APPLICATION.ROM has a 'what' string which is identical to the one displayed by the HE command.

Steve Steel

[Gabriel Muñoz]

The EMS system frequently send a message to server showing next text:

>------------ Event Monitoring Service Event Notification ------------<

Notification Time: Tue Jan 8 19:50:44 2002

Node A sent Event Monitor notification information:

/system/events/core_hw/core_hw is >= 3.
Its current value is SERIOUS(4).

Event data from monitor:

Event Time..........: Tue Jan 8 19:50:44 2002
Severity............: SERIOUS
Monitor.............: dm_core_hw
Event #.............: 32
System..............: Node A

Summary:
Service processor not responding


Description of Error:

The operating system is unable to communicate with the service processor.

Probable Cause / Recommended Action:

The support bus which connects the system processors, the service
processor and the Power Monitor or Platform Monitor may have become hung.
(The support bus can be tested by issuing the service processor command
"XD", and selecting the I2C access test).
To reset the bus, issue the service processor command "XD" and then
select "R", use the HP-UX command `stty +resetGSP press the service processor reset button. If this solves the problem
(if the I2C access test now works) and the system is an N-Class,
rp7400, L-Class, rp5400, rp5430, rp5450 or rp5470, check the service
processor firmware revision using the service processor command "HE".
If the service processor firmware version is less than A.01.09,
schedule an update of the service processor firmware to version
A.01.09 or a more recent version to prevent a reoccurrence of this
problem.

There could be a problem with the service processor.
Verify that the service processor appears to be operating normally.
This can be done by typing a B at the console and verifying
that the service processor responds to commands. If the service
processor has failed, contact your HP support representative to check
the core I/O board.

There could be a problem with the system board.
Contact your HP support representative to check the system board if
necessary.

Additional Event Data:
System IP Address...: XXX.XXX.XXX.XX
Event Id............: 0x3c3b3f8400000000
Monitor Version.....: B.01.00
Event Class.........: System
Client Configuration File...........:
/var/stm/config/tools/monitor/default_dm_core_hw.clcfg
Client Configuration File Version...: A.01.00
Qualification criteria met.
Number of events..: 1
Associated OS error log entry id(s):
0x3c3b3ea600000000
Additional System Data:
System Model Number.............: 9000/800/L1000-44
EMS Version.....................: A.03.20
STM Version.....................: A.28.00
Latest information on this event:
http://docs.hp.com/hpux/content/hardware/ems/dm_core_hw.htm#32

v-v-v-v-v-v-v-v-v-v-v-v-v D E T A I L S v-v-v-v-v-v-v-v-v-v-v-v-v


FRU Physical Location: 0xffffffffffffff00
FRU Source = 0 (unknown, no source stated)
Source Detail = 0 (unknown, no source stated)
Cannot decode any remaining physical location data.


>---------- End Event Monitoring Service Event Notification ----------<

I thing this message is due to unclaimed device, because the Node B not receive any message as this. If this message not has any relation with unclaimed device, why is send this message?