Adding tag into "Whiteboard" field - ReadyForDev
*Status is correct
*Platform is included
*Feature is included
*Priority and Severity correctly set
*Logs included

(In reply to David H. Gutteridge from comment #0)
> Created attachment 130919 [details]
> Log of dmesg with drm.debug enabled from boot to oops
> 
> I've been encountering a recurring kernel oops since I upgraded a (rather
> old) laptop to the 4.10 kernel series. These happen pretty consistently
> after the machine has been up for a few hours, and after a series of
> warnings are logged.
> I reproduced this with Fedora's 4.10.11-200.fc25.i686 kernel last evening.
> This is a regression against the 4.9 kernel.

> I've attached a dmesg log from boot to the oops, with drm.debug output
> enabled.

Sorry for the delay.  Is this still reproducible with a recent kernel?

The log has some high order allocation failure in GEM immediately preceding the WARN_ON and oops, so this is likely a mishandling of the allocation error path.  Since you observed this on a 4.10 distro kernel, can you please confirm it still occur with the tip of drm-intel-nightly mainline branch and provide the logs?

Thanks.

(In reply to krisman from comment #2)
> (In reply to David H. Gutteridge from comment #0)
> > Created attachment 130919 [details]
> > Log of dmesg with drm.debug enabled from boot to oops
> > 
> > I've been encountering a recurring kernel oops since I upgraded a (rather
> > old) laptop to the 4.10 kernel series. These happen pretty consistently
> > after the machine has been up for a few hours, and after a series of
> > warnings are logged.
> > I reproduced this with Fedora's 4.10.11-200.fc25.i686 kernel last evening.
> > This is a regression against the 4.9 kernel.
> 
> > I've attached a dmesg log from boot to the oops, with drm.debug output
> > enabled.
> 
> Sorry for the delay.  Is this still reproducible with a recent kernel?
> 
> The log has some high order allocation failure in GEM immediately preceding
> the WARN_ON and oops, so this is likely a mishandling of the allocation
> error path.  Since you observed this on a 4.10 distro kernel, can you please
> confirm it still occur with the tip of drm-intel-nightly mainline branch and
> provide the logs?

I haven't reproduced it with a 4.11 series kernel, but I haven't been using the machine as much of late, so I haven't really taxed it to the point it would reliably hit this. I've cloned drm-intel-nightly and will build a test kernel when I get a chance, probably next week.

I tried testing with the drm-intel-nightly branch cloned the evening of July 7th, but this has proven unusable for me for an unrelated reason: the mouse cursor ends up being stuck permanently rendered in its initial position. That is, the underlying mouse movement is registered (regardless of trackpad or mouse, X.org or Wayland) on the screen, with GUI components reacting as the mouse position changes, but the cursor itself never moves. (The config I'm using is basically what's used by Fedora, since I need various options enabled for the laptop in question to be usable. The default config in drm-intel-nightly wasn't adequate for that.)

I've also tried testing with a downstream Fedora build of the 4.12 kernel, which doesn't exhibit the frozen mouse cursor problem. I haven't been able to duplicate this original issue yet with that kernel, though I haven't had time to put in as much use as I'd like. (It typically happened under memory pressure after the machine was up at least a few hours.) (I compared output with drm.debug enabled between the drm-intel-nightly and Fedora kernels, and I don't see anything to indicate why the mouse pointer problem is happening.) I can continue testing with the Fedora kernel if that's still relevant here. (I also have a build of the vanilla 4.12 kernel I can try if need be. I'm not remotely familiar with the Intel kernel branches, but I also found the test kernel I built from drm-intel-nightly panics on boot when I use it in a VM, where the vanilla kernel does not. In that case, it relates to the qxl driver, which might not be of interest on an Intel branch.)

Anyway, in short, this hasn't been a simple exercise.

(In reply to David H. Gutteridge from comment #4)
> I tried testing with the drm-intel-nightly branch cloned the evening of July
> 7th, but this has proven unusable for me for an unrelated reason: the mouse
> cursor ends up being stuck permanently rendered in its initial position.
> That is, the underlying mouse movement is registered (regardless of trackpad
> or mouse, X.org or Wayland) on the screen, with GUI components reacting as
> the mouse position changes, but the cursor itself never moves. (The config
> I'm using is basically what's used by Fedora, since I need various options
> enabled for the laptop in question to be usable. The default config in
> drm-intel-nightly wasn't adequate for that.)
> 
> I've also tried testing with a downstream Fedora build of the 4.12 kernel,
> which doesn't exhibit the frozen mouse cursor problem. I haven't been able
> to duplicate this original issue yet with that kernel, though I haven't had
> time to put in as much use as I'd like. (It typically happened under memory
> pressure after the machine was up at least a few hours.) (I compared output
> with drm.debug enabled between the drm-intel-nightly and Fedora kernels, and
> I don't see anything to indicate why the mouse pointer problem is
> happening.) I can continue testing with the Fedora kernel if that's still
> relevant here. (I also have a build of the vanilla 4.12 kernel I can try if
> need be. I'm not remotely familiar with the Intel kernel branches, but I
> also found the test kernel I built from drm-intel-nightly panics on boot
> when I use it in a VM, where the vanilla kernel does not. In that case, it
> relates to the qxl driver, which might not be of interest on an Intel
> branch.)

ouch.. That is a bummer. :(  Sorry about that.

Regarding the mouse issue, it reminded me of a new Ville patch. Can you give it a try and see how it goes?

https://lists.freedesktop.org/archives/intel-gfx/2017-July/133158.html

Also, I'd ask you to open a new bug to track that issue.

Regarding the QXL crash, I'd like to take a look at that one too.  Can you please report it to dri-devel@freedesktop.org together with the Oops log?  Please, CC me too so I can follow up quickly.

(In reply to krisman from comment #5)
> Regarding the mouse issue, it reminded me of a new Ville patch. Can you give
> it a try and see how it goes?
> 
> https://lists.freedesktop.org/archives/intel-gfx/2017-July/133158.html
> 
> Also, I'd ask you to open a new bug to track that issue.

It looks like bug 101790 is already open, so I appended my own comments there. (In short, that patch fixed the issue for me.)

> Regarding the QXL crash, I'd like to take a look at that one too.  Can you
> please report it to dri-devel@freedesktop.org together with the Oops log? 
> Please, CC me too so I can follow up quickly.

I was mistaken when I said the vanilla 4.12 kernel doesn't exhibit that QXL issue. I can duplicate with it: in order for the issue to happen, a graphical boot option must be passed, it seems. Anyway, I'm working on getting you a better log than what I have right now.

*** This bug has been marked as a duplicate of bug 101790 ***

*** This bug has been marked as a duplicate of bug 101790 ***

(In reply to Elizabeth from comment #8)
> 
> *** This bug has been marked as a duplicate of bug 101790 ***

Notice that bug 101790 was only mentioned as a fix for a different issue that was raised during the upstream test David performed. The bug being tracked here is a different one (WARN_ON message followed by an Oops) that we still need to confirm if it occurs on the mainline kernel.

(In reply to krisman from comment #9)
> (In reply to Elizabeth from comment #8)
> > 
> > *** This bug has been marked as a duplicate of bug 101790 ***
> 
> Notice that bug 101790 was only mentioned as a fix for a different issue
> that was raised during the upstream test David performed. The bug being
> tracked here is a different one (WARN_ON message followed by an Oops) that
> we still need to confirm if it occurs on the mainline kernel.

Understood, sorry for the double comment, internet failed for some minutes. Thank you.

I haven't been able to reproduce this with 4.11 or 4.12 kernels, so I think we're safe to close this. I can refile if I hit it again.

(In reply to David H. Gutteridge from comment #11)
> I haven't been able to reproduce this with 4.11 or 4.12 kernels, so I think
> we're safe to close this. I can refile if I hit it again.

Thanks for the verification.  I'm closing it per the above comment.  If you can reproduce it, please reopen.

It happens to me on (Linux Mint 18.2):

$ cat /proc/version 
Linux version 4.13.2-041302-generic (kernel@tangerine) (gcc version 7.2.0 (Ubuntu 7.2.0-3ubuntu1)) #201709132057 SMP Thu Sep 14 00:59:32 UTC 2017

/var/log/syslog has:

Oct 29 16:28:11 figini kernel: [445122.160964] [drm] GPU HANG: ecode 9:1:0xeeffefa1, in Xorg [1040], reason: Hang on bcs0, action: reset
Oct 29 16:28:11 figini kernel: [445122.160970] [drm] GPU hangs can indicate a bug anywhere in the entire gfx stack, including userspace.
Oct 29 16:28:11 figini kernel: [445122.160972] [drm] Please file a _new_ bug report on bugs.freedesktop.org against DRI -> DRM/Intel
Oct 29 16:28:11 figini kernel: [445122.160974] [drm] drm/i915 developers can then reassign to the right component if it's not a kernel issue.
Oct 29 16:28:11 figini kernel: [445122.160975] [drm] The gpu crash dump is required to analyze gpu hangs, so please always attach it.
Oct 29 16:28:11 figini kernel: [445122.160978] [drm] GPU crash dump saved to /sys/class/drm/card0/error
Oct 29 16:28:11 figini kernel: [445122.161194] drm/i915: Resetting chip after gpu hang
Oct 29 16:28:11 figini kernel: [445122.164497] BUG: unable to handle kernel NULL pointer dereference at 0000000000000070
Oct 29 16:28:11 figini kernel: [445122.164614] IP: reset_common_ring+0x9a/0x100 [i915]
Oct 29 16:28:11 figini kernel: [445122.164641] PGD 0 
Oct 29 16:28:11 figini kernel: [445122.164642] P4D 0 
Oct 29 16:28:11 figini kernel: [445122.164654] 
Oct 29 16:28:11 figini kernel: [445122.164677] Oops: 0000 [#1] SMP
Oct 29 16:28:11 figini kernel: [445122.164696] Modules linked in: rfcomm ccm bnep binfmt_misc intel_rapl intel_telemetry_pltdrv intel_punit_ipc intel_telemetry_core intel_pmc_ipc x86_pkg_temp_thermal intel_powerclamp coretemp kvm irqbypass snd_soc_skl snd_soc_skl_ipc crct10dif_pclmul crc32_pclmul ghash_clmulni_intel pcbc aesni_intel snd_soc_sst_ipc snd_hda_codec_hdmi snd_hda_codec_generic snd_soc_sst_dsp aes_x86_64 uvcvideo snd_hda_ext_core videobuf2_vmalloc videobuf2_memops videobuf2_v4l2 snd_soc_sst_match videobuf2_core videodev snd_soc_core media snd_compress ac97_bus snd_pcm_dmaengine crypto_simd btusb glue_helper cryptd snd_hda_intel btrtl snd_hda_codec btbcm snd_hda_core intel_cstate btintel bluetooth snd_hwdep intel_rapl_perf ecdh_generic snd_pcm joydev snd_seq_midi snd_seq_midi_event intel_spi_platform intel_spi spi_nor mtd
Oct 29 16:28:11 figini kernel: [445122.165170]  snd_rawmidi arc4 idma64 iwlmvm mac80211 snd_seq snd_seq_device snd_timer snd iwlwifi virt_dma soundcore intel_lpss_pci cfg80211 wmi_bmof intel_lpss lpc_ich input_leds serio_raw ideapad_laptop mac_hid elan_i2c mei_me tpm_crb mei shpchp sparse_keymap parport_pc ppdev lp parport autofs4 btrfs xor raid6_pq dm_mirror dm_region_hash dm_log hid_generic usbhid i915 i2c_algo_bit drm_kms_helper syscopyarea sysfillrect sysimgblt fb_sys_fops drm r8169 ahci mii libahci i2c_hid wmi hid video pinctrl_broxton pinctrl_intel
Oct 29 16:28:11 figini kernel: [445122.165465] CPU: 3 PID: 5344 Comm: kworker/3:0 Not tainted 4.13.2-041302-generic #201709132057
Oct 29 16:28:11 figini kernel: [445122.165510] Hardware name: LENOVO 80XR/LNVNB161216, BIOS 5RCN20WW 05/22/2017
Oct 29 16:28:11 figini kernel: [445122.165582] Workqueue: events_long i915_hangcheck_elapsed [i915]
Oct 29 16:28:11 figini kernel: [445122.165617] task: ffffa0956d0b8000 task.stack: ffffc1a981468000
Oct 29 16:28:11 figini kernel: [445122.165683] RIP: 0010:reset_common_ring+0x9a/0x100 [i915]
Oct 29 16:28:11 figini kernel: [445122.165712] RSP: 0000:ffffc1a98146bb58 EFLAGS: 00010246
Oct 29 16:28:11 figini kernel: [445122.165741] RAX: 0000000000003f00 RBX: ffffa094b0ede1c0 RCX: 0000000000004000
Oct 29 16:28:11 figini kernel: [445122.165778] RDX: 0000000000003fff RSI: ffffa095aebcf400 RDI: 0000000000000000
Oct 29 16:28:11 figini kernel: [445122.165819] RBP: ffffc1a98146bb70 R08: ffffa095aebcf400 R09: ffffa095b16c0000
Oct 29 16:28:11 figini kernel: [445122.165857] R10: ffffc1a98146ba90 R11: 000000000000023c R12: ffffa095ba566000
Oct 29 16:28:11 figini kernel: [445122.165894] R13: ffffa095aebcf428 R14: ffffa095ba566000 R15: ffffa094b0ede1c0
Oct 29 16:28:11 figini kernel: [445122.165932] FS:  0000000000000000(0000) GS:ffffa095bfd80000(0000) knlGS:0000000000000000
Oct 29 16:28:11 figini kernel: [445122.165974] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
Oct 29 16:28:11 figini kernel: [445122.166005] CR2: 0000000000000070 CR3: 0000000176a49000 CR4: 00000000003406e0
Oct 29 16:28:11 figini kernel: [445122.166048] Call Trace:
Oct 29 16:28:11 figini kernel: [445122.166098]  i915_gem_reset+0xba/0x3a0 [i915]
Oct 29 16:28:11 figini kernel: [445122.166156]  ? intel_uncore_forcewake_put.part.8+0x3e/0x50 [i915]
Oct 29 16:28:11 figini kernel: [445122.166222]  ? gen6_reset_engines+0xd0/0xd0 [i915]
Oct 29 16:28:11 figini kernel: [445122.166252]  ? bit_wait_io+0x60/0x60
Oct 29 16:28:11 figini kernel: [445122.166301]  i915_reset+0xdf/0x170 [i915]
Oct 29 16:28:11 figini kernel: [445122.166352]  i915_reset_and_wakeup+0x17b/0x1b0 [i915]
Oct 29 16:28:11 figini kernel: [445122.166441]  i915_handle_error+0x206/0x210 [i915]
Oct 29 16:28:11 figini kernel: [445122.166470]  ? scnprintf+0x49/0x80
Oct 29 16:28:11 figini kernel: [445122.166526]  hangcheck_declare_hang+0xe2/0x110 [i915]
Oct 29 16:28:11 figini kernel: [445122.166590]  ? fwtable_read32+0x8d/0x1d0 [i915]
Oct 29 16:28:11 figini kernel: [445122.166651]  i915_hangcheck_elapsed+0x262/0x2d0 [i915]
Oct 29 16:28:11 figini kernel: [445122.166683]  process_one_work+0x1e7/0x410
Oct 29 16:28:11 figini kernel: [445122.166708]  worker_thread+0x4a/0x410
Oct 29 16:28:11 figini kernel: [445122.166730]  kthread+0x125/0x140
Oct 29 16:28:11 figini kernel: [445122.166750]  ? process_one_work+0x410/0x410
Oct 29 16:28:11 figini kernel: [445122.166775]  ? kthread_create_on_node+0x70/0x70
Oct 29 16:28:11 figini kernel: [445122.166802]  ret_from_fork+0x25/0x30
Oct 29 16:28:11 figini kernel: [445122.166824] Code: 89 50 14 48 8b 83 80 00 00 00 8b 93 c0 01 00 00 89 50 20 48 8b bb 80 00 00 00 e8 e2 27 00 00 49 8b bc 24 a0 02 00 00 48 83 e7 fc <48> 8b 47 70 48 39 43 70 74 26 48 85 ff 74 05 f0 ff 0f 74 41 49 
Oct 29 16:28:11 figini kernel: [445122.166992] RIP: reset_common_ring+0x9a/0x100 [i915] RSP: ffffc1a98146bb58
Oct 29 16:28:11 figini kernel: [445122.167030] CR2: 0000000000000070
Oct 29 16:28:11 figini kernel: [445122.182162] ---[ end trace 8a0b95373355dd67 ]---
Oct 29 16:28:14 figini kernel: [445125.188143] asynchronous wait on fence i915:Xorg[1040]/0:25153 timed out
Oct 29 16:28:14 figini kernel: [445125.188193] asynchronous wait on fence i915:Xorg[1040]/0:25153 timed out
Oct 29 16:28:14 figini kernel: [445125.244213] pipe A vblank wait timed out
Oct 29 16:28:14 figini kernel: [445125.244224] pipe B vblank wait timed out
Oct 29 16:28:14 figini kernel: [445125.244350] ------------[ cut here ]------------

Could you try latest stable: https://www.kernel.org??