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