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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Sun, 10 Jan 2010 19:30:04 -0600
From:	Daniel Goller <morfic@...il.com>
To:	linux-kernel@...r.kernel.org
Cc:	Alan Cox <alan@...rguk.ukuu.org.uk>
Subject: Re: staging/et131x Driver Transmits but does not Receive Packets

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@...rguk.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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/