Created attachment 274293 [details] Contains dmesg output for bugged suspend/resume and for normal Description of problem: On kernel 4.15.3, when you suspend the computer, after resuming, the ethernet will fail to reconnect. This is confirmed kernel issue as booting with 4.14.18 solves the problem. I am using Fedora KDE. Version-Release number of selected component (if applicable): kernel-4.15.3-300.fc27.x86_64 How reproducible: Very, unsure if DE affects Steps to Reproduce: 1. Boot with kernel 4.15.3 (Fedora KDE, unsure if desktop env. has effect) 2. Suspend the machine 3. Resume the machine Actual results: Ethernet fails to reconnect, notification appears of following error message: do_IRQ: 5.37 No irq handler for vector Expected results: Ethernet connection resumes upon logging back in Additional Information: Original bug report made to Red Hat; reporting here as instructed by them. Link: https://bugzilla.redhat.com/show_bug.cgi?id=1547277
This is fixed in 4.15.4. Closing.
Re-opening this as it's now happening again since 4.15.6, but now, when I switch back to 4.15.4, it still happens.
Setting kernel boot option noapic fixes this.
Update, now I am able to boot without noapic and the problem still does not happen. I have no idea what changed.
Update, it started happening again, but now, noapic does not fix the problem.
Update, setting kernel option acpi=noirq causes the error to change from do_IRQ 5.37 to do_IRQ 5.35.
what system is this? please supply the complete dmesg for normal operation (back to time 0) and the output of acpidump
Created attachment 275879 [details] DMESG+ACPIDUMP_full (4.16.7)
I'm also affected. I've atteched full desmeg (4.16.7-100.fc26.x86_64) for boot with working network > running some time > hibernation > resume (r8169 fail) +++ acpidump.
Same behaviour here. > $ sudo pm-suspend > > Message from syslogd@aria at May 13 08:49:01 ... > kernel:do_IRQ: 3.38 No irq handler for vector Device is Realtek 8111E (reported as "RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller" by lshw) Driver is r8169. Firmware is rtl8168e-3_0.0.4. Always reproducible with kernel 4.16.7-200.fc27.x86_64. All is working fine with kernel 4.14.14-300.fc27.x86_64.
steelstring94@gmail.com please confirm if this is an regression or not. for the others, the problems may or may not be the same issue with the original reporter. please 1. boot the kernel with boot opinion initcall_debug 2. run "echo 0 > /sys/power/_pm_async" 3. attach the dmesg output after resume Plus, please do the test and attach the result for both good and bad cases.
(In reply to Zhang Rui from comment #11) > steelstring94@gmail.com > please confirm if this is an regression or not. > for the others, the problems may or may not be the same issue with the > original reporter. > please > 1. boot the kernel with boot opinion initcall_debug > 2. run "echo 0 > /sys/power/_pm_async" > 3. attach the dmesg output after resume > Plus, please do the test and attach the result for both good and bad cases. Sorry, I already switched off to Arch to escape this issue. Hopefully someone else can run this.
Created attachment 275995 [details] dmesg 4.14.14 OK
Created attachment 275997 [details] dmesg 4.16.7 FAILED
Apparently fixed for me with 4.17.3-100.fc27.x86_64.
> Apparently fixed for me with 4.17.3-100.fc27.x86_64 closed.