Re: [Intel-gfx] Linux 3.16-rc2

On Tue 2014-06-24 13:27:37, Chris Wilson wrote: On Tue, Jun 24, 2014 at 02:24:30PM +0200, Thomas Meyer wrote: Am Dienstag, den 24.06.2014, 12:57 +0100 schrieb Chris Wilson: On Tue, Jun 24, 2014 at 02:06:24PM +0300, Jani Nikula wrote: On Tue, 24 Jun 2014, Thomas Meyer tho...@m3y3r.de

Re: [Intel-gfx] [PATCH] Revert drm/i915: Don't set the 8to6 dither flag when not scaling

the WARNING backtraces in the references bugzilla are about gmch_pfit.lvds_border_bits mismatch, not at all about the dither bit. That one seems to work. Cc: Jiri Kosina jkos...@suse.cz Acked-by: Pavel Machek pa...@ucw.cz

Re: [Intel-gfx] 3.15-rc: regression in suspend

On Mon 2014-07-07 10:39:08, Daniel Vetter wrote: On Fri, Jun 27, 2014 at 03:37:16PM +0200, Jiri Kosina wrote: On Thu, 26 Jun 2014, Pavel Machek wrote: Ok, so I have set up machines for ktest / autobisect, and found out that 3.16-rc1 no longer has that problem. Oh well, bisect would

[Intel-gfx] [PATCH] work around warning in i915_gem_gtt

Gcc warns that addr might be used uninitialized. It may not, but I see why gcc gets confused. Additionally, hiding code with side-effects inside WARN_ON() argument seems uncool, so I moved it outside. Signed-off-by: Pavel Machek pa...@ucw.cz diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c b

Re: [Intel-gfx] 3.15-rc: regression in suspend

On Thu 2014-05-15 17:31:54, Daniel Vetter wrote: On Thu, May 15, 2014 at 5:29 PM, Jiri Kosina jkos...@suse.cz wrote: Note that X do work somehow after resume (I can't switch virtual desktops and dialog is stuck on screen, but it is not complete failure). I can do ctrl-alt-f1 and get to

Re: [Intel-gfx] 3.15-rc: regression in suspend

On Thu 2014-05-15 17:31:54, Daniel Vetter wrote: On Thu, May 15, 2014 at 5:29 PM, Jiri Kosina jkos...@suse.cz wrote: Note that X do work somehow after resume (I can't switch virtual desktops and dialog is stuck on screen, but it is not complete failure). I can do ctrl-alt-f1 and get to

Re: [Intel-gfx] 3.15-rc: regression in suspend

On Sat 2014-06-07 14:06:14, Pavel Machek wrote: On Thu 2014-05-15 17:31:54, Daniel Vetter wrote: On Thu, May 15, 2014 at 5:29 PM, Jiri Kosina jkos...@suse.cz wrote: Note that X do work somehow after resume (I can't switch virtual desktops and dialog is stuck on screen

Re: [Intel-gfx] 3.15-rc: regression in suspend

On Mon 2014-06-09 11:25:20, Daniel Vetter wrote: On Sun, Jun 8, 2014 at 1:11 AM, Pavel Machek pa...@ucw.cz wrote: Strange. It seems 3.15 with the patch reverted only boots in 30% or so cases... And I've seen resume failure, too, so maybe I was just lucky that it worked for a while. git

[Intel-gfx] Bisecting the heisenbugs (was Re: 3.15-rc: regression in suspend)

On Mon 2014-06-09 13:03:31, Jiri Kosina wrote: On Mon, 9 Jun 2014, Pavel Machek wrote: Strange. It seems 3.15 with the patch reverted only boots in 30% or so cases... And I've seen resume failure, too, so maybe I was just lucky that it worked for a while. git bisect really

[Intel-gfx] 3.16, i915: less colors in X?

Hi! I just test-booted 3.16-rc1, and background in X looked just wrong -- very noticeable bands on the background gradient. I thought that maybe it is just my eyes, but I went back to older kernel, and background is ok now. I'm trying to figure out how to ask X what color depth it is using...?

Re: [Intel-gfx] 3.16, i915: less colors in X?

On Sat 2014-06-21 22:29:01, Pavel Machek wrote: Hi! I just test-booted 3.16-rc1, and background in X looked just wrong -- very noticeable bands on the background gradient. I thought that maybe it is just my eyes, but I went back to older kernel, and background is ok now. I'm trying

Re: [Intel-gfx] 3.16, i915: less colors in X?

On Sat 2014-06-21 22:06:52, Chris Wilson wrote: On Sat, Jun 21, 2014 at 10:29:01PM +0200, Pavel Machek wrote: Hi! I just test-booted 3.16-rc1, and background in X looked just wrong -- very noticeable bands on the background gradient. I thought that maybe it is just my eyes, but I went

[Intel-gfx] regression: 3.16, i915: less colors in X?, caused by 773875bfb6737982903c42d1ee88cf60af80089c

Hi! I just test-booted 3.16-rc1, and background in X looked just wrong -- very noticeable bands on the background gradient. I thought that maybe it is just my eyes, but I went back to older kernel, and background is ok now. I'm trying to figure out how to ask X what color depth

Re: [Intel-gfx] 3.15-rc: regression in suspend

On Mon 2014-06-09 13:03:31, Jiri Kosina wrote: On Mon, 9 Jun 2014, Pavel Machek wrote: Strange. It seems 3.15 with the patch reverted only boots in 30% or so cases... And I've seen resume failure, too, so maybe I was just lucky that it worked for a while. git bisect really

[Intel-gfx] WARN_ON() and X session lost from i915 on 3.14-rc6

Hi! This cost me two half-written mails... So far it happened once, so it may be very infrequent; but I do not think I seen similar failure from i915 before, so it may be an regression. Well... -22 should be EINVAL afaict. Any ideas?

Re: [Intel-gfx] WARN_ON() and X session lost from i915 on 3.14-rc6

On Wed 2014-03-12 23:52:09, Chris Wilson wrote: On Thu, Mar 13, 2014 at 12:30:39AM +0100, Pavel Machek wrote: Hi! This cost me two half-written mails... So far it happened once, so it may be very infrequent; but I do not think I seen similar failure from i915 before, so it may

[Intel-gfx] 3.15-rc2: i915 regression: only top 20% of screen works in X

Hi! After update to 3.15-rc2, only top 20% of screen works on X. 00:02.0 VGA compatible controller: Intel Corporation 4 Series Chipset Integrated Graphics Controller (rev 03) 00:02.1 Display controller: Intel Corporation 4 Series Chipset Integrated Graphics Controller (rev 03)

Re: [Intel-gfx] 3.15-rc2: i915 regression: only top 20% of screen works in X

On Wed 2014-04-23 23:09:45, Daniel Vetter wrote: On Wed, Apr 23, 2014 at 10:22 PM, Pavel Machek pa...@ucw.cz wrote: After update to 3.15-rc2, only top 20% of screen works on X. 00:02.0 VGA compatible controller: Intel Corporation 4 Series Chipset Integrated Graphics Controller (rev 03

Re: [Intel-gfx] 3.15-rc2: i915 regression: only top 20% of screen works in X

Hi! After update to 3.15-rc2, only top 20% of screen works on X. 00:02.0 VGA compatible controller: Intel Corporation 4 Series Chipset Integrated Graphics Controller (rev 03) 00:02.1 Display controller: Intel Corporation 4 Series Chipset Integrated Graphics Controller (rev 03)

Re: [Intel-gfx] 3.15-rc2: i915 regression: only top 20% of screen works in X

Hi! After update to 3.15-rc2, only top 20% of screen works on X. 00:02.0 VGA compatible controller: Intel Corporation 4 Series Chipset Integrated Graphics Controller (rev 03) 00:02.1 Display controller: Intel Corporation 4 Series Chipset Integrated Graphics Controller

Re: [Intel-gfx] 3.15-rc2: i915 regression: only top 20% of screen works in X

On Thu 2014-04-24 08:03:04, Daniel Vetter wrote: On Thu, Apr 24, 2014 at 7:50 AM, Chris Wilson ch...@chris-wilson.co.uk wrote: That says that i915.ko failed to initialise the GPU (or rather the GPU wasn't responding) and bailed during module load. The key line here is

Re: [Intel-gfx] 3.15-rc2: i915 regression: only top 20% of screen works in X

Hi! Like Chris said please test latest drm-intel-nighlty from http://cgit.freedesktop.org/drm-intel to make sure that the recently merged mitigation measures work properly. But those won't get your gpu back, only the display and it's only for 3.16. We're still hunting a What does it means

[Intel-gfx] [partial bisect] Re: 3.15-rc2: i915 regression: only top 20% of screen works in X

Hi! And if you can indeed reliably reproduce this a bisect could be really useful It seems reliable, yes. So far I got: Pavel git bisect start # good: [455c6fdbd219161bd09b1165f11699d6d73de11c] Linux 3.14 git bisect good

[Intel-gfx] [PATCH] fix i915 regression: only top 20% of screen works in X

Fix regression where only 20% of screen works in X. This is manual revert of a51435a3137ad8ae75c288c39bd2d8b2696bae8f. Signed-off-by: Pavel Machek pa...@ucw.cz diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c b/drivers/gpu/drm/i915/intel_ringbuffer.c index 6bc68bd..cf63c67 100644

Re: [Intel-gfx] [bisect result] Re: 3.15-rc2: i915 regression: only top 20% of screen works in X

On Thu, Apr 24, 2014 at 09:40:38PM +0200, Pavel Machek wrote: Hi! And if you can indeed reliably reproduce this a bisect could be really useful. And we have a winner here :-) Ok, it was not as painfull as I feared. It does not revert cleanly, but doing it by hand

Re: [Intel-gfx] [bisect result] Re: 3.15-rc2: i915 regression: only top 20% of screen works in X

Hi! And if you can indeed reliably reproduce this a bisect could be really useful. And we have a winner here :-) Ok, it was not as painfull as I feared. It does not revert cleanly, but doing it by hand was not that bad. Oh my. That is bizarre, can you check whether you

Re: [Intel-gfx] 3.11-rc7: i915: stuck on render ring

On Wed 2013-09-04 11:08:14, Chris Wilson wrote: On Tue, Sep 03, 2013 at 09:06:47PM +0200, Pavel Machek wrote: Hi! I was happily using X... and then screen froze. Mouse still moves. Switching to text console still worked, good. It is first time in a while, normally this machine works

Re: [Intel-gfx] [PATCH] drm/i915: apply the PCI_D0/D3 hibernation workaround everywhere on pre GEN6

On Wed 2015-07-01 11:35:48, Jani Nikula wrote: On Tue, 30 Jun 2015, Pavel Machek pa...@ucw.cz wrote: Hi! commit da2bc1b9db3351addd293e5b82757efe1f77ed1d Author: Imre Deak imre.d...@intel.com Date: Thu Oct 23 19:23:26 2014 +0300 drm/i915: add poweroff_late handler

Re: [Intel-gfx] [PATCH] drm/i915: apply the PCI_D0/D3 hibernation workaround everywhere on pre GEN6

On Wed 2015-07-01 13:53:31, Ville Syrjälä wrote: On Wed, Jul 01, 2015 at 11:51:27AM +0200, Pavel Machek wrote: - Embedded panels have a well defined shutdown sequence. We don't have any good reason to not follow this, in fact for some panels the subsequent

Re: [Intel-gfx] [PATCH] drm/i915: apply the PCI_D0/D3 hibernation workaround everywhere on pre GEN6

- Embedded panels have a well defined shutdown sequence. We don't have any good reason to not follow this, in fact for some panels the subsequent reinitialization could be problematic in case of a hard power-off. (Thanks to Jani for this info) Please cite

[Intel-gfx] 4.1-rc3: i915-related crash

Hi! Debian 8 based system. X suddenly froze. Not quite reproducible, I'm afraid. Pavel [331445.592203] ftdi_sio 5-2:1.0: device disconnected [331447.063345] r8169 :03:00.0 eth0: link up [331447.930260] PM: resume of devices

Re: [Intel-gfx] [PATCH] drm/i915: apply the PCI_D0/D3 hibernation workaround everywhere on pre GEN6

Hi! commit da2bc1b9db3351addd293e5b82757efe1f77ed1d Author: Imre Deak imre.d...@intel.com Date: Thu Oct 23 19:23:26 2014 +0300 drm/i915: add poweroff_late handler introduced a regression on old platforms during hibernation. A workaround was added in commit

Re: [Intel-gfx] 4.0.8-4.1.3 : after resume from s2ram both internal and external display of a docked ThinkPad ate black

On Wed 2015-07-29 15:54:00, Toralf Förster wrote: Undocking helps, and then I can dock again. This happens at a hardened 64 bit Gentoo with i915, but I think, it is not hardened related, or ? Any chance to bisect it? -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures)

Re: [Intel-gfx] 4.0.8->4.1.3 : after resume from s2ram both internal and external display of a docked ThinkPad ate black

On Sun 2015-10-04 18:30:14, Toralf Förster wrote: > On 08/04/2015 02:29 PM, Toralf Förster wrote: > > On 08/02/2015 09:43 AM, Pavel Machek wrote: > >> Any chance to bisect it? > > Did it. > > > > FWIW: the mentioned commit was introduced between 3.18 and 3.19

[Intel-gfx] 4.0 -> 4.1 regression : after resume from s2ram both internal and external display of a docked ThinkPad ate black

> >>> commit e7d6f7d708290da1b7c92f533444b042c79412e0 > >>> Author: Dave Airlie > >>> Date: Mon Dec 8 13:23:37 2014 +1000 > >>> > >>> drm/i915: resume MST after reading back hw state > >> Is there anything else what I can do ? > >> > >> Current kernels up to 4.2.3

Re: [Intel-gfx] [PATCH 2/2] drm/i915: Limit the busy wait on requests to 2us not 10ms!

Hi! > Reported-by: Jens Axboe > Link: https://lkml.org/lkml/2015/11/12/621 > Cc: Jens Axboe > Cc; "Rogozhkin, Dmitry V" > Cc: Daniel Vetter > Cc: Tvrtko Ursulin > Cc: Eero

Re: [Intel-gfx] Suspend To RAM failure in >= 4.1 - bissected to "drm/i915: Track GEN6 page table usage"

Hi! > > I then ran a git bissect between v4.0 and v4.1 from Linus's tree and > > found the "guilty" commit was > > > > commit 317b4e903636305cfe702ab3e5b3d68547a69e72 > > Author: Ben Widawsky > > Date: Mon Mar 16 16:00:55 2015 + > > > > drm/i915: Extract

Re: [Intel-gfx] 4.7-rc0: redshift stopped working on intel display

Hi! > Could you try to apply the following patch [1], hopefully this fixes > the issue for you. > > [1] https://patchwork.freedesktop.org/patch/89111/ I updated the kernel, applied the patch and yes, that helped. Thanks!

[Intel-gfx] 4.7-rc0: redshift stopped working on intel display

Hi! It looks like redshift stopped working. Even pretty crazy settings have no visible effect: pavel@amd:~$ redshift -O 1500 -g 6.6:6.6:6.6 Using method `randr'. pavel@amd:~$ redshift -x Using method `randr'. pavel@amd:~$ uname -a Linux amd 4.6.0 #47 SMP Fri May 27 12:07:10 CEST 2016 x86_64

Re: [Intel-gfx] 4.7-rc0: redshift stopped working on intel display

On Sat 2016-05-28 12:12:06, Pavel Machek wrote: > Hi! > > It looks like redshift stopped working. Even pretty crazy settings > have no visible effect: > > pavel@amd:~$ redshift -O 1500 -g 6.6:6.6:6.6 > Using method `randr'. > pavel@amd:~$ redshift -x > Using method `r

Re: [Intel-gfx] Kernel stability on baytrail machines

On Tue 2016-07-12 16:41:58, Ezequiel Garcia wrote: > Hi Alan, > > (Adding interested people to this thread) > > On 09 Apr 08:14 PM, One Thousand Gnomes wrote: > > > > I do feel that the importance of the mentioned bug is currently > > > > underestimated. Can anyone here give a note, how much

Re: [Intel-gfx] Kernel stability on baytrail machines

> On Tue 2016-07-12 16:41:58, Ezequiel Garcia wrote: > >>Hi Alan, > >> > >>(Adding interested people to this thread) > >> > >>On 09 Apr 08:14 PM, One Thousand Gnomes wrote: > >I do feel that the importance of the mentioned bug is currently > >underestimated. Can anyone here give a note,

[Intel-gfx] 4.11-rc0, thinkpad x220: GPU hang

Hi! mplayer stopped working after a while. Dmesg says: [ 3000.266533] cdc_ether 2-1.2:1.0 usb0: register 'cdc_ether' at usb-:00:1d.0-1.2, CDC Ethernet Device, 22:1b:e4:4e:56:f5 [ 3190.767227] [drm] GPU HANG: ecode 6:0:0xbb409fff, in chromium [4597], reason: Hang on render ring, action: reset

[Intel-gfx] 4.8-rc1: it is now common that machine needs re-run of xrandr after resume

Hi! I have 00:02.0 VGA compatible controller: Intel Corporation 4 Series Chipset Integrated Graphics Controller (rev 03) In previous kernels, resume worked ok. With 4.8-rc1, I quite often (1 in 10 resumes?) get in state where primary monitor (DVI) is dead (in powersave) and all windows move to

Re: [Intel-gfx] 4.8-rc1: it is now common that machine needs re-run of xrandr after resume

Hi! > I have > > 00:02.0 VGA compatible controller: Intel Corporation 4 Series Chipset > Integrated Graphics Controller (rev 03) > > In previous kernels, resume worked ok. With 4.8-rc1, I quite often (1 > in 10 resumes?) get in state where primary monitor (DVI) is dead (in > powersave) and all

Re: [Intel-gfx] 4.8-rc1: it is now common that machine needs re-run of xrandr after resume

On Tue 2016-09-13 22:38:45, Martin Steigerwald wrote: > Hi. > > Am Dienstag, 13. September 2016, 22:23:50 CEST schrieb Pavel Machek: > > I have > > > > 00:02.0 VGA compatible controller: Intel Corporation 4 Series Chipset > > Integrated Graphics Controller (re

Re: [Intel-gfx] 4.8-rc1: it is now common that machine needs re-run of xrandr after resume

On Wed 2016-09-14 10:38:18, Jani Nikula wrote: > On Wed, 14 Sep 2016, Pavel Machek <pa...@ucw.cz> wrote: > > Hi! > > > >> I have > >> > >> 00:02.0 VGA compatible controller: Intel Corporation 4 Series Chipset > >> Integrated Graphics C

Re: [Intel-gfx] 4.8-rc1: it is now common that machine needs re-run of xrandr after resume

Hi! On Wed 2016-09-14 14:14:35, Jani Nikula wrote: > On Wed, 14 Sep 2016, Jani Nikula <jani.nik...@linux.intel.com> wrote: > > On Wed, 14 Sep 2016, Pavel Machek <pa...@ucw.cz> wrote: > >> For the "sometimes need xrandr after resume": I don't think I can >

Re: [Intel-gfx] v4.9-rc3: graphical artefacts in X

On Fri 2016-11-18 11:14:16, Chris Wilson wrote: > On Fri, Nov 18, 2016 at 12:02:56PM +0100, Pavel Machek wrote: > > Hi! > > > > With v4.9, if I maximize "nowcast -x" application, I get broken > > display (as if someone split the window into rectangles an

[Intel-gfx] v4.9-rc3: graphical artefacts in X

Hi! With v4.9, if I maximize "nowcast -x" application, I get broken display (as if someone split the window into rectangles and shuffled them a bit). Switching virtual desktops either fixes it or breaks it, depending in how fast I switch. (Yes, strange). pavel@amd:~$ lspci | grep VGA 00:02.0 VGA

Re: [Intel-gfx] [Linux v4.10.0-rc1] call-traces after suspend-resume (pm? i915? cpu/hotplug?)

Hi! > [ Add some pm | i915 | x86 folks ] > > Hi, > > I have built Linux v4.10-rc1 today on my Ubuntu/precise AMD64 system > and I see some call-traces. > It is reproducible on suspend and resume. > > I cannot say which area touches the problem or if these are several > independent problems. >

Re: [Intel-gfx] [regression] Re: 4.11-rc0, thinkpad x220: GPU hang

On Mon 2017-03-06 12:23:41, Chris Wilson wrote: > On Mon, Mar 06, 2017 at 01:10:48PM +0100, Pavel Machek wrote: > > On Mon 2017-03-06 11:15:28, Chris Wilson wrote: > > > On Mon, Mar 06, 2017 at 12:01:51AM +0100, Pavel Machek wrote: > > > > Hi! > > > >

Re: [Intel-gfx] [regression] Re: 4.11-rc0, thinkpad x220: GPU hang

Hi! > > > > > > mplayer stopped working after a while. Dmesg says: > > > > > > > > > > > > [ 3000.266533] cdc_ether 2-1.2:1.0 usb0: register 'cdc_ether' at > > > > > > > > Now I'm pretty sure it is a regression in v4.11-rc0. Any ideas what to > > > > try? Bisect will be slow and nasty :-(. > >

Re: [Intel-gfx] [regression] Re: 4.11-rc0, thinkpad x220: GPU hang

On Mon 2017-03-06 12:23:41, Chris Wilson wrote: > On Mon, Mar 06, 2017 at 01:10:48PM +0100, Pavel Machek wrote: > > On Mon 2017-03-06 11:15:28, Chris Wilson wrote: > > > On Mon, Mar 06, 2017 at 12:01:51AM +0100, Pavel Machek wrote: > > > > Hi! > > > >

Re: [Intel-gfx] [regression] Re: 4.11-rc0, thinkpad x220: GPU hang

On Tue 2017-03-14 10:08:23, Thorsten Leemhuis wrote: > On 06.03.2017 00:01, Pavel Machek wrote: > >>> mplayer stopped working after a while. Dmesg says: > >>> > >>> [ 3000.266533] cdc_ether 2-1.2:1.0 usb0: register 'cdc_ether' at > > Now I'm pretty su

Re: [Intel-gfx] [regression] Re: 4.11-rc0, thinkpad x220: GPU hang

On Mon 2017-03-06 11:15:28, Chris Wilson wrote: > On Mon, Mar 06, 2017 at 12:01:51AM +0100, Pavel Machek wrote: > > Hi! > > > > > > mplayer stopped working after a while. Dmesg says: > > > > > > > > [ 3000.266533] cdc_ether 2-1.2:1.0 usb0: r

[Intel-gfx] [regression] Re: 4.11-rc0, thinkpad x220: GPU hang

Hi! > > mplayer stopped working after a while. Dmesg says: > > > > [ 3000.266533] cdc_ether 2-1.2:1.0 usb0: register 'cdc_ether' at Now I'm pretty sure it is a regression in v4.11-rc0. Any ideas what to try? Bisect will be slow and nasty :-(.

Re: [Intel-gfx] GPU hang with kernel 4.10rc3

On Mon 2017-01-23 10:39:27, Juergen Gross wrote: > On 13/01/17 15:41, Juergen Gross wrote: > > On 12/01/17 10:21, Chris Wilson wrote: > >> On Thu, Jan 12, 2017 at 07:03:25AM +0100, Juergen Gross wrote: > >>> On 11/01/17 18:08, Chris Wilson wrote: > On Wed, Jan 11, 2017 at 05:33:34PM +0100,

Re: [Intel-gfx] [RFC PATCH 1/6] drm: Add Content Protection property

On Wed 2017-11-29 22:08:56, Sean Paul wrote: > This patch adds a new optional connector property to allow userspace to enable > protection over the content it is displaying. This will typically be > implemented > by the driver using HDCP. > > The property is a tri-state with the following

Re: [Intel-gfx] [RFC PATCH 1/6] drm: Add Content Protection property

On Tue 2017-12-05 11:45:38, Daniel Vetter wrote: > On Tue, Dec 05, 2017 at 11:28:40AM +0100, Pavel Machek wrote: > > On Wed 2017-11-29 22:08:56, Sean Paul wrote: > > > This patch adds a new optional connector property to allow userspace to > > > enable > &

Re: [Intel-gfx] [RFC PATCH 1/6] drm: Add Content Protection property

Hi! > >> > Why would user of the machine want this to be something else than > >> > 'OFF'? > >> > > >> > If kernel implements this, will it mean hardware vendors will have to > >> > prevent user from updating kernel on machines they own? > >> > > >> > If this is merged, does it open kernel

[Intel-gfx] v4.20-rc1: list_del corruption on thinkpad x220

Hi! My machine locked hard (thinkpad x220). After reboot, I found this in syslog: Sounds like memory corruption..? Does not sound like easy to debug. ...otoh, it still looks like an addres, so maybe it is "just" race in GPU drivers? Any ideas?

Re: [Intel-gfx] [regression from v4.19] Re: 4.20.0-rc6-next-20181210, v4.20-rc1: list_del corruption on thinkpad x220, graphics related?

Hi! > > > So if you could please try drm-tip reproducing AND open a bug in Bugzilla. > > > If you are unwilling to do that, it is very difficult to help you > > > more. > > > > Website says I have to read and agree to two different pieces of > > legalesee, and I'd need to keep track of yet

[Intel-gfx] 4.20.0-rc6-next-20181210, v4.20-rc1: list_del corruption on thinkpad x220, graphics related?

Hi! > > > > > > > There's one similar for nouveau in Bugzilla, but it seems like a > > > > > > > genuine > > > > > > > memory corruption (1 bit flipped): > > > > > > > > > > > > > > https://bugs.freedesktop.org/show_bug.cgi?id=84880 > > > > > > > > > > > > > > Any extra information would be of

[Intel-gfx] [regression from v4.19] Re: 4.20.0-rc6-next-20181210, v4.20-rc1: list_del corruption on thinkpad x220, graphics related?

Hi! > > > > If you think it is useful, I can try to update my machine to > > > > linux-next. > > > > > > linux-next is closer to drm-tip, so it's better. Do you have some > > > specific reason for not wanting to run drm-tip (but linux-next is still > > > ok)? > > > > I already have build/update

Re: [Intel-gfx] v4.20-rc1: list_del corruption on thinkpad x220, graphics related?

Hi! > > > > There's one similar for nouveau in Bugzilla, but it seems like a genuine > > > > memory corruption (1 bit flipped): > > > > > > > > https://bugs.freedesktop.org/show_bug.cgi?id=84880 > > > > > > > > Any extra information would be of use :) > > > > > > > > Regards, Joonas > > > > >

Re: [Intel-gfx] v4.20-rc1: list_del corruption on thinkpad x220, graphics related?

On Sat 2018-12-08 12:13:46, Pavel Machek wrote: > Hi! > > > > > > There's one similar for nouveau in Bugzilla, but it seems like a > > > > > genuine > > > > > memory corruption (1 bit flipped): > > > > > > > > > >

[Intel-gfx] v4.20-rc5+ on x220: Resetting chip for hang on rcs0

Hi! Another day, another problem... but this one is different from the previous hang, as machine survives. Chromium was running with youtube video playing. [31850.666274] [drm] GPU hangs can indicate a bug anywhere in the entire gfx stack, including userspace. [31850.666277] [drm] Please file

Re: [Intel-gfx] v4.20-rc1: list_del corruption on thinkpad x220

Hi! > > > There's one similar for nouveau in Bugzilla, but it seems like a genuine > > > memory corruption (1 bit flipped): > > > > > > https://bugs.freedesktop.org/show_bug.cgi?id=84880 > > > > > > Any extra information would be of use :) > > > > > > Regards, Joonas > > > > > > PS. Could you

Re: [Intel-gfx] v4.20-rc1: list_del corruption on thinkpad x220

Hi! > > My machine locked hard (thinkpad x220). After reboot, I found this in > > syslog: > > > > Sounds like memory corruption..? Does not sound like easy to debug. > > Were you doing something GPU intense when you experienced the hard hang? > > And if so, have you been able to hit the issue

5.2: display corruption on X60, X220

Hi! In recent kernels (5.2.0-rc1-next-20190522, 5.2-rc2) I'm getting display corruption in X. Usually in terminals, but also in title bars etc. Black areas with white lines in them, usually... Same configuration worked properly in ... probably 4.19? Then I got some graphics-crashes on X220 that

Re: 5.2: display corruption on X60, X220

On Thu 2019-06-06 11:32:18, Jani Nikula wrote: > On Mon, 03 Jun 2019, Pavel Machek wrote: > > In recent kernels (5.2.0-rc1-next-20190522, 5.2-rc2) I'm getting > > display corruption in X. Usually in terminals, but also in title bars > > etc. Black areas with white l

Re: 5.4-rc1 on Thinkpad x220: graphics regression, it "snows" on digital output

Hi! > When 5.4-rc1 is booted on thinkpad X220 I get "snow" and other > artefacts on digital output. > > 00:02.0 VGA compatible controller: Intel Corporation 2nd Generation > Core Processor Family Integrated Graphics Controller (rev 09) > > It already snows when kernel is booting, snow continues

5.4-rc1 on Thinkpad x220: graphics regression, it "snows" on digital output

Hi! When 5.4-rc1 is booted on thinkpad X220 I get "snow" and other artefacts on digital output. 00:02.0 VGA compatible controller: Intel Corporation 2nd Generation Core Processor Family Integrated Graphics Controller (rev 09) It already snows when kernel is booting, snow continues in X. HDMI1

Re: DDC on Thinkpad x220

On Tue 2019-10-01 12:39:34, Jani Nikula wrote: > On Mon, 30 Sep 2019, Pavel Machek wrote: > > Hi! > > > > Thinkpad X220 should be new enough machine to talk DDC to the > > monitors, right? And my monitor has DDC enable/disable in the menu, so > > it should suppo

[Intel-gfx] DDC on Thinkpad x220

Hi! Thinkpad X220 should be new enough machine to talk DDC to the monitors, right? And my monitor has DDC enable/disable in the menu, so it should support it, too... But I don't have /dev/i2c* and did not figure out how to talk to the monitor. Is the support there in the kernel? What do I need

Re: [Intel-gfx] [PATCH] drm: Add support for integrated privacy screens

On Tue 2019-10-22 17:12:06, Rajat Jain wrote: > Certain laptops now come with panels that have integrated privacy > screens on them. This patch adds support for such panels by adding > a privacy-screen property to the drm_connector for the panel, that > the userspace can then use to control and

[Intel-gfx] xorg hang in 5.5-rc1 -- use after free?

Hi! I got an X hang and there seems to be something useful in dmesg... Any ideas? Pavel [0.00] Linux version 5.5.0-rc1+ (pavel@amd) (gcc version 4.9.2 (Debian 4.9.2-10+deb8u2)) #73 SMP PREEMPT Fri Dec 13 00:46:17

Re: [Intel-gfx] Linus, please revert 7dc8f11437: regression in 5.7-rc0, hangs while attempting to run X

Hi! > > > Beyond the fix already submitted? > > > > I did not get that one, can I have a pointer? > > What's the status of this one? I tried updating my kernel on April 3, that one did not work, but it did not include 721017cf4bd8. > I'm assuming the fix is commit 721017cf4bd8 ("drm/i915/gem:

Re: [Intel-gfx] Linus, please revert 7dc8f11437: regression in 5.7-rc0, hangs while attempting to run X

Hi! > > > 7dc8f1143778a35b190f9413f228b3cf28f67f8d > > > > > > drm/i915/gem: Drop relocation slowpath > > > > > > Since the relocations are no longer performed under a global > > > struct_mutex, or any other lock, that is also held by pagefault > > > handlers, > > > we can

[Intel-gfx] Linus, please revert 7dc8f11437: regression in 5.7-rc0, hangs while attempting to run X

On Fri 2020-04-03 15:00:31, Pavel Machek wrote: > Hi! > > 7dc8f1143778a35b190f9413f228b3cf28f67f8d > > drm/i915/gem: Drop relocation slowpath > > Since the relocations are no longer performed under a global > struct_mutex, or any other lock, that i

[Intel-gfx] 5.6-rc6: Xorg hangs

Hi! Hardware is thinkpad x220. I had this crash few days ago. And today I have similar-looking one, with slightly newer kernel. (Will post as a follow-up). Any idea what can be wrong? Pavel

[Intel-gfx] 5.7-rc0: hangs while attempting to run X

Hi! > > Hardware is thinkpad x220. I had this crash few days ago. And today I > > have similar-looking one, with slightly newer kernel. (Will post > > as a follow-up). As part of quest for working system, I tried 5.7-rc0, based on Merge: 50a5de895dbe b4d8ddf8356d Author: Linus Torvalds Date:

[Intel-gfx] [bisected] Re: 5.7-rc0: regression caused by drm tree, hangs while attempting to run X

Hi! > > > commit f365ab31efacb70bed1e821f7435626e0b2528a6 > > > Merge: 4646de87d325 59e7a8cc2dcf > > > Author: Linus Torvalds > > > Date: Wed Apr 1 15:24:20 2020 -0700 > > > > > > Merge tag 'drm-next-2020-04-01' of > > > git://anongit.freedesktop.org/drm/drm > > > > Any ideas, besides

[Intel-gfx] 5.7-rc0: regression caused by drm tree, hangs while attempting to run X

Hi! > > > > Hardware is thinkpad x220. I had this crash few days ago. And today I > > > > have similar-looking one, with slightly newer kernel. (Will post > > > > as a follow-up). > > > > As part of quest for working system, I tried 5.7-rc0, based on > > > > Merge: 50a5de895dbe b4d8ddf8356d > >

Re: [Intel-gfx] 5.7-rc0: hangs while attempting to run X

Hi! > > > Hardware is thinkpad x220. I had this crash few days ago. And today I > > > have similar-looking one, with slightly newer kernel. (Will post > > > as a follow-up). > > As part of quest for working system, I tried 5.7-rc0, based on > > Merge: 50a5de895dbe b4d8ddf8356d > Author: Linus

Re: [Intel-gfx] 5.7-rc0: regression caused by drm tree, hangs while attempting to run X

Hi! > > commit f365ab31efacb70bed1e821f7435626e0b2528a6 > > Merge: 4646de87d325 59e7a8cc2dcf > > Author: Linus Torvalds > > Date: Wed Apr 1 15:24:20 2020 -0700 > > > > Merge tag 'drm-next-2020-04-01' of > > git://anongit.freedesktop.org/drm/drm > Any ideas, besides the b-word? > >

Re: [Intel-gfx] [bisected] Re: 7dc8f11437: regression in 5.7-rc0, hangs while attempting to run X

Hi! 7dc8f1143778a35b190f9413f228b3cf28f67f8d drm/i915/gem: Drop relocation slowpath Since the relocations are no longer performed under a global struct_mutex, or any other lock, that is also held by pagefault handlers, we can relax and allow our fast path to take a fault. As

Re: [Intel-gfx] 5.9-rc1: graphics regression moved from -next to mainline

On Tue 2020-09-01 13:57:55, Harald Arnesen wrote: > Still (rc3) doesn't work without the three reverts. > > I'm not sure how to proceed, I cannot capture any oops, and see nothing > obvious in any logs. I believe this is the place when you ask Linus for reverts... Best regards,

Re: [Intel-gfx] [PATCH 1/2] drm/i915/gem: Replace reloc chain with terminator on error unwind

I915_MAP_FORCE_WC); > + map = i915_gem_object_pin_map(pool->obj, I915_MAP_FORCE_WB); > > on top of the previous patch. Faultinjection didn't turn up anything in > eb_relocate_vma, so we need to dig deeper. With this on top of other patches, it works. Tested-by: Pavel Machek Bes

Re: [Intel-gfx] [PATCH v2] mm: Track page table modifications in __apply_to_page_range()

> > Tested-by: Chris Wilson #x86-32 > Cc: # v5.8+ > Signed-off-by: Joerg Roedel This seems to solve screen blinking problems on Thinkpad X60. (It already survived few unison runs, which would usually kill it.). Tested-by: Pavel Machek

Re: [Intel-gfx] 5.9-rc1: graphics regression moved from -next to mainline

On Thu 2020-08-20 09:16:18, Linus Torvalds wrote: > On Thu, Aug 20, 2020 at 2:23 AM Pavel Machek wrote: > > > > Yes, it seems they make things work. (Chris asked for new patch to be > > tested, so I am switching to his kernel, but it survived longer than > > it usually

Re: [Intel-gfx] [PATCH v2] mm: Track page table modifications in __apply_to_page_range()

Hi! > > > The __apply_to_page_range() function is also used to change and/or > > > allocate page-table pages in the vmalloc area of the address space. > > > Make sure these changes get synchronized to other page-tables in the > > > system by calling arch_sync_kernel_mappings() when necessary. > >

Re: [Intel-gfx] [PATCH v2] mm: Track page table modifications in __apply_to_page_range()

Hi! > > > The __apply_to_page_range() function is also used to change and/or > > > allocate page-table pages in the vmalloc area of the address space. > > > Make sure these changes get synchronized to other page-tables in the > > > system by calling arch_sync_kernel_mappings() when necessary. > >

Re: [Intel-gfx] [PATCH 1/2] drm/i915/gem: Replace reloc chain with terminator on error unwind

Hi! > If we hit an error during construction of the reloc chain, we need to > replace the chain into the next batch with the terminator so that upon > flushing the relocations so far, we do not execute a hanging batch. Thanks for the patches. I assume this should fix problem from "5.9-rc1:

Re: [Intel-gfx] 5.9-rc1: graphics regression moved from -next to mainline

Hi! > > I think there's been some discussion about reverting that change for > > other reasons, but it's quite likely the culprit. > > Hmm. It reverts cleanly, but the end result doesn't work, because of > other changes. > > Reverting all of > >763fedd6a216 ("drm/i915: Remove

Re: [Intel-gfx] [PATCH 1/2] drm/i915/gem: Replace reloc chain with terminator on error unwind

Hi! > > Yep, my machines are low on memory. > > > > But ... test did not work that well. I have dead X and blinking > > screen. Machine still works reasonably well over ssh, so I guess > > that's an improvement. > > > [ 7744.718473] BUG: unable to handle page fault for address: f8c0 > > [

Re: [Intel-gfx] 5.9-rc1: graphics regression moved from -next to mainline

On Tue 2020-08-18 18:59:27, Linus Torvalds wrote: > On Tue, Aug 18, 2020 at 6:13 PM Dave Airlie wrote: > > > > I think there's been some discussion about reverting that change for > > other reasons, but it's quite likely the culprit. > > Hmm. It reverts cleanly, but the end result doesn't work,

Re: [Intel-gfx] [PATCH 1/2] drm/i915/gem: Replace reloc chain with terminator on error unwind

Hi! > > > If we hit an error during construction of the reloc chain, we need to > > > replace the chain into the next batch with the terminator so that upon > > > flushing the relocations so far, we do not execute a hanging batch. > > > > Thanks for the patches. I assume this should fix problem

Re: [Intel-gfx] 5.9-rc1: graphics regression moved from -next to mainline

Hi! > > I think there's been some discussion about reverting that change for > > other reasons, but it's quite likely the culprit. > > Hmm. It reverts cleanly, but the end result doesn't work, because of > other changes. > > Reverting all of > >763fedd6a216 ("drm/i915: Remove

  1   2   >