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

[Daniel Goller <morfic@gmail.com>]

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.
>
>