From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <SRS0=rpvq=P6=vger.kernel.org=netdev-owner@kernel.org>
X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on
	aws-us-west-2-korg-lkml-1.web.codeaurora.org
X-Spam-Level: 
X-Spam-Status: No, score=-2.5 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS,
	MAILING_LIST_MULTI,SPF_PASS,USER_AGENT_MUTT autolearn=ham autolearn_force=no
	version=3.4.0
Received: from mail.kernel.org (mail.kernel.org [198.145.29.99])
	by smtp.lore.kernel.org (Postfix) with ESMTP id 9E58DC282C3
	for <netdev@archiver.kernel.org>; Tue, 22 Jan 2019 16:10:08 +0000 (UTC)
Received: from vger.kernel.org (vger.kernel.org [209.132.180.67])
	by mail.kernel.org (Postfix) with ESMTP id 76A3720823
	for <netdev@archiver.kernel.org>; Tue, 22 Jan 2019 16:10:08 +0000 (UTC)
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
        id S1729146AbfAVQKH (ORCPT <rfc822;netdev@archiver.kernel.org>);
        Tue, 22 Jan 2019 11:10:07 -0500
Received: from torres.zugschlus.de ([85.214.131.164]:37972 "EHLO
        torres.zugschlus.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
        with ESMTP id S1728669AbfAVQKG (ORCPT
        <rfc822;netdev@vger.kernel.org>); Tue, 22 Jan 2019 11:10:06 -0500
Received: from mh by torres.zugschlus.de with local (Exim 4.89)
        (envelope-from <mh+netdev@zugschlus.de>)
        id 1glycn-0007H9-7x; Tue, 22 Jan 2019 17:10:05 +0100
Date:   Tue, 22 Jan 2019 17:10:05 +0100
From:   Marc Haber <mh+netdev@zugschlus.de>
To:     Heiner Kallweit <hkallweit1@gmail.com>
Cc:     "netdev@vger.kernel.org" <netdev@vger.kernel.org>
Subject: Re: WoL broken in r8169.c since kernel 4.19
Message-ID: <20190122161005.GA27062@torres.zugschlus.de>
References: <20190112200831.GB20268@torres.zugschlus.de>
 <cb8d8da1-e485-9b62-8472-08ed2fa9b7cc@gmail.com>
 <20190113160149.GG20268@torres.zugschlus.de>
 <04cbac76-e0c4-dc97-4a11-0dc7d85be276@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <04cbac76-e0c4-dc97-4a11-0dc7d85be276@gmail.com>
User-Agent: Mutt/1.10.1 (2018-07-13)
Sender: netdev-owner@vger.kernel.org
Precedence: bulk
List-ID: <netdev.vger.kernel.org>
X-Mailing-List: netdev@vger.kernel.org

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.

> 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?

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.

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

-- 
-----------------------------------------------------------------------------
Marc Haber         | "I don't trust Computers. They | Mailadresse im Header
Leimen, Germany    |  lose things."    Winona Ryder | Fon: *49 6224 1600402
Nordisch by Nature |  How to make an American Quilt | Fax: *49 6224 1600421