Messages in this thread | | | Date | Sun, 10 Jan 2010 19:30:04 -0600 | Subject | Re: staging/et131x Driver Transmits but does not Receive Packets | From | Daniel Goller <> |
| |
I can not claim this is a regression (for myself), i just purchased the Device late December, when i found Nick Bowles' report of a regression (for him, it is) None of the kernel versions he reports working for him have worked for me. (.31 and .32) So i wouldn't quite know where to start. He said it has been working since 2.6.29 (for him), i could go this far back and see if 2.6.29 or 2.6.30 build and work for me, should i be able to use it with either, i could go forward until it no longer works and report that.
Is there anything that could be considered until then, based on the fact that he has a desktop PCI-e card while i have a laptop 34mm ExpressCard?
Thanks,
Daniel
Going to get 2.6.29 and 2.6.30 now. On Sun, Jan 10, 2010 at 6:17 PM, Alan Cox <alan@lxorguk.ukuu.org.uk> wrote: >> I will gladly provide any further info you require to look into this. >> >> Thank you in advance for your time, > > There are a huge series of small patches applied to the driver so the > first step to finding which one broke your card is to find which release > or rc it breaks upon and then to narrow down to which patch. > > The easiest way if you don't mind a lot of building is to use the git > tree and git bisect. > > The basic idea is to pull a kernel git tree (so that it has all the > patches and meta data) then do > > git-bisect reset # Starting a new bisect > git-bisect start > git-bisect good v2.6.31-rc1 # Or whatever you know worked (later > # the better) > > git-bisect bad v2.6.32-rc3 # Earliest you know is broken (or miss > # version for 'current') > > > It'll then generate a tree half way between the two > > Then build a kernel and test it. If it works > > git-bisect good > > If not > > git-bisect bad > > and it'll pick another spot half way between the two until it pins down > the offender. > > If you get one that won't build/fails for some other reason you can > git-bisect skip > > to bump on one > > It'll quite rapidly pin down the offending change if you've got a > repeatable bug. > > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |