From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: 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=-1.1 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_PASS 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 6C059C282C3 for ; Tue, 22 Jan 2019 18:47:56 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 3A09921019 for ; Tue, 22 Jan 2019 18:47:56 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="e+y8YuSp" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726813AbfAVSrz (ORCPT ); Tue, 22 Jan 2019 13:47:55 -0500 Received: from mail-wm1-f67.google.com ([209.85.128.67]:55693 "EHLO mail-wm1-f67.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725896AbfAVSry (ORCPT ); Tue, 22 Jan 2019 13:47:54 -0500 Received: by mail-wm1-f67.google.com with SMTP id y139so15143050wmc.5 for ; Tue, 22 Jan 2019 10:47:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=VoRD7hCSaWeWFZu9zwGROPBitBwMtJgfTwTtO5lt3s8=; b=e+y8YuSpMHBGtBAwNoYB+kBO4qDnwiGD+EAY9h5mCz+HVQInVpdosJejKvy8w2FPXM Cb7n/XwRZXIFJ3ReYzxBGKuPrqsIu6mkchFg8k5dQ2T2cgvyy/ALnj854NJFDus3esfK tYhmBJqKVY7TnzllbEBJcawSEQt65Hy++N7nGq1bvwJAADwy8YL053sgk58Gj8OlMlTg RM76o7dVX8VXJlPtTYcj1KItn1Nc5lCejbWPiohd6EZ39yRIsdFfDauiflHr/GsGZkm+ 00/8aCe8snFOmG4e2CiewN0W0k3RrC9yK/CiDW4Gj8629nk+VhJUCCEaWbU262vH7cc7 /m6Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=VoRD7hCSaWeWFZu9zwGROPBitBwMtJgfTwTtO5lt3s8=; b=jTI/exd4ZSPIlEOX0j2QbsFEaYteNgpeKKKELlwcWe4RUbnXVj510Sb87A0b38syDe pNYc7jqhU8IZMi5MMphwFScbFais4CZ830lW5sdXwftoqAxPFzJjzRUtN8y5bKHUvTiq iBJ7YwPnsNPt1zzCGAV43VkzDQhMRwOKTdYdbmJxSlBf450EO8Kee/gRF1qCDBuZEUkl vcAJSFb+LAEeQzEw+8OGV/R47W/Db+WIxmveQUhrDiAbZjmKGLOxi/evhWCWwJbKtbjm tfUnCnatWWiZePayIa/YsTzkAkAitrB2poQbtZWlSyP3AlNLWwVdps1RQS/owT9ZvHqV XuNA== X-Gm-Message-State: AJcUukfhHz7CmUMJyQQoGdOjZTqfCuGf4O67DGObz7WMLpuneoe6CFc9 ERD1PoyV8yI3tYs0vEttQdFp9j5L X-Google-Smtp-Source: ALg8bN7bnuD3ZfrHD7ggi926e4zpFgXykeSeLs2VpgvOIGjtwS2hF8YR3Gvbs62BGVXwlTzvKnUhNw== X-Received: by 2002:a1c:6607:: with SMTP id a7mr4691126wmc.129.1548182872789; Tue, 22 Jan 2019 10:47:52 -0800 (PST) Received: from ?IPv6:2003:ea:8bf1:e200:e51b:82a9:abd5:2eeb? (p200300EA8BF1E200E51B82A9ABD52EEB.dip0.t-ipconnect.de. [2003:ea:8bf1:e200:e51b:82a9:abd5:2eeb]) by smtp.googlemail.com with ESMTPSA id 198sm97734846wmt.36.2019.01.22.10.47.51 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 22 Jan 2019 10:47:52 -0800 (PST) Subject: Re: WoL broken in r8169.c since kernel 4.19 To: Marc Haber Cc: "netdev@vger.kernel.org" References: <20190112200831.GB20268@torres.zugschlus.de> <20190113160149.GG20268@torres.zugschlus.de> <04cbac76-e0c4-dc97-4a11-0dc7d85be276@gmail.com> <20190122161005.GA27062@torres.zugschlus.de> From: Heiner Kallweit Message-ID: <3c3249f8-6e09-43a7-e4e2-f4fc2b9531ab@gmail.com> Date: Tue, 22 Jan 2019 19:47:45 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.4.0 MIME-Version: 1.0 In-Reply-To: <20190122161005.GA27062@torres.zugschlus.de> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: netdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org 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 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 wol d ethtool -s 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 >