netdev - Re: WoL broken in r8169.c since kernel 4.19

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]

Message-ID: <773e213a-1428-51c2-7bff-f83597e72ae4@gmail.com>
Date:   Sat, 12 Jan 2019 21:44:41 +0100
From:   Heiner Kallweit <hkallweit1@...il.com>
To:     Marc Haber <mh+debian-packages@...schlus.de>
Cc:     "netdev@...r.kernel.org" <netdev@...r.kernel.org>
Subject: Re: WoL broken in r8169.c since kernel 4.19

On 12.01.2019 21:28, Heiner Kallweit wrote:
> On 12.01.2019 21:08, Marc Haber wrote:
>> Hi,
>>
>> I am writing to all people who have commits in r8169.c between the v4.18
>> and v4.19 tags in the Linux kernel. Please ignore as appropriate. If
>> you'd prefer that to be on a mailing list, please indicate on which list
>> you want to have that, and I'll resend.
>>
> It should be cc'ed to the netdev mailing list, as listed in MAINTAINERS.
> 
>> My desktop copmuter has the following network interface:
>>
>> 06:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 06)
>>         Subsystem: ASUSTeK Computer Inc. P8P67 and other motherboards
>>         Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx+
>>         Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
>>         Latency: 0, Cache Line Size: 64 bytes
>>         Interrupt: pin A routed to IRQ 17
>>         NUMA node: 0
>>         Region 0: I/O ports at e800 [size=256]
>>         Region 2: Memory at fdfff000 (64-bit, prefetchable) [size=4K]
>>         Region 4: Memory at fdff8000 (64-bit, prefetchable) [size=16K]
>>         Capabilities: <access denied>
>>         Kernel driver in use: r8169
>>         Kernel modules: r8169
>>
> Unfortunately there's different chip versions with the same description.
> Please provide the result of "dmesg | grep XID".
> 
>> I regularly buíld a VPN tunnel to my local network from 'on the road'
>> and use WoL to wake up the desktop box when I need it.
>>
>> Since kernel 4.19, that does not work any more, the desktop remains
>> suspended when I send it a magic packet. This still applies to 4.20.1,
>> and it still works with any 4.18 kernel.
>>
> WoL works perfectly fine here with r8169 from runtime-suspend and
> from S3. How do you enable WoL? And which WoL method do you use
> (magic packet or ..) ?
> Please provide a register dump (ethtool -d <if>).
> 
Sorry, missed that you mentioned "magic packet". So one question is
answered.
Do you want to wake the system from S3 or S5? If waking from S5 fails,
does waking from S3 work?

>> I transplanted the 4.18 r8169.c into 4.20.1, and then WoL worked again.
>> Thus, the issue must have been introduced between 4.18 and 4.19.
>>
>> Does anybody of you have an idea how to find the issue in the 4.20 code?
>>
>> I have seen 648458fe97b5c0630435fa2b2cd65ba57ceb18e0 in 4.19.14 and
>> tried applying it to 4.20.1 (was necessary to do it manually because the
>> patch wouldn't apply), but that one didn't help.
>>
>> 4.19.14, which has a WoL-related patch applied, doesn't wake on LAN as
>> well.
>>
>> I tried bisecting for r8169.c between v4.18 and v4.19, but right the
>> first step didn't even boot far enough for the disk password prompt, so
>> I am at a loss here.
>>
>> Any ideas?
>>
>> Greetings
>> Marc
>>
>>
> Heiner
>