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-101 Lustre <p>When building 1.8.x against out-of-kernel OFED and a Lustre kernel with in-kernel IB support, Lustre will pick up the IB symvers of the kernel. The workaround is to remove all references to IB in the kernel module.symvers, but it's a confusing step. It would be nice if Lustre did the right thing here and preferred the --with-o2ib symvers over the kernel symvers. I thought that there had been some work on this in the past, but it seems to not have stuck, as we still run into this issue regularly. </p> <p>Thanks,<br/> Kit</p> <p>On an administrative note: Which should we use to mark how important a bug is? Priority or severity? This issue is not at all critical since there is a well understood workaround and it doesn't affect anything except the build process.</p> LU-101

building Lustre against OFED when the kernel has built-in IB causes symbol mismatch

Bug Minor Resolved Fixed Brian Murrell Kit Westneat Mon, 28 Feb 2011 11:52:40 +0000 Tue, 28 Jun 2011 15:01:43 +0000 Fri, 18 Mar 2011 19:56:24 +0000 Lustre 1.8.6 0 1 <p>Brian</p> <p>You are the engineer who had worked in this area. Could you please comment?</p> <p>Thanks</p> <p>Peter</p> <p>Kit</p> <p>Priority=Importance and Severity=Impactfulness. Usually these are in sync, but it might be possible to have a low priority high severity issue (a theoretical system crasher that never occurs in real life) or a high priority low severity issue (Lustre mis-spelt somewhere very noticeable)</p> <p>HTH</p> <p>Peter</p> <p>Kit, from looking at the code (lnet/autoconf/lustre-lnet.m4:447 in current master) and the kernel documentation for Module.symvers AFAICT, we are doing the right thing already, modulo the lack of specification in the kernel's modules.txt about which Module.symvers takes precedence when a symbol exists in both the kernel's own Module.symvers <b>and</b> an external module's Module.symvers.</p> <p>As far as having to remove the IB symbols from the kernel's Module.symvers, obviously this is not something the Lustre build code can do as it would be (IMHO) a serious issue to go molesting the kernel source tree as part of a module build.</p> <p>I will keep investigating to see if I can resolve the question about preference when more than one Module.symvers has a given symbol.</p> <p>I can't reproduce this.</p> <p>I built OFED-1.5.2's kernel-ib</p> {,-devel} <p> and installed the kernel-ib-devel. I then built lustre with:</p> <div class="code panel" style="border-width: 1px;"><div class="codeContent panelContent"> <pre class="code-java">$ ./configure --with-linux=/usr/src/kernels/2.6.18-194.32.1.el5-x86_64/ --with-o2ib=/usr/src/ofa_kernel/ --without-lustre-iokit --disable-quilt --disable-liblustre --disable-docs --disable-snmp --disable-tests $ make </pre> </div></div> <p>When I interrogate <tt>lnet/klnds/o2iblnd/ko2iblnd.ko</tt> for the version of a given I/B function that it wants I get:</p> <div class="code panel" style="border-width: 1px;"><div class="codeContent panelContent"> <pre class="code-java">$ /sbin/modprobe --dump-modversions lustre-release/lnet/klnds/o2iblnd/ko2iblnd.ko | grep ib_create_cq 0x17fa926d ib_create_cq </pre> </div></div> <p>When I then interrogate the kernel and OFED Module.symvers files:</p> <div class="code panel" style="border-width: 1px;"><div class="codeContent panelContent"> <pre class="code-java">$ grep ib_create_cq /usr/src/ofa_kernel/Module.symvers /usr/src/kernels/2.6.18-194.32.1.el5-x86_64/Module.symvers /usr/src/ofa_kernel/Module.symvers:0x17fa926d ib_create_cq drivers/infiniband/core/ib_core EXPORT_SYMBOL /usr/src/kernels/2.6.18-194.32.1.el5-x86_64/Module.symvers:0x1e8a9cb5 ib_create_cq drivers/infiniband/core/ib_core EXPORT_SYMBOL </pre> </div></div> <p>So as you can see, ko2iblnd.ko is looking for the OFED version of the function, not the kernel's own version.</p> <p>Can you provide any more information as to how you are arriving at different results? Or maybe where I am misunderstanding your problem?</p> <p>Kit,</p> <p>Were you able to gather any more information on this issue?</p> <p>Hey Brian,</p> <p>I haven't had time to work on this unfortunately, I should be able to next week.</p> <p>Thanks,<br/> Kit</p> <p>It looks like it is working, so I'm not sure what was going on. I'll close it up. </p> <p>actually, is it possible for me to close it? I can't find that functionality. </p> <p>Not sure, but I have closed it for you Kit</p> Development Rank 1|hzw1kv: Rank (Obsolete) 10337 Severity