LTC Owner is: firstname.lastname@example.org
LTC Originator is: email@example.com
The current RHEL 5 RT NetXen driver is incompatible with the latest firmware.
The NetXen development team has posted some major updates to the driver to the
netdev mailing list including firmware compatibility, driver stability, and
support for multi port cards.
When these patches get included into the netdev git tree in their final form, we
need to pull them into the RHEL 5 RT tree.
Sorry to have to ask, but what is the NetXen driver - and why is it needed.
Is this *really* a Xen related driver? I ask because we don't support Xen in
conjunction with RT.
Are these patches included in the upstream 2.6.21 kernel? ie, do we need to
pull them into our .20 based kernel now, or can we just wait a month and inherit
them in .21?
----- Additional Comments From firstname.lastname@example.org (prefers email at email@example.com) 2007-04-19 10:23 EDT -------
> Sorry to have to ask, but what is the NetXen driver - and why is it needed.
No, it's my fault for assuming that you knew about the product. NetXen is the
maker of 10Gb Ethernet cards, some of which fit into IBM BladeCenter blades as
> Is this *really* a Xen related driver? I ask because we don't support Xen in
> conjunction with RT.
Not related to Xen at all.
> Are these patches included in the upstream 2.6.21 kernel? ie, do we need to
> pull them into our .20 based kernel now, or can we just wait a month and
inherit them in .21?
The driver was originally included in 2.6.20 (I believe) but has been under
heavy development over the past few months. The latest driver can be obtained
via the netdev-git tree plus a series of 7 patches that were recently posted to
the netdev mailing list (and are due to be re-posted after some minor fixes soon).
I don't think they will make it into 2.6.21 because they aren't in any of the RC
kernels. So yes, we will have to 'backport' them from 2.6.22-rcX or from the
netdev git tree once they are committed.
ok, we can incorporate provided:
- the patches are contained to the driver itself - and don't reach its tentacles
out into other kludgy areas
- there is an understanding that the inclusion is provisional. meaning that we
can include it under the assumption it will get in upstream, but if it doesn't
appear to be imminently accepted at the point we make the first real product
release, then we may have to yank it out. (we'll give it the benefit of the
doubt for now).
- no need to bother with a 2.6.20 version as we'll be rebasing soon
Once we come out with our first 2.6.21 based kernel for you, please then provide
the patches. Or if the patches are well contained and won't conflict with other
patches, then just post them here as well.
In the interim, I'm setting the bugzilla into NEEDINFO state until the patches
matched to our 2.6.21 appear.
----- Additional Comments From firstname.lastname@example.org (prefers email at email@example.com) 2007-05-15 19:06 EDT -------
Most of the netxen driver updates have hit Linus' git tree. There are still
some powerpc updates that have not. My question to RedHat is do we want to wait
for those updates, or shall I direct you to just pull from Linus' tree now and
supply you with a backport patch from 2.6.22-rcX to 2.6.21?
I haven't tested the latest git netxen drivers in a while, but last time I
tested them they were working. Before we have you grab the latest stuff, I will
test again to make sure all is in order.
If there are ppc updates missing, thats irrelevant as we aren't supporting that
arch. So, if the rest of the driver is ready, please proceed to backport to .21
and test it built in with our source rpms for our .21 variant. After doing that
you can provide us the driver to incorporate.
Setting bug state to NEEDINFO until the above backport/test is done.
----- Additional Comments From firstname.lastname@example.org (prefers email at email@example.com) 2007-05-18 11:03 EDT -------
I just tested the most recent upstream version of the netxen driver and it
didn't work. So there must be more than the ppc fixes that are in the
outstanding patchset. Jeff Garzik just nacked a patch that seems to fix the
problem because it undid some endian fixes. So I guess we are still waiting for
this 'Updates for register access routines' patch to get reworked by the netxen
folks and resubmitted to netdev.
----- Additional Comments From firstname.lastname@example.org (prefers email at email@example.com) 2007-05-24 09:57 EDT -------
I was told that the RedHat folks were worried about destabilizing the driver by
pulling in new code. Just as a data point, the current NetXen driver in
RHEL5-rt causes my machine to panic when I try to bring up an interface. Some
time when that machine is not in use otherwise, I will post the panic message if
you want. But suffice it to say, just about any code updates will be better
than that. :)
The reason I didn't bring this up earlier is because I figured that with the new
code coming in for this bug, the panic would go away.
----- Additional Comments From firstname.lastname@example.org (prefers email at email@example.com) 2007-05-24 14:38 EDT -------
I must have been mistaken about the crash messages. I am not seeing any crashes
with 2.6.21-14.el5rt -- but the driver still doesn't work, which is why we will
have to update it when the NetXen folks get all their patches accepted into the
Sorry for the scare.
What |Removed |Added
Summary|RH236869- NetXen driver |RH236869- [FOCUS] NetXen
|needs to be updated |driver needs to be updated
------- Additional Comments From firstname.lastname@example.org 2007-06-19 13:10 EDT -------
Marking P1 and FOCUS, this is where active work is being done, although Bug
35547 is the SR2 counterpart to this bug.
----- Additional Comments From email@example.com (prefers email at firstname.lastname@example.org) 2007-06-19 19:27 EDT -------
(The last comment was mis-placed.)
Vernon: When you get a chance, can you see about sending RH a patch for the
NetXen bits that are not in 2.6.21, but are needed for functionality?
FYI: There are three extra patches that got put in mainline tree for NetXen:
Here is the ACK:
* RESEND [PATCH 1/3] NetXen: Fix issue of MSI not working correctly
* RESEND [PATCH 2/3] NetXen: Support per PCI-function interrupt mask registers
* RESEND [PATCH 3/3] NetXen: Graceful teardown of interface and hardware upon
----- Additional Comments From email@example.com (prefers email at firstname.lastname@example.org) 2007-07-02 16:08 EDT -------
The latest mainline git + these three patches (which are queued to go to Linus'
tree) plus a patch to backport it to 2.6.21.x works fine for me. I tested this
driver and found it to be the same (performance wise) as older drivers we have
I am not sure how you want to proceed here... Two easy routes would be to 1)
wait for the patches to hit Linus' git three and pull the entire driver from
there, 2) grab the current driver from Linus' tree and apply these three patches
to it. After either one of these, then you could apply the backport patch so it
will compile against the 2.6.21.x kernel.
Created attachment 158374 [details]
----- Additional Comments From email@example.com (prefers email at firstname.lastname@example.org) 2007-07-02 16:10 EDT -------
Patch to backport latest mainline netxen driver to 2.6.21.x kernels
Created attachment 158378 [details]
What |Removed |Added
Attachment #29001|0 |1
is obsolete| |
------- Additional Comments From email@example.com (prefers email at firstname.lastname@example.org) 2007-07-02 16:30 EDT -------
NetXen driver backport patch for mainline to 2.6.21.x
It appears that while the patch itself was correct, I forgot to update the
comments at the top of the patch. Here is a patch with updated comments.
Sorry for the confusion.
Created attachment 158823 [details]
------- Additional Comments From email@example.com (prefers email at firstname.lastname@example.org) 2007-07-09 19:58 EDT -------
(In reply to comment #26)
> NetXen driver backport patch for mainline to 2.6.21.x
Today I copied the NetXen driver from the 2.6.22 mainline kernel, patched it
with the patch supplied 2 comments ago and built it against the 2.6.21-31.el5rt
kernel. As long as other previous versions of the NetXen driver had not been
loaded since boot, this driver worked just fine (i.e. delete the 2.6.21-31.el5rt
netxen_nic module and reboot).
I ran some basic tests: ping, throughput, and driver loading/unloading. The
driver seems very stable and is has better performance than previous versions
that I have tested. I believe that the 2.6.22 mainline version of the NetXen
driver (plus the backport for 2.6.21*) is ready for inclusion into RHEL5-RT.
Assigning to Clark to incorporate this driver patch.
We discussed this in a weekly call on July 9, but I'd like to reiterate it here
so that everyone has the correct expectations.
We do intend to incorporate this patch in the 2.6.21 based RHEL-RT kernel.
(When we rebase to .22 this patch will no longer be needed as its upstream.)
The matter of getting netxen included in the standard RHEL5 maintenance stream
(ie 5.1, 5.2...) must be tracked separately. ie, just because we put it in
RHEL-RT doesn't mean it is (or is not) in 5.1, 5.2... This is relevant here
because the standard RHEL5 product is the installation prerequisite prior to
plopping in the RT kernel. Also the standard RHEL5 kdump kernel is used in the
There is a bug against 5.1 tracking its inclusion: bug #231724. That indicates
that an early version of the netxen driver did get included in RHEL5.1 - which
is good news. What I'm not completely clear about is whether in RHEL5.1 netxen
is being labeled as "fully supported" vs "tech preview". Where tech preview
basically means "being supplied primarily for testing purposes, may not be fully
baked - give it a try and report bugs so hopefully we can gain confidence to
promote it fully supported status in 5.2." I'm checking on that distinction...
Created attachment 234421 [details]
Netxen backport to 2.6.21
This applies ontop of the NetXen 2.6.23 patch
Created attachment 234431 [details]
Netxen 2.6.23 patch
Patch for updated netxen 2.6.23 code.
We've got a few patches attached to this BZ and I'd like to be sure that I'm
grabbing the right one for the right kernel tree. It looks like the patch at #25
is the one I should apply to our 2.6.21-based tree (currently
It also looks like the patch at #26 is what I should use for our 2.6.23-based
tree (currently kernel-rt-2.6.23-2.el5rt).
Have I got that right?
Also, do the last two patches obsolete the previous three from back in August?
Clark: Just to clarify, we're using the last two patches, #25 and #26 both (in
order) applied on top of the 2.6.21-39 kernel.
Oh wait.. there's been some mirroing order issues.. the ordering is actually #26
applies first then #25.
Patched applied to -44 kernel.