[Intel-gfx] [i915] assert_device_not_suspended

Samuel Thibault samuel.thibault at ens-lyon.org
Tue Apr 14 01:00:10 PDT 2015


Hello,

Yesterday, as usual I ran xlock before the night. In the morning, I
typed a key to wake it up, it didn't. I had to reboot. I could however
read in the logs:

Apr 14 05:00:13 type kernel: [33976.116204] WARNING: CPU: 2 PID: 63 at drivers/gpu/drm/i915/intel_uncore.c:69 assert_device_not_suspended+0x45/0x4e [i915]()
Apr 14 05:00:13 type kernel: [33976.116206] Device suspended
Apr 14 05:00:13 type kernel: [33976.116206] Modules linked in: tun xt_REDIRECT nf_nat_redirect xt_tcpudp ipt_MASQUERADE nf_nat_masquerade_ipv4 iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 nf_nat nf_conntrack ip_tables x_tables binfmt_misc nfsd cpufreq_powersave auth_rpcgss cpufreq_stats oid_registry nfs_acl cpufreq_userspace lockd cpufreq_conservative bbswitch(O) grace sunrpc joydev hid_generic usbhid hid cdc_mbim cdc_ncm usbnet mii cdc_acm cdc_wdm arc4 brcmsmac cordic brcmutil b43 nls_utf8 nls_cp437 mac80211 vfat fat cfg80211 x86_pkg_temp_thermal i915 kvm_intel kvm snd_hda_codec_hdmi ssb rng_core pcmcia pcmcia_core crct10dif_pclmul crc32_pclmul ghash_clmulni_intel aesni_intel aes_x86_64 dell_wmi lrw sparse_keymap gf128mul drm_kms_helper dell_laptop glue_helper rfkill ablk_helper cryptd drm psmouse dcdbas evdev serio_raw bcma i2c_i801 acpi_cpufreq tpm_tis wmi i2c_algo_bit tpm i2c_core 8250_fintek video ac battery processor button snd_hda_codec_idt snd_hda_codec_generic ledtrig_timer ledtrig_oneshot ledtrig_heartbeat ledtrig_default_on snd_hda_intel snd_hda_controller snd_hda_codec snd_hwdep snd_pcm_oss snd_mixer_oss snd_pcm snd_timer snd soundcore coretemp ohci_hcd ledtrig_backlight pcspkr i8k firewire_sbp2 firewire_core crc_itu_t loop fuse parport_pc ppdev lp parport autofs4 microcode crc32c_intel ehci_pci ehci_hcd sdhci_pci sr_mod sdhci cdrom sg mmc_core usbcore e1000e ptp usb_common pps_core thermal thermal_sys
Apr 14 05:00:13 type kernel: [33976.116266] CPU: 2 PID: 63 Comm: kswapd0 Tainted: G           O    4.0.0 #87
Apr 14 05:00:13 type kernel: [33976.116267] Hardware name: Dell Inc. Latitude E6420/      , BIOS A14 07/11/2012
Apr 14 05:00:13 type kernel: [33976.116268]  0000000000000000 0000000000000009 ffffffff8144544b ffff8800b1313a88
Apr 14 05:00:13 type kernel: [33976.116270]  ffffffff8104a9bc 0000000000000002 ffffffffa0848b37 ffffea00026dffa0
Apr 14 05:00:13 type kernel: [33976.116272]  ffff8801388b0000 0000000000100028 ffff8801388b0068 000000000010002c
Apr 14 05:00:13 type kernel: [33976.116274] Call Trace:
Apr 14 05:00:13 type kernel: [33976.116280]  [<ffffffff8144544b>] ? dump_stack+0x40/0x50
Apr 14 05:00:13 type kernel: [33976.116284]  [<ffffffff8104a9bc>] ? warn_slowpath_common+0x98/0xb0
Apr 14 05:00:13 type kernel: [33976.116295]  [<ffffffffa0848b37>] ? assert_device_not_suspended+0x45/0x4e [i915]
Apr 14 05:00:13 type kernel: [33976.116297]  [<ffffffff8104aa19>] ? warn_slowpath_fmt+0x45/0x4a
Apr 14 05:00:13 type kernel: [33976.116308]  [<ffffffffa0848b37>] ? assert_device_not_suspended+0x45/0x4e [i915]
Apr 14 05:00:13 type kernel: [33976.116317]  [<ffffffffa0849186>] ? gen6_write32+0x32/0x83 [i915]
Apr 14 05:00:13 type kernel: [33976.116328]  [<ffffffffa0830772>] ? i915_gem_write_fence+0x270/0x46d [i915]
Apr 14 05:00:13 type kernel: [33976.116337]  [<ffffffffa08309af>] ? i915_gem_object_update_fence+0x40/0xa6 [i915]
Apr 14 05:00:13 type kernel: [33976.116346]  [<ffffffffa0830ab7>] ? i915_gem_object_put_fence+0xa2/0xac [i915]
Apr 14 05:00:13 type kernel: [33976.116355]  [<ffffffffa0830b65>] ? i915_vma_unbind+0xa4/0x1a6 [i915]
Apr 14 05:00:13 type kernel: [33976.116364]  [<ffffffffa0830e7e>] ? i915_gem_shrink+0x11e/0x178 [i915]
Apr 14 05:00:13 type kernel: [33976.116373]  [<ffffffffa0831597>] ? i915_gem_shrinker_scan+0x60/0x82 [i915]
Apr 14 05:00:13 type kernel: [33976.116376]  [<ffffffff810ef6ad>] ? shrink_slab.part.53.constprop.71+0x1a6/0x2ac
Apr 14 05:00:13 type kernel: [33976.116379]  [<ffffffff810f1a38>] ? shrink_zone+0x6b/0x131
Apr 14 05:00:13 type kernel: [33976.116381]  [<ffffffff810f26ca>] ? kswapd+0x57a/0x740
Apr 14 05:00:13 type kernel: [33976.116383]  [<ffffffff810f2150>] ? zone_reclaim+0x1cb/0x1cb
Apr 14 05:00:13 type kernel: [33976.116386]  [<ffffffff81060503>] ? kthread+0xab/0xb3
Apr 14 05:00:13 type kernel: [33976.116388]  [<ffffffff81060458>] ? __kthread_parkme+0x5d/0x5d
Apr 14 05:00:13 type kernel: [33976.116389]  [<ffffffff81448d58>] ? ret_from_fork+0x58/0x90
Apr 14 05:00:13 type kernel: [33976.116391]  [<ffffffff81060458>] ? __kthread_parkme+0x5d/0x5d
Apr 14 05:00:13 type kernel: [33976.116392] ---[ end trace de34697426b2c759 ]---

So it seems it's the reclaiming that triggered an i915 operation while
the graphic card was suspended.

It's probably worth mentioning that I use on my i915 card:

echo auto > /sys/bus/pci/devices/0000:00:02.0/power/control

In the following days, I'll be trying the attached patch.

Samuel
-------------- next part --------------
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -5258,6 +5258,11 @@ i915_gem_shrinker_scan(struct shrinker *
 	if (!i915_gem_shrinker_lock(dev, &unlock))
 		return SHRINK_STOP;
 
+	if (HAS_RUNTIME_PM(dev_priv->dev) && dev_priv->pm.suspended)
+	{
+		freed = SHRINK_STOP;
+		goto out;
+	}
 	freed = i915_gem_shrink(dev_priv,
 				sc->nr_to_scan,
 				I915_SHRINK_BOUND |
@@ -5268,6 +5273,8 @@ i915_gem_shrinker_scan(struct shrinker *
 					 sc->nr_to_scan - freed,
 					 I915_SHRINK_BOUND |
 					 I915_SHRINK_UNBOUND);
+
+out:
 	if (unlock)
 		mutex_unlock(&dev->struct_mutex);
 


More information about the Intel-gfx mailing list