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=-4.1 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,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 26128C282C0 for ; Fri, 25 Jan 2019 06:50:07 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id DC3CD218D9 for ; Fri, 25 Jan 2019 06:50:06 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="ImFYlY9h" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726802AbfAYGuF (ORCPT ); Fri, 25 Jan 2019 01:50:05 -0500 Received: from mail-wm1-f66.google.com ([209.85.128.66]:37405 "EHLO mail-wm1-f66.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726021AbfAYGuF (ORCPT ); Fri, 25 Jan 2019 01:50:05 -0500 Received: by mail-wm1-f66.google.com with SMTP id g67so5506489wmd.2 for ; Thu, 24 Jan 2019 22:50:04 -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=O7LvExfbn6uQXCDw53CXWaXRQeiclOn1emrnVSgJoTw=; b=ImFYlY9hYST7YViFsGLqXjZT9rcmIr9QBZE678fc3S2+V0bDpZiQpjfPyq28dWcNpg Aur3+oJ/EKRlieEsgcqeeKIkrFxUz8gHtMfC/QIw7imRfUFo579tdawfiOkvhlEOR7kv k0ArAq5toQnxNerWelSe8WtAv0aszys2D9vgL4a34UQ6r++rg5urFXsCj6CA7bH4UMKT 5t3W2e71y4/QUkHSj20gSfSvWXoIXn/9AduCJWEwcvPVxlJN6XVckEdRXlvz5SLJJBYV 6hgBbM1Ri23rVDoufrV0bgom8c55tgqBwWDg/e4TxOoT9UUGgC9NtCxEwwPRZOGGmbGa /1/A== 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=O7LvExfbn6uQXCDw53CXWaXRQeiclOn1emrnVSgJoTw=; b=COe6R7bEY9f1mZQl2njdoeikEWWpaqaDvVhVADmEFT9Y38uSIMu3+UmAL+DXoVvI83 Y6qB/HoY5ThwBYJ9+qGfy5LZZ1H4mHwKj/vK+ThubdFJ+3ngKlT4uT8evKNXDIiBzVep 4mONA1IoWkkKWGECY9qwonx2TUJgVKX6W5LRbGmoeZYvJ15oDXEA/QJOEEx8Ya5mb3Ge yXc3j7IMuTbosN2ip8TEjb+tLyR1XDvFMzf2z2P50qPSJqPUKzdgppuPsmIAOqWN+xM8 tU6jSSHOOxSXZgUAXyuIMjc5RYzhpZ0G3uD/gqgR9bl+FOKUbl+OsJfhTHdQ3cG5+jpV IBYg== X-Gm-Message-State: AJcUukflF4P3frJCEghAupZnr7K7Eb89peOllxEoGb1ya9Pdc9Ov+SdR EFkR1FnERID+q1n0H7Rxhb6rbw/D X-Google-Smtp-Source: ALg8bN46xxyOULhbHf2lUj/9LXuqF4J9NVdBeW6ci7/MIXHLDtLiB5yqcSEdNpoZsZY72ysfm3E1vQ== X-Received: by 2002:a1c:d7d3:: with SMTP id o202mr5981949wmg.135.1548399002916; Thu, 24 Jan 2019 22:50:02 -0800 (PST) Received: from ?IPv6:2003:ea:8bf1:e200:4d2f:a090:24ac:468? (p200300EA8BF1E2004D2FA09024AC0468.dip0.t-ipconnect.de. [2003:ea:8bf1:e200:4d2f:a090:24ac:468]) by smtp.googlemail.com with ESMTPSA id z9sm111473632wrs.63.2019.01.24.22.50.01 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 24 Jan 2019 22:50:02 -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> <3c3249f8-6e09-43a7-e4e2-f4fc2b9531ab@gmail.com> <20190125055919.GB27062@torres.zugschlus.de> From: Heiner Kallweit Message-ID: <6ae02156-8903-70fd-675f-a5aee9c452b4@gmail.com> Date: Fri, 25 Jan 2019 07:49:56 +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: <20190125055919.GB27062@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 Hi Marc, thanks a lot for the detailed analysis. That this ethtool sequence ethtool -s wol d ethtool -s wol g helps makes me think that the following patch should help too. Could you please test? There's an old story why this call is missing. Certain notebooks immediately woke up again if WoL was enabled and they were suspended. I think they should disable WoL instead of having this hack in the driver. Heiner --- drivers/net/ethernet/realtek/r8169.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/net/ethernet/realtek/r8169.c b/drivers/net/ethernet/realtek/r8169.c index 04c403539..1d101659f 100644 --- a/drivers/net/ethernet/realtek/r8169.c +++ b/drivers/net/ethernet/realtek/r8169.c @@ -7423,6 +7423,7 @@ static int rtl_init_one(struct pci_dev *pdev, const struct pci_device_id *ent) } tp->saved_wolopts = __rtl8169_get_wol(tp); + device_set_wakeup_enable(&pdev->dev, tp->saved_wolopts); mutex_init(&tp->wk.mutex); INIT_WORK(&tp->wk.work, rtl_task); -- 2.20.1 On 25.01.2019 06:59, Marc Haber wrote: > Hi Heiner, > > On Tue, Jan 22, 2019 at 07:47:45PM +0100, Heiner Kallweit wrote: >> Which version of 4.18 are you running that is ok? To check the code .. > > I pull over drivers/net/ethernet/realtek/r8169.c from an unpacked > 4.18.16 source tree. It sets RTL8169_VERSION "2.3LK-NAPI". The last > commit in this file's history is > > commit 241e5a13a5ad75fd0b5a47b583e098fa08917d5c > Author: Maciej S. Szmigiero > Date: Thu Oct 11 16:02:10 2018 +0200 > > r8169: set RX_MULTI_EN bit in RxConfig for 8168F-family chips > > Unfortunately, very different r8169.c in 4.20.3 also sets RTL8169_VERSION "2.3LK-NAPI", so we cannot use this as identification. > >> 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 > > This test was done with the Debian kernel package 4.20.0-trunk-amd64, > which contains a kernel 4.20.1 compiled on 2018-12-24, from Debian's > experimental repository. > > This are my steps: > (1) ethtool -s lanc0 wol d > (2) ethtool -s lanc0 wol g > (3) systemctl suspend > (4) system gows down into Suspend to RAM, an audible *click* from a > relay, power LED blinking, Switch reporting that the ethernet link state > changed from 1000Full to down and then to 10Full. > (5) sent a magic packet > (6) *click* system up again. This is good. > (7) switch reported link state change from 10Full to down and then to > 1000Full > (8) system and network operational > (9) shut down the system completely, remove power. all LEDs off, link > down > (10) re-plug power, all LEDs off, link 10Full > (11) push power button, bring system up again with Debian's 4.20 kernel > (12) link up at 1000Full > (12a) take register dump, exhibit 12a > (13) systemctl suspend > (14) system gows down into Suspend to RAM, an audible *click* from a > relay, power LED blinking, Switch reporting that the ethernet link state > changed from 1000Full to down and then to 10Full. > (15) send magic packet identical to step (5) > (16) system remains suspended, blinking LED; link 10Full > (17) push any key on keyboard > (18) *click* system up again. This is good. > (19) switch reported link state change from 10Full to down and then to > 1000Full > (19a) take register dump, exhibit 19a > (20) system and network operational > (21) repeat steps (1) through (5) > (22) system reacts to magic packet and wakes up > (23) ethtool -s lanc0 wol d > (24) ethtool -s lanc0 wol g > (25) take register dump, exhibit 25 > (26) systemctl suspend > (27) system gows down into Suspend to RAM, an audible *click* from a > relay, power LED blinking, Switch reporting that the ethernet link state > changed from 1000Full to down and then to 10Full. > (28) sent a magic packet > (29) *click* system up again. This is good. > (30) switch reported link state change from 10Full to down and then to > 1000Full > (31) take register dump, exhibit 31 > (32) system and network operational > > So, our hypothesis is now that the older driver does "something" that > the new driver doesn't, but what is needed for my machine to wake up on > magic packet from suspend to RAM. the two ethtool calls do seem to fix > that. > > Unfortunately, exhibits 19a, 25 and 31 are identical, and exhibit 12a > only differs in a single line, PHY access holding 0x8001796d instead of > 0x80040de1. So, whatever the two ethtools do, it is not visible in the > register dump. > > I repaeted the experiment with stock 4.20.4, with the same results, and > 4.20.4 with a r8169.c transplant from 4.18.16, with the result of > ethtool not needed. > > Exhibits from the stock 4.20.4 experiments: > exhibit-4.20.4-preeth-presleep - direct after boot > exhibit-4.20.4-preeth-postsleep - after suspend with manual wakeup needed > exhibit-4.20.4-posteth-presleep - after the two ethtool calls > exhibit-4.20.4-posteth-postsleep - after successful wake on lan > > Exhibits from the 4.20.4+transplant experiments: > exhibit-4.18-presleep - direct after boot > exhibit-4.18-postsleep - after successful wake on LAN. > > I hope this helps. Let me know if additional data is helpful. > > Greetings > Marc >