Bug 198855

Summary:	Ethernet fails to reconnect on resume from suspend w/error do_IRQ: 5.37 No irq handler for vector
Product:	ACPI	Reporter:	steelstring94
Component:	Config-Interrupts	Assignee:	Chen Yu (yu.c.chen)
Status:	CLOSED PATCH_ALREADY_AVAILABLE
Severity:	normal	CC:	jb.poittevin, lenb, mathieu+kernel, rui.zhang, samoht0-bugzilla
Priority:	P1
Hardware:	x86-64
OS:	Linux
Kernel Version:	4.15.12-301.fc27.x86_64	Subsystem:
Regression:	No	Bisected commit-id:
Attachments:	Contains dmesg output for bugged suspend/resume and for normal DMESG+ACPIDUMP_full (4.16.7) 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

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.