Hi all.
I'm a Japanese OSS programmer.
On Wed, 16 Jan 2008 16:47:06 +0100
"Peter Pothier" <[EMAIL PROTECTED]> wrote:
> Using OpenHPI 2.10.1, AMC cards appear to be non-hotswap-able.
> #1868725 AMC not recognized if inserted after Discovery
> #1794820 Inventory RDRs no longer visible after Hotswap AMC
I'm now investigating this issue, and I have some questions about it.
When I lanuch an openhpid without AMC, I can fetch RDR entries by hpitop
like this (it is a little different from the latest version because my
customer uses openhpi-2.6):
{SYSTEM_CHASSIS,7}
+--- {SYSTEM_CHASSIS,7}{PHYSICAL_SLOT,10}{160,0}
| |__ Sensor Num: 0, Type: OEM_SENSOR, Category: SENSOR_SPECIFIC, Tag:
Hot Swap
| |__ ....
| |__ Sensor Num: 1, Type: OEM_SENSOR, Category: SENSOR_SPECIFIC, Tag:
B1 Hot Swap
| |__ Sensor Num: 2, Type: OEM_SENSOR, Category: SENSOR_SPECIFIC, Tag:
B2 Hot Swap
| |__ Sensor Num: 3, Type: OEM_SENSOR, Category: SENSOR_SPECIFIC, Tag:
B3 Hot Swap
| |__ Sensor Num: 4, Type: OEM_SENSOR, Category: SENSOR_SPECIFIC, Tag:
B4 Hot Swap
| |__ ....
On the other hand, when I lanuch openhpid with an AMC, I can get it
like this:
{SYSTEM_CHASSIS,7}
+--- {SYSTEM_CHASSIS,7}{PHYSICAL_SLOT,10}{160,0}
| |__ Sensor Num: 0, Type: OEM_SENSOR, Category: SENSOR_SPECIFIC, Tag:
Hot Swap
| |__ ....
| |__ Sensor Num: 1, Type: OEM_SENSOR, Category: SENSOR_SPECIFIC, Tag:
B1 Hot Swap
| |__ Sensor Num: 2, Type:OEM_SENSOR, Category: SENSOR_SPECIFIC, Tag:
B2 Hot Swap
| |__ Sensor Num: 3, Type: OEM_SENSOR, Category: SENSOR_SPECIFIC, Tag:
B3 Hot Swap
| |__....
|
+--- {SYSTEM_CHASSIS,7}{PHYSICAL_SLOT,10}{193,8}
| |__ Sensor Num: 4, Type: OEM_SENSOR, Category: SENSOR_SPECIFIC, Tag:
B4 Hot Swap
| |__ Sensor Num: 20, Type: CURRENT, Category: THRESHOLD, Tag: B4 +12V
Curr
| |__ ...
Where, you should notice that a location of a hotswap sensor is
different between in these two cases. A hotswap sensor is moved from
carrier board to AMC! But both entries points a same physical sensor
(The sensor is implemented on the carrier board). Some other sensors
are also moved from the carrier board to the AMC. It's too strange.
I read the source code of the ipmidirect plugin and I found an answer
for this issue. When the ipmidirect find a sensor without a parent FRU,
the sensor is judged as grand parent's sensor at
cIpmiSdrs::FindParentFru(). According to my ipmidirect's log, such
sensors are always reported as AMC's sensor by ShMM, but are registered
as carrier board's sensor by above code when no AMC card exists:
2008.03.03 14:16:52.285 Entity ID 193, Instance 101 is not a FRU
2008.03.03 14:16:52.285 Entity ID 193, Instance 101 parent ID 160, Instance 96
2008.03.03 14:16:52.285 FindResource mc 144 FRU 0 type 160 instance 96
2008.03.03 14:16:52.285 Looking for resource:
{SYSTEM_CHASSIS,7}{PHYSICAL_SLOT,10}{160,0}.
2008.03.03 14:16:52.285 adding rdr:
{SYSTEM_CHASSIS,7}{PHYSICAL_SLOT,10}{160,0}{193,5} 1 B1 Hot Swap
2008.03.03 14:16:52.285 WARNING: found a second hotswap sensor, discard it !
Now I have a question:
* Where shoud such sensors be mapped to by the HPI specification?
I read the HPI-to-AdvancedTCA Mapping Specification and I found a hint
for this issue. According to this spec, some "slot resources" shoule
exist in addition to some "FRU resources", like this:
{ROOT, 0}
├ {PHYSICAL_SLOT, x}
├ {PHYSICAL_SLOT, x}{PICMG_SUBBOARD_CARRIER_BLADE, y}
├ {PHYSICAL_SLOT, x}{PICMG_SUBBOARD_CARRIER_BLADE, y}{AMC_SLOT, z}
├ {PHYSICAL_SLOT, x}{PICMG_SUBBOARD_CARRIER_BLADE, y}{AMC_SLOT, z}{AMC, 1}
I think such sensors should be mapped to such "slot resources".
But there are no "slot resources" in the current ipmidirect
implementation:
{ROOT, 0}
├ {PHYSICAL_SLOT, x}{PICMG_SUBBOARD_CARRIER_BLADE, y}
├ {PHYSICAL_SLOT, x}{AMC, 1}
My understanding is correct?
If it is correct, is it openhpi's problem? or hardware's problem?
If it isn't, how should we treat such sensors?
I'm now writing a work arround patch. In this patch, I always treat such
sensors as AMC's sensor, and don't show such sensors when the AMC
doesn't exist. I don't craete "slot resources" in this patch because
I'm not sure about it and it is too heavy to implement for me.
Could you please advise to me?
Regards,
--
Takuro Ashie <[EMAIL PROTECTED]>
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Openhpi-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/openhpi-devel
