Jeff Garzik <jgarzik@xxxxxxxxx> :
[...]
> Have those already been tested?
Yes. Tester (damouse) included in Cc: list.
The patches improves the situation so that it is possible to bring the
interface up and send/receive traffic but something clearly smashes the
stack (if someone wants to check, .jpg panic and r8169 module available
at http://www.fr.zoreil.com/people/francois/misc/debug).
After the latest days of "patch/patch -R/change line foo into bar/...",
I have rediffed the whole serie of changes against 2.6.1 so M. Damouse can
test an identified set of patches and isolate the misbehaving one(s). It is
available at http://www.fr.zoreil.com/linux/kernel/2.6.x/2.6.1.
If people can reproduce the tests that M. Damouse made, it should look like:
apply r8169-dma-api-tx.patch
apply r8169-dma-api-rx-buffers.patch
apply r8169-dma-api-rx-buffers-ahum.patch
apply r8169-rx-fill-typo.patch
apply r8169-start-xmit-fixes.patch
apply r8169-dma-api-tx-buffers.patch
apply r8169-rx_copybreak.patch
-> So far, so good, no regression from classical driver
apply r8169-mac-phy-version.patch
apply r8169-buggy-devinitdata.patch
-> Seems fine but panics after a few ko of traffic
<blink>Confirmation, anyone ?</blink>
The set contains two extra/untested patches [*] wrt 2.6.1-bk1-netdev2.
No need to push these further until the current issues are fixed imho.
M. Pollock's problems look different:
- they do not depend on the driver used;
- they seem timing/smp related (mobile computer + p4 HT).
[*]
r8169-addr-high.patch
r8169-ethtool-introduction.patch
--
Ueimor
|