Re: [Freeipmi-users] FW: ipmi_sdr_cache_iterate: error returned in callback
Hi Michael, Glad it worked. I'll add a todo to add this workaround sometime in the future. Al On Mon, 2020-08-31 at 14:12 +, FRANK Michael wrote: > Hi Al, > > Thank you very much for your support. > We did a hard reset of the controller and now everything is OK. > Next time I will ask my customer to do this first to avoid > unnecessary mails. > Sometimes this is a little bit hard for operational servers. > > Regards > > Michael > > -Original Message- > From: Al Chu > Sent: Wednesday, August 26, 2020 7:03 PM > To: FRANK Michael ; > freeipmi-users@gnu.org > Subject: Re: [Freeipmi-users] FW: ipmi_sdr_cache_iterate: error > returned in callback > > Hi Michael, > > This is a bit of a puzzler. The IPMI spec has no definition for this > error code for the "Get FRU Inventory Area Info" command. > > > 10.100.212.11: IPMI Command Data: > > 10.100.212.11: -- > > 10.100.212.11: [ 10h] = cmd[ 8b] > > 10.100.212.11: [ 81h] = comp_code[ 8b] > > Similar FRU commands treat 0x81 as "busy" errors. > > > FRU device busy. The requested cannot be completed because the > implementation of the logical FRU device is in a state where the FRU > information is temporarily unavailable. This could be due to a > condition such as a loss of arbitration if the FRU is implemented as > a device on a shared bus." > > > So I am just guessing that's what the vendor meant with the 0x81 > completion code. > > I'm just taking a guess, but maybe some device in the system is > legitimately stuck sensor wise. If possible, a hard power reset > could fix (i.e. pulling the plug optimally, but remote power control > hard reset if you can't do that)? > > If not, we'll have to add a workaround in the code to handle this > case and just say the FRU information isn't available for this > device. > > Al > > On Thu, 2020-08-20 at 09:54 +, FRANK Michael wrote: > > Hello, > > > > Trust everybody is OK and like to say thank you for this very good > > software. It helps us every day to prevent hardware outages. > > > > I have the error "ipmi_sdr_cache_iterate: error returned in > > callback" > > on a Lenovo x3650 M5 Server HW rev 9. Other M5s working well. > > > > The last section in debug before closing the session is below. > > This > > has no meaning for me, and any help is much appreciated. > > > > 10.100.212.11: > > = > > 10.100.212.11: IPMI 2.0 Get FRU Inventory Area Info Response > > 10.100.212.11: > > = > > 10.100.212.11: RMCP Header: > > 10.100.212.11: > > 10.100.212.11: [ 6h] = version[ 8b] > > 10.100.212.11: [ 0h] = reserved[ 8b] > > 10.100.212.11: [ FFh] = sequence_number[ 8b] > > 10.100.212.11: [ 7h] = message_class.class[ 5b] > > 10.100.212.11: [ 0h] = message_class.reserved[ 2b] > > 10.100.212.11: [ 0h] = message_class.ack[ 1b] > > 10.100.212.11: IPMI RMCPPLUS Session Header: > > 10.100.212.11: - > > 10.100.212.11: [ 6h] = authentication_type[ 4b] > > 10.100.212.11: [ 0h] = reserved1[ 4b] > > 10.100.212.11: [ 0h] = payload_type[ 6b] > > 10.100.212.11: [ 1h] = payload_type.authenticated[ > > 1b] > > 10.100.212.11: [ 1h] = payload_type.encrypted[ 1b] > > 10.100.212.11: [638898C2h] = session_id[32b] > > 10.100.212.11: [ B1h] = session_sequence_number[32b] > > 10.100.212.11: [ 20h] = ipmi_payload_len[16b] > > 10.100.212.11: IPMI RMCPPLUS Payload: > > 10.100.212.11: -- > > 10.100.212.11: [ BYTE ARRAY ... ] = confidentiality_header[16B] > > 10.100.212.11: [ 38h 2Dh E7h A8h 52h 65h 91h 6Fh ] > > 10.100.212.11: [ FCh A8h 2Bh CDh DBh B9h E2h 19h ] > > 10.100.212.11: [ BYTE ARRAY ... ] = payload_data[ 8B] > > 10.100.212.11: [ 81h 2Ch 53h 20h 84h 10h 81h CBh ] > > 10.100.212.11: [ 707060504030201h] = confidentiality_trailer[64b] > > 10.100.212.11: IPMI Message Header: > > 10.100.212.11: > > 10.100.212.11: [ 81h] = rq_addr[ 8b] > > 10.100.212.11: [ 0h] = rq_lun[ 2b] > > 10.100.212.11: [ Bh] = net_fn[ 6b] > > 10.100.212.11: [ 53h] = checksum1[ 8b] > > 10.100.212.11: [ 20h] = rs_addr[ 8b] > > 10.100.212.11
Re: [Freeipmi-users] FW: ipmi_sdr_cache_iterate: error returned in callback
Hi Michael, This is a bit of a puzzler. The IPMI spec has no definition for this error code for the "Get FRU Inventory Area Info" command. > 10.100.212.11: IPMI Command Data: > 10.100.212.11: -- > 10.100.212.11: [ 10h] = cmd[ 8b] > 10.100.212.11: [ 81h] = comp_code[ 8b] Similar FRU commands treat 0x81 as "busy" errors. FRU device busy. The requested cannot be completed because the implementation of the logical FRU device is in a state where the FRU information is temporarily unavailable. This could be due to a condition such as a loss of arbitration if the FRU is implemented as a device on a shared bus." So I am just guessing that's what the vendor meant with the 0x81 completion code. I'm just taking a guess, but maybe some device in the system is legitimately stuck sensor wise. If possible, a hard power reset could fix (i.e. pulling the plug optimally, but remote power control hard reset if you can't do that)? If not, we'll have to add a workaround in the code to handle this case and just say the FRU information isn't available for this device. Al On Thu, 2020-08-20 at 09:54 +, FRANK Michael wrote: > Hello, > > Trust everybody is OK and like to say thank you for this very good > software. It helps us every day to prevent hardware outages. > > I have the error "ipmi_sdr_cache_iterate: error returned in callback" > on a Lenovo x3650 M5 Server HW rev 9. Other M5s working well. > > The last section in debug before closing the session is below. This > has no meaning for me, and any help is much appreciated. > > 10.100.212.11: = > 10.100.212.11: IPMI 2.0 Get FRU Inventory Area Info Response > 10.100.212.11: = > 10.100.212.11: RMCP Header: > 10.100.212.11: > 10.100.212.11: [ 6h] = version[ 8b] > 10.100.212.11: [ 0h] = reserved[ 8b] > 10.100.212.11: [ FFh] = sequence_number[ 8b] > 10.100.212.11: [ 7h] = message_class.class[ 5b] > 10.100.212.11: [ 0h] = message_class.reserved[ 2b] > 10.100.212.11: [ 0h] = message_class.ack[ 1b] > 10.100.212.11: IPMI RMCPPLUS Session Header: > 10.100.212.11: - > 10.100.212.11: [ 6h] = authentication_type[ 4b] > 10.100.212.11: [ 0h] = reserved1[ 4b] > 10.100.212.11: [ 0h] = payload_type[ 6b] > 10.100.212.11: [ 1h] = payload_type.authenticated[ 1b] > 10.100.212.11: [ 1h] = payload_type.encrypted[ 1b] > 10.100.212.11: [638898C2h] = session_id[32b] > 10.100.212.11: [ B1h] = session_sequence_number[32b] > 10.100.212.11: [ 20h] = ipmi_payload_len[16b] > 10.100.212.11: IPMI RMCPPLUS Payload: > 10.100.212.11: -- > 10.100.212.11: [ BYTE ARRAY ... ] = confidentiality_header[16B] > 10.100.212.11: [ 38h 2Dh E7h A8h 52h 65h 91h 6Fh ] > 10.100.212.11: [ FCh A8h 2Bh CDh DBh B9h E2h 19h ] > 10.100.212.11: [ BYTE ARRAY ... ] = payload_data[ 8B] > 10.100.212.11: [ 81h 2Ch 53h 20h 84h 10h 81h CBh ] > 10.100.212.11: [ 707060504030201h] = confidentiality_trailer[64b] > 10.100.212.11: IPMI Message Header: > 10.100.212.11: > 10.100.212.11: [ 81h] = rq_addr[ 8b] > 10.100.212.11: [ 0h] = rq_lun[ 2b] > 10.100.212.11: [ Bh] = net_fn[ 6b] > 10.100.212.11: [ 53h] = checksum1[ 8b] > 10.100.212.11: [ 20h] = rs_addr[ 8b] > 10.100.212.11: [ 0h] = rs_lun[ 2b] > 10.100.212.11: [ 21h] = rq_seq[ 6b] > 10.100.212.11: IPMI Command Data: > 10.100.212.11: -- > 10.100.212.11: [ 10h] = cmd[ 8b] > 10.100.212.11: [ 81h] = comp_code[ 8b] > 10.100.212.11: IPMI Trailer: > 10.100.212.11: - > 10.100.212.11: [ CBh] = checksum2[ 8b] > 10.100.212.11: IPMI RMCPPLUS Session Trailer: > 10.100.212.11: -- > 10.100.212.11: [h] = integrity_pad[16b] > 10.100.212.11: [ 2h] = pad_length[ 8b] > 10.100.212.11: [ 7h] = next_header[ 8b] > 10.100.212.11: [ BYTE ARRAY ... ] = authentication_code[12B] > 10.100.212.11: [ DEh 3Ah 51h DDh 19h F9h 9Bh 0Ch ] > 10.100.212.11: [ F5h 0Bh F2h 18h ] > ipmi_fru_open_device_id: internal IPMI error > ipmi_sdr_cache_iterate: error returned in callback > > > > Michael FRANK > Supervisor Global Monitoring Architecture Faurecia Clean Mobility T > +49 821 4103 420 ● M +49 171 9967 206 michael.fr...@faurecia.com > Faurecia Emissions Control Technologies, Germany GmbH - Biberbachstraße 9 – > 86154 Augsburg – Germany > > Sitz der Gesellschaft: Augsburg - Registergericht Augsburg HR B 20757 > Geschäftsführer: Yves Andres, Françoise Crenn, Thomas Hanak > Vorsitzender des Aufsichtsrats: Mathias Miedreich > > > > This electronic transmission (and
