Bug 450470 - RDMA kernel stack initializing package
Summary: RDMA kernel stack initializing package
Keywords:
Status: CLOSED NEXTRELEASE
Alias: None
Product: Fedora
Classification: Fedora
Component: Package Review
Version: rawhide
Hardware: noarch
OS: Linux
low
low
Target Milestone: ---
Assignee: Ed Hill
QA Contact: Fedora Extras Quality Assurance
URL: http://people.redhat.com/dledford/Inf...
Whiteboard:
Depends On:
Blocks: 450476 450477 450481 451095
TreeView+ depends on / blocked
 
Reported: 2008-06-08 22:15 UTC by Doug Ledford
Modified: 2009-04-10 11:53 UTC (History)
5 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2009-04-10 11:53:58 UTC
Type: ---
Embargoed:
ed: fedora-review+
kevin: fedora-cvs+


Attachments (Terms of Use)

Description Doug Ledford 2008-06-08 22:15:21 UTC
This package provides an init script and a config file and an awk script and
some udev rules that are needed to properly setup the kernel InfiniBand/iWARP
modules at bootup or anytime someone wants to reload the stack.  It's generally
needed in order to get all the proper modules loaded for things like IPoIB to
work smoothly as there is no good means of mapping from things like ib0 network
configuration to actual hardware module without hacking up modprobe to know
things about the IB stack like it does about the SCSI stack (such as loading sdX
devices requires scsi_hostadapter* to be loaded too, same goes here, loading ib*
devices would require the addition of an rdma_hostadapter concept to modprobe).
 It seems a better idea to implement the logic here than to add another specific
hack to modprobe et. al.

Comment 1 Doug Ledford 2008-06-08 22:17:21 UTC
Package can be found under

http://people.redhat.com/dledford/Infiniband/f10/noarch/

Comment 2 Doug Ledford 2008-06-08 23:38:14 UTC
src rpm can be found under

http://people.redhat.com/dledford/Infiniband/f10/SRPMS/

Comment 3 Bill Nottingham 2008-06-09 14:19:28 UTC
Not necessarily *package* review comments:

- The udev in Fedora is new enough that you should be able to do add
--attr-match or --subsystem-match to your udevtrigger call so it doesn't cause a
retrigger of everything.
- Shouldn't those chipset errata be in PCI quirks (and the MTRR in DMI quirks)?


Comment 4 Doug Ledford 2008-06-09 17:47:55 UTC
OK, I'll look into the match options with udev.

As for the chipset errata, I'll look into it.

As for the MTRR, I don't have anywhere near an exhaustive list of machines that
do this, and since it only shows up as bad performance on ib_ipath or on a
mmaped video frame buffer, I doubt I'm going to get an exhaustive list.  So, the
awk script works, and it's not tied to a list of machines, and it also allows
people to test if it helps since I wasn't 100% sure of the correctness of doing
this on all machines that punch out mtrr holes.

Comment 5 Doug Ledford 2008-06-09 22:09:33 UTC
I've uploaded a new version of the package.  One of the pci errata things could
be done as a quirk (but isn't yet), the other I'm not so sure about as it would
require looking for a specific model and revision of hardware behind a specific
model of pci bridge and then applying the quirk, most of the kernel quirks don't
like being tied combinationally like that.  The udevtrigger line now works (and
what to match against is a bit obtuse, but I got it working and it now only does
a trigger on pci based devices with no driver and that are either class NETWORK
or INFINIBAND).

Comment 6 Ed Hill 2008-06-19 20:44:15 UTC
I built, installed, and tested this package on an F8 x86_64 system and it 
seems to work correctly.  I do *not* understand udev well enough to say  
whether the rules are correct but they do look reasonable -- esp. compared
the the OFED docs.

Here is a quick review:

GOOD:
+ rpmlint reports a few ignorable warnings and an error:
    rdma.noarch: W: no-documentation
    rdma.noarch: W: non-conffile-in-etc /etc/rdma/fixup-mtrr.awk
    rdma.noarch: W: non-conffile-in-etc /etc/udev/rules.d/90-rdma.rules
    rdma.noarch: W: no-url-tag
    rdma.noarch: E: malformed-line-in-lsb-comment-block #
+ naming looks OK
+ license is OK and correctly not included
+ spec is legible, macros look sane
+ compiles and installs on F8 x86_64
+ dir ownership looks OK

NEEDSWORK:
+ please remove the "blank" line which fixes the rpmlint error:

=== trivial patch ===
--- rdma.ORIG   2008-06-19 16:29:58.000000000 -0400
+++ rdma        2008-06-19 16:30:18.000000000 -0400
@@ -12,7 +12,6 @@
 # Required-Stop: $network $srpd $opensm
 # Short-Description: Loads and unloads the InfiniBand and iWARP kernel modules
 # Description: Loads and unloads the InfiniBand and iWARP kernel modules
-#
 ### END INIT INFO
 
 CONFIG=/etc/rdma/rdma.conf
=== trivial patch ===



Comment 7 Doug Ledford 2008-06-20 01:18:17 UTC
New rpm uploaded over the top of the old rpm (meaning you might need to flush
your web cache/proxy to get the new rpm) that solves the rpmlint error (empty
line removed from rdma.init).

Comment 8 Martin-Gomez Pablo 2008-06-26 20:03:16 UTC
The package and the spec files seem good to me. Just the name rdma should be
replace by the macro %{name}.

Comment 9 Ed Hill 2008-06-26 20:29:14 UTC
I don't see any blockers here so its APPROVED.

And sorry for the delay responding!

Comment 10 Doug Ledford 2008-06-26 20:52:52 UTC
Awesome.  I've updated the spec file to use the %{name} macro more, but since
this is a case where the package itself is the upstream source, no one should be
changing the name on us ;-)

New Package CVS Request
=======================
Package Name: rdma
Short Description: Infiniband/iWARP Kernel Module Initializer
Owners: dledford
Branches: F-8 F-9
InitialCC:
Cvsextras Commits: yes


Comment 11 Kevin Fenzi 2008-06-27 16:58:06 UTC
cvs done.


Note You need to log in before you can comment on or make changes to this bug.