Re: staging/et131x Driver Transmits but does not Receive Packets

From: Daniel Goller
Date: Sun Jan 10 2010 - 20:30:20 EST

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



Going to get 2.6.29 and 2.6.30 now.
On Sun, Jan 10, 2010 at 6:17 PM, Alan Cox <alan@xxxxxxxxxxxxxxxxxxx> 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@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at