|Summary:||Ethernet fails to reconnect on resume from suspend w/error do_IRQ: 5.37 No irq handler for vector|
|Component:||Config-Interrupts||Assignee:||Chen Yu (yu.c.chen)|
|Severity:||normal||CC:||jb.poittevin, lenb, mathieu+kernel, rui.zhang, samoht0-bugzilla|
Contains dmesg output for bugged suspend/resume and for normal
dmesg 4.14.14 OK
dmesg 4.16.7 FAILED
Description steelstring94 2018-02-21 01:16:18 UTC
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
Comment 1 steelstring94 2018-02-28 13:48:12 UTC
This is fixed in 4.15.4. Closing.
Comment 2 steelstring94 2018-03-05 16:08:39 UTC
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.
Comment 3 steelstring94 2018-03-06 15:14:01 UTC
Setting kernel boot option noapic fixes this.
Comment 4 steelstring94 2018-03-08 23:03:25 UTC
Update, now I am able to boot without noapic and the problem still does not happen. I have no idea what changed.
Comment 5 steelstring94 2018-03-29 20:55:45 UTC
Update, it started happening again, but now, noapic does not fix the problem.
Comment 6 steelstring94 2018-03-30 14:13:17 UTC
Update, setting kernel option acpi=noirq causes the error to change from do_IRQ 5.37 to do_IRQ 5.35.
Comment 7 Len Brown 2018-05-02 17:33:12 UTC
what system is this? please supply the complete dmesg for normal operation (back to time 0) and the output of acpidump
Comment 8 samoht0 2018-05-09 16:05:30 UTC
Created attachment 275879 [details] DMESG+ACPIDUMP_full (4.16.7)
Comment 9 samoht0 2018-05-09 16:05:50 UTC
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.
Comment 10 Jean-Baptiste Poittevin 2018-05-13 08:13:36 UTC
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.
Comment 11 Zhang Rui 2018-05-15 07:16:04 UTC
firstname.lastname@example.org 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.
Comment 12 steelstring94 2018-05-15 10:19:43 UTC
(In reply to Zhang Rui from comment #11) > email@example.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.
Comment 13 Jean-Baptiste Poittevin 2018-05-15 18:26:34 UTC
Created attachment 275995 [details] dmesg 4.14.14 OK
Comment 14 Jean-Baptiste Poittevin 2018-05-15 18:27:17 UTC
Created attachment 275997 [details] dmesg 4.16.7 FAILED
Comment 15 Jean-Baptiste Poittevin 2018-07-01 13:06:34 UTC
Apparently fixed for me with 4.17.3-100.fc27.x86_64.
Comment 16 Len Brown 2018-10-17 03:21:27 UTC
> Apparently fixed for me with 4.17.3-100.fc27.x86_64 closed.