Applying e1000e patch to the Debian 2.6.26 kernel
Thomas Goirand
There's more and more e1000e hardware around these days, and I was
wondering if it was possible to have the attached patch applied to the
current kernel of Lenny. This patch, I made it by taking the sources
from 2.6.27 and back porting it. I tested it, and my ethernet e1000e was
seen and working. Maybe that could be added to the next point release of
Debian (Lenny and a half)? I think it's a quite safe patch...
Thanks for your attention,
Thomas
P.S: Please Cc: to me for this thread, I'm not registered to this list
(I know I shouldn't be asking this, sorry...).
Ben Hutchings
> Hi there,
>
> There's more and more e1000e hardware around these days, and I was
> wondering if it was possible to have the attached patch applied to the
> current kernel of Lenny. This patch, I made it by taking the sources
> from 2.6.27 and back porting it. I tested it, and my ethernet e1000e was
> seen and working. Maybe that could be added to the next point release of
> Debian
We normally backport specific bug fixes and small changes to support new
hardware, rather than updating drivers completely. Some driver changes
will depend on core changes in the kernel.
> (Lenny and a half)?
I don't know when that will be released, but it will use an entirely new
kernel version.
> I think it's a quite safe patch...
It's a large patch combining cleanup and functional changes, which is
always hard to review. Please instead identify which of the following
changes between 2.6.26 and 2.6.27 are needed:
95b866d e1000e: Fix incorrect debug warning
6f92a6a e1000e: update version from k4 to k6
717d438 e1000e: debug contention on NVM SWFLAG
4fa7553 e1000e: drop stats lock
23033fa e1000e: remove phy read from inside spinlock
a8f88ff e1000e: do not ever sleep in interrupt context
37f4023 e1000e: reset swflag after resetting hardware
4a77035 e1000e: write protect ICHx NVM to prevent malicious write/erase
05c550b e1000e: remove unnecessary snippet missed in prior check_options update
f8d59f7 e1000e: test for unusable MSI support
d53f706 e1000e: increase minimum frame size allowed
10f1b49 e1000e: Increase Tx timeout factor for 10Mbps
808ff67 e1000e: Use skb_copy_to_linear_data_offset introduced in 2.6.22
2d06cad e1000e: Set InterruptThrottleRate to default when invalid value used
56e1f82 e1000e: Return 1 instead of a non-zero value for link up indication
f0f422e e1000e: remove inapplicable test for ioport
c43bc57 e1000e: fix drv load issues
10aa4c0 e1000e: perform basic 82573 EEPROM checks for known issues
44defeb e1000e: convert ndev_ printks to something smaller
8d8bb39 dma-mapping: add the device argument to dma_mapping_error()
e8ebe3b e1000e: fix e1000_netpoll(), remove extraneous e1000_clean_tx_irq() call
d55b53f igb/ixgbe/e1000e: resolve tx multiqueue bug
78ed11a netdrv intel: always enable VLAN filtering except in promiscous mode
746b9f0 netdrv intel: disable VLAN filtering in promiscous mode
38b2219 netdrv: don't truncate VLAN TCI with VLAN stripping
6e4f6f6 e1000e: make ioport free
a5136e2 e1000e: allow VLAN devices to use TSO and TCP CSUM offload
I've put these individual changes in
http://womble.decadent.org.uk/tmp/e1000e-patches/ so you don't need to
use git to generate them.
Ben.
--
Ben Hutchings
Life would be so much easier if we could look at the source code.
maximilian attems
dannf likes to include tested driver updates,
just report a bug report with the severity important.
--
maks
--
To UNSUBSCRIBE, email to debian-ker...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Thomas Goirand
> We normally backport specific bug fixes and small changes to support new
> hardware, rather than updating drivers completely. Some driver changes
> will depend on core changes in the kernel.
>
>> (Lenny and a half)?
>
> I don't know when that will be released, but it will use an entirely new
> kernel version.
Do I still have a chance to have it included anytime soon in Debian?
Because that's the goal... It's really an annoying problem for us.
> It's a large patch combining cleanup and functional changes, which is
> always hard to review. Please instead identify which of the following
> changes between 2.6.26 and 2.6.27 are needed:
>
> 95b866d e1000e: Fix incorrect debug warning
> [...]
> a5136e2 e1000e: allow VLAN devices to use TSO and TCP CSUM offload
>
> I've put these individual changes in
> http://womble.decadent.org.uk/tmp/e1000e-patches/ so you don't need to
> use git to generate them.
>
> Ben.
Thanks a lot for the effort to put this all online for me. I got them
downloaded already locally, you can cleanup and delete these from your
web server if you want.
I can try the patches one by one, but that can take a long long time if
I have to recompile a full kernel package each time. What do you think
is the best approach for me to make quick tests? Just do a "make
modules_install" from the linux-source-2.6.26 folder (taken from the
linux-source-2.6 package), test, apply another patch, test, etc. ?
Also, what's your suggestion to test all this? Make a dichotomy test,
applying half of the patches, then 1/4, etc. until I can isolate what
patch(es) are needed? That's my first idea, and shouldn't take too long
if I can compile the e1000e module only and not the full kernel.
Thanks for your help,
Thomas
dann frazier
> Ben Hutchings wrote:
> > We normally backport specific bug fixes and small changes to support new
> > hardware, rather than updating drivers completely. Some driver changes
> > will depend on core changes in the kernel.
> >
> >> (Lenny and a half)?
> >
> > I don't know when that will be released, but it will use an entirely new
> > kernel version.
>
> Do I still have a chance to have it included anytime soon in Debian?
> Because that's the goal... It's really an annoying problem for us.
5.0.2 should release very soon, but there's time for 5.0.3.
> > It's a large patch combining cleanup and functional changes, which is
> > always hard to review. Please instead identify which of the following
> > changes between 2.6.26 and 2.6.27 are needed:
> >
> > 95b866d e1000e: Fix incorrect debug warning
> > [...]
> > a5136e2 e1000e: allow VLAN devices to use TSO and TCP CSUM offload
> >
> > I've put these individual changes in
> > http://womble.decadent.org.uk/tmp/e1000e-patches/ so you don't need to
> > use git to generate them.
> >
> > Ben.
>
> Thanks a lot for the effort to put this all online for me. I got them
> downloaded already locally, you can cleanup and delete these from your
> web server if you want.
>
> I can try the patches one by one, but that can take a long long time if
> I have to recompile a full kernel package each time. What do you think
> is the best approach for me to make quick tests? Just do a "make
> modules_install" from the linux-source-2.6.26 folder (taken from the
> linux-source-2.6 package), test, apply another patch, test, etc. ?
You shouldn't need to recompile the whole kernel every time - just do
it once, then run make again after each patch application/removal.
> Also, what's your suggestion to test all this? Make a dichotomy test,
> applying half of the patches, then 1/4, etc. until I can isolate what
> patch(es) are needed? That's my first idea, and shouldn't take too long
> if I can compile the e1000e module only and not the full kernel.
What is the problem you are seeing w/ the existing 2.6.26 kernel? I
didn't see any explicit support for new hardware in these changesets,
so I'm guessing the driver already loads but fails? The failure mode
might give us a hint.
> Thanks for your help,
>
> Thomas
>
>
--
dann frazier
Ben Hutchings
From: Ben Hutchings <b...@decadent.org.uk>
To: Thomas Goirand <tho...@goirand.fr>
Subject: Re: Applying e1000e patch to the Debian 2.6.26 kernel
Date: Sat, 13 Jun 2009 16:26:32 +0100
On Sat, 2009-06-13 at 22:57 +0800, Thomas Goirand wrote:
> Ben Hutchings wrote:
> > We normally backport specific bug fixes and small changes to support new
> > hardware, rather than updating drivers completely. Some driver changes
> > will depend on core changes in the kernel.
> >
> >> (Lenny and a half)?
> >
> > I don't know when that will be released, but it will use an entirely new
> > kernel version.
>
> Do I still have a chance to have it included anytime soon in Debian?
> Because that's the goal... It's really an annoying problem for us.
Unfortunately you have just missed the cut-off for stable update 5.0.2,
but there may be an update to stable-proposed-updates soon after, which
you could then add to your APT sources.
Alternately you can build and install e1000e separately from
e1000.sf.net.
> > It's a large patch combining cleanup and functional changes, which is
> > always hard to review. Please instead identify which of the following
> > changes between 2.6.26 and 2.6.27 are needed:
> >
> > 95b866d e1000e: Fix incorrect debug warning
> > [...]
> > a5136e2 e1000e: allow VLAN devices to use TSO and TCP CSUM offload
> >
> > I've put these individual changes in
> > http://womble.decadent.org.uk/tmp/e1000e-patches/ so you don't need to
> > use git to generate them.
> >
> > Ben.
>
> Thanks a lot for the effort to put this all online for me.
You're welcome. It's actually really easy to extract a patch series
like this from git.
> I got them
> downloaded already locally, you can cleanup and delete these from your
> web server if you want.
>
> I can try the patches one by one, but that can take a long long time if
> I have to recompile a full kernel package each time.
You won't.
> What do you think
> is the best approach for me to make quick tests? Just do a "make
> modules_install" from the linux-source-2.6.26 folder (taken from the
> linux-source-2.6 package), test, apply another patch, test, etc. ?
Once you've configured and built the kernel once, it should be as simple
as:
patch -p1 < some-patch
make # will rebuild just e1000e
rmmod e1000e
insmod drivers/net/e1000e/e1000e.ko
> Also, what's your suggestion to test all this? Make a dichotomy test,
> applying half of the patches, then 1/4, etc. until I can isolate what
> patch(es) are needed? That's my first idea, and shouldn't take too long
> if I can compile the e1000e module only and not the full kernel.
A lot of them are just formatting changes or adaptation to API changes,
and can immediately be discounted. Then you could do what you suggest
(this is commonly called bisection, not dichotomy) over the remainder.
Ben.
--
Ben Hutchings
Never attribute to conspiracy what can adequately be explained by stupidity.
Thomas Goirand
>>> 95b866d e1000e: Fix incorrect debug warning
>>> [...]
>>> a5136e2 e1000e: allow VLAN devices to use TSO and TCP CSUM offload
>>>
>>> I've put these individual changes in
>>> http://womble.decadent.org.uk/tmp/e1000e-patches/ so you don't need to
>>> use git to generate them.
Hi,
I started to try yesterday, and finished today, and I'm very surprised
here. I just used the package linux-source-2.6.26 from Lenny, unpacked
the resulting archive in /usr/src, did make-kpkg, dpkg -i of the
resulting image, mkinitrdfs, edited my grub menu.lst and rebooted. The I
was expecting my e1000e to not work at all. But it did work, without
applying any patch.
The issue here is NOT my laptop (in fact, I don't care my laptop, I run
the newest kernel 2.6.30 on it). I want to have the Debian kernel to
work on the core i7 boards of Supermicro, the X8STi-3F, that has 2
e1000e boards. Last time my employee Felix in Singapore tried the Debian
installer CD in our hardware supplier place in Singapore, it did NOT
recognize the network board.
So I'm wondering, did somebody applied some patches for e1000e between
the release of Lenny 5.01? Or maybe, the e1000e on the X8STi-3F is
different from the one of my Thinkpad t500? Is there even different
versions of the board at Intel?
I'd appreciate some pointers here. It's really so important for our
business to have this issue solved, and I guess that I'm not the only
one that desperately need to run the Debian Xen kernel with e1000e
(running custom made Xen kernels is not an option as we have too many
servers in production).
Thomas
dann frazier
Can you provide the bootlog of your machine when booting 1) the debian
kernel and 2) when booting your custom kernel?
--
dann frazier
Ben Hutchings
> So I'm wondering, did somebody applied some patches for e1000e between
> the release of Lenny 5.01? Or maybe, the e1000e on the X8STi-3F is
> different from the one of my Thinkpad t500? Is there even different
> versions of the board at Intel?
There are many slightly different chips handled by the e1000e driver. If
it was broken for all of them we would have fixed it before release! You
have to test on the specific model which the kernel from "lenny" doesn't
work on.
Ben.
--
Ben Hutchings
Reality is just a crutch for people who can't handle science fiction.
Thomas Goirand
> On Tue, Jun 16, 2009 at 12:50:34AM +0800, Thomas Goirand wrote:
> [...]
>> So I'm wondering, did somebody applied some patches for e1000e between
>> the release of Lenny 5.01? Or maybe, the e1000e on the X8STi-3F is
>> different from the one of my Thinkpad t500? Is there even different
>> versions of the board at Intel?
> [...]
>
> There are many slightly different chips handled by the e1000e driver. If
> it was broken for all of them we would have fixed it before release! You
> have to test on the specific model which the kernel from "lenny" doesn't
> work on.
>
> Ben.
That is quite what I think as well. Here's what I am up to.
1/ The Debian kernel, which USED to have no support for my Thinkpad
e1000e works fully now. Someone MUST have done something to the kernel,
because I'm 100% sure that at the time of Lenny, it was not working.
2/ On our last test on the Supermicro board, it did FAIL last week.
Now, I have asked my hardware supplier to put one of these X8STi-F
online in order to test with it, he has been very nice, and he said he
will. I'll be able to do a full test and report here.
Thanks to you all for helping me to find out what's going on!
Thomas
Thomas Goirand
> Ben Hutchings wrote:
>> On Tue, Jun 16, 2009 at 12:50:34AM +0800, Thomas Goirand wrote:
>> [...]
>>> So I'm wondering, did somebody applied some patches for e1000e between
>>> the release of Lenny 5.01? Or maybe, the e1000e on the X8STi-3F is
>>> different from the one of my Thinkpad t500? Is there even different
>>> versions of the board at Intel?
>> [...]
>>
>> There are many slightly different chips handled by the e1000e driver. If
>> it was broken for all of them we would have fixed it before release! You
>> have to test on the specific model which the kernel from "lenny" doesn't
>> work on.
>>
>> Ben.
>
> That is quite what I think as well. Here's what I am up to.
>
> 1/ The Debian kernel, which USED to have no support for my Thinkpad
> e1000e works fully now. Someone MUST have done something to the kernel,
> because I'm 100% sure that at the time of Lenny, it was not working.
> 2/ On our last test on the Supermicro board, it did FAIL last week.
>
> Now, I have asked my hardware supplier to put one of these X8STi-F
> online in order to test with it, he has been very nice, and he said he
> will. I'll be able to do a full test and report here.
>
> Thanks to you all for helping me to find out what's going on!
>
> Thomas
Hi again,
Finally, my hardware supplier in California has been VERY nice, and has
made it possible for me to have access to a server equipped with the
Supermicro X8STi-F motherboard that we want to use later on in
production. As the guy is really awesome, I want to name him publicly.
If you need any kind of hardware for servers, ask to talk to John Wu at
KingstarUSA in California. He will reply to you within minutes, and make
reasonable quotes. He will also be able to support you with any issue
(like now). Drop him a mail if you need, his is as Cc: here. Give him
some business, he deserves it!
Anyway, back to the patch. I have tried to apply all the patches that
Ben sent to me, and this is NOT ENOUGH to have the e1000e working. In
fact, we have to realize that, if it's still the same Ethernet
controller name (I mean e1000e), it's quite a different controller. The
one on that motherboard is a 82574L, which seems to be a more recent
model. The driver source in the kernel has many specificities for it. So
if you guys, at the kernel team, decide to add and maintain a patch,
this will NOT be a tiny one just adding new PCI IDs...
Please read (quickly) the diff file that I have attached, it shows
better than anything else what I'm talking about. It was done the
"wrong" way: taking the sources from 2.6.29 (from backports.org), making
a diff -r -u of the e1000e folder, and apply corrections until it
compiles, including some kernel API changes that I had to backport. It's
a bit ugly, but IT DOES work very well, and I'm quite happy that I have
at least the solution to apply this patch to the Debian kernel sources.
Now, if you still think that there is a possibility to have a patch
included (which would be, to my eyes, a very wise decision), I guess
that I'd need to apply patches from Git again in order to make it
cleaner and smaller. I have searched, and couldn't find the gitweb for
the e1000e project.
Ben Hutchings, would you be able to do what you did before: give me a
patch collection that I can apply one by one, until I can see the driver
working? This time I need MORE patches, at least until kernel 2.6.28 (as
the driver appeared to work with the backported Debian CD including
2.6.28 kernel). Then I'll do my best to make a much smaller patch than
the one that I have attached, and hopefully, have it accepted by you guys.
Thanks for your time reading this, and the support of my work here,
Thomas
John Wu
Good afternoon. I deeply appreciate for this, and I will always try my
very best working with you or any customers.
Our company web site is www.kingstarusa.com, and yes, my e-mail address
is jo...@kingstarusa.com. I sincerely look forward to hearing from you for
any questions or quote requests. Have a nice weekend.
Best Regards!
John Wu
King Star Computer
1259 Reamwood Avenue
Sunnyvale, CA 94089
TEL: 408-736-8590 ex. 107
FAX: 408-736-4151
Jo...@kingstarusa.com
- Supermicro Preferred System Provider.
- Asus & Tyan Approved System Integrator.
- Intel Premier Channel Partner 2009.
- AMD Solution Provider.
- nVidia Authorized System Integrator, Tesla C1060, S1070, etc.
- Lenovo Approved Solution Partner & Reseller.
- InforTrend FC, SAS, SATA, SCSI, iSCSI Storage Provider.
-----Original Message-----
From: Thomas Goirand [mailto:tho...@goirand.fr]
Sent: Friday, June 19, 2009 1:52 PM
To: Ben Hutchings
Cc: dann frazier; debian...@lists.debian.org; in...@gplhost.com; John Wu
Subject: Re: Applying e1000e patch to the Debian 2.6.26 kernel
Hi again,
Thomas
dann frazier
Please try the attached patches against a vanilla Debian 2.6.26.
I haven't looked yet to see if they are reasonable for a stable
release.
> Thanks for your time reading this, and the support of my work here,
> Thomas
--
dann frazier
Thomas Goirand
> oops - sorry, that was the wrong version. updated patches attached.
EXCELLENT! That actually seem to work!!!
Will that be included in the next Debian kernel release?
dann frazier
> dann frazier wrote:
> > oops - sorry, that was the wrong version. updated patches attached.
>
> EXCELLENT! That actually seem to work!!!
Thanks for the feedback
> Will that be included in the next Debian kernel release?
Can't say yet - we will need to review it first to assess the risk of
regression.
--
dann frazier