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”.
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):
~ # 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.
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?
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.
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:
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.
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.
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.