linux-kernel - Re: 2.6.27.19 + 28.7: network timeouts for r8169 and 8139too

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:	Fri, 6 Mar 2009 01:17:39 +0100
From:	Michael Büker <m.bueker@...lin.de>
To:	Francois Romieu <romieu@...zoreil.com>
Cc:	linux-kernel@...r.kernel.org
Subject: Re: 2.6.27.19 + 28.7: network timeouts for r8169 and 8139too

On Wednesday 04 March 2009, you wrote:
> The kernel displays a scary warning, I can guess that it is almost surely
> associated with some loss of network connectivity for a few seconds at the
> very least but it is a bit hard to figure the real scale of your problem.

I'll try to be more precise :)

I can readily reproduce the symptoms by initiating the scp transfer of a large 
file. The transfer will stall somewhere between ~2MB and ~50MB of data 
transferred. After that, the results differ for the two network cards:
With the r8169 card, the transfer never recovers, but after ~1min to ~2min, 
there is a "link up" message in dmesg and the network will be back up.
With the 8139too card, the stall will be no longer than ~30sec and the 
transfer will resume. There is also a "link up" message upon the network's 
resurrection.

I have been able to verify that this problem does _not_ occur when using the 
same network (and target server) through my wireless USB adapter. The average 
speed this way is lower, however - ~690kb/s as opposed to ~1.8MB/s over the 
wire (the reason this is so much lower than the physical limit for both types 
of connections probably lies in the fact that we're dealing with a pentium2 
that has to do ssl encryption on the fly).

The two dmesg files I have attached contain the log of the following actions:
1. Booting with the respective card inserted
2. Initializing the file transfer
3. Abort the transfer after it's been dead for ~10sec
4. Wait for the network to come back up

The two attached lspci outputs were recorded with the two cards inserted 
respectively.

> Can you identify a kernel which worked flawlessly ?

I'm quite sure I did not experience this problem with the last kernel I ran, 
which was 2.6.25.15.

Hope to help!
Michael

-- 
I came for the quality, but I stayed for the freedom.
- Sean Neakums

View attachment "dmesg_8139too" of type "text/plain" (18296 bytes)

View attachment "dmesg_r8169" of type "text/plain" (17356 bytes)

View attachment "lspci_8139too" of type "text/plain" (6403 bytes)

View attachment "lspci_r8169" of type "text/plain" (6482 bytes)