[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