netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Heiner Kallweit <hkallweit1@gmail.com>
To: Marc Haber <mh+netdev@zugschlus.de>
Cc: "netdev@vger.kernel.org" <netdev@vger.kernel.org>
Subject: Re: WoL broken in r8169.c since kernel 4.19
Date: Tue, 29 Jan 2019 20:01:14 +0100	[thread overview]
Message-ID: <1f40f95a-f595-45f5-5641-9eb4837da71e@gmail.com> (raw)
In-Reply-To: <20190129153553.GL27062@torres.zugschlus.de>

Hi Marc,

the change to replace __rtl8169_set_wol(tp, 0) doesn't seem to be the right commit
because it was included in 4.18 already. And if you read the commit description you'll
see that it was replaced because it caused issues with certain boards. Having said that
it's not an option for us.

Still I'm struggling to see where the relevant difference between 4.18 and 4.19 is.
Especially as 4.19 and also later versions work perfectly fine here.

Can you in addition apply the following (again it may not apply cleanly) and provide
the results for 4.18 and 4.19?

And from today's run, can you provide the full dmesg output? I'd like to check
why the message was written on resume only.

Heiner

---
 drivers/net/ethernet/realtek/r8169.c | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/drivers/net/ethernet/realtek/r8169.c b/drivers/net/ethernet/realtek/r8169.c
index bd26d3f2e..e9c37f10c 100644
--- a/drivers/net/ethernet/realtek/r8169.c
+++ b/drivers/net/ethernet/realtek/r8169.c
@@ -1414,6 +1414,8 @@ static void rtl8169_get_wol(struct net_device *dev, struct ethtool_wolinfo *wol)
 	wol->supported = WAKE_ANY;
 	wol->wolopts = tp->saved_wolopts;
 	rtl_unlock_work(tp);
+
+	pr_info("get_wol: 0x%08x\n", wol->wolopts);
 }
 
 static void __rtl8169_set_wol(struct rtl8169_private *tp, u32 wolopts)
@@ -1491,6 +1493,8 @@ static int rtl8169_set_wol(struct net_device *dev, struct ethtool_wolinfo *wol)
 	struct rtl8169_private *tp = netdev_priv(dev);
 	struct device *d = tp_to_dev(tp);
 
+	pr_info("set_wol: 0x%08x\n", wol->wolopts);
+
 	if (wol->wolopts & ~WAKE_ANY)
 		return -EINVAL;
 
-- 
2.20.1




On 29.01.2019 16:35, Marc Haber wrote:
> Hi,
> 
> after having a good night's sleep over that, it's obviously a merge
> commit which cannot easily be reverted. How would I continue after
> identifying a merge commit as the culprit?
> 
> On Tue, Jan 29, 2019 at 08:32:53AM +0100, Marc Haber wrote:
>> According to bisect, the first bad commit is
>> 19725496da5602b401eae389736ab00d1817e264
>>
>> commit 19725496da5602b401eae389736ab00d1817e264
>> Merge: aea5f654e6b7 9981b4fb8684
> 
> git diff aea5f654e6b7..19725496da5602b401eae389736ab00d1817e264,
> filtered for r8169 looks manageable:
> 
> --- a/drivers/net/ethernet/realtek/r8169.c
> +++ b/drivers/net/ethernet/realtek/r8169.c
> @@ -7396,8 +7396,7 @@ static int rtl_init_one(struct pci_dev *pdev, const struc
>                 return rc;
>         }
>  
> -       /* override BIOS settings, use userspace tools to enable WOL */
> -       __rtl8169_set_wol(tp, 0);
> +       tp->saved_wolopts = __rtl8169_get_wol(tp);
>  
>         mutex_init(&tp->wk.mutex);
>         u64_stats_init(&tp->rx_stats.syncp);
> 
> but the other one seems unmanageably big:
> 
> [18/5009]mh@fan:~/linux/git/linux (master % u=) $ git diff 9981b4fb8684..19725496da5602b401eae389736ab00d1817e264 -- drivers/net/ethernet/realtek/r8169.c | diffstat
>  r8169.c |  815 ++++++++++++++++++----------------------------------------------
>  1 file changed, 234 insertions(+), 581 deletions(-)
> [19/5009]mh@fan:~/linux/git/linux (master % u=) $ 
> 
> -------
> But, indeed, adding the call to __rtl8169_set_wol(tp, 0) fixes the issue
> for me and the machine now wakes up from StR on a magic packet without
> having to go through strange ethtool motions.
> -------
> 
> Would that code change be suitable for the official kernel cod?
> 
> Greetings
> Marc
> 


  reply	other threads:[~2019-01-29 19:01 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-01-12 20:08 WoL broken in r8169.c since kernel 4.19 Marc Haber
2019-01-12 20:28 ` Heiner Kallweit
2019-01-12 20:44   ` Heiner Kallweit
2019-01-13 16:01   ` Marc Haber
2019-01-13 16:19     ` Heiner Kallweit
2019-01-22 16:10       ` Marc Haber
2019-01-22 18:47         ` Heiner Kallweit
2019-01-25  5:59           ` Marc Haber
2019-01-25  6:49             ` Heiner Kallweit
2019-01-25 12:02               ` Marc Haber
2019-01-25 18:22                 ` Heiner Kallweit
2019-01-26 13:56                   ` Marc Haber
2019-01-26 14:04                     ` Heiner Kallweit
2019-01-26 17:07                       ` Marc Haber
2019-01-26 19:22                         ` Heiner Kallweit
2019-01-27 20:55                           ` Marc Haber
2019-01-27 21:09                             ` Heiner Kallweit
2019-01-28  7:30                               ` Marc Haber
2019-01-28 19:02                                 ` Heiner Kallweit
2019-01-28 20:59                                   ` Marc Haber
2019-01-28 21:21                                     ` Heiner Kallweit
2019-01-29 11:52                                       ` Marc Haber
2019-01-28 20:22                                 ` Marc Haber
2019-01-28 20:28                                   ` Heiner Kallweit
2019-01-29  7:32                                     ` Marc Haber
2019-01-29 15:35                                       ` Marc Haber
2019-01-29 19:01                                         ` Heiner Kallweit [this message]
2019-01-30  8:46                                           ` Marc Haber
2019-01-29 21:20                                         ` Heiner Kallweit
2019-01-30 15:37                                           ` Marc Haber
2019-02-01  6:49                                             ` Heiner Kallweit
2019-02-01 17:19                                               ` Marc Haber
2019-02-01 18:24                                                 ` Heiner Kallweit
2019-02-01 18:41                                                   ` Marc Haber
2019-01-26 14:08     ` Heiner Kallweit
2019-01-26 14:09       ` Heiner Kallweit

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1f40f95a-f595-45f5-5641-9eb4837da71e@gmail.com \
    --to=hkallweit1@gmail.com \
    --cc=mh+netdev@zugschlus.de \
    --cc=netdev@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).