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