Re: Policy Routing and two independent, not cooperating IPv6 uplinks
On Tue, Sep 01, 2020 at 12:14:02AM +0200, Marc Haber wrote: > Thanks for your help and consideration. I hope this message is not going > to be ignored and I would love to have this taken up by you developers > as an every-day, but non-trivial use case from a productive network. Hi, no-one wants to even comment? Please. Thanks in advance. 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
Policy Routing and two independent, not cooperating IPv6 uplinks
ed aspects of the packet that might affect the correctness of the routing decision. A colleague has also advised that I might be better off by using the "src" selector inside a route and doing things completely without routing rules, but I haven't gotten that to work at all. If that is a promising approach, I'd appreciate a pointer towards some documentation. Thanks for your help and consideration. I hope this message is not going to be ignored and I would love to have this taken up by you developers as an every-day, but non-trivial use case from a productive network. 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
Re: iwl_mvm_add_new_dqa_stream_wk BUG in lib/list_debug.c:56
On Thu, May 30, 2019 at 10:12:57AM +0200, Marc Haber wrote: > on my primary notebook, a Lenovo X260, with an Intel Wireless 8260 > (8086:24f3), running Debian unstable, I have started to see network > hangs since upgrading to kernel 5.1. In this situation, I cannot > restart Network-Manager (the call just hangs), I can log out of X, but > the system does not cleanly shut down and I need to Magic SysRq myself > out of the running system. This happens about once every two days. The issue is also present in 5.1.5 and 5.1.6. 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
Re: WoL broken in r8169.c since kernel 4.19
On Fri, Feb 01, 2019 at 07:24:01PM +0100, Heiner Kallweit wrote: > It's too much effort to make the current r8169 compile under an older kernel. > But thanks anyway for trying! Will the patch be in 5.0-rc5? 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
Re: WoL broken in r8169.c since kernel 4.19
On Fri, Feb 01, 2019 at 07:49:09AM +0100, Heiner Kallweit wrote:
> Great, thanks. This patch has been applied and is part of latest linux-next
> kernel already:
> https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/tree/?h=next-20190201
> Would be much appreciated if you could build and test this kernel version.
I regret that I have not been able to get this through the compiler.
When I clone the linux-next repo and try to build with deb-pkg, some
process chokes on the weird version number of the linux-next kernel, and
transplanting the r8169.c from linux-next on to 4.20.6, compile aborts:
In file included from drivers/net/ethernet/realtek/r8169.c:13:
./include/linux/pci.h:830:12: error: ‘PCI_VENDOR_ID_USR’ undeclared here (not
in a function); did you mean ‘PCI_VENDOR_ID_UMC’?
.vendor = PCI_VENDOR_ID_##vend, .device = (dev), \
^~
drivers/net/ethernet/realtek/r8169.c:222:4: note: in expansion of macro
‘PCI_VDEVICE’
{ PCI_VDEVICE(USR, 0x0116), RTL_CFG_0 },
^~~
drivers/net/ethernet/realtek/r8169.c: In function ‘rtl8169_start_xmit’:
drivers/net/ethernet/realtek/r8169.c:6261:6: error: implicit declaration of
function ‘__netdev_sent_queue’; did you mean ‘netdev_sent_queue’?
[-Werror=implicit-function-declaration]
if (__netdev_sent_queue(dev, skb->len, skb->xmit_more))
^~~
netdev_sent_queue
drivers/net/ethernet/realtek/r8169.c: In function ‘r8169_phy_connect’:
drivers/net/ethernet/realtek/r8169.c:6653:22: warning: passing argument 1 of
‘linkmode_copy’ makes pointer from integer without a cast [-Wint-conversion]
linkmode_copy(phydev->advertising, phydev->supported);
~~^
In file included from ./include/linux/phy.h:22,
from drivers/net/ethernet/realtek/r8169.c:19:
./include/linux/linkmode.h:13:49: note: expected ‘long unsigned int *’ but
argument is of type ‘u32’ {aka ‘unsigned int’}
static inline void linkmode_copy(unsigned long *dst, const unsigned long *src)
~~~^~~
drivers/net/ethernet/realtek/r8169.c:6653:43: warning: passing argument 2 of
‘linkmode_copy’ makes pointer from integer without a cast [-Wint-conversion]
linkmode_copy(phydev->advertising, phydev->supported);
~~^~~
In file included from ./include/linux/phy.h:22,
from drivers/net/ethernet/realtek/r8169.c:19:
./include/linux/linkmode.h:13:75: note: expected ‘const long unsigned int *’
but argument is of type ‘u32’ {aka ‘unsigned int’}
static inline void linkmode_copy(unsigned long *dst, const unsigned long *src)
~^~~
cc1: some warnings being treated as errors
make[4]: *** [scripts/Makefile.build:297: drivers/net/ethernet/realtek/r8169.o]
Error 1
Will it help if I transplant more files from linux-next to 4.20.6?
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
Re: WoL broken in r8169.c since kernel 4.19
On Tue, Jan 29, 2019 at 10:20:48PM +0100, Heiner Kallweit wrote:
> one more attempt, could you please test the following with 4.19 or 4.20
> (w/o the other debug patches) ?
With the following patch, the machine wakes up fine on a WoL magic
packet:
nux-4.20.5/drivers/net/ethernet/realtek/r8169.c 2019-01-30 16:03:00.090841076
+0100
+++ orig/linux-4.20.5/drivers/net/ethernet/realtek/r8169.c 2019-01-26
09:20:52.0 +0100
@@ -1418,7 +1418,6 @@
#define WAKE_ANY (WAKE_PHY | WAKE_MAGIC | WAKE_UCAST | WAKE_BCAST | WAKE_MCAST)
-#if 0
static u32 __rtl8169_get_wol(struct rtl8169_private *tp)
{
u8 options;
@@ -1453,7 +1452,6 @@
return wolopts;
}
-#endif
static void rtl8169_get_wol(struct net_device *dev, struct ethtool_wolinfo
*wol)
{
@@ -1463,8 +1461,6 @@
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)
@@ -1540,8 +1536,6 @@
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;
@@ -4174,7 +4168,7 @@
{
struct phy_device *phydev;
- if (!device_may_wakeup(tp_to_dev(tp)))
+ if (!__rtl8169_get_wol(tp))
return false;
/* phydev may not be attached to netdevice */
@@ -7372,6 +7366,8 @@
return rc;
}
+ tp->saved_wolopts = __rtl8169_get_wol(tp);
+
mutex_init(&tp->wk.mutex);
u64_stats_init(&tp->rx_stats.syncp);
u64_stats_init(&tp->tx_stats.syncp);
1 [14/5006]mh@fan:~/linux/4.20.5 $
I'll send the dmesg output to you in private e-mail
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
Re: WoL broken in r8169.c since kernel 4.19
On Tue, Jan 29, 2019 at 08:01:14PM +0100, Heiner Kallweit wrote: > 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. :-( > Can you in addition apply the following (again it may not apply cleanly) and > provide > the results for 4.18 and 4.19? In addition to the debug output? Can I do that together with the other patch you sent yesterday or does that need to be two different tests? > 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. I guess that it just didn't find its way to syslog before resume and got stuck in some buffer during suspend. 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
Re: WoL broken in r8169.c since kernel 4.19
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
Re: WoL broken in r8169.c since kernel 4.19
On Mon, Jan 28, 2019 at 10:21:50PM +0100, Heiner Kallweit wrote: > And I wonder why the following didn't work for you, you said it makes > no difference. Could you try again the following in addition to the > latest debug output statement? This time it says Jan 29 12:34:59 fan kernel: [ 141.397307] may wakeup? 1 Jan 29 12:46:39 fan kernel: [ 819.665683] may wakeup? 1 while the machine needed a manual wakeup at 12:34 as usual. The log entry is only written after resume, first suspend was at 09:05 and the machine was sleeping for three hours. 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
Re: WoL broken in r8169.c since kernel 4.19
On Mon, Jan 28, 2019 at 09:28:13PM +0100, Heiner Kallweit wrote:
> Because we're interested in file r8169.c only, you could test r8169.c
> from the oops-ing kernel on top of a working kernel version.
That's a really nice idea, and so obvious once one thinks about it.
According to bisect, the first bad commit is
19725496da5602b401eae389736ab00d1817e264
commit 19725496da5602b401eae389736ab00d1817e264
Merge: aea5f654e6b7 9981b4fb8684
Author: David S. Miller
Date: Tue Jul 24 19:21:58 2018 -0700
Merge ra.kernel.org:/pub/scm/linux/kernel/git/davem/net
diff --cc drivers/net/ethernet/realtek/r8169.c
index 49a6e25ddc2b,eaedc11ed686..8ea1fa36ca43
--- a/drivers/net/ethernet/realtek/r8169.c
+++ b/drivers/net/ethernet/realtek/r8169.c
@@@ -7396,9 -7734,24 +7396,8 @@@ static int rtl_init_one(struct pci_dev
return rc;
}
- /* override BIOS settings, use userspace tools to enable WOL */
- __rtl8169_set_wol(tp, 0);
+ tp->saved_wolopts = __rtl8169_get_wol(tp);
- if (rtl_tbi_enabled(tp)) {
- tp->set_speed = rtl8169_set_speed_tbi;
- tp->get_link_ksettings = rtl8169_get_link_ksettings_tbi;
- tp->phy_reset_enable = rtl8169_tbi_reset_enable;
- tp->phy_reset_pending = rtl8169_tbi_reset_pending;
- tp->link_ok = rtl8169_tbi_link_ok;
- tp->do_ioctl = rtl_tbi_ioctl;
- } else {
- tp->set_speed = rtl8169_set_speed_xmii;
- tp->get_link_ksettings = rtl8169_get_link_ksettings_xmii;
- tp->phy_reset_enable = rtl8169_xmii_reset_enable;
- tp->phy_reset_pending = rtl8169_xmii_reset_pending;
- tp->link_ok = rtl8169_xmii_link_ok;
- tp->do_ioctl = rtl_xmii_ioctl;
- }
-
mutex_init(&tp->wk.mutex);
u64_stats_init(&tp->rx_stats.syncp);
u64_stats_init(&tp->tx_stats.syncp);
What confuses me here is the big part where the "-" is not in column 1, and
patch -R calls it garbage.
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
Re: WoL broken in r8169.c since kernel 4.19
On Mon, Jan 28, 2019 at 08:02:47PM +0100, Heiner Kallweit wrote: > One more test .. Can you provide the output of the following under 4.18 and > under 4.19? > It may not apply cleanly, but you get the idea. The message is written when > suspending. I booted, suspeneded, sent a magic packet that got ignored. I then woke the box up with the any key, went through the ethtool motions, suspended again, sent a magic paket that the machine acted on and woke up Log says: 1 [1/4994]mh@fan:~ $ grep 'may wakeup' /var/log/syslog/syslog Jan 28 21:51:44 fan kernel: [ 77.571211] may wakeup? 0 Jan 28 21:54:11 fan kernel: [ 183.994131] may wakeup? 1 [2/4995]mh@fan:~ $ 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
Re: WoL broken in r8169.c since kernel 4.19
On Mon, Jan 28, 2019 at 08:30:10AM +0100, Marc Haber wrote: > On Sun, Jan 27, 2019 at 10:09:51PM +0100, Heiner Kallweit wrote: > > Yes. All you have to do after each "git bisect good/bad" is build again, > > test, and make current build as good or bad. > > Will report back if I get any results. When I bisected last time, I > ended up with a kernel that didn't even boot, but with 5 steps this is > probably manageable. Will take most of the week though. [3/4995]mh@fan:~/linux/git/linux ((6fcf9b1d4d6c...) *%|BISECTING) $ git bislog git bisect start 'drivers/net/ethernet/realtek/r8169.c' # good: [4ff36466281428734791d3cc6331b8cca7c76019] r8169: replace get_protocol with vlan_get_protocol git bisect good 4ff36466281428734791d3cc6331b8cca7c76019 # bad: [649f0837a8cc2b39329f2de00fa0d04b029291c5] r8169: fix broken Wake-on-LAN from S5 (poweroff) git bisect bad 649f0837a8cc2b39329f2de00fa0d04b029291c5 # bad: [098b01ad9837b4d4d0022f407300f069a999e55a] r8169: don't include asm headers directly git bisect bad 098b01ad9837b4d4d0022f407300f069a999e55a [4/4996]mh@fan:~/linux/git/linux ((6fcf9b1d4d6c...) *%|BISECTING) $ The kernel that I now have is 6fcf9b1d4d6cd38202247de5c0ac7d85c4483abb and that one throws oopses on booting and won't suspend at all. Can I continue from here while still making sense? 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
Re: WoL broken in r8169.c since kernel 4.19
On Sun, Jan 27, 2019 at 10:09:51PM +0100, Heiner Kallweit wrote: > Yes. All you have to do after each "git bisect good/bad" is build again, > test, and make current build as good or bad. Will report back if I get any results. When I bisected last time, I ended up with a kernel that didn't even boot, but with 5 steps this is probably manageable. Will take most of the week though. 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
Re: WoL broken in r8169.c since kernel 4.19
On Sat, Jan 26, 2019 at 08:22:33PM +0100, Heiner Kallweit wrote:
> You could go with this range:
> from 4ff364662814 ("r8169: replace get_protocol with vlan_get_protocol")
> to 649f0837a8cc ("r8169: fix broken Wake-on-LAN from S5 (poweroff)")
I am quite inexperienced with bisecting and am therefore giving a better
account of my actions here.
[2/4994]mh@fan:~/linux/git/linux ((v4.18.16) %) $ git pull
remote: Counting objects: 786, done.
remote: Compressing objects: 100% (197/197), done.
remote: Total 786 (delta 659), reused 697 (delta 589)
Receiving objects: 100% (786/786), 146.00 KiB | 1.20 MiB/s, done.
Resolving deltas: 100% (659/659), completed with 237 local objects.
>From git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux
ba6069759381..1fc7f56db7a7 master -> origin/master
You are not currently on a branch.
1 [3/4995]mh@fan:~/linux/git/linux ((v4.18.16) %) $ git checkout 4ff364662814
Checking out files: 100% (13994/13994), done.
Previous HEAD position was 6b3252287aa2 Linux 4.18.16
HEAD is now at 4ff364662814 r8169: replace get_protocol with vlan_get_protocol
[4/4996]mh@fan:~/linux/git/linux ((4ff364662814...) %) $ git bisect start
drivers/net/ethernet/realtek/r8169.c
[5/4997]mh@fan:~/linux/git/linux ((4ff364662814...) %|BISECTING) $
(copy 4.20 config, make oldconfig, say no to everything, make deb-pkg, install
and try)
this boots and wakes up on magic packet from suspend to ram
[2/4994]mh@fan:~/linux/git/linux ((4ff364662814...) *%|BISECTING) $ git bisect
good
[3/4995]mh@fan:~/linux/git/linux ((4ff364662814...) *%|BISECTING) $ git
checkout 649f0837a8cc
Checking out files: 100% (21794/21794), done.
M scripts/package/Makefile
Previous HEAD position was 4ff364662814 r8169: replace get_protocol with
vlan_get_protocol
HEAD is now at 649f0837a8cc r8169: fix broken Wake-on-LAN from S5 (poweroff)
[4/4996]mh@fan:~/linux/git/linux ((649f0837a8cc...) *%|BISECTING) $
(copy 4.20 config, make oldconfig, say no to everything, make deb-pkg, install
and try)
this boots and does not wake up from StR on magic packet, after
waking up with any key on the keyboard I had an amdgpu issue on the console
and a dead console, but was able to ssh in and reboot.
[2/4994]mh@fan:~/linux/git/linux ((649f0837a8cc...) *%|BISECTING) $ git
bisect bad
Bisecting: 33 revisions left to test after this (roughly 5 steps)
[098b01ad9837b4d4d0022f407300f069a999e55a] r8169: don't include asm
headers directly
[3/4995]mh@fan:~/linux/git/linux ((098b01ad9837...) *%|BISECTING) $
I think I am on the right way here, am I?
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
Re: WoL broken in r8169.c since kernel 4.19
On Sat, Jan 26, 2019 at 03:04:34PM +0100, Heiner Kallweit wrote: > Thanks for testing. Then the only way to find the offending commit is > bisecting. :-( Bisecting between which tags? Greetings Ma "at least this issue is readily reproducible" rc -- ----- 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
Re: WoL broken in r8169.c since kernel 4.19
On Fri, Jan 25, 2019 at 07:22:36PM +0100, Heiner Kallweit wrote: > Then I'm slowly running out of ideas. New in 4.19 is a check for invalid > WoL flags, but usually the caller should warn if -EINVAL is returned. > Nevertheless, could you try the following and check whether the warning > is triggered? Compiled the kernel, went through the motions: - boot - suspend - try unsuccessful WoL - wake up manually - do ethtool gymnastics - suspend - try successful WoL - grep syslog for "WoL", nothing found. 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
Re: WoL broken in r8169.c since kernel 4.19
On Fri, Jan 25, 2019 at 07:49:56AM +0100, Heiner Kallweit wrote: > 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? That patch didn't apply cleanly because the rtl_init_one in kernel 4.20.4 is missing the INIT_WORK call at this place. And it doesn't change the behavior, the two ethtool calls are needed so that the host wakes up from suspend to ram on a magic packet. 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
Re: WoL broken in r8169.c since kernel 4.19
status 0x84321043 0x68: TBI Autonegotiation advertisement (ANAR)0xf02c 0x6A: TBI Link partner ability (LPAR) 0x 0x6C: PHY status0x93 0x84: PM wakeup frame 00x 0x 0x8C: PM wakeup frame 10x 0x4af63565 0x94: PM wakeup frame 2 (low) 0x6202016b 0x8ab829be 0x9CM wakeup frame 2 (high) 0x40bee65e 0x800e2860 0xA4: PM wakeup frame 3 (low) 0x44280748 0x1ceea050 0xAC: PM wakeup frame 3 (high) 0xc465e124 0xc465 0xB4: PM wakeup frame 4 (low) 0x 0x 0xBC: PM wakeup frame 4 (high) 0x 0x 0xC4: Wakeup frame 0 CRC 0x 0xC6: Wakeup frame 1 CRC 0x 0xC8: Wakeup frame 2 CRC 0x 0xCA: Wakeup frame 3 CRC 0x 0xCC: Wakeup frame 4 CRC 0x 0xDA: RX packet maximum size 0x4000 0xE0: C+ Command 0x20e1 VLAN de-tagging RX checksumming 0xE2: Interrupt Mitigation0x5151 TxTimer: 5 TxPackets: 1 RxTimer: 5 RxPackets: 1 0xE4: Rx Ring Addr 0x0e02d000 0x0004 0xEC: Early Tx threshold0x27 0xF0: Func Event 0x00400030 0xF4: Func Event Mask 0x 0xF8: Func Preset State 0x000303ff 0xFC: Func Force Event0x - - 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
Re: WoL broken in r8169.c since kernel 4.19
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 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
WoL broken in r8169.c since kernel 4.19
Hi, I am writing to all people who have commits in r8169.c between the v4.18 and v4.19 tags in the Linux kernel. Please ignore as appropriate. If you'd prefer that to be on a mailing list, please indicate on which list you want to have that, and I'll resend. My desktop copmuter has the following network interface: 06:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 06) Subsystem: ASUSTeK Computer Inc. P8P67 and other motherboards Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx+ Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- Kernel driver in use: r8169 Kernel modules: r8169 I regularly buíld a VPN tunnel to my local network from 'on the road' and use WoL to wake up the desktop box when I need it. Since kernel 4.19, that does not work any more, the desktop remains suspended when I send it a magic packet. This still applies to 4.20.1, and it still works with any 4.18 kernel. I transplanted the 4.18 r8169.c into 4.20.1, and then WoL worked again. Thus, the issue must have been introduced between 4.18 and 4.19. Does anybody of you have an idea how to find the issue in the 4.20 code? I have seen 648458fe97b5c0630435fa2b2cd65ba57ceb18e0 in 4.19.14 and tried applying it to 4.20.1 (was necessary to do it manually because the patch wouldn't apply), but that one didn't help. 4.19.14, which has a WoL-related patch applied, doesn't wake on LAN as well. I tried bisecting for r8169.c between v4.18 and v4.19, but right the first step didn't even boot far enough for the disk password prompt, so I am at a loss here. Any ideas? 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
Re: WoL broken in r8169.c since kernel 4.19
On Sat, Jan 12, 2019 at 09:28:48PM +0100, Heiner Kallweit wrote: > On 12.01.2019 21:08, Marc Haber wrote: > > I am writing to all people who have commits in r8169.c between the v4.18 > > and v4.19 tags in the Linux kernel. Please ignore as appropriate. If > > you'd prefer that to be on a mailing list, please indicate on which list > > you want to have that, and I'll resend. > > > It should be cc'ed to the netdev mailing list, as listed in MAINTAINERS. I have bounced the original message there. Sorry for missing that, I was not aware that the MAINTAINERS file goes down on a single driver level. > > My desktop copmuter has the following network interface: > > > > 06:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. > > RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 06) > > Subsystem: ASUSTeK Computer Inc. P8P67 and other motherboards > > Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- > > Stepping- SERR+ FastB2B- DisINTx+ > > Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- > > SERR- > Latency: 0, Cache Line Size: 64 bytes > > Interrupt: pin A routed to IRQ 17 > > NUMA node: 0 > > Region 0: I/O ports at e800 [size=256] > > Region 2: Memory at fdfff000 (64-bit, prefetchable) [size=4K] > > Region 4: Memory at fdff8000 (64-bit, prefetchable) [size=16K] > > Capabilities: > > Kernel driver in use: r8169 > > Kernel modules: r8169 > > > Unfortunately there's different chip versions with the same description. > Please provide the result of "dmesg | grep XID". [1/5004]mh@fan:~ $ dmesg | grep XID [2.671004] r8169 :06:00.0 eth0: RTL8168evl/8111evl, 54:04:a6:82:21:00, XID 2c900800, IRQ 29 > > I regularly buíld a VPN tunnel to my local network from 'on the road' > > and use WoL to wake up the desktop box when I need it. > > > > Since kernel 4.19, that does not work any more, the desktop remains > > suspended when I send it a magic packet. This still applies to 4.20.1, > > and it still works with any 4.18 kernel. > > > WoL works perfectly fine here with r8169 from runtime-suspend and > from S3. How do you enable WoL? And which WoL method do you use > (magic packet or ..) ? I do enable WOL via systemd-networkd: [7/5009]mh@fan:~ $ cat /etc/systemd/network/10-lanc0.link [Match] MACAddress=54:04:a6:82:21:00 [Link] Name=lanc0 WakeOnLan=magic and I wake up the box by calling sudo etherwake -i int182 54:04:a6:82:21:00 on the router. int182 is the interface name of the correct interface, this is proven correct by the fact that the box wakes up just fine with older version of the driver. > Please provide a register dump (ethtool -d ). The register dump is here (obtained with 4.20.1 with the r8169.c from 4.18): [5/5008]mh@fan:~ $ sudo ethtool -d lanc0 RealTek RTL8168evl/8111evl registers: 0x00: MAC Address 54:04:a6:82:21:00 0x08: Multicast Address Filter 0x 0x 0x10: Dump Tally Counter Command 0x20f36000 0x0004 0x20: Tx Normal Priority Ring Addr 0x14994000 0x0004 0x28: Tx High Priority Ring Addr 0x 0x 0x30: Flash memory read/write 0x 0x34: Early Rx Byte Count 0 0x36: Early Rx Status 0x00 0x37: Command 0x0c Rx on, Tx on 0x3C: Interrupt Mask 0x803f SERR LinkChg RxNoBuf TxErr TxOK RxErr RxOK 0x3E: Interrupt Status0x 0x40: Tx Configuration0x2f900f80 0x44: Rx Configuration0x0002c70f 0x48: Timer count 0x 0x4C: Missed packet counter 0x00 0x50: EEPROM Command0x10 0x51: Config 0 0x00 0x52: Config 1 0xcf 0x53: Config 2 0xbd 0x54: Config 3 0x60 0x55: Config 4 0x51 0x56: Config 5 0x02 0x58: Timer interrupt 0x 0x5C: Multiple Interrupt Select 0x 0x60: PHY access 0x8005c1e1 0x64: TBI control and status 0x84321043 0x68: TBI Autonegotiation advertisement (ANAR)0xf02c 0x6A: TBI Link partner ability (LPAR) 0x 0x6C: PHY status0x93 0x84: PM wakeup frame 00x 0x 0x8C: P
Re: [offlist] Re: Crash in netlink/sk_filter_trim_cap on ARMv7 on 4.18rc1
000 [ 11.999732] 1fc0: be8dcf80 b6f19ce8 0186aea0 0128 0062 0186b6e8 [ 12.007902] 1fe0: 0128 be8dcf50 b6e003e3 b6e01346 [ 12.012957] Code: e3130010 e1a0c000 1a30 e35c (e584900c) [ 12.019056] Internal error: Oops: a06 [#4] SMP ARM [ 12.019171] ---[ end trace 1b60255ae59ac008 ]--- -- ----- 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
Re: 319554f284dd ("inet: don't use sk_v6_rcv_saddr directly") causes bind port regression
Hi, those four patches never made it into any 4.13 release. 0001-net-call-sk_reuseport_match-if-we-are-a-reusesock.patch 0001-net-don-t-fast-patch-mismatched-sockets-in-STRICT-mo.patch 0001-net-use-inet6_rcv_saddr-to-compare-sockets.patch 0001-net-set-tb-fast_sk_family.patch And I have just seen that the first two are not even in 4.14. What does that mean for libvirt users on systems runnign a 4.14 kernel? The third and fourth patch (0001-net-use-inet6_rcv_saddr-to-compare-sockets.patch and 0001-net-set-tb-fast_sk_family.patch) seem to be in 4.14. Greetings Marc On Mon, Sep 18, 2017 at 10:02:32AM +0200, Marc Haber wrote: > On Sun, Sep 17, 2017 at 09:17:13AM -0400, Cole Robinson wrote: > > On 09/15/2017 01:51 PM, Josef Bacik wrote: > > > Finally got access to a box to run this down myself. This patch on top > > > of the other patches fixes the problem for me, could you verify it works > > > for you? Thanks, > > > > > > > Yup I can confirm that patch fixes things when applied on top of the > > previous 3 patches. Thanks! Please tag those patches for stable releases > > if appropriate, this is affecting a decent amount of libvirt users > > I can also confirm that these four patches fix things for me (on > Debian) as well. Thanks! > > I would love to have this in one of Greg's next 4.13 releases. -- - 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
Re: 319554f284dd ("inet: don't use sk_v6_rcv_saddr directly") causes bind port regression
On Sun, Sep 17, 2017 at 09:17:13AM -0400, Cole Robinson wrote: > On 09/15/2017 01:51 PM, Josef Bacik wrote: > > Finally got access to a box to run this down myself. This patch on top of > > the other patches fixes the problem for me, could you verify it works for > > you? Thanks, > > > > Yup I can confirm that patch fixes things when applied on top of the > previous 3 patches. Thanks! Please tag those patches for stable releases > if appropriate, this is affecting a decent amount of libvirt users I can also confirm that these four patches fix things for me (on Debian) as well. Thanks! I would love to have this in one of Greg's next 4.13 releases. 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
Re: After a while of system running no incoming UDP any more?
On Fri, Aug 11, 2017 at 04:34:53PM +0200, Marc Haber wrote: > On Fri, Jul 28, 2017 at 02:14:34PM +0200, Marc Haber wrote: > > I can confirm that these two changes make a system in bad state work > > again immediately. Will try the patch on 4.12.4 later today. > > After upgrading my test systems to 4.12.5, the issue reappeared. This > shows me that the patch indeed helped (my patched 4.12.4 kernels didn't > show the bad behavior), and that the patch didn't make its way into > 4.12.5. The patch applied to 4.12.5, kernels are building. It seems to be in the freshly released 4.12.6. 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
Re: After a while of system running no incoming UDP any more?
On Fri, Jul 28, 2017 at 02:14:34PM +0200, Marc Haber wrote: > I can confirm that these two changes make a system in bad state work > again immediately. Will try the patch on 4.12.4 later today. After upgrading my test systems to 4.12.5, the issue reappeared. This shows me that the patch indeed helped (my patched 4.12.4 kernels didn't show the bad behavior), and that the patch didn't make its way into 4.12.5. The patch applied to 4.12.5, kernels are building. The run-time fix works as well. 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
Re: After a while of system running no incoming UDP any more?
On Fri, Jul 28, 2017 at 10:07:57AM +0200, Paolo Abeni wrote: > Ad a workaround you can disable UDP early demux: > > echo 0 > /proc/sys/net/ipv4/udp_early_demux > > (will affect both ipv4 and ipv6). > > and (if the system is already into the bad state) increase the udp > accounted memory limit, writing in /proc/sys/net/ipv4/udp_mem greater > values than the current ones (the actual values depends on the system > total memory). I can confirm that these two changes make a system in bad state work again immediately. Will try the patch on 4.12.4 later today. Thanks for helping! 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
Re: After a while of system running no incoming UDP any more?
tagrams 1 0.0 UdpInErrors 50 0.0 UdpOutDatagrams 47 0.0 UdpIgnoredMulti 1 0.0 Ip6InReceives 75 0.0 Ip6InDelivers 73 0.0 Ip6OutRequests 64 0.0 Ip6InMcastPkts 2 0.0 Ip6InOctets 7837 0.0 Ip6OutOctets11876 0.0 Ip6InMcastOctets2790.0 Ip6InNoECTPkts 75 0.0 Udp6InErrors3 0.0 IpExtInBcastPkts1 0.0 IpExtInOctets 18447 0.0 IpExtOutOctets 3478 0.0 IpExtInBcastOctets 1830.0 IpExtInNoECTPkts59 0.0 ; <<>> DiG 9.10.3-P4-Debian <<>> +time=2 @8.8.8.8 zugschlus.de mx ; (1 server found) ;; global options: +cmd ;; connection timed out; no servers could be reached Recv-Q Send-Q Local Address:Port Peer Address:Port 0 0 216.231.132.60:7879 202.12.27.33:domain 0 0 216.231.132.60:32711 202.12.27.33:domain 0 0 216.231.132.60:54238 202.12.27.33:domain 0 0 216.231.132.60:30948 192.228.79.201:domain 0 0 216.231.132.60:4106 202.12.27.33:domain 0 0 216.231.132.60:6667 202.12.27.33:domain 0 0 216.231.132.60:2090 192.228.79.201:domain 0 0 216.231.132.60:60459 192.228.79.201:domain 0 0 216.231.132.60:16427 202.12.27.33:domain 0 0 216.231.132.60:9019 202.12.27.33:domain 0 0 216.231.132.60:2113 202.12.27.33:domain 0 0 216.231.132.60:34907 202.12.27.33:domain 0 0 216.231.132.60:34654 202.12.27.33:domain 0 0 216.231.132.60:47725 202.12.27.33:domain 0 0 216.231.132.60:35774 202.12.27.33:domain IpInReceives38 0.0 IpInDelivers38 0.0 IpOutRequests 38 0.0 UdpInDatagrams 2 0.0 UdpInErrors 34 0.0 UdpOutDatagrams 36 0.0 Ip6InReceives 14 0.0 Ip6InDelivers 13 0.0 Ip6OutRequests 13 0.0 Ip6InMcastPkts 1 0.0 Ip6InOctets 1046 0.0 Ip6OutOctets6277 0.0 Ip6InMcastOctets1330.0 Ip6InNoECTPkts 13 0.0 Ip6InECT0Pkts 1 0.0 Udp6InDatagrams 1 0.0 Udp6OutDatagrams1 0.0 IpExtInOctets 15963 0.0 IpExtOutOctets 2397 0.0 IpExtInNoECTPkts37 0.0 IpExtInECT0Pkts 1 0.0 [20/1079]mh@impetus:~ $ I am afraid I cannot keep this state for much longer than a few additional hours as this is an authoritative name server... Greetings Marc -- ----- Marc Haber | "I don't trust Computers. They | Mailadresse im Header Leimen, Germany| lose things."Winona Ryder | Fon: *49 6224
Re: After a while of system running no incoming UDP any more?
On Tue, Jul 25, 2017 at 02:17:52PM +0200, Paolo Abeni wrote: > On Tue, 2017-07-25 at 13:57 +0200, Marc Haber wrote: > > On Mon, Jul 24, 2017 at 04:19:10PM +0200, Paolo Abeni wrote: > > > Once that a system enter the buggy status, do the packets reach the > > > relevant socket's queue? > > > > > > ss -u > > > > That one only shows table headers on an unaffected system in normal > > operation, right? > > This one shows the current lenght of the socket receive queue (Recv-Q, > the first column). If the packets land into the skbuff (and the user > space reader for some reason is not woken up) such value will grow over > time. Only that there is no value: [4/4992]mh@swivel:~ $ ss -u Recv-Q Send-Q Local Address:Port Peer Address:Port [5/4992]mh@swivel:~ $ (is that the intended behavior on a system thiat is not affected by the issue?) > > > nstat |grep -e Udp -e Ip > > > > > > will help checking that. > > > > An unaffected system will show UdpInDatagrams, right? > > > > But where is the connection to the relevant socket's queue? > > If the socket queue lenght (as reported above) does not increase, > IP/UDP stats could give an hint of where and why the packets stop > traversing the network stack. We'll see. Still waiting for the phenomenon to show up again. > Beyond that, you can try using perf probes or kprobe/systemtap to [try > to] track the relevant packets inside the kernel. That's way beyond my kernel foo, I'm afraid. Thanks for helping, I'll report back. 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
Re: After a while of system running no incoming UDP any more?
Hi Paolo,
thanks for your answer. I appreciate that.
On Mon, Jul 24, 2017 at 04:19:10PM +0200, Paolo Abeni wrote:
> On Mon, 2017-07-24 at 14:09 +0200, Marc Haber wrote:
> > Before I begin running older kernels on productive systems, I would like
> > to ask wether there have been recent changes in the 4.11 => 4.12
> > development cycle that might cause an issue like that.
>
> While there has been some activity regarding the UDP protocol lately,
> almost nothing touched UDP in the 4.11 release cycle.
4.11 is good, 4.12 is bad.
> The issue you describe looks similar to the bug fixed by the commit
> 9bd780f5e066 ("udp: fix poll()"), but the bugged code is only in later
> kernels.
That one is in v4.13-rc1 and v4.13-rc2, but it doesn't apply to my 4.12
trees.
> > Any idea what might be happening here and what else I could try?
>
> Once that a system enter the buggy status, do the packets reach the
> relevant socket's queue?
>
> ss -u
That one only shows table headers on an unaffected system in normal
operation, right?
> nstat |grep -e Udp -e Ip
>
> will help checking that.
An unaffected system will show UdpInDatagrams, right?
But where is the connection to the relevant socket's queue?
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
After a while of system running no incoming UDP any more?
Hi, I am running ~ 50 servers, most of them as KVM guests, some of them as Xen guests, and even less of them on hardware, and have recently updated to Debian stretch. I usually use kernels locally built from the latest vanille stable release. Roughly since the upgrade to Debian stretch and kernel 4.12, some of my systems have begun to not forward UDP packets (such as incoming DNS replies) to the user space. When this happens, I see the packet coming in on tcpdump -p, but the application never sees it and eventuelly times out. An strace on the process sees the process waiting on the select() syscall and nothing happens when the system receives the UDP packet. I do also see the same phenomenon with ntp. A reboot always fixes the issue. Runnign wireshark on a pcap file obtained on an affected systems does show all checksums to be in order. Both IPv4 and IPv6 are affected, and in the DNS case, switching dig/drill or even the system resolver to TCP also fixes the issue. This happens only after the system has been running for a few days, and I have seen this happen on both KVM and Xen guests, but not (yet) on real hardware. In my zoo of servers, this happens - over the entire sample - about twice a week, often enough to be annoying and seldomly enough to make debugging really difficult since you'll never know in advance which system will have the issue for the next time. I have therefore been reluctant to downgrade kernel or system since that would mean days of work. Bisecting is probably out of the question since you'll never know when "git bisect good" is a sufficiently safe assumption. Before I begin running older kernels on productive systems, I would like to ask wether there have been recent changes in the 4.11 => 4.12 development cycle that might cause an issue like that. Since I have never seen the issue on stretch systems when they were still running 4.11.8 (the latest 4.11 kernel that I had deployed before switching over to 4.12), I do really suspect the kernel, and I do also suspect that network interface offloading is probably not the culprit. On the KVM guests, I use virtio-net, and I had that one high on my list until one of the two Xen guests that doesn't show any network modules loaded has been showing the phenomenon as well. That Xen guest outputs the following to lshw -C network: that doesn't show any network modules loaded has been showing the phenomenon as well. That Xen guest outputs the following to lshw -C network: *-network description: Ethernet interface physical id: 1 logical name: eth0 serial: 0e:06:5f:74:48:97 capabilities: ethernet physical configuration: broadcast=yes driver=vif ip= link=yes multicast=yes So I assume that this one is not using virtio-net, so virtio-net seems safe as well. Any idea what might be happening here and what else I could try? 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
Re: [PATCH (net.git) 2/3] Revert "stmmac: Fix 'eth0: No PHY found' regression"
On Wed, Apr 13, 2016 at 05:44:25PM +0200, Marc Haber wrote:
> On Fri, Apr 01, 2016 at 09:07:15AM +0200, Giuseppe Cavallaro wrote:
> > This reverts commit 88f8b1bb41c6208f81b6a480244533ded7b59493.
> > due to problems on GeekBox and Banana Pi M1 board when
> > connected to a real transceiver instead of a switch via
> > fixed-link.
>
> This reversal is still needed in Linux 4.5.1 on Banana Pi.
>
> Please consider including it in Linux 4.5.2.
This reversal is still needed in Linux 4.5.4 on Banana Pi.
Please consider including it in Linux 4.5.5.
Greetings
Marc
>
> >
> > Signed-off-by: Giuseppe Cavallaro
> > Cc: Gabriel Fernandez
> > Cc: Andreas Färber
> > Cc: Frank Schäfer
> > Cc: Dinh Nguyen
> > Cc: David S. Miller
> > ---
> > drivers/net/ethernet/stmicro/stmmac/stmmac_mdio.c | 11 ++-
> > .../net/ethernet/stmicro/stmmac/stmmac_platform.c |9 +
> > include/linux/stmmac.h |1 -
> > 3 files changed, 11 insertions(+), 10 deletions(-)
> >
> > diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_mdio.c
> > b/drivers/net/ethernet/stmicro/stmmac/stmmac_mdio.c
> > index ea76129..af09ced 100644
> > --- a/drivers/net/ethernet/stmicro/stmmac/stmmac_mdio.c
> > +++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_mdio.c
> > @@ -199,12 +199,21 @@ int stmmac_mdio_register(struct net_device *ndev)
> > struct stmmac_priv *priv = netdev_priv(ndev);
> > struct stmmac_mdio_bus_data *mdio_bus_data = priv->plat->mdio_bus_data;
> > int addr, found;
> > - struct device_node *mdio_node = priv->plat->mdio_node;
> > + struct device_node *mdio_node = NULL;
> > + struct device_node *child_node = NULL;
> >
> > if (!mdio_bus_data)
> > return 0;
> >
> > if (IS_ENABLED(CONFIG_OF)) {
> > + for_each_child_of_node(priv->device->of_node, child_node) {
> > + if (of_device_is_compatible(child_node,
> > + "snps,dwmac-mdio")) {
> > + mdio_node = child_node;
> > + break;
> > + }
> > + }
> > +
> > if (mdio_node) {
> > netdev_dbg(ndev, "FOUND MDIO subnode\n");
> > } else {
> > diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
> > b/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
> > index dcbd2a1..9cf181f 100644
> > --- a/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
> > +++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
> > @@ -146,7 +146,6 @@ stmmac_probe_config_dt(struct platform_device *pdev,
> > const char **mac)
> > struct device_node *np = pdev->dev.of_node;
> > struct plat_stmmacenet_data *plat;
> > struct stmmac_dma_cfg *dma_cfg;
> > - struct device_node *child_node = NULL;
> >
> > plat = devm_kzalloc(&pdev->dev, sizeof(*plat), GFP_KERNEL);
> > if (!plat)
> > @@ -177,19 +176,13 @@ stmmac_probe_config_dt(struct platform_device *pdev,
> > const char **mac)
> > plat->phy_node = of_node_get(np);
> > }
> >
> > - for_each_child_of_node(np, child_node)
> > - if (of_device_is_compatible(child_node, "snps,dwmac-mdio")) {
> > - plat->mdio_node = child_node;
> > - break;
> > - }
> > -
> > /* "snps,phy-addr" is not a standard property. Mark it as deprecated
> > * and warn of its use. Remove this when phy node support is added.
> > */
> > if (of_property_read_u32(np, "snps,phy-addr", &plat->phy_addr) == 0)
> > dev_warn(&pdev->dev, "snps,phy-addr property is deprecated\n");
> >
> > - if ((plat->phy_node && !of_phy_is_fixed_link(np)) || !plat->mdio_node)
> > + if ((plat->phy_node && !of_phy_is_fixed_link(np)) || plat->phy_bus_name)
> > plat->mdio_bus_data = NULL;
> > else
> > plat->mdio_bus_data =
> > diff --git a/include/linux/stmmac.h b/include/linux/stmmac.h
> > index 4bcf5a6..6e53fa8 100644
> > --- a/include/linux/stmmac.h
> > +++ b/include/linux/stmmac.h
> > @@ -114,7 +114,6 @@ struct plat_stmmacenet_data {
> > int interface;
> > struct stmmac_mdio_bus_data *mdio_bus_data;
> > struct device_node *phy_node;
> > - struct device_node *mdio_node;
Re: [PATCH (net.git) 2/3] Revert "stmmac: Fix 'eth0: No PHY found' regression"
On Fri, Apr 01, 2016 at 09:07:15AM +0200, Giuseppe Cavallaro wrote:
> This reverts commit 88f8b1bb41c6208f81b6a480244533ded7b59493.
> due to problems on GeekBox and Banana Pi M1 board when
> connected to a real transceiver instead of a switch via
> fixed-link.
This reversal is still needed in Linux 4.5.1 on Banana Pi.
Please consider including it in Linux 4.5.2.
Greetings
Marc
>
> Signed-off-by: Giuseppe Cavallaro
> Cc: Gabriel Fernandez
> Cc: Andreas Färber
> Cc: Frank Schäfer
> Cc: Dinh Nguyen
> Cc: David S. Miller
> ---
> drivers/net/ethernet/stmicro/stmmac/stmmac_mdio.c | 11 ++-
> .../net/ethernet/stmicro/stmmac/stmmac_platform.c |9 +
> include/linux/stmmac.h |1 -
> 3 files changed, 11 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_mdio.c
> b/drivers/net/ethernet/stmicro/stmmac/stmmac_mdio.c
> index ea76129..af09ced 100644
> --- a/drivers/net/ethernet/stmicro/stmmac/stmmac_mdio.c
> +++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_mdio.c
> @@ -199,12 +199,21 @@ int stmmac_mdio_register(struct net_device *ndev)
> struct stmmac_priv *priv = netdev_priv(ndev);
> struct stmmac_mdio_bus_data *mdio_bus_data = priv->plat->mdio_bus_data;
> int addr, found;
> - struct device_node *mdio_node = priv->plat->mdio_node;
> + struct device_node *mdio_node = NULL;
> + struct device_node *child_node = NULL;
>
> if (!mdio_bus_data)
> return 0;
>
> if (IS_ENABLED(CONFIG_OF)) {
> + for_each_child_of_node(priv->device->of_node, child_node) {
> + if (of_device_is_compatible(child_node,
> + "snps,dwmac-mdio")) {
> + mdio_node = child_node;
> + break;
> + }
> + }
> +
> if (mdio_node) {
> netdev_dbg(ndev, "FOUND MDIO subnode\n");
> } else {
> diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
> b/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
> index dcbd2a1..9cf181f 100644
> --- a/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
> +++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
> @@ -146,7 +146,6 @@ stmmac_probe_config_dt(struct platform_device *pdev,
> const char **mac)
> struct device_node *np = pdev->dev.of_node;
> struct plat_stmmacenet_data *plat;
> struct stmmac_dma_cfg *dma_cfg;
> - struct device_node *child_node = NULL;
>
> plat = devm_kzalloc(&pdev->dev, sizeof(*plat), GFP_KERNEL);
> if (!plat)
> @@ -177,19 +176,13 @@ stmmac_probe_config_dt(struct platform_device *pdev,
> const char **mac)
> plat->phy_node = of_node_get(np);
> }
>
> - for_each_child_of_node(np, child_node)
> - if (of_device_is_compatible(child_node, "snps,dwmac-mdio")) {
> - plat->mdio_node = child_node;
> - break;
> - }
> -
> /* "snps,phy-addr" is not a standard property. Mark it as deprecated
>* and warn of its use. Remove this when phy node support is added.
>*/
> if (of_property_read_u32(np, "snps,phy-addr", &plat->phy_addr) == 0)
> dev_warn(&pdev->dev, "snps,phy-addr property is deprecated\n");
>
> - if ((plat->phy_node && !of_phy_is_fixed_link(np)) || !plat->mdio_node)
> + if ((plat->phy_node && !of_phy_is_fixed_link(np)) || plat->phy_bus_name)
> plat->mdio_bus_data = NULL;
> else
> plat->mdio_bus_data =
> diff --git a/include/linux/stmmac.h b/include/linux/stmmac.h
> index 4bcf5a6..6e53fa8 100644
> --- a/include/linux/stmmac.h
> +++ b/include/linux/stmmac.h
> @@ -114,7 +114,6 @@ struct plat_stmmacenet_data {
> int interface;
> struct stmmac_mdio_bus_data *mdio_bus_data;
> struct device_node *phy_node;
> - struct device_node *mdio_node;
> struct stmmac_dma_cfg *dma_cfg;
> int clk_csr;
> int has_gmac;
> --
> 1.7.4.4
>
--
-
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
Re: IPv6 route to gateway on fe80::1%eth0 when I have fe80::1%br0 locally
On Tue, Feb 23, 2016 at 10:03:28AM +0100, Hannes Frederic Sowa wrote: > Thanks for letting me know. Hopefully this also fixes > https://bugzilla.kernel.org/show_bug.cgi?id=110721. As far as I have understood the systemd release logs, the code handling IPv6 RAs was added in systemd 229, which was released on February 11. So, #110721, filed in January, seems to be "safe" from this issue unless a development snapshot of systemd was used here. 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
Re: IPv6 route to gateway on fe80::1%eth0 when I have fe80::1%br0 locally
On Mon, Feb 22, 2016 at 05:15:41PM +0100, Hannes Frederic Sowa wrote: > On 22.02.2016 16:47, Marc Haber wrote: > >Can you reproduce the behavior with accept_ra_from_local =0 as well? > >Unfortunately, the debugging VM I build works fine, it's just the > >physical host showing this behavior. This is really strange. > > Same here. Debugging VM didn't show this error at all and other systems > didn't show this symptom either (4.4.2 as well as net-next). > > With which kernel did you see this behavior for the first time and what was > the last working version? Thanks for motivating me to investigate this further. I have to apologize. It is not a kernel issue. It has turned out that systemd, starting with version 229, has placed a "Not invented here" stamp on route advertisement processing in the kernel and has implemented its own userspace code to handle router advertisements. And, of course, they did it wrong. Setting IPv6AcceptRouterAdvertisements=0 in eth0.network seems to disable enough code that this issue does not show any more. Sorry for the rumble, I debugged the wrong piece of software. Bugs in Debian are filed, #815582, #815586. I don't file bugs with systemd upstream any more since I got silenced on systemd-devel for losing my temper. 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
Re: IPv6 route to gateway on fe80::1%eth0 when I have fe80::1%br0 locally
On Mon, Feb 22, 2016 at 04:12:36PM +0100, Hannes Frederic Sowa wrote: > On 22.02.2016 16:04, Marc Haber wrote: > >In prose: > > > >The host is a host for KVM VMs. It receives IPv6 connectivity via RA > >on eth0, where the default gateway announces its address as fe80::1. > >It also provides IPv6 connectivity to the VMs via the br0 interface. > >It is running radvd on br0, and for statically configured VMs it has > >also fe80::1 on br0. > > > >If accept_ra_from_local on eth0 were 0, the system would not accept > >the RA from the default gateway and and up with no IPv6 since fe80::1 > >is locally configured with br0. > > Isn't this behavior fixed with > > commit c1a9a291cee0890eb0f435243f3fb84fefb04348 > Author: Hannes Frederic Sowa > Date: Wed Dec 23 22:44:37 2015 +0100 > > ipv6: honor ifindex in case we receive ll addresses in router > advertisements > > $ git describe --contains c1a9a291cee0890eb0f435243f3fb84fefb04348 > v4.4-rc8~5^2~10 > > ? > > If you don't have fe80::1%br0 bound on exactly that interface, it should > work, no? So, no need for accept_ra_from_local, which has dubious semantics > anyway. I have accept_ra_from_local set to 0 on all interfaces now, and I still get the dubious default route on eth0. > >If accept_ra_from_local on eth0 is 1, the system accepts both the RA > >from the default gateway on eth0 _AND_ its own RA sent out and > >received on br0, and, making things worse, is setting the IP address > >and default route not on br0, but on eth0. > > Understood. Thanks, I was just able to easily reproduce it. Was already > wondering why someone would enable accept_ra_from_local besides only > testing. I check it out, thanks! Can you reproduce the behavior with accept_ra_from_local =0 as well? Unfortunately, the debugging VM I build works fine, it's just the physical host showing this behavior. This is really strange. 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
Re: IPv6 route to gateway on fe80::1%eth0 when I have fe80::1%br0 locally
Hi Hannes,
On Tue, Dec 22, 2015 at 10:50:04PM +0100, Hannes Frederic Sowa wrote:
> Thanks but no need to do that, I already cooked a patch and will submit
> tomorrow after some testing. We don't need to enhance the sysctl,
> default should be to simply check the interface too if a route with
> link-local address is received.
Kernel bugzilla #112751 is related to this.
The following is snipped to the relevant parts and was obtained on a
Debian system running kernel 4.4.2
[1/501]mh@fan:~$ for f in
/proc/sys/net/ipv6/conf/*/{accept_ra,accept_ra_from_local,forwarding}; do echo
$f; cat $f; done
/proc/sys/net/ipv6/conf/all/accept_ra
1
/proc/sys/net/ipv6/conf/br0/accept_ra
0
/proc/sys/net/ipv6/conf/default/accept_ra
1
/proc/sys/net/ipv6/conf/eth0/accept_ra
2
/proc/sys/net/ipv6/conf/all/accept_ra_from_local
0
/proc/sys/net/ipv6/conf/br0/accept_ra_from_local
0
/proc/sys/net/ipv6/conf/default/accept_ra_from_local
0
/proc/sys/net/ipv6/conf/eth0/accept_ra_from_local
1
[2/502]mh@fan:~$ ip a
2: eth0: mtu 1500 qdisc pfifo_fast state UP
group default qlen 1000
inet6 2a01:238:4071:328d:5604:a6ff:fe82:2100/64 scope global mngtmpaddr
noprefixroute dynamic
valid_lft 86038sec preferred_lft 14038sec
inet6 2a01:238:4071:3282:5604:a6ff:fe82:2100/64 scope global mngtmpaddr
noprefixroute dynamic
valid_lft 86372sec preferred_lft 14372sec
3: br0: mtu 1500 qdisc noqueue state UP group
default qlen 1000
inet6 2a01:238:4071:328d::1d:153/64 scope global
valid_lft forever preferred_lft forever
inet6 2a01:238:4071:328d::1d:100/64 scope global
valid_lft forever preferred_lft forever
[3/503]mh@fan:~$ ip -6 r
default via fe80::1 dev eth0 proto ra metric 1024 pref medium
default via fe80::c4f4:98ff:fedc:5e21 dev eth0 proto ra metric 1024 pref
medium
[4/504]mh@fan:~$
In prose:
The host is a host for KVM VMs. It receives IPv6 connectivity via RA
on eth0, where the default gateway announces its address as fe80::1.
It also provides IPv6 connectivity to the VMs via the br0 interface.
It is running radvd on br0, and for statically configured VMs it has
also fe80::1 on br0.
If accept_ra_from_local on eth0 were 0, the system would not accept
the RA from the default gateway and and up with no IPv6 since fe80::1
is locally configured with br0.
If accept_ra_from_local on eth0 is 1, the system accepts both the RA
from the default gateway on eth0 _AND_ its own RA sent out and
received on br0, and, making things worse, is setting the IP address
and default route not on br0, but on eth0.
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
Re: IPv6 route to gateway on fe80::1%eth0 when I have fe80::1%br0 locally
Hi Hannes, thanks for your mail. On Tue, Dec 22, 2015 at 04:15:14PM +0100, Hannes Frederic Sowa wrote: > On 12.12.2015 20:58, Marc Haber wrote: > > Any hints would be appreciated. > > This sysctl should help: > > accept_ra_from_local - BOOLEAN > Accept RA with source-address that is found on local machine > if the RA is otherwise proper and able to be accepted. > Default is to NOT accept these as it may be an un-intended > network loop. > > Functional default: >enabled if accept_ra_from_local is enabled >on a specific interface. >disabled if accept_ra_from_local is disabled >on a specific interface. > > Anyway, this has to be fixed up in a clean way and should work by default. The clean way would be: accept_ra_from_local=0: never accept RA with source-address that is found on local machine accept_ra_from_local=1: always accept RA with source-address that is found on local machine. Dangerous. accept_ra_from_local=2: only accept RA with link local source-address that is found on local machine, and not if received RA points to an address that is locally configured on the same interface. Default. Shall I file a bug for this in bugzilla? 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 -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
IPv6 route to gateway on fe80::1%eth0 when I have fe80::1%br0 locally
Hi,
one of my systems (Debian unstable, kernel 4.3.2) serves as host to
virtualize other systems. It therefore has a Bridge interface br0 to
talk to the virtual machines. To have simple configuration, I have
configured fe80::1 on br0, and the VMs use that as a default gateway
(in the case that SLAAC might be turned off on the target machines).
|[1/498]mh@fan:~$ ip -6 addr show dev br0
|3: br0: mtu 1500 state UP qlen 1000
|inet6 2a01:238:4071:328d:c4f4:98ff:fedc:5e21/64 scope global mngtmpaddr
dynamic
| valid_lft 86400sec preferred_lft 14400sec
|inet6 2a01:238:4071:328d::1d:153/64 scope global
| valid_lft forever preferred_lft forever
|inet6 2a01:238:4071:328d::1d:100/64 scope global
| valid_lft forever preferred_lft forever
|inet6 fec0:0:0:::3/128 scope site
| valid_lft forever preferred_lft forever
|inet6 fec0:0:0:::2/128 scope site
| valid_lft forever preferred_lft forever
|inet6 fec0:0:0:::1/128 scope site
| valid_lft forever preferred_lft forever
|inet6 fe80::1/64 scope link
| valid_lft forever preferred_lft forever
|inet6 fe80::c4f4:98ff:fedc:5e21/64 scope link
| valid_lft forever preferred_lft forever
|[2/499]mh@fan:~$
The Machine itself does, of course, have an uplink to the Internet. I
would like to have it do SLAAC on that uplink interface so that it
learns the gateway automatically.
/proc/sys/net/ipv6/conf/{all,eth0}/forwarding is 1,
/proc/sys/net/ipv6/conf/{all,eth0}/accept_ra is 2.
On older machines, this setup works fine.
Here is the result of SLAAC:
|[2/499]mh@fan:~$ ip -6 addr show dev eth0
|2: eth0: mtu 1500 state UP qlen 1000
|inet6 2a01:238:4071:3282:5604:a6ff:fe82:2100/64 scope global mngtmpaddr
dynamic
| valid_lft 86318sec preferred_lft 14318sec
|inet6 fe80::5604:a6ff:fe82:2100/64 scope link
| valid_lft forever preferred_lft forever
|[3/500]mh@fan:~$
Please note that eth0 does _not_ have an fe80::1 address.
The gateway that is reachable on the physical eth0 is a Linux as well.
It's running radvd 1.9.1, and it has fe80::1 on its inner interface
configured, for the same reason of ease of configurability on systems
not running SLAAC. It also has a auto-configured link local address,
fe80::7c79:61ff:fe31:5528/64.
For some strange reasons, the radvd running on the router now
announces fe80::1 as the gateway address and not the auto-configured
link local address that older radvd versions (such as the 1.8 in
Debian oldstable) use.
Fan, the system in question, uses this as excuse to only honor the
prefix announcement in the RA coming in from the router and to ignore
the gateway, presumably because we have the same IP address bound to
one of our other IP addresses.
In IPv6, this setup is however, perfectly valid and common. fe80::1 is
commonly used on interfaces that can be used as gateway towards the
Internet so that the local admin does not need to think when manually
setting a default route. This is easily proven by manually setting the
route ("ip -6 route add default via fe80::1 dev eth0"), which makes
the entire setup work immediately.
Cross-Checking, with the fe80::1 removed from br0, things are fine as
well, prefix and route are learned on eth0 in this case.
I find the kernel's behavior perfectly valid for IPv4, so that it
doesn't accept routes pointing towards locally bound IP addresses. In
IPv6, link local addresses do depend on the interface, and thus only
the combination of IP address and interface should be used for this
extra check.
It should be possible to have fe80::1%br0 locally while having a route
point towards fe80::1%eth0. That this does not work is, in my opinion,
a kernel bug.
I am open to arguments why the kernel's behavior is correct this way,
and would like to know what to do on my systems to (a) have SLAAC
working on my "routing" VM host and to (b) keep ease of configuration
on non-SLAAC systems on both the physical and the virtual network.
Any hints would be appreciated.
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
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
