linux-kernel - Re: 3.4.x regression: rtl8169: frequent resets

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 for Android: free password hash cracker in your pocket

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

Message-ID: <87fw9fp2e1.fsf@spindle.srvr.nix>
Date:	Thu, 28 Jun 2012 22:12:06 +0100
From:	Nix <nix@...eri.org.uk>
To:	Francois Romieu <romieu@...zoreil.com>
Cc:	netdev@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: 3.4.x regression: rtl8169: frequent resets

On 28 Jun 2012, Francois Romieu stated:

> Nix <nix@...eri.org.uk> :
>> I recently upgraded from 3.3.x to 3.4.4, and am now experiencing
>> networking problems with my desktop box's r8169 card. The symptoms are
>> that all traffic ceases for five to ten seconds, then the card appears
>> to reset and everything is back to normal -- until it happens again. It
>> can happen quite a lot:
>
> Can you try and revert 036dafa28da1e2565a8529de2ae663c37b7a0060 ?

I can try, but there's been a *lot* of code motion since then, 'git
revert' fails hilariously (trying to patch obviously the wrong places):
I'll have to do it by hand.

I'll try that tomorrow. (But, as before, it might be several days before
we know anything one way or the other. Assuming I can revert it without
fouling something else up.)

I'm not using BQL (yet, anyway).

I note that at some time (after the first reset?), my MTU either flipped
back to 1500, from its initial jumbo default, or simply refused to go
jumbo in the first place. I bring it up like so:

ip link set fastnet up multicast on txqueuelen 100 mtu 7200
ip addr add local 192.168.16.20/24 broadcast 192.168.16.255 dev fastnet

but its MTU is now shown as 1500 :( so at some point either jumbo frames
have stopped working or the reset is flipping them off. (It used to
work, with a warning yelling about how terribly dangerous jumbo frames
were because any attacker on the local subnet could subvert my machine.
Any attacker on the local subnet will be sitting in my lap and/or will
have root on the NFS server from which this machine is getting all its
data, so I don't care one jot about that. This may be because rx
checksumming is turned on by default, and as of last year that forces
jumbo frames off: I've turned that off and will see if jumbo frames
start working next time I bring the interface up. I *thought* my local
network was awful slow lately...)

> I would welcome a complete dmesg including the XID line from the
> r8169 driver.

Now that I can do :) it's long, so here's the relevant bit: complete
gzipped dmesg attached.

[    1.338060] r8169 Gigabit Ethernet driver 2.3LK-NAPI loaded
[    1.339700] r8169 0000:06:00.0: irq 70 for MSI/MSI-X
[    1.339793] r8169 0000:06:00.0: eth0: RTL8168c/8111c at 0xffffc90000048000, 00:24:8c:0f:64:18, XID 1c4000c0 IRQ 70
[    1.341389] r8169 0000:06:00.0: eth0: jumbo features [frames: 6128 bytes, tx checksumming: ko]

(the interface is renamed to 'fastnet' by udev a little later in the
boot process.)

Download attachment "d.gz" of type "application/octet-stream" (18208 bytes)