Hi Pierre,
I did some more testings on what Stefan started and found
following:
the uTCA system I am using includes following components:
FRU Device State Name
==========================================
4 mcmc2 M4 NAT-MCH-MCMC
6 AMC2 M4 NAMC-8560-8E1
40 CU1 M4 Schroff uTCA CU
41 CU2 M4 Schroff uTCA CU
51 PM2 M4 PM DC600W -48V
==========================================
When I startup the daemon some IPMI messages fail:
ERR - GET_ADDRESS_INFO: FRU 5 not init
ERR - GET_ADDRESS_INFO: FRU 3 not init
ERR - GET_ADDRESS_INFO: FRU 50 not init
hpitop only displays the cooling units and the related sensors
and controls:
hpitop ver 0.2 HPI-B
Hpi Version 131585 Implemented.
{SYSTEM_CHASSIS,7}
|
+--- {SYSTEM_CHASSIS,7}{SHELF_MANAGER,0}{SWITCH_BLADE,0}
|
+--- {SYSTEM_CHASSIS,7}{SYS_MGMNT_MODULE,170}{COOLING_UNIT,2}
| |__ Sensor Num: 0, Type: OEM_SENSOR, Category: SENSOR_SPECIFIC, Tag:
Hot Swap
...
| |__ Control Num: 5120, Type: ANALOG, Output Type: FAN_SPEED, Tag: Fan
Control
| |__ Inventory Idr Num: 0, Num Areas: 3, Tag: Schroff uTCA CU
|
+--- {SYSTEM_CHASSIS,7}{SYS_MGMNT_MODULE,168}{COOLING_UNIT,1}
| |__ Sensor Num: 0, Type: OEM_SENSOR, Category: SENSOR_SPECIFIC, Tag:
Hot Swap
...
| |__ Control Num: 5120, Type: ANALOG, Output Type: FAN_SPEED, Tag:
Fan
Control
| |__ Inventory Idr Num: 0, Num Areas: 3, Tag: Schroff uTCA CU
|
End of {SYSTEM_CHASSIS,7}
So what I suspect now is that the daemon starts scanning for FRUs
(starting with FRU 3 for the MCMC, with FRU 5 for AMCs and with
FRU 50 for PMs) and if the first round in the loop fails it does
not search for further FRU devices of the same type. This would
explain why only the CUs are displayed correctly: two CUs (i.e.
all valid CU FRU values) are mounted in the uTCA system, but not
all MCHs, PMs and AMCs are mounted (at least not in the order OpenHPI
expects them).
I remember that I already did a fix for this problem for OpenHPI
V2.7.3 (which we are currently using and which displays all found
resources) but unfortunately I did not deliver a patch for this
problem ... I will check if I can fix this in 2.10.0 too ...
Regards,
Christof
Pierre Sangouard wrote:
> Hi Stefan,
>
>> I did as you told me:
>>
>>> Please try this patch on 2.10.0 and let me know how it goes (log file
>>> appreciated in any case).
>> Result: unchanged behaviour, hpitop output is this:
>>
>> hpitop ver 0.2 HPI-B
>> Hpi Version 131585 Implemented.
>>
>>
>> {SYSTEM_CHASSIS,7}
>> |
>> +--- {SYSTEM_CHASSIS,7}{SHELF_MANAGER,0}{SWITCH_BLADE,0}
>> | |__ Control Num: 5120, Type: ANALOG, Output Type: FAN_SPEED,
>> Tag: Fan Control
>> |
>> End of {SYSTEM_CHASSIS,7}
>>
>> I attached the session logfile - maybe you can see what is going
>> wrong.
>
> Your Shelf Manager does not meet the following requirements from MicroTCA
> 1.0 specification: 3.466, 3.194 & 3.195.
>
>> BTW: We decided to continue using openhpi-2.7.3-nat for our stuff
>> here. No need to panic.
>>
>
> Well I am not panicking since the ball does not seem to be in my camp...
>
> Regards,
> Pierre
>
>
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems? Stop.
> Now Search log events and configuration files using AJAX and a browser.
> Download your FREE copy of Splunk now >> http://get.splunk.com/
> _______________________________________________
> Openhpi-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/openhpi-devel
-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
Openhpi-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/openhpi-devel
