https://jira.whamcloud.com This file is an XML representation of an issue en-us 9.4.14 940014 05-12-2023 https://jira.whamcloud.com/browse/LU-2491 Lustre <p>I see the following LNet Error in the logs:</p> <div class="preformatted panel" style="border-width: 1px;"><div class="preformattedContent panelContent"> <pre>2012-12-13 13:09:08 LNetError: 21195:0:(o2iblnd_cb.c:2261:kiblnd_passive_connect()) Can't accept 172.20.13.43@o2ib500 on NA (ib0:0:172.20.5.2): bad dst nid 172.20.5.2@o2ib500 2012-12-13 13:09:08 LNetError: 21180:0:(o2iblnd_cb.c:2261:kiblnd_passive_connect()) Can't accept 172.20.14.153@o2ib500 on NA (ib0:0:172.20.5.2): bad dst nid 172.20.5.2@o2ib500 2012-12-13 13:09:08 LNet: Added LNI 172.20.5.2@o2ib500 [8/1024/0/180] 2012-12-13 13:09:09 LNET configured </pre> </div></div> <p>Without looking at the code, it seems like LNet is denying the incoming connection because it is not yet configured. If that is the case, I don't think that warrants a console message. It should just silently refuse the connection until it is fully configured.</p> LU-2491

Spurious LNet Error: Can't accept connection on "bad dst nid"

Bug Blocker Resolved Won't Fix Isaac Huang Prakash Surya LB sequoia shh Thu, 13 Dec 2012 16:18:33 +0000 Tue, 8 Jan 2013 18:12:00 +0000 Tue, 8 Jan 2013 18:12:00 +0000 Lustre 2.4.0 0 5 <p>Yes there's a small window after the o2iblnd has created a listening CMID but before the lnd_startup() call completes. Console errors shouldn't be used in such cases.</p> <p>I looked at the code, and it appeared not easy to do it properly. The CERROR() is shared by several similar error cases, and if simply changed to a CDEBUG() some important error cases would be muted too which actually deserves immediate attention. It's hard to single out the exact case here, i.e. an incoming connection comes while a <b>matching</b> interface is still being initialized, taking into consideration the upcoming lnet dynamic config project.</p> <p>In short, a correct fix would involve quite some complexity, making the code harder to maintain in the long run. So I have to ask how many of these have been seen at LLNL to make it a concern for you guys?</p> <p>I'd tend to think it's not a problem because:</p> <ul class="alternate" type="square"> <li>The window during which it could happen shouldn't be longer than a couple of milliseconds.</li> <li>When it does happen on a node, LNet is still initializing itself, so Lustre isn't running yet. The console messages can't cause other Lustre debug messages to go unnoticed, because Lustre isn't running yet.</li> </ul> <p>Please let me know if I've missed something that makes it more problematic than I thought. Otherwise I'd prefer to leave it there and keep the code simple.</p> <p>Well, I'd like to see it fixed, but if it would cause a lot of added complexity to code which will be reworked with the upcoming LNET changes, I'm OK leaving it as is. It's more of an annoyance than what I'd call a problem.</p> <p>It's difficult to filter out exactly the spurious case only. Do you guys enable neterror console logging by default? If not, it'd be a good simple trade-off to just change the CERROR() into a CNETERR().</p> <p>IIRC, we do enable neterror by default. If it isn't worth the effort to filter the spurious case, lets just close this as "wont fix". This definitely shouldn't be a blocker, IMO.</p> <p>It's hard to filter out the exact spurious case without adding lots of complexity elsewhere.</p> Development Rank 1|hzvdtb: Rank (Obsolete) 5845 Severity