Re: [ewg] mlx4 and ibv_devinfo discrepancy?
Pradeep Satyanarayana wrote: Why does ibv_devinfo show the port 1 as PORT_ACTIVE? Isn't that incorrect? Is this a known problem? ibv_devinfo shows the IB port status, and active means an SM succeeded to bring up the port and assign a LID to it. It does not mean ibn (from IPoIB) is up Tziporet ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
Re: [ewg] [PATCH] add ib_qib driver to OFED-1.5
Ralph Campbell wrote: I added one more commit to the previous list: commit d361b285743ddf30097d0cd0f53c380a8469d2a7 Author: Ralph Campbell (QLogic) ral...@hosting.openfabrics.org Date: Tue Jul 7 17:27:11 2009 -0700 IB/qib: add QIB driver to kernel spec file and init.d script This adds the QIB driver to the kernel spec file and init.d script. Signed-off-by: Ralph Campbell ralph.campb...@qlogic.com On Tue, 2009-07-07 at 14:38 -0700, Ralph Campbell wrote: Vlad, Please pull from: git://git.openfabrics.org/~ralphc/linux-2.6/.git ofed_kernel_1_5 Done, Regards, Vladimir ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
Re: [ewg] mlx4 and ibv_devinfo discrepancy?
Pradeep, There is no one-to-one connection between an **infiniband** port being active, and an **IPoIB** port being up. The Infiniband port active means that its logical link is up, and it can send and receive packets from its wire interface. For example, if you run the ibv_ud_pingpong example application, you will see that it sends and receives packets. On the other hand, ib0 up or down is an IPoIB concept. ib0 may show down even if the infiniband port is active. For example, if the administrator does ifconfig ib0 down, you will see that the ib0 operational state is down -- however, the underlying infiniband port remains active -- and, for example, the various ibv_xx_pingpong example apps will work. There is no problem with what you saw. -Jack On Tuesday 07 July 2009 19:48, Pradeep Satyanarayana wrote: I was attempting to debug an IPoIB multicast join failed issue and in the process discovered the discrepancy (was using OFED-1.4.1 on ppc64 blades) as described below. My setup consisted of two nodes with dual port ConnectX HCAs with ports 1 on each node connected to a switch say switch1 and ports 2 on each node connected to another switch, say switch2. The problem was that ports 1 would not join the multicast group as shown ib0: multicast join failed for ff12:401b::::::, status -22 ib0: multicast join failed for ff12:401b::::::, status -22 If the same ports were connected to switch2, using the same cables, everything worked fine. The problem was due to an MTU mismatch, so IPoIB did behave as expected. However, as shown the output of ibv_devinfo was misleading. This was the output when the port 1 was connected to switch1 with incorrect MTU. [r...@cluster-1 ~]# ibv_devinfo hca_id: mlx4_0 fw_ver: 2.6.000 node_guid: 0002:c903:0001:2058 sys_image_guid: 0002:c903:0001:205b vendor_id: 0x02c9 vendor_part_id: 25418 hw_ver: 0xA0 board_id: IBM08A001 phys_port_cnt: 2 port: 1 state: PORT_ACTIVE (4) max_mtu:2048 (4) active_mtu: 2048 (4) sm_lid: 1 port_lid: 50 port_lmc: 0x00 port: 2 state: PORT_ACTIVE (4) max_mtu:2048 (4) active_mtu: 2048 (4) sm_lid: 1 port_lid: 11 port_lmc: 0x00 Same issue with the other HCA too. [r...@cluster-2 ~]# ibv_devinfo hca_id: mlx4_0 fw_ver: 2.6.000 node_guid: 0002:c903:0001:21e4 sys_image_guid: 0002:c903:0001:21e7 vendor_id: 0x02c9 vendor_part_id: 25418 hw_ver: 0xA0 board_id: IBM08A001 phys_port_cnt: 2 port: 1 state: PORT_ACTIVE (4) max_mtu:2048 (4) active_mtu: 2048 (4) sm_lid: 1 port_lid: 51 port_lmc: 0x00 port: 2 state: PORT_ACTIVE (4) max_mtu:2048 (4) active_mtu: 2048 (4) sm_lid: 1 port_lid: 66 port_lmc: 0x00 [r...@cluster-2 ~]# cat /sys/class/net/ib0/operstate showed down and that clued me to the fact that there was something amiss and as shown the link was down. [r...@cluster-1 ~]# ip link show dev ib0 3: ib0: NO-CARRIER,BROADCAST,MULTICAST,UP mtu 65520 qdisc pfifo_fast qlen 256 link/infiniband 80:00:00:48:fe:80:00:00:00:00:00:00:00:02:c9:03:00:01:20:59 brd 00:ff:ff:ff:ff:12:40:1b:ff:ff:00:00:00:00:00:00:ff:ff:ff:ff [r...@cluster-1 ~]# ip link show dev ib1 4: ib1: BROADCAST,MULTICAST,UP,LOWER_UP mtu 65520 qdisc pfifo_fast qlen 256 link/infiniband 80:00:00:49:fe:80:00:00:00:00:00:00:00:02:c9:03:00:01:20:5a brd 00:ff:ff:ff:ff:12:40:1b:ff:ff:00:00:00:00:00:00:ff:ff:ff:ff [r...@cluster-1 ~]# [r...@cluster-2 ~]# ip link show dev ib0 3: ib0:
[ewg] Re: [PATCH v4] libibmad: Handle MAD redirection
Hal Rosenstock hal.rosenst...@gmail.com wrote on 07.07.2009 17:23:18:
+static int redirect_port(ib_portid_t *port, uint8_t *mad)
+{
+ port-lid = mad_get_field(mad, 64, IB_CPI_REDIRECT_LID_F);
+ if (!port-lid) {
+ IBWARN(GID-based redirection is not supported);
+ return -1;
+ }
I hate to keep beating this horse but the lack of a LID certainly
means GID based redirection when the GID is not 0, IMO this LID check
is insufficient in general.
If the LID is given, my code does the right thing by redirecting
regardless
of any GID, as the spec requires. If no LID is given, but a GID is, my
code
bails with an error stating that GID-based redirection is not supported.
If
both GID and LID are 0, that's an error and my code bails with an error
message (which may or may not be misleading depending on your perspective,
but frankly I couldn't care less about broken agents).
Which of those three reactions do you think is insufficient?
I suppose this can be fixed down the road.
Is that an ACK? ;)
Cheers,
Joachim
___
ewg mailing list
ewg@lists.openfabrics.org
http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
[ewg] Re: [PATCH v4] libibmad: Handle MAD redirection
On 7/8/09, Joachim Fenkes fen...@de.ibm.com wrote:
Hal Rosenstock hal.rosenst...@gmail.com wrote on 07.07.2009 17:23:18:
+static int redirect_port(ib_portid_t *port, uint8_t *mad)
+{
+ port-lid = mad_get_field(mad, 64, IB_CPI_REDIRECT_LID_F);
+ if (!port-lid) {
+ IBWARN(GID-based redirection is not supported);
+ return -1;
+ }
I hate to keep beating this horse but the lack of a LID certainly
means GID based redirection when the GID is not 0, IMO this LID check
is insufficient in general.
If the LID is given, my code does the right thing by redirecting
regardless
of any GID, as the spec requires. If no LID is given, but a GID is, my
code
bails with an error stating that GID-based redirection is not supported.
If
both GID and LID are 0, that's an error and my code bails with an error
message (which may or may not be misleading depending on your perspective,
but frankly I couldn't care less about broken agents).
Which of those three reactions do you think is insufficient?
It looks to me like both GID and LID are allowed to be specified in
the redirect and if so, there is the possibility of GID based
redirection there (as well as when LID is 0) and it is the requester
which decides on GRH inclusion or not.
I suppose this can be fixed down the road.
Is that an ACK? ;)
Indeed, a qualified ACK :-) This case that concerns me ends up
entangled in the to be specified multiple IB subnet case (router
spec).
-- Hal
Cheers,
Joachim
___
ewg mailing list
ewg@lists.openfabrics.org
http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
[ewg] Re: [PATCH] Add QIB driver to OFED builds
Ralph Campbell wrote:
Vlad,
This should be applied to your ofabuild.git tree after pulling
the changes to add ib_qib to OFED-1.5.
Signed-off-by: Ralph Campbell ralph.campb...@qlogic.com
diff --git a/build_ofa_kernel.sh b/build_ofa_kernel.sh
index 88bf94e..2f5b690 100755
--- a/build_ofa_kernel.sh
+++ b/build_ofa_kernel.sh
@@ -150,6 +150,17 @@ set_packages()
;;
esac
+# QIB
+case ${arch} in
+x86_64)
+case ${kern} in
+
*2.6.9-67*|*2.6.9-78*|*2.6.16.60-0.21*|*2.6.18-93*|*2.6.18-128*|*2.6.27*)
+WITH_PACKAGES=${WITH_PACKAGES} --with-qib-mod
+;;
+esac
+;;
+esac
+
# srp target
case ${kern} in
2.6.16.*-*-*|2.6.18-*fc[56]*|2.6.*.el5|2.6.2[0-9]*|2.6.30)
Hi Ralph,
This patch is applied,
Please send me the patch for the install.pl script.
Thanks,
Vladimir
___
ewg mailing list
ewg@lists.openfabrics.org
http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
[ewg] RHEL5.4 support in OFED 1.5
RHEL5.4 Beta was announced last week and the Beta kernels can be found at http://people.redhat.com/dzickus/el5. Is there anyone currently working on the RHEL5.4 backports for OFED 1.5? When can we expect something to be in-tree? I was able to apply the kernels found at that location to a RHEL5.3 install, and did the NFSRDMA backport against it. I can send out my patches to create the RHEL5.4 tree and the NFSRDMA backport. The tree can obviously be updated when RHEL5.4 is officially released next month. This could save us all the headache of having to wait for it to come out before we do our backports for OFED 1.5 Thanks, Jon ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
Re: [ewg] OFED-1.5-20090706-0600 build break
On Mon, Jul 06, 2009 at 10:44:09PM +0300, Tziporet Koren wrote: Adding Sasha - maybe he knows the reason We are still seeing this breakage in the latest nightly build. Can this package be regressed until the issue is solved? The version in 07/02 worked, so maybe that could used. Thanks, Jon Tziporet Jon Mason wrote: We are hitting the following issue when trying to build the OFED 1.5 nightly build. It looks like a header file is missing in infiniband-diags. Thanks, Jon --- Distibution: CentOS 5.3 CPU type: x86_64 Linux kernel: 2.6.30 OFED version: OFED-1.5-20090706-0600 # ./install.pl - 2,3 ... Failed to build infiniband-diags RPM See /tmp/OFED.27292.logs/infiniband-diags.rpmbuild.log # less /tmp/OFED.27292.logs/infiniband-diags.rpmbuild.log ... src/ibnetdisc.c:57:22: error: internal.h: No such file or directory In file included from src/ibnetdisc.c:58: src/chassis.h:83: warning: 'struct ibnd_fabric' declared inside parameter list src/chassis.h:83: warning: its scope is only this definition or declaration, whi ch is probably not what you want src/ibnetdisc.c:73: warning: 'struct ibnd_port' declared inside parameter list src/ibnetdisc.c:73: warning: 'struct ibnd_fabric' declared inside parameter list src/ibnetdisc.c: In function 'get_port_info': src/ibnetdisc.c:79: error: dereferencing pointer to incomplete type src/ibnetdisc.c:80: error: dereferencing pointer to incomplete type src/ibnetdisc.c:81: error: dereferencing pointer to incomplete type src/ibnetdisc.c:83: error: dereferencing pointer to incomplete type src/ibnetdisc.c:84: error: dereferencing pointer to incomplete type src/ibnetdisc.c:87: error: dereferencing pointer to incomplete type src/ibnetdisc.c:89: warning: implicit declaration of function 'IBND_DEBUG' src/ibnetdisc.c:90: error: dereferencing pointer to incomplete type src/ibnetdisc.c:91: error: dereferencing pointer to incomplete type src/ibnetdisc.c:92: error: dereferencing pointer to incomplete type ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
[ewg] Re: [PATCH v4] libibmad: Handle MAD redirection
Hal Rosenstock hal.rosenst...@gmail.com wrote on 08.07.2009 15:24:53: I suppose this can be fixed down the road. Is that an ACK? ;) Indeed, a qualified ACK :-) Cool, thanks! This patch should make its way into OFED 1.5... so who should pull it? You? Vlad? Someone not on CC? Whoever, please apply for OFED 1.5 -- thanks! Cheers Joachim ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
[ewg] Re: [PATCH v4] libibmad: Handle MAD redirection
On 7/8/09, Joachim Fenkes fen...@de.ibm.com wrote: Hal Rosenstock hal.rosenst...@gmail.com wrote on 08.07.2009 15:24:53: I suppose this can be fixed down the road. Is that an ACK? ;) Indeed, a qualified ACK :-) Cool, thanks! This patch should make its way into OFED 1.5... so who should pull it? You? Vlad? Someone not on CC? Whoever, please apply for OFED 1.5 -- thanks! Sasha is the management maintainer. Userspace trees for OFED 1.5 haven't been created and I think this aspect is in transition. -- Hal Cheers Joachim ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
[ewg] [GIT PULL ofed-1.5] cxgb3 RH4 backports
Vlad, Please pull the cxgb3 RH4.6/7 backports from ssh://v...@sofa.openfabrics.org/~swise/scm/ofed_kernel.git ofed_1_5 Thanks, Steve. --- commit 87452763e07240d48083bd8ad8b20b08c4163166 Author: Steve Wise sw...@opengridcomputing.com Date: Wed Jul 8 11:13:27 2009 -0500 cxgb3: Backports for RH4U7. Signed-off-by: Steve Wise sw...@opengridcomputing.com .../backport/2.6.9_U7/include/linux/if_arp.h | 11 + .../backport/2.6.9_U7/include/linux/skbuff.h | 102 .../cxgb3_0001_backout_multq_netdeviceops.patch| 228 .../backport/2.6.9_U7/cxgb3_0002_undo_250.patch| 164 ++ .../backport/2.6.9_U7/cxgb3_0004_undo_240.patch| 86 +++ ...xgb3_0008_pci_dma_mapping_error_to_2_6_26.patch | 17 + .../backport/2.6.9_U7/cxgb3_0010_napi.patch| 600 .../backport/2.6.9_U7/cxgb3_0020_sysfs.patch | 202 +++ .../backport/2.6.9_U7/cxgb3_0030_sset.patch| 34 ++ .../backport/2.6.9_U7/cxgb3_0040_remove_eeh.patch | 87 +++ .../backport/2.6.9_U7/cxgb3_0100_remove_lro.patch | 391 + .../2.6.9_U7/cxgb3_0110_provider_sysfs.patch | 120 .../backport/2.6.9_U7/cxgb3_0120_fixwarnings.patch | 39 ++ .../2.6.9_U7/cxgb3_0200_fl1_mpage_fix.patch| 21 + .../backport/2.6.9_U7/cxgb3_0300_t3_to_2_6_9.patch | 43 ++ 15 files changed, 2145 insertions(+), 0 deletions(-) commit 194e4b052a79412b6c7efefc569e5c2d8747b6bd Author: Steve Wise sw...@opengridcomputing.com Date: Wed Jul 8 11:13:03 2009 -0500 cxgb3: Backports for RH4U6. Signed-off-by: Steve Wise sw...@opengridcomputing.com .../backport/2.6.9_U6/include/linux/if_arp.h | 11 + .../backport/2.6.9_U6/include/linux/skbuff.h | 102 .../backport/2.6.9_U6/include/linux/types.h.orig | 22 + .../cxgb3_0001_backout_multq_netdeviceops.patch| 228 .../backport/2.6.9_U6/cxgb3_0002_undo_250.patch| 164 ++ .../backport/2.6.9_U6/cxgb3_0004_undo_240.patch| 86 +++ ...xgb3_0008_pci_dma_mapping_error_to_2_6_26.patch | 17 + .../backport/2.6.9_U6/cxgb3_0010_napi.patch| 600 .../backport/2.6.9_U6/cxgb3_0020_sysfs.patch | 202 +++ .../backport/2.6.9_U6/cxgb3_0030_sset.patch| 34 ++ .../backport/2.6.9_U6/cxgb3_0040_remove_eeh.patch | 87 +++ .../backport/2.6.9_U6/cxgb3_0100_remove_lro.patch | 391 + .../2.6.9_U6/cxgb3_0110_provider_sysfs.patch | 120 .../backport/2.6.9_U6/cxgb3_0120_fixwarnings.patch | 39 ++ .../2.6.9_U6/cxgb3_0200_fl1_mpage_fix.patch| 21 + .../backport/2.6.9_U6/cxgb3_0300_t3_to_2.6.9.patch | 43 ++ 16 files changed, 2167 insertions(+), 0 deletions(-) ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
Re: [ewg] i need to avoid the NFSRDMA headers in kernel-ib-devel
On Tue, Jun 30, 2009 at 03:36:31PM -0400, Brian J. Murrell wrote: I think I have asked about this before, or at least tangentially in bug 1523. The problem is, when I am building software against the OFED kernel-ib-devel package, because the NFSRDMA headers are in the same include tree as the OFED headers, I cannot get to the OFED headers and avoid the NFSRDMA headers. When is this a problem? When I have built my OFED stack *without* NFSRDMA support. So my expectation is that the driver that I am building with the OFED kernel-ib-devel will use the NFS and RPC implementation in the linux kernel, not in /usr/src/ofa-kernel, however because the NFSRDMA implementation is populated in the same include tree as the core OFED implementation, I cannot avoid it. The OFED NFS implementation replaces the in-kernel version. So it will be the version being used. All references in the tree will thus be pointing to the correct NFS. Why would you not want this to be the case? Thanks, Jon Thots? b. ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
Re: [ewg] i need to avoid the NFSRDMA headers in kernel-ib-devel
On Wed, 2009-07-08 at 14:16 -0500, Jon Mason wrote: The OFED NFS implementation *optionally* replaces the in-kernel version. If one desires that. So it will be the version being used. Per above, only if you selected to build/install it. Why would you not want this to be the case? Because we are trying to minimize our responsibility for kernel deviation (and hence bugs) from the vendor's distributed kernel. OFED is an integral component of our software, so we are willing to take on the responsibility for that deviation. NFS[RDMA] is not integral to our software, so we'd just as soon let the customer use what they would be using with the vendor's stock kernel if they want to use NFS. b. signature.asc Description: This is a digitally signed message part ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
Re: [ewg] i need to avoid the NFSRDMA headers in kernel-ib-devel
On Wed, Jul 08, 2009 at 03:27:29PM -0400, Brian J. Murrell wrote: On Wed, 2009-07-08 at 14:16 -0500, Jon Mason wrote: The OFED NFS implementation *optionally* replaces the in-kernel version. If one desires that. So it will be the version being used. Per above, only if you selected to build/install it. Why would you not want this to be the case? Because we are trying to minimize our responsibility for kernel deviation (and hence bugs) from the vendor's distributed kernel. OFED is an integral component of our software, so we are willing to take on the responsibility for that deviation. NFS[RDMA] is not integral to our software, so we'd just as soon let the customer use what they would be using with the vendor's stock kernel if they want to use NFS. Just tell them that NFSRMDA is NOT optional ;-) Creating a seperate package can be quite harry and will eat a large chunk of time. I think it would be much easier to have some compile time checkes, for example #ifdef CONFIG_NFS_FS around all the NFS specific functions/headers. Does that sound plausable/reasonable? b. ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
Re: [ewg] i need to avoid the NFSRDMA headers in kernel-ib-devel
On Wed, Jul 08, 2009 at 04:12:12PM -0400, Brian J. Murrell wrote: On Wed, 2009-07-08 at 14:42 -0500, Jon Mason wrote: Just tell them that NFSRMDA is NOT optional ;-) Oh, I'm sure not many would have a problem with that. It's our own risk management that prevents us from doing that. Creating a seperate package can be quite harry and will eat a large chunk of time. Fair enough. I think it would be much easier to have some compile time checkes, for example #ifdef CONFIG_NFS_FS around all the NFS specific functions/headers. Does that sound plausable/reasonable? This sounds like one of the options I suggested in the bugzilla bug, but CONFIG_NFS_FS is the generic kernel definition to enable NFS isn't it? That would mean that if the vendor's default .config enabled NFS, it would still not guard the NFSRDMA headers, if I understand you correctly. I think you need to invent your own macro (maybe CONFIG_OFA_NFS_FS) which you define when the user chooses the OFED NFSRDMA and that definition guards all of the declarations (heck, in most cases, probably just entire include files, with #include_next as the #else case of the guard) in the OFED NFSRDMA headers. I can look into this more and see if it does what you want. Am I correct in assuming that you want this for 1.4.2 as well? Thanks, Jon b. ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
Re: [ewg] i need to avoid the NFSRDMA headers in kernel-ib-devel
On Wed, 2009-07-08 at 15:22 -0500, Jon Mason wrote: I can look into this more and see if it does what you want. Great. Am I correct in assuming that you want this for 1.4.2 as well? Ideally. :-) Definitely fixing in trunk is desired though. b. signature.asc Description: This is a digitally signed message part ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
[ewg] Re: [PATCH] ehca: use port autodetect mode as default
looks good, applied ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
[ewg] [GIT PULL OFED-1.5] NFSRDMA bugfix
Hey Jack, Please pull from ssh://ja...@sofa.openfabrics.org/home/jon/scm/ofed_kernel-1.5.git dev I have run the build script on sofa, and I did not see any issues. It contains the following patch: commit 5f0e2d987dfd5a0b8d8f8dd6f1ecf51b7ac7b1f8 Author: Jon Mason j...@opengridcomputing.com Date: Wed Jul 8 13:36:10 2009 -0500 RHEL5.3 does not need the backported write_cache_pages that RHEL5.2 needs. Remove it and call the in-kernel version of that function. Signed-Off-By: Jon Mason j...@opengridcomputing.com Thanks, Jon ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
[ewg] [PATCH] install.pl: Install QIB driver instead of Ipath
Vlad,
Please apply this to your ~vlad/ofed_scripts.git ofed_1_5 repo.
This patch installs the qib driver which replaces the ipath driver
in OFED-1.5.
Signed-off-by: Ralph Campbell ralph.campb...@qlogic.com
diff --git a/install.pl b/install.pl
index 7d8036b..92988e5 100755
--- a/install.pl
+++ b/install.pl
@@ -309,7 +309,7 @@ my @suse_ofed_packages = (
# List of all available packages sorted following dependencies
my @kernel_packages = (kernel-ib, kernel-ib-devel, ib-bonding,
ib-bonding-debuginfo);
-my @basic_kernel_modules = (core, mthca, mlx4, mlx4_en, cxgb3,
nes, ehca, ipath, ipoib);
+my @basic_kernel_modules = (core, mthca, mlx4, mlx4_en, cxgb3,
nes, ehca, qib, ipoib);
my @ulp_modules = (sdp, srp, srpt, rds, qlgc_vnic, iser,
nfsrdma);
# kernel modules in technology preview status can be installed by
@@ -394,6 +394,9 @@ my %kernel_modules_info = (
'ipath' =
{ name = ipath, available = 0, selected = 0,
included_in_rpm = 0, requires = [core], },
+'qib' =
+{ name = qib, available = 0, selected = 0,
+included_in_rpm = 0, requires = [core], },
'cxgb3' =
{ name = cxgb3, available = 0, selected = 0,
included_in_rpm = 0, requires = [core], },
@@ -1658,11 +1661,9 @@ sub set_availability
# $kernel =~
m/2.6.16.[0-9.]*-[0-9.]*-[A-Za-z0-9.]*|2.6.1[7-9]|2.6.2[0-9]/) or
#($arch =~ m/x86_64/ and
# $kernel =~
m/2.6.9-42|2.6.9-55|2.6.9-67|2.6.9-78|2.6.16.[0-9.]*-[0-9.]*-[A-Za-z0-9.]*|2.6.1[7-9]|2.6.2[0-9]/)
) {
-if ( ($arch =~ m/ppc64/ and
-$kernel =~ m/2.6.30/) or
- ($arch =~ m/x86_64/ and
+if ( ($arch =~ m/x86_64/ and
$kernel =~ m/2.6.30/) ) {
-$kernel_modules_info{'ipath'}{'available'} = 1;
+$kernel_modules_info{'qib'}{'available'} = 1;
$packages_info{'libipathverbs'}{'available'} = 1;
$packages_info{'libipathverbs-devel'}{'available'} = 1;
$packages_info{'libipathverbs-debuginfo'}{'available'} = 1;
@@ -2814,6 +2815,9 @@ sub build_kernel_rpm
elsif ($module eq ipath) {
$kernel_configure_options .= --with-ipath_inf-mod;
}
+elsif ($module eq qib) {
+$kernel_configure_options .= --with-qib-mod;
+}
elsif ($module eq srpt) {
$kernel_configure_options .= --with-srp-target-mod;
}
___
ewg mailing list
ewg@lists.openfabrics.org
http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
Re: [ewg] [PATCH] install.pl: Install QIB driver instead of Ipath
This patch installs the qib driver which replaces the ipath driver in OFED-1.5. Maybe I missed some discussion of this. But what is the QIB driver? What are you planning to do to support qlogic HCAs for the mainline kernel? - R. ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
Re: [ewg] [PATCH] install.pl: Install QIB driver instead of Ipath
On Wed, 2009-07-08 at 17:29 -0700, Roland Dreier wrote: This patch installs the qib driver which replaces the ipath driver in OFED-1.5. Maybe I missed some discussion of this. But what is the QIB driver? What are you planning to do to support qlogic HCAs for the mainline kernel? - R. The ib_qib driver is a modified version of the ib_ipath driver with a lot of changes to support dual ports, APM, QDR, etc. It supports the older QLogic QLE SDR and DDR cards too. The plan is to submit the ib_qib driver upstream soon. It seemed better to rename the driver than try to patch the old driver since the patches were likely to be larger. At some point I would expect to remove the ib_ipath driver. For now, we are just disabling the ib_ipath compile/install. ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
