Bug 198855 - Ethernet fails to reconnect on resume from suspend w/error do_IRQ: 5.37 No irq handler for vector
Summary: Ethernet fails to reconnect on resume from suspend w/error do_IRQ: 5.37 No ir...
Status: CLOSED PATCH_ALREADY_AVAILABLE
Alias: None
Product: ACPI
Classification: Unclassified
Component: Config-Interrupts (show other bugs)
Hardware: x86-64 Linux
: P1 normal
Assignee: Chen Yu
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2018-02-21 01:16 UTC by steelstring94
Modified: 2018-10-17 03:21 UTC (History)
5 users (show)

See Also:
Kernel Version: 4.15.12-301.fc27.x86_64
Tree: Mainline
Regression: No


Attachments
Contains dmesg output for bugged suspend/resume and for normal (14.02 KB, text/x-csrc)
2018-02-21 01:16 UTC, steelstring94
Details
DMESG+ACPIDUMP_full (4.16.7) (85.61 KB, application/x-7z-compressed)
2018-05-09 16:05 UTC, samoht0
Details
dmesg 4.14.14 OK (229.01 KB, text/plain)
2018-05-15 18:26 UTC, Jean-Baptiste Poittevin
Details
dmesg 4.16.7 FAILED (230.13 KB, text/plain)
2018-05-15 18:27 UTC, Jean-Baptiste Poittevin
Details

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
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.
Comment 12 steelstring94 2018-05-15 10:19:43 UTC
(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.
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.

Note You need to log in before you can comment on or make changes to this bug.