[openib-general] Question

Hal Rosenstock halr at voltaire.com
Mon Feb 28 15:39:23 PST 2005


On Mon, 2005-02-28 at 18:34, Ronald G. Minnich wrote:
> ok, here you go. THis is the first one that appears to fail. 
> 
> YOu can probably guess why :-)
> 
> [1109632561:000646260][411FF970] -> __osm_sm_mad_ctrl_process_get_resp: [
> [1109632561:000646268][411FF970] -> __osm_sm_mad_ctrl_update_wire_stats: [
> [1109632561:000646277][411FF970] -> __osm_sm_mad_ctrl_update_wire_stats: 0 
> SMPs on the wire, 322 outstanding.
> [1109632561:000646285][411FF970] -> osm_vl15_poll: [
> [1109632561:000646293][411FF970] -> osm_vl15_poll: Signalling poller 
> thread.
> [1109632561:000646305][411FF970] -> osm_vl15_poll: ]
> [1109632561:000646317][411FF970] -> __osm_sm_mad_ctrl_update_wire_stats: ]
> [1109632561:000646329][411FF970] -> osm_mad_pool_put: [
> [1109632561:000646342][40DFF970] -> __osm_vl15_poller: Servicing p_madw = 
> 0x785890 (mad 0x2a96f9bb80 req 1)
> [1109632561:000646360][411FF970] -> osm_mad_pool_put: Releasing p_madw = 
> 0x2a95f297b0, p_mad = 0x2a95f502f0.
> [1109632561:000646374][411FF970] -> osm_vendor_put: [
> [1109632561:000646382][411FF970] -> osm_vendor_put: Retiring UMAD 
> 0x2a95f502f0.
> [1109632561:000646391][411FF970] -> osm_vendor_put: ]
> [1109632561:000646399][411FF970] -> osm_mad_pool_put: ]
> [1109632561:000646408][411FF970] -> __osm_sm_mad_ctrl_process_get_resp: 
> Posting Dispatcher message OSM_MSG_MAD_PKEY.
> [1109632561:000646418][411FF970] -> __osm_sm_mad_ctrl_process_get_resp: ]
> [1109632561:000646430][411FF970] -> __osm_sm_mad_ctrl_rcv_callback: ]
> [1109632561:000646443][40DFF970] -> SMP dump:
>                                 base_ver................0x1
>                                 mgmt_class..............0x81
>                                 class_ver...............0x1
>                                 method..................0x1 (SubnGet)
>                                 status..................0x0
>                                 hop_ptr.................0x0
>                                 hop_count...............0xA
>                                 trans_id................0x6a40
>                                 attr_id.................0x11 (NodeInfo)
>                                 resv....................0x0
>                                 attr_mod................0x0
>                                 m_key...................0x0000000000000000
>                                 dr_slid.................0xFFFF
>                                 dr_dlid.................0xFFFF
> 
>                                 Initial path: 
> [0][1][3][5][5][7][3][1][3][1][4]
>                                 Return path:  
> [0][0][0][0][0][0][0][0][0][0][0]
>                                 Reserved:     [0][0][0][0][0][0][0]
> 
>                                 00 00 00 00 00 00 00 00   00 00 00 00 00 
> 00 00 00
> 
>                                 00 00 00 00 00 00 00 00   00 00 00 00 00 
> 00 00 00
> 
>                                 00 00 00 00 00 00 00 00   00 00 00 00 00 
> 00 00 00
> 
>                                 00 00 00 00 00 00 00 00   00 00 00 00 00 
> 00 00 00
> 
> [1109632561:000646482][40DFF970] -> osm_vendor_send: [
> [1109632561:000646494][40BFF970] -> osm_pkey_rcv_process: [
> [1109632561:000646508][40DFF970] -> __osm_mtl_send_callback: Completed 
> Sending Request MADW:0x785890.
> [1109632561:000646521][40DFF970] -> osm_vendor_send: ]
> [1109632561:000646533][40BFF970] -> osm_pkey_rcv_process: Got 
> GetResp(PKey) block:1 port_num 3 with GUID = 0x2c90108d192e0 for parent 
> node GUID = 0x2c90108d192e0, TID = 0x6a3f.
> [1109632561:000646552][40DFF970] -> __osm_vl15_poller: 1 on wire, 322 
> outstanding, 0 unicasts sent, 22541 sent total.
> [1109632561:000646628][40BFF970] -> P_Key table dump:
>                         port_giud...........0x0002c90108d192e0
>                         block_num...........0x1
>                         port_num............0x3
>         P_Key Table:  0X0 | 0X0 | 0X0 | 0X0 | 0X0 | 0X0 | 0X0 | 0X0 | 0X0 
> | 0X0 | 0X0 | 0X0 | 0X0 | 0X0 | 0X0 | 0X0 | 0X0 | 0X0 | 0X0 | 0X0 | 0X0 | 
> 0X0 | 0X0 | 0X0 | 0X0 | 0X0 | 0X0 | 0X0 | 0X0 | 0X0 | 0X0 | 0X0 |
> 
> 
> 
> 
> Actually I'm not sure if that is the first bad one, but ... is the return 
> path supposed to be all zeros? 

The return path is filled in on the way back (in the response) so this
is fine.

> Can I take it that such a path indicates an error? 

No.

> Maybe not: there's a ton of them in there. 

Right. It is also showing the PKey table on response.

> Hal, what else can I send you?

Are you sure ibnetdiscover gets your whole topology and nothing is
missing (like a switch) ?

-- Hal




More information about the general mailing list