Bug 112351 - jme driver breaks suspend/resume
Summary: jme driver breaks suspend/resume
Status: RESOLVED CODE_FIX
Alias: None
Product: Drivers
Classification: Unclassified
Component: Network (show other bugs)
Hardware: x86-64 Linux
: P1 normal
Assignee: drivers_network@kernel-bugs.osdl.org
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2016-02-12 07:44 UTC by Diego Viola
Modified: 2016-02-25 16:10 UTC (History)
0 users

See Also:
Kernel Version: 4.4.1-2-ARCH
Subsystem:
Regression: No
Bisected commit-id:


Attachments
lspci (1.40 KB, text/plain)
2016-02-13 00:23 UTC, Diego Viola
Details
dmidecode (6.80 KB, text/plain)
2016-02-13 00:24 UTC, Diego Viola
Details

Description Diego Viola 2016-02-12 07:44:19 UTC
I have this network card:

02:00.0 Ethernet controller: JMicron Technology Corp. JMC260 PCI Express Fast Ethernet Controller (rev 03)

Every time I initiate a suspend 'systemctl suspend' the machine hangs at resume unless I unload the jme driver.

I can also suspend the computer when the driver is loaded but when the link is down: 'ip link set ens34 down'

However, as soon as the link is up, the hang occurs again.

Here is a call trace I was able to get after it hanged:


<IRQ>
tasklet_action+0xb0/0xd0
__do_softirq+0xcf/0x290
irq_exit+0xa3/0xb0
do_IRQ+0x54/0xd0
common_interrupt+0x82/0x82

<EOI>
jme_start_irq+0x84/0xa0 [jme]
jme_resume+0x12f/0x210 [jme]
pci_pm_resume+0x64/0xa0
? pci_pm_thaw+0x90/0x90
dpm_run_callback+0x4e/0x130
device_resume+0xd3/0x1f0
async_resume+0x1d/0x50
async_run_entry_fn+0x48/0x150
process_one_work+0x14b/0x440
worker_thread+0x48/0x4a0
? process_one_work+0x440/0x440
kthread+0xd8/0xf0
? kthread_worker_fn+0x170/0x170
ret_from_fork+0x3f/0x70
? kthread_worker_fn+0x170/0x170

I run Arch Linux (x86-64), I also tried compiling the latest kernel from git but the problem is still there, I also went back to Linux 3.11 so I could try to git bisect the issue, but the problem was there in the 3.11 kernel as well.

Please let me know if you need any other information.
Comment 1 Diego Viola 2016-02-12 07:53:34 UTC
This is on a desktop computer BTW, not a laptop.
Comment 2 Diego Viola 2016-02-13 00:23:18 UTC
Created attachment 203571 [details]
lspci
Comment 3 Diego Viola 2016-02-13 00:24:11 UTC
Created attachment 203581 [details]
dmidecode
Comment 4 Diego Viola 2016-02-13 01:54:41 UTC
I think this is probably a race condition, because I managed to resume from suspend a few times while testing this, and when the device was up, but this happened very random and it was rare.

Most of the time (99% of the time) it just hangs after resume from suspend.
Comment 5 Diego Viola 2016-02-13 01:57:40 UTC
I mean, the hang only occurs when the device is up, if the device is down (ip link set ens34 down) the hang doesn't occur.
Comment 6 Diego Viola 2016-02-13 18:42:11 UTC
Tried all these parameters from the module, no effect:

parm:           force_pseudohp:Enable pseudo hot-plug feature manually by driver instead of BIOS. (int)
parm:           no_pseudohp:Disable pseudo hot-plug feature. (int)
parm:           no_extplug:Do not use external plug signal for pseudo hot-plug. (int)
Comment 7 Diego Viola 2016-02-13 20:39:27 UTC
So I found that disabling async helps with my issue, e.g.

$ echo 0 > /sys/power/pm_async

I can't reproduce the hang anymore, tried suspend/resume almost ~15 times.
Comment 8 Diego Viola 2016-02-20 17:57:31 UTC
Anyone please?
Comment 9 Diego Viola 2016-02-23 00:40:29 UTC
Fixed here:

https://lkml.org/lkml/2016/2/22/994

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