Realtek 8169 Lock-ups

Hum... where are we on this?

Francois made a few key fixes before he left, which I've included in the latest netdev patch...

http://www.kernel.org/pub/linux/kernel/people/jgarzik/patchkits/2.6/2.6.1-bk1-netdev2.patch.bz2

Have those already been tested?

Thanks,

Jeff

Jeff Garzik <[email protected]> :
[...]

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

Re,

latest pile of r8169 related patches against 2.6.1-bk1 available at
http://www.fr.zoreil.com/linux/kernel/2.6.x/2.6.1-bk1

If you want to help:
apply r8169-dma-api-tx.patch
apply r8169-dma-api-rx-buffers.patch
apply r8169-dma-api-rx-buffers-ahum.patch
apply r8169-dma-api-rx-buffers-argl.patch <-- bug removed, sing and rejoice ! apply r8169-rx-fill-typo.patch
apply r8169-start-xmit-fixes.patch
apply r8169-dma-api-tx-buffers.patch
apply r8169-rx_copybreak.patch

-> does it work here ?

apply r8169-mac-phy-version.patch
apply r8169-buggy-devinitdata.patch

-> and here ?

--
Ueimor

Re,

latest pile of r8169 related patches against 2.6.1-bk1 available at:
http://www.fr.zoreil.com/linux/kernel/2.6.x/2.6.1-bk1-a

Credits go to [email protected] for a bug removal in r8169-init_one.patch.

No change of behavior expected for SMP so far.

--
Ueimor

[email protected] <[email protected]> :
[...]

Well, it is not clear that the "Too muck work at interrupt" recovery logic really recovers much (be it for vanilla or modified r8169 driver).

Does it behave differently if you make the "while (boguscnt > 0);" always true in rtl8169_interrupt() and ask for a finite number of packets (say pgset "count 1000" or more) ?

--
Ueimor

Francois,

Many apologies. It was my own stupidity. I've sorted things out, and am now running 2.6.1-bk1 with your patchset.

With SMP enabled, I get a timeout from the watchdog and my network connection becomes unresponsive. In fact, during boot the DHCPC server times out looking for an IP address.

I tried changing (boguscnt > 0) to (1 > 0) and this made no difference.

Both of these tests were run with 1000 9014-byte packets.

Even with SMP disabled, and even with the patches not applied, there seems to be problems (this is on 2.6.1-bk1). Perhaps I just wasn't seeing them earlier. Basically, sometimes the packet generator completes normally the first time. Sometimes, it does not. Either way, by the second run of the packet generator, the network device stops responding.

I will try the most recent kernel and patch set, and see what problems I get.

Doug.