Some help about backporting a nic module to 2.6.32 longterm
Hi, I'm using the 2.6.32.x longterm series for our servers but we are facing a problem with the bnx2x driver module in our latest G7 HP blade servers, the module exists but it doenst ping and cant access any node in the network, i saw too that the broadcom and hp driver specs can't build on 2.6.32 kernel because they only support the 2.6.18 redhat series. The version maintained by CentOS/Redhat om 5.x release works but it is based on 2.6.18 kernel. My initial idea was pull the CentOS 6 kernel source (based on 2.6.32) and make a patch of the bnx2x driver for my kernel source, the patch applies but when i boot the kernel the version it remains the same, i saw that the /firmware directory has some bnx2x files on it, my question to you is that i couldnt find anywhere is how the .c file and the .fw correlates , or , how can i create a real backport of this driver so i can use an usable version of the driver for the longterm release? I'm starting to read Linux Device Drivers but i really don't know if this question will be answered on it, if you guys have more sources of information so i can read i'll be glad if send me some . Thanks in advance,
On Mon, Jan 09, 2012 at 07:19:18PM -0200, André Ferraz wrote:
Hi,
I'm using the 2.6.32.x longterm series for our servers but we are facing a problem with the bnx2x driver module in our latest G7 HP blade servers, the module exists but it doenst ping and cant access any node in the network, i saw too that the broadcom and hp driver specs can't build on 2.6.32 kernel because they only support the 2.6.18 redhat series. The version maintained by CentOS/Redhat om 5.x release works but it is based on 2.6.18 kernel.
My initial idea was pull the CentOS 6 kernel source (based on 2.6.32) and make a patch of the bnx2x driver for my kernel source, the patch applies but when i boot the kernel the version it remains the same, i saw that the /firmware directory has some bnx2x files on it, my question to you is that i couldnt find anywhere is how the .c file and the .fw correlates , or , how can i create a real backport of this driver so i can use an usable version of the driver for the longterm release?
Why not just use the 3.2 kernel release, where this should be fixed already, right? Once you start backporting "bits and pieces", you can quickly end up with an unmaintainable mess, not to mention something that no one, including the community, or any company, will ever support. greg k-h
Hi Greg, the problem is that i need to stay with the 2.6.32 grsec patchset for my servers, if i didn't have any dependencies like that sure i'll be using the 3.2 kernel. The idea is to just backport this device driver, the rest of the drivers works pretty well, but i didnt find any HowTo or some documentation specific to the process of update a driver on your kernel source. []s On Mon, 9 Jan 2012 14:49:51 -0800 Greg KH <greg@kroah.com> wrote:
On Mon, Jan 09, 2012 at 07:19:18PM -0200, André Ferraz wrote:
Hi,
I'm using the 2.6.32.x longterm series for our servers but we are facing a problem with the bnx2x driver module in our latest G7 HP blade servers, the module exists but it doenst ping and cant access any node in the network, i saw too that the broadcom and hp driver specs can't build on 2.6.32 kernel because they only support the 2.6.18 redhat series. The version maintained by CentOS/Redhat om 5.x release works but it is based on 2.6.18 kernel.
My initial idea was pull the CentOS 6 kernel source (based on 2.6.32) and make a patch of the bnx2x driver for my kernel source, the patch applies but when i boot the kernel the version it remains the same, i saw that the /firmware directory has some bnx2x files on it, my question to you is that i couldnt find anywhere is how the .c file and the .fw correlates , or , how can i create a real backport of this driver so i can use an usable version of the driver for the longterm release?
Why not just use the 3.2 kernel release, where this should be fixed already, right?
Once you start backporting "bits and pieces", you can quickly end up with an unmaintainable mess, not to mention something that no one, including the community, or any company, will ever support.
greg k-h
A: No. Q: Should I include quotations after my reply? http://daringfireball.net/2007/07/on_top On Mon, Jan 09, 2012 at 11:08:18PM -0200, André Ferraz wrote:
Hi Greg, the problem is that i need to stay with the 2.6.32 grsec patchset for my servers, if i didn't have any dependencies like that sure i'll be using the 3.2 kernel.
Why are you using grsec? Why has it not been updated in the many years since 2.6.32 was released?
The idea is to just backport this device driver, the rest of the drivers works pretty well, but i didnt find any HowTo or some documentation specific to the process of update a driver on your kernel source.
Just backporting a single driver, usually isn't that easy, as it relies on other parts of the kernel. The kernel is ment to be used as a "whole" release, picking and choosing is very tough at times, and you will be on your own. I don't recommend it at all. good luck, greg k-h
A: No. Q: Should I include quotations after my reply?
Sorry about that
Why are you using grsec? Why has it not been updated in the many years since 2.6.32 was released?
Grsec patchset brings some security features that i need in my servers, they are accessible for the clients via ssh and some of them gets hacked, they try to exploit the system and other things... and the project has patchet for the 3.1.8 kernel, but is a test branch, the stable branch is based on the 2.6.32 longterm (http://grsecurity.net/download_stable.php)
Just backporting a single driver, usually isn't that easy, as it relies on other parts of the kernel.
Indeed , but my problem now is to understand why still patching my kernel with the modifications of a CentOS 6 (just bnx2x driver) when i boot the kernel it still show me the old release version, the patch is applied but looks like that i'm missing some based on the firmware files that CentOS has on their kernel, thats why i asked you guys from the mailing list if there is some documentation that cold help me understand this
good luck,
Thanks Greg
On Wed, Jan 11, 2012 at 07:42:04PM -0200, André Ferraz wrote:
A: No. Q: Should I include quotations after my reply?
Sorry about that
Why are you using grsec? Why has it not been updated in the many years since 2.6.32 was released?
Grsec patchset brings some security features that i need in my servers, they are accessible for the clients via ssh and some of them gets hacked, they try to exploit the system and other things... and the project has patchet for the 3.1.8 kernel, but is a test branch, the stable branch is based on the 2.6.32 longterm (http://grsecurity.net/download_stable.php)
Well, I suggest you ask the grsec developers for a new version of the patch, surely they have updated it in the many years since 2.6.32 was released. You also might realize that most of those grsec "features" are already in the 3.2 kernel release, so you might not need that patchset at all anymore.
Just backporting a single driver, usually isn't that easy, as it relies on other parts of the kernel.
Indeed , but my problem now is to understand why still patching my kernel with the modifications of a CentOS 6 (just bnx2x driver) when i boot the kernel it still show me the old release version, the patch is applied but looks like that i'm missing some based on the firmware files that CentOS has on their kernel, thats why i asked you guys from the mailing list if there is some documentation that cold help me understand this
If you are using a CentOS kernel, you really need to go ask those developers about it, as it is a _very_ patched 2.6.32 kernel, not an upstream kernel.org version at all. good luck, greg k-h
participants (2)
-
André Ferraz -
Greg KH