RTL8111h onboard, wake on lan broken, wakeup immediately

I have an Asus PRIME N100I-D D4 Board with onboard NIC.

The NIC is in PCI slot 0000:02:00.0, which seems to be behind 0000:00:1c.6 (pcieport). Presumably a PCI Bridge?

I cannot get WOL to work. Nevertheless, it is activated. But after a few seconds, the system wakes up.

# wicked ethtool eth0 --get-wol
wake-on-lan:
	options: magic

# systemctl suspend
# cat /proc/acpi/wakeup 
Device	S-state	  Status   Sysfs node
...
RP09	  S4	*enabled   pci:0000:00:1d.0
PXSX	  S4	*disabled  pci:0000:03:00.0
...
RP07	  S4	*enabled   pci:0000:00:1c.6
PXSX	  S4	*enabled   pci:0000:02:00.0
...
AWAC	  S4	*enabled   platform:ACPI000E:00

I tried kernel module r8169 for default, later replaced it by r8168 both, from pacman and from @Sauerland. To no avail.

Usually with the wakeup a message lines comes:

# dmesg
...
pcieport 0000:00:1c.6: PME: Spurious native interrupt!
...

I tried all reasonable BIOS settings, they all come down to the same result. I booted kernel with pci=noacpi – the “Spurious native interrupt!” was gone, but the wakeup persists.

Any idea? I guess r8168 is not for RTL8111h but only for other suffixes like “A,B,C,D,E,G”.

Thanks!

I am not quite understanding this.

Do you mean that after shutdown the system reboots from itself? Like if it sees a WOL?

When hat is true, you will never be able to even test if WOL works because you do not get a chance to test it.
But I would say that then WOL does work (when you switch it off, or not on, with ethtool it will not boot all by itself I assume), only “to good”.

I have seen this once on a system rather long ago. Switching on and shutdown let it boot immediate after. I never found out the BIOS setting to prevent this.

BTW.
I see you using wicked ethtool. I did not know that existed, but found it now in the man pages. Do you use wicked to manage your network?
I always use ethtool itself, but I assume it does the same.

PS
I get the impression that you very well know about WOL, but I nevertheless will point to my experiences (maybe for others):

Post

inxi -aMNSz

Possibly you’ll need to update inxi from Experimental repo.

Thanks for your reply, @Svyatko . Here’s the output:

~ # inxi -aMNSz
System:
  Kernel: 6.4.0-150600.23.33-default arch: x86_64 bits: 64 compiler: gcc v: 7.5.0
    parameters: BOOT_IMAGE=/boot/vmlinuz-6.4.0-150600.23.33-default
    root=UUID=1d0196ac-d3cf-4ec6-bc96-a64f1a13bcae splash=silent
    resume=/dev/disk/by-uuid/90981159-d9f3-413e-8c8e-18a9b869d20b preempt=full quiet
    security=apparmor mitigations=auto
  Console: pty pts/0 Distro: openSUSE Leap 15.6
Machine:
  Type: Desktop System: ASUS product: N/A v: N/A serial: N/A
  Mobo: ASUSTeK model: PRIME N100I-D D4 v: Rev 1.xx serial: <filter> UEFI: American Megatrends
    v: 0405 date: 12/13/2023
Network:
  Device-1: Realtek RTL8111/8168/8211/8411 PCI Express Gigabit Ethernet vendor: ASUSTeK RTL8111H
    driver: r8169 v: kernel pcie: gen: 1 speed: 2.5 GT/s lanes: 1 port: 3000 bus-ID: 02:00.0
    chip-ID: 10ec:8168 class-ID: 0200

Does inxi fit or should I update (it comes with a lot of dependencies unfortunately)?

Please note, I have uninstalled kernel module r8168 temporarily (r8169 is selected automatically).

Thank you, @hcvv , I had read it already. And i used ethtool as well.

Also post:
zypper lr -d
zypper se -si kernel-default r816

I skipped details (-d) because I couldn’t paste the result in a readable way.

~ # zypper lr
Repository priorities are without effect. All enabled repositories share the same priority.
#  | Alias                       | Name          | Enabled | GPG Check | Refresh---+-----------------------------+---------------+---------+-----------+-------- 1 | home_Sauerland_hardware     | Hardware (o-> | Yes     | (r ) Yes  | No
 2 | openSUSE-Leap-15.6-1        | openSUSE-Le-> | Yes     | (r ) Yes  | Yes
 3 | repo-backports-debug-update | Update repo-> | No      | ----      | ----
 4 | repo-backports-update       | Update repo-> | Yes     | (r ) Yes  | Yes
 5 | repo-debug                  | Debug Repos-> | No      | ----      | ----
 6 | repo-debug-non-oss          | Debug Repos-> | No      | ----      | ----
 7 | repo-debug-update           | Update Repo-> | No      | ----      | ----
 8 | repo-debug-update-non-oss   | Update Repo-> | No      | ----      | ----
 9 | repo-non-oss                | Non-OSS Rep-> | Yes     | (r ) Yes  | Yes
10 | repo-openh264               | Open H.264 -> | Yes     | (r ) Yes  | Yes
11 | repo-oss                    | Haupt-Repos-> | Yes     | (r ) Yes  | Yes
12 | repo-sle-debug-update       | Update repo-> | No      | ----      | ----
13 | repo-sle-update             | Update repo-> | Yes     | (r ) Yes  | Yes
14 | repo-source                 | Source Repo-> | No      | ----      | ----
15 | repo-update                 | Hauptaktual-> | Yes     | (r ) Yes  | Yes
16 | repo-update-non-oss         | Aktualisier-> | Yes     | (r ) Yes  | Yes
~ # zypper se -si kernel-default r816
Loading repository data...
Reading installed packages...
S  | Name                    | Type    | Version              | Arch   | Repository
---+-------------------------+---------+----------------------+--------+-------------------------------------------------------------
i+ | kernel-default          | package | 6.4.0-150600.23.33.1 | x86_64 | Update
repository with updates from SUSE Linux Enterprise 15
i  | kernel-default-extra    | package | 6.4.0-150600.23.33.1 | x86_64 | Update
repository with updates from SUSE Linux Enterprise 15
i  | kernel-default-optional | package | 6.4.0-150600.23.33.1 | x86_64 | Update
repository with updates from SUSE Linux Enterprise 15
i+ | r8168-ueficert          | package | 8.054.00-lp156.64.1  | x86_64 | Hardware (openSUSE_Leap_15.6)

@Sauerland The package r8168-ueficert is a remainer from your your Hardware repos (I haven’t removed it because I probably will need keys for testing again…).

About your r8168 builds: The discription lists a lot of RTL8111___ NICs, however not my RTL8111H rev. 15 (I double checked with the boards manual about the “H”). Also one can read the other revisions (like with single digits) should work.

I’d like to add some points maybe of interest:

  • I can see if WOL is turned on because otherwise lights of NIC stop blinking.
  • I am mostly interested in WOL while in suspend, however I could use a poweroff as well (I tested but results were erratic, either no turn on or immediate turn on).
  • I do see a difference between the signals for wakeup. E.g. physical ends suspend virtually instantanios. Also unicast, multicast and broadcast do not really last longer. With magic packet it gives me a pretty random time between 5 and 30 seconds until wakeup.
  • I tried all BIOS settings, most are overriden by OS anyway
  • dmesg does not show any exceptional but a regular suspend and a regular wakeup; The spurious native interrupt is from the bridge to the NIC, I guess.

After all, I suspect the kernel module

These are the sources of my build and also of the build from Packman:
https://www.realtek.com/Download/List?cate_id=584

So I think I can not say anything about problems with WOL because I only build and use them (without WOL), maybe deinstall all r8168 packages, use the r8169 package and open a bugreport:
https://bugzilla.opensuse.org/index.cgi

@Sauerland
Just for my understanding, can your recent package kernel-firmware-realtek-20250122-lp156.535.1.noarch.rpm help? I see it includes rtl-nic/rtl8168h-2.fw which is according to the r8169 kernel module source the required firmware. Is it updated or just the same old?

This is the date of the kernel-firmware package, if you use an older, maybe switch to the new one like me:

LANG=C zypper se -s kernel-firmware-realtek
Loading repository data...
Reading installed packages...

S  | Name                    | Type    | Version               | Arch   | Repository
---+-------------------------+---------+-----------------------+--------+-------------------------------------------------------------
i+ | kernel-firmware-realtek | package | 20250122-lp156.535.1  | noarch | Sauerland-OSS
v  | kernel-firmware-realtek | package | 20241128-150600.3.9.1 | noarch | Update repository with updates from SUSE Linux Enterprise 15
v  | kernel-firmware-realtek | package | 20240728-150600.3.6.1 | noarch | Update repository with updates from SUSE Linux Enterprise 15
v  | kernel-firmware-realtek | package | 20240712-150600.3.3.1 | noarch | Update repository with updates from SUSE Linux Enterprise 15
v  | kernel-firmware-realtek | package | 20240201-150600.1.2   | noarch | OSS

Unfortunately, the firmware is exactly the same…

I see it, from 2022…

So bugreport.

Asus PRIME N100I-D D4

Manageability: WOL by PME, PXE

https://www.asus.com/support/faq/1045950/

https://wiki.archlinux.org/title/Wake-on-LAN

https://wiki.archlinux.org/title/Wake-on-LAN#r8168

Thanks, I was aware of this page. Tried the r6168 and switched back to r6169 aöready. However, my situation is different than the description there: My system does suspend (S3) but immediately returns to normal aka wakeup. Also I can enable WOL because lights are blincking even in suspend and - if I am fast enough - I can wake the machine up from remote.

Maybe this bug:
https://bugzilla.kernel.org/show_bug.cgi?id=219717

Well, I haven’t found issues in connectivity so far. Only in regard to my “spurious” wakeups. I tried kernel 6.13 and earlier (Suse default). Since it seems to be a regression, shouldn’t I encounter different behaviour between kernels? Can you explain why you think it may be related?

However, I found some more details on the issue:

  1. Looking into current r8168 code, it uploads pretty different firmwares for 8111h card revisions. Actually they have four different versions for 8168h while kernel module r8169 only offers two and uses ‘the latest’ but years old version for my newer “rev. 15” card. According to r8168’s sources, version 2 differs a lot from version 3. The latter in my understanding is used for my card, would be nice if I could test version 4.
    You cannot see the dirfferent firmwares from outside because, by default, r8168 is compiled without external firmware files, the firmware is hex code in the sources then.
  2. To be clear: Although I have a feeling that r8168 may handle the card more accurately, WOL does not work! The symptoms are the same like with r8169.
  3. I tried “neighbouring” (for RTL cards with a similar or later release date) firmwares together with r8169. Just for testing. Most firmware files work the same, some not (ethernet does not come up). Even removing the firmware file completly makes no different (beside complaints in dmesg).

My conclusion: r8169 does not make use of firmware at all ;-). I may be wrong, but in my understanding WOL definetly needs its functions in firmwar while the system is sleeping. When going to sleep without a network cable plugged in, suspend works. Basically the NIC behaves like it wakes on all traffic - not only on magic packet. r8168 however is using an outdated firmware not the newest on my rev. 15 card.

Thanks for your concern btw.!