On Sat, Jun 13, 2009 at 10:57:10PM +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.

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


-- 
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Reply via email to