Date:   Tue, 22 Jan 2019 19:47:45 +0100
From:   Heiner Kallweit <hkallweit1@...il.com>
To:     Marc Haber <mh+netdev@...schlus.de>
Cc:     "netdev@...r.kernel.org" <netdev@...r.kernel.org>
Subject: Re: WoL broken in r8169.c since kernel 4.19

On 22.01.2019 17:10, Marc Haber wrote:
> On Sun, Jan 13, 2019 at 05:19:41PM +0100, Heiner Kallweit wrote:
>> I assume you want to wake the system from S5 (poweroff).
> 
> No. The machine is almost never completely powered down.
> 
>> Does is wake from S3 (suspend-to-RAM) ? You can trigger this with
>> "systemctl suspend".
> 
> That's what I am doing, with the behavior I reported: No reaction to
> magic packet with the 4.20 driver, waking up from suspend to ram with a
> current kernel with 4.18's r8169.c transplanted.
> 
OK, good to know. I was asking because once there was an issue
with S5 only.

>> Any difference if you enable WoL manually via ethtool "ethtool -s <if> wol g" ?
> 
> Would that make any difference if ethtool already says "Wake-on: g"? Why
> would that make a difference with the 4.20 driver, but not with the
> older one?
> 
ethtool only reports the chip settings, it doesn't consider whether
wake-up is enabled on system level.
As an additional note: When setting WoL ethtool first queries the settings
and it only does something if it finds the new settings are different.

For wake-up basically three things are involved:
1. physical network, so that wakeup packet can reach NIC
2. chip must be programmed to detect WoL packet and generate PME
3. system must be programmed to detect PME from this source

Point 2 seems to be ok based on the register dump you provided.
Point 1 we should check, therefore answer to your last question is: yes.

Point 3 we still have to check.
Which version of 4.18 are you running that is ok? To check the code ..

Based on what I wrote above, could you try the following sequence and
check whether wake from S3 works then?

ethtool -s <if> wol d
ethtool -s <if> wol g

> And yes, I remember this being one of the very first attempts after
> noticing the issue, and I frankly would consider it at least a
> regression if the 4.20 driver needs manual intervention while the 4.18
> driver works fine with the appropriate setting in systemd-networkd
> configuration.
> 
> Let me repeat, the issue does immediately vanish once I replace the
> r8169 driver in the kernel with an older version, and re-establishes
> itself immediately once I use a current driver version. No other parts
> of the system or the network do not even get touched.
> 
>> And a basic question: Once you have powered off your system, is network
>> LED on PC and router on?
> 
> When the system is in suspend, the manageable TP-Link 52 Port Gigabit
> Switch reports the link on port 41 going down for a second and then
> coming up again with 10 Mbit/s Full-Duplex. The Link LED on the system
> board is _off_ in this case, even with the older driver and working Wake
> on LAN. After receiving the magic packet, the system wakes up from
> suspend to RAM, the link LED on the system board lights up again, the
> switch reports the link going down again for a second and then
> re-establishes as 1000 Mbit/s Full-Duplex.
> 
> The router's link to the same switch, different port, stays up with 1000
> Mbit/s Full-Duplex, as expected, and frankly I do not see why the
> totally unrelated network link between switch and router plays a role
> here.
> 
I asked for the router because I assumed that your system is connected
to the router directly.

> All those tests were done with Linux 4.20.3 with the driver from 4.18
> transplanted and WoL working. I guess you want me to retry with the
> broken driver?
> 
> Greetings
> Marc
> 

Powered by blists - more mailing lists