netdev - Re: r8169 driver from kernel 5.0 crashing

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:   Thu, 14 Mar 2019 07:43:59 +0100
From:   Heiner Kallweit <hkallweit1@...il.com>
To:     VDR User <user.vdr@...il.com>
Cc:     netdev@...r.kernel.org
Subject: Re: r8169 driver from kernel 5.0 crashing

On 14.03.2019 04:04, VDR User wrote:
> Hi Heiner,
> 
> Thanks for your response. Request info follows..
> 
>>> Hi, after updating to kernel 5.0, the nic driver (r8169) has been
>>> crashing whenever I start using heavy traffic on it (for example,
>>> xferring large files to the box across my lan). The destination
>>> harddrive may be sleeping and need to spin-up, or not, but the box
>>> itself does not suspend/hibernate. The nic becomes completely
>>> unresponsive and all connections to the box drop. After what I think
>>> is several minutes, the connection comes back to life. The problem
>>> happens consistently but seemingly not consistently at the same point.
>>> For example, I can xfer a few 4gb files and it will crash at around
>>> 2-3gb on the first file. The next time it might not crash until 2-3gb
>>> on the second file.Prior to kernel 5.0 I was using 4.19.12 and this
>>> problem didn't occur. I have since downgraded back to 4.19.12 pending
>>> what response this post gets.
>>>
>> Thanks for the report. Helpful would be:
>> - full dmesg output
> 
> Added as attachment.
> 
>> - "lspci -vv" output (as root) for the network card
> 
[...]
>> Can you test a recent 4.20 kernel? This would narrow down the number
>> of potentially problematic patches.
> 
> I compiled and test 4.20.15 and didn't experience any crashing. I then
> switched back to 5.0.0 and this time I had to transfer significantly
> more until the crash occured. I'm not sure but it seems like the
> crashes happen when there's both outgoing & incoming traffic
> simultaneously. Is the dmesg crash info helpful at all?
> 
Thanks for the additional info and for testing 4.20.15.
To rule out that the issue is caused by a regression in network or
some other subsystem: Can you take the r8169.c from 4.20.15 and test
it on top of 5.0?
Meanwhile I'll look at the changes in the driver between 4.20 and 5.0.

> Thanks,
> Derek
> 
Heiner