Bjørn Mork writes:
> Chris Wilson 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 eventually ring a
bell.,. And googling I see that
Chris Wilson 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
>> whatever activites my laptop/X-
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] GP
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 mi
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 wa
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 and opening the lid f
process_one_work+0x265/0x50b
[] worker_thread+0x1fc/0x2dd
[] ? 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
rtual ones.
>
> Reported-by: Bjørn Mork
> Reference: http://mid.gmane.org/87y4bes74m@nemi.mork.no
> Cc: Gerd Hoffmann
> Fixes: 39bfcd5235e0 ("drm/i915: more virtual south bridge detection")
> Signed-off-by: Jani Nikula
>
> ---
>
> Bjørn, please provide
ems 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
>> Signed-off-by: Gerd Hoffmann
>
> Already sent the reve
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:
Maarten Lankhorst 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 trigger mechanism is unknown. Related to
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 matte
Maarten Lankhorst 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
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 squeez
bile and desktop, GEN4 and non-GEN4) seem
>> to work fine. Based on this apply the workaround on all GEN4 Lenovo
>> platforms.
>> - add code comment about failing platforms (Ville)
>>
>> Reference:
>> http://lists.freedesktop.org/archives/intel-gfx/2015-Febru
Ville Syrjälä 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 platforms the BIOS
Imre Deak writes:
> Attached is the proposed fix for this issue.
>
> --Imre
>
> From 5c23657bc168db12a1ba100ab65fabd305c89c8a Mon Sep 17 00:00:00 2001
> From: Imre Deak
> Date: Thu, 26 Feb 2015 18:38:53 +0200
> Subject: [PATCH] drm/i915: gm45: work around hang during hibernation
I can confirm t
Imre Deak 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 previous wor
Imre Deak 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 sequence by for exam
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 th
20 matches
Mail list logo
