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 _______________________________________________ openib-general mailing list openib-general@openib.org http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general