Hi,

the regression I reported yesterday (#388) had the side effect of exposing another issue that I actually experienced a long time ago once. Back then, I had a suspicion of what was going on, but I didn't follow up on it. Now, combing through the logs of before and after the firmware upgrade I attempted to do two days ago, I can see my suspicion was correct.

Issue
When you populate the mPCIe slots on an APU2 board, the PCI addresses of other PCIe devices change, in particular the ethernet interfaces, which in turn leads to new ethernet device names if you use systemd with its default persistent interface naming scheme. On a gateway or router, this may cause serious problems.

History
Over a year ago, I added two wireless mPCIe modules to my APU2 setup. After doing so, my network was dysfunctional and I was locked out of my device (at least via SSH). When I hooked up a serial cable, I was baffled to see that my ethernet interfaces got new names (all their indexes were 1 higher than before). Hence, my firewall rules were broken, my PPPoE connection was broken and all o the services that bind to an interface failed. When I removed the wireless cards, everything worked as before. My workaround back then was to write my own udev rules to make sure my interface names are persistent (based on the driver and MAC address).

Manifestation
Now, with the attempted upgrade to v4.11.0.5 two days ago and the effect that my WLE200NX wifi module did not work anymore after the upgrade, I can actually see this in my logs. Before the upgrade (with both of my wireless modules operational) my network devices had the following PCI addresses:
ath9k 0000:01:00.0 (Compex WLE200NX)
igb 0000:02:00.0 (Intel i210AT NIC no. 1)
igb 0000:03:00.0 (Intel i210AT NIC no. 2)
igb 0000:04:00.0 (Intel i210AT NIC no. 3)
ath10k_pci 0000:05:00.0 (Compex WLE600VX)

Now, after booting with firmware v4.11.0.5 and my WLE200NX card dysfunctional, the addresses became these:
igb 0000:01:00.0
igb 0000:02:00.0
igb 0000:03:00.0
ath10k_pci 0000:04:00.0

Lucky me, this time it caused no issues for me because I still have my custom udev rules in place, making sure my interface names are fixed.

Notes
I'm not really sure whether this technically is a bug, i.e. whether PCI addresses may change depending on whether a slot is populated or not. But it is against user expectation (and apparently the expectations of systemd developers) that adding a PCIe module will change the interface names of other network devices. After all, it's not that we're adding new slots rather than merely populating one that was there before.

In addition, this issue is not related to v4.11.0.5 in any way other that it showed it as a side effect. When I first ran into that problem more than a year ago, I was obviously running a completely different version. And I'm not even sure, whether back than I was running mainline or legacy.

Regards,

Timo