Re: [Intel-gfx] "BUG: unable to handle kernel NULL pointer dereference at 0000000000000070" in [i915] reset_common_ring

Bjørn Mork <bj...@mork.no> writes: > Chris Wilson <ch...@chris-wilson.co.uk> writes: > >> and at a guess >> intel_iommu=igfx_off to avoid the hangs in the first place. > > Thanks for the tip. I'll try that My memory is more than a bit flakey, but this did event

Re: [Intel-gfx] "BUG: unable to handle kernel NULL pointer dereference at 0000000000000070" in [i915] reset_common_ring

Chris Wilson <ch...@chris-wilson.co.uk> writes: > Quoting Bjørn Mork (2017-10-19 11:24:57) >> Hello, >> >> I get these Oopses from time to time, but unfortunately(?) not often >> enough to be anywhere near reproducible. But they seem to be related to >>

Re: [Intel-gfx] "BUG: unable to handle kernel NULL pointer dereference at 0000000000000070" in [i915] reset_common_ring

Here's another one I had lying around in pstore. Note that this one has slighty older kernel and BIOS version, possibly eliminating a couple of variables. <6>[18285.732012] [drm] GPU HANG: ecode 9:0:0xfffe, in Xorg [842], reason: Hang on render ring, action: reset <6>[18285.732024] [drm]

[Intel-gfx] "BUG: unable to handle kernel NULL pointer dereference at 0000000000000070" in [i915] reset_common_ring

Hello, I get these Oopses from time to time, but unfortunately(?) not often enough to be anywhere near reproducible. But they seem to be related to whatever activites my laptop/X-server/driver/gpu/screen is doing while I'm not present. The oops happens when I'm away for a while. So I guess it

[Intel-gfx] regression since v4.9-rcX: "Resetting chip after gpu hang" times out(?) and is repeated every 20th second

Hello, I've been having occasional GPU HANGs on my Skylake laptop ever since I got it, originally reported here: https://bugs.freedesktop.org/show_bug.cgi?id=96894 But this is not the reason I try this list. The HANGs used to be resolved nicely by the driver up to and including v4.8. The GPU

Re: [Intel-gfx] [4.6-rcX regression] closing and opening LID on thinkpad x200s freezes X

Jiri Kosina writes: > Hi, > > after updating to 4.6-rcX (where X is 1 or 2, doesn't really matter) on > thinkpad x200s notebook with > > 00:02.0 VGA compatible controller: Intel Corporation Mobile 4 Series > Chipset Integrated Graphics Controller (rev 07) > > closing

[Intel-gfx] [PATCH] drm/i915: fix deadlock on lid open

[] ? rescuer_thread+0x309/0x309 [] ? rescuer_thread+0x309/0x309 [] kthread+0xe0/0xe8 [] ? local_clock+0x19/0x22 [] ret_from_fork+0x22/0x40 [] ? kthread_create_on_node+0x1b5/0x1b5 Fixes: e2c8b8701e2d ("drm/i915: Use atomic helpers for suspend, v2.") Cc: Maarten Lankhorst <maarten.lankho..

Re: [Intel-gfx] [PATCH] drm/i915: refine qemu south bridge detection

matches on real hardware. Having the check for >> virtual systems last in the list is not enough to avoid >> that ... >> >> Refine the check by additionally verifying the pci >> subsystem id to see whenever it *really* is qemu. >> >> Reported-by: Bjørn Mork <bj...@

Re: [Intel-gfx] [PATCH] Revert "drm/i915: more virtual south bridge detection"

because it mistakes real physical south bridges for virtual ones. > > Reported-by: Bjørn Mork <bj...@mork.no> > Reference: http://mid.gmane.org/87y4bes74m@nemi.mork.no > Cc: Gerd Hoffmann <kra...@redhat.com> > Fixes: 39bfcd5235e0 ("drm/i915: more virtual south

[Intel-gfx] Regression in v4.5-rc1, bisected to commit 39bfcd5235e0 ("drm/i915: more virtual south bridge detection")

Hello, my oldish Thinkpad X301 only wanted to show a blank screen in v4.5-rc1. Bisecting resulted in: HEAD is now at 39bfcd5235e0 drm/i915: more virtual south bridge detection 39bfcd5235e07e95ad3e70eab8e0b85db181de9e is the first bad commit commit 39bfcd5235e07e95ad3e70eab8e0b85db181de9e Author:

Re: [Intel-gfx] Still time for v4.2? - c0165304e10f ("drm/i915: Only enable cursor if it can be enabled.")

Just for the record: I still get these quite often on resuming from suspend-to-ram. But I can't reliably provoke them for some reason, so the exact trigger mechanism is unknown. Related to timing issues caused by other devices, maybe? Or some odd Lenovo firmware thingy? Does of course not

Re: [Intel-gfx] Still time for v4.2? - c0165304e10f ("drm/i915: Only enable cursor if it can be enabled.")

Maarten Lankhorst <maarten.lankho...@linux.intel.com> writes: > Op 08-09-15 om 09:31 schreef Bjørn Mork: >> Just for the record: I still get these quite often on resuming from >> suspend-to-ram. But I can't reliably provoke them for some reason, so >> the exact t

[Intel-gfx] Still time for v4.2? - c0165304e10f (drm/i915: Only enable cursor if it can be enabled.)

Hello, I see that I consistently get the warning below on v4.2-rc8. I believe you already fixed this a long time ago by commit c0165304e10f (drm/i915: Only enable cursor if it can be enabled.), which I assume is a stable candidate for v4.2.y. But wouldn't it look better if you managed to squeeze

Re: [Intel-gfx] Still time for v4.2? - c0165304e10f (drm/i915: Only enable cursor if it can be enabled.)

Maarten Lankhorst maarten.lankho...@linux.intel.com writes: Hey, Op 25-08-15 om 09:45 schreef Bjørn Mork: Hello, I see that I consistently get the warning below on v4.2-rc8. I believe you already fixed this a long time ago by commit c0165304e10f (drm/i915: Only enable cursor if it can

Re: [Intel-gfx] [PATCH v2] drm/i915: gen4: work around hang during hibernation

. - add code comment about failing platforms (Ville) Reference: http://lists.freedesktop.org/archives/intel-gfx/2015-February/060633.html Reported-and-bisected-by: Bjørn Mork bj...@mork.no Signed-off-by: Imre Deak imre.d...@intel.com Bjørn, I would really appreciate your Tested

Re: [Intel-gfx] [PATCH] drm/i915: fix failure to power off after hibernate

Ville Syrjälä ville.syrj...@linux.intel.com writes: @@ -651,7 +651,14 @@ static int i915_drm_suspend_late(struct drm_device *drm_dev) } pci_disable_device(drm_dev-pdev); -pci_set_power_state(drm_dev-pdev, PCI_D3hot); +/* + * During hibernation on some GM45

Re: [Intel-gfx] [PATCH] drm/i915: fix failure to power off after hibernate

Imre Deak imre.d...@intel.com writes: Attached is the proposed fix for this issue. --Imre From 5c23657bc168db12a1ba100ab65fabd305c89c8a Mon Sep 17 00:00:00 2001 From: Imre Deak imre.d...@intel.com Date: Thu, 26 Feb 2015 18:38:53 +0200 Subject: [PATCH] drm/i915: gm45: work around hang

Re: [Intel-gfx] [PATCH] drm/i915: fix failure to power off after hibernate

Imre Deak imre.d...@intel.com writes: That patch fixes the problem, with only pci_set_power_state commented out. Do you still want me to try with pci_disable_device() commented out as well? No, but it would help if you could still try the two attached patch separately, without any of the

Re: [Intel-gfx] [PATCH] drm/i915: fix failure to power off after hibernate

Imre Deak imre.d...@intel.com writes: The poweroff handlers undo the actions of the thaw handlers. As the original commit stated saving the registers is not needed there, but it's also not a big overhead and there should be no problem doing it. We are planning to optimize the hibernation

[Intel-gfx] [BISECTED REGRESSION v3.18-v3.19-rc1] drm/i915: failure to poweroff after hibernation

Hello, My Lenovo Thinkpad X301 has failed to power off after saving the hibernation image ever since v3.19-rc1. This is a regression since v3.18. The regression is still present i v4.0-rc1. The symptoms are: Hibernation proceeds as usual, writing a complete image. But instead of powering off