Hi, Sorry for the delay in replying, I was in vacation last week. See my answers below.
Pierre > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:openhpi-devel- > [EMAIL PROTECTED] On Behalf Of Takuro Ashie > Sent: Monday, March 03, 2008 12:13 > To: [email protected] > Subject: Re: [Openhpi-devel] AMC Not Hotswap-able > > 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. Which sensors other that the hotswap ones move from carrier board to the AMC? Could you send me the plugin log file for both runs described above? Also, which version of OpenHPI are you using? > > 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. Please note that ipmidirect plugin does not implement HPI-to-AdvancedTCA Mapping. > 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? > Slot resources "contain" only a limited amount of sensors and controls that are all listed in the mapping specification. Hotswap sensors are not part of them. My understanding of the HPI-to-ATCA mapping specification is that hotswap sensors should not be exposed through HPI. Since ipmidirect does not implement this mapping, that's the reason why they are exposed. > 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. With the logs I asked for above I should be able to write a simple patch. > > 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 ------------------------------------------------------------------------- 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
