Re: 3.15-rc: regression in suspend

Re: 3.15-rc: regression in suspend

[Daniel Vetter]

On Thu, May 15, 2014 at 5:29 PM, Jiri Kosina <jkosina@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 useful prompt.
>>
>> Oops. You were right. It seems it is duplicate after all.
>>
>> [drm:init_ring_common] *ERROR* render ring initialization failed ctl 0001f001 head 00001020 tail 00000000 start 00003000
>
> Pavel, thanks a lot for testing.
>
> Adding Daniel and Chris to CC -- we have another incarnation of the bug
> that is being chased in 76554.

Someone succeeding at a bisect would be awesome ... Note that the only
key here is the ring init failure in dmesg.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

Re: 3.15-rc: regression in suspend

[Pavel Machek]

On Thu 2014-05-15 17:31:54, Daniel Vetter wrote:
> On Thu, May 15, 2014 at 5:29 PM, Jiri Kosina <jkosina@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 useful prompt.
> >>
> >> Oops. You were right. It seems it is duplicate after all.
> >>
> >> [drm:init_ring_common] *ERROR* render ring initialization failed ctl 0001f001 head 00001020 tail 00000000 start 00003000
> >
> > Pavel, thanks a lot for testing.
> >
> > Adding Daniel and Chris to CC -- we have another incarnation of the bug
> > that is being chased in 76554.
> 
> Someone succeeding at a bisect would be awesome ... Note that the only
> key here is the ring init failure in dmesg.

Hmm. I was slowly getting ready for doing the bisect, but it seems
someone did it for me.

Date: Wed, 28 May 2014 18:25:21 +0100
From: Ken Moffat <zarniwhoop@ntlworld.com>
To: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Dave Airlie <airlied@redhat.com>, linux-kernel@vger.kernel.org
Subject: Resume from suspend broken in 3.15. (bisected)
User-Agent: Mutt/1.5.23 (2014-03-12)

I manually reverted 25f397a429dfa43f22c278d0119a60a343aa568f and it
seems I'm back at working suspend/resume in i915.

The 3.15 regression seemed to be "if suspend works once, it seems to
work until reboot", otherwise it failed in cca 70% cases. I did two
reboots so far with 25f... reverted, and it seems to behave ok.

Best regards,  
								Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: 3.15-rc: regression in suspend

[Pavel Machek]

On Thu 2014-05-15 17:31:54, Daniel Vetter wrote:
> On Thu, May 15, 2014 at 5:29 PM, Jiri Kosina <jkosina@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 useful prompt.
> >>
> >> Oops. You were right. It seems it is duplicate after all.
> >>
> >> [drm:init_ring_common] *ERROR* render ring initialization failed ctl 0001f001 head 00001020 tail 00000000 start 00003000
> >
> > Pavel, thanks a lot for testing.
> >
> > Adding Daniel and Chris to CC -- we have another incarnation of the bug
> > that is being chased in 76554.
> 
> Someone succeeding at a bisect would be awesome ... Note that the only
> key here is the ring init failure in dmesg.

Oh and... the machine has problems comming up after reboot (never seen
those before 3.15). Sometimes, boot will hang with blank screen, and hard
powerdown is needed...
									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: 3.15-rc: regression in suspend

[Pavel Machek]

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 <jkosina@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 useful prompt.
> > >>
> > >> Oops. You were right. It seems it is duplicate after all.
> > >>
> > >> [drm:init_ring_common] *ERROR* render ring initialization failed ctl 0001f001 head 00001020 tail 00000000 start 00003000
> > >
> > > Pavel, thanks a lot for testing.
> > >
> > > Adding Daniel and Chris to CC -- we have another incarnation of the bug
> > > that is being chased in 76554.
> > 
> > Someone succeeding at a bisect would be awesome ... Note that the only
> > key here is the ring init failure in dmesg.
> 
> Oh and... the machine has problems comming up after reboot (never seen
> those before 3.15). Sometimes, boot will hang with blank screen, and hard
> powerdown is needed...

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.
									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: 3.15-rc: regression in suspend

[Daniel Vetter]

On Sun, Jun 8, 2014 at 1:11 AM, Pavel Machek <pavel@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 bisect really likes 25f397a429dfa43f22c278d0119a60 - you're about
the 5th report or so that claims this is the culprit but it's
something else. The above code is definitely not used in i915 so bogus
bisect result.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

Re: 3.15-rc: regression in suspend

[Pavel Machek]

On Mon 2014-06-09 11:25:20, Daniel Vetter wrote:
> On Sun, Jun 8, 2014 at 1:11 AM, Pavel Machek <pavel@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 bisect really likes 25f397a429dfa43f22c278d0119a60 - you're about
> the 5th report or so that claims this is the culprit but it's
> something else. The above code is definitely not used in i915 so bogus
> bisect result.

Note I did not do the bisect, I only attempted revert and test.

And did three boots of successful s2ram.. only to find out that it
does not really fix s2ram, I was just lucky :-(.

Unfortunately, this means my s2ram problem will be tricky/impossible
to bisect :-(.

									Pavel

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: 3.15-rc: regression in suspend

[Jiri Kosina]

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 likes 25f397a429dfa43f22c278d0119a60 - you're about
> > the 5th report or so that claims this is the culprit but it's
> > something else. The above code is definitely not used in i915 so bogus
> > bisect result.
> 
> Note I did not do the bisect, I only attempted revert and test.
> 
> And did three boots of successful s2ram.. only to find out that it
> does not really fix s2ram, I was just lucky :-(.
> 
> Unfortunately, this means my s2ram problem will be tricky/impossible
> to bisect :-(.

Welcome to the situation I have been in for past several months.

-- 
Jiri Kosina
SUSE Labs

Bisecting the heisenbugs (was Re: 3.15-rc: regression in suspend)

[Pavel Machek]

[-- Attachment #1: Type: text/plain, Size: 2709 bytes --]

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 likes 25f397a429dfa43f22c278d0119a60 - you're about
> > > the 5th report or so that claims this is the culprit but it's
> > > something else. The above code is definitely not used in i915 so bogus
> > > bisect result.
> > 
> > Note I did not do the bisect, I only attempted revert and test.
> > 
> > And did three boots of successful s2ram.. only to find out that it
> > does not really fix s2ram, I was just lucky :-(.
> > 
> > Unfortunately, this means my s2ram problem will be tricky/impossible
> > to bisect :-(.
> 
> Welcome to the situation I have been in for past several months.

I attempted to do some analysis. It should be possible to bisect when
tests are not reliable, but it will take time and it will be almost
neccessary to have the bisection automated.

How long does the testing take for you to get to 50% test reliability?

It seems to be one minute here.

Trivial strategy is to repeat each test to get to 99% test
reliability. That should make the test about 2x longer.

There are other strategies possible -- like selecting bisect points
closer to the "bad" end, and tricky "lets compute probabilities for
each point", that work well for some parameter settings. There is
probably even better strategy possible... if you have an idea, you can
try it below.

Monte carlo simulation is attached. 

Bisector on reliable bug
-----
1024 versions bug with probability of  0  false success, monte carlo
of  30000  tries
Assume compilation takes  6 minutes and test takes 1 minutes
Average cost  71.0522 minutes
Average tests  9.99793333333
Bisector
-----
1024 versions bug with probability of  0.5  false success, monte carlo
of  30000  tries
Assume compilation takes  6 minutes and test takes 1 minutes
Average cost  143.393933333 minutes
Average tests  44.5374666667
Trisector
-----
1024 versions bug with probability of  0.5  false success, monte carlo
of  30000  tries
Assume compilation takes  6 minutes and test takes 1 minutes
Average cost  160.554 minutes
Average tests  39.9552666667
Strange
-----
1024 versions bug with probability of  0.5  false success, monte carlo
of  3000  tries
Assume compilation takes  6 minutes and test takes 1 minutes
Average cost  246.658 minutes
Average tests  38.412
pavel@amd:~/WWW$ 


									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

[-- Attachment #2: tricky_bisect.py --]
[-- Type: text/x-python, Size: 4321 bytes --]

#!/usr/bin/python

import random
import numpy

class Devil:
    def init(m):
        m.versions = 1024
        # Costs in minutes
        m.cost_compile = 6
        m.cost_test = 1
        # Penalty for wrongly identifying a commit.
        m.cost_failure = 1000
        # 0. == nicely behaved bug which always triggers
        m.p_false_success = .5
        m.verbose = 2

    def init_run(m):
        m.broken = random.randint(0, m.versions-1)
        m.tests = 0
        m.last_ver = -1
        m.cost = 0

    def test_failed(m, ver):
        m.tests += 1
        if ver != m.last_ver:
            m.cost += m.cost_compile
        m.cost += m.cost_test
        m.last_ver = ver
        if m.verbose > 1:
            print "   testing version ", ver, "(tests %d, cost %d)" % (m.tests, m.cost),
        if ver >= m.broken:
            if m.verbose > 1:
                print "(bad)",
            if random.random() > m.p_false_success:
                if m.verbose > 1:
                    print "FAIL"
                return 1
        if m.verbose > 1:
            print "pass"
        return 0

    def evaluate(m):
        ver = m.run()
        if ver == m.broken:
            if m.verbose:
                print "success"
        else:
            if m.verbose:
                print "FAILURE"
            m.cost += m.cost_failure

class Bisector(Devil):
    def init_run(m):
        Devil.init_run(m)
        m.good = 0
        m.bad = m.versions-1

    def run(m):
        while m.good+1 < m.bad:
            ver = (m.good + m.bad) / 2
            p_bad = 1
            failed = 0
            while p_bad > .01:
                if m.test_failed(ver):
                    m.bad = ver
                    failed = 1
                    break
                p_bad *= m.p_false_success
            if not failed:
                m.good = ver
        return m.bad

class Trisector(Devil):
    def init_run(m):
        Devil.init_run(m)
        m.good = 0
        m.bad = m.versions-1

    def run(m):
        while m.good+1 < m.bad:
            ver = (m.good*6 + m.bad*14) / 20
            p_bad = 1
            failed = 0
            while p_bad > .01:
                if m.test_failed(ver):
                    m.bad = ver
                    failed = 1
                    break
                p_bad *= m.p_false_success
            if not failed:
                m.good = ver
        return m.bad


class Strange(Devil):
    def init_run(m):
        Devil.init_run(m)
        m.good = 0
        m.bad = m.versions-1
        m.prob_bad = numpy.zeros([m.versions], float)
        m.prob_bad[:m.versions] = .9

    def ask_for(m, ver):
        if m.test_failed(ver):
            m.bad = ver
            m.prob_bad[:ver+1] /= m.prob_bad[ver]
            m.prob_bad[ver:] = 1
            return

        m.prob_bad[:ver+1] *= m.p_false_success
        m.good = ver

    def last_good(m, prob):
        g = 0
        for i in range(m.bad):
            if m.prob_bad[i] <= prob:
                g = i
        return g

    def run(m):

        while m.last_good(.01)+1 < m.bad:
            if m.verbose > 1:
                print m.prob_bad
            m.good = m.last_good(.5)
            ver = (m.good*10 + m.bad*10) / 20
            m.ask_for(ver)
            m.good = m.last_good(.1)
            ver = (m.good*10 + m.bad*10) / 20
            m.ask_for(ver)


        return m.bad

def monte_carlo(bis, tries = 30000):
    total_cost = 0.
    total_tests = 0.
    for i in range(tries):
        bis.init_run()
        if tries > 500:
            bis.verbose = 0
        bis.evaluate()
        total_cost += bis.cost
        total_tests += bis.tests

    print "-----"
    print bis.versions, "versions bug with probability of ", bis.p_false_success, " false success, monte carlo of ", tries, " tries"
    print "Assume compilation takes ", bis.cost_compile, "minutes and test takes", bis.cost_test, "minutes"
    print "Average cost ", total_cost / tries, "minutes"
    print "Average tests ", total_tests / tries

print "Bisector on reliable bug"
bis = Bisector()
bis.init()
bis.p_false_success = 0
monte_carlo(bis)

print "Bisector"
bis = Bisector()
bis.init()
monte_carlo(bis)

print "Trisector"
bis = Trisector()
bis.init()
monte_carlo(bis)

print "Strange"
bis = Strange()
bis.init()
monte_carlo(bis, 3000)





[-- Attachment #3: Type: text/plain, Size: 159 bytes --]

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

3.16, i915: less colors in X?

[Pavel Machek]

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...?

This is thinkpad x60 with Debian 6.0.9.

Any ideas?
									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: 3.16, i915: less colors in X?

[Pavel Machek]

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 to figure out how to ask X what color depth it is using...?
> 
> This is thinkpad x60 with Debian 6.0.9.
> 
> Any ideas?

Xorg.log does not show anything too suspicious:

diff -u /var/log/Xorg.0.log{,.old} > /tmp/delme

									Pavel

--- /var/log/Xorg.0.log	2014-06-21 22:24:15.005229099 +0200
+++ /var/log/Xorg.0.log.old	2014-06-21 22:22:38.275847726 +0200
@@ -3,8 +3,8 @@
 Release Date: 2010-05-04
 X Protocol Version 11, Revision 0
 Build Operating System: Linux 3.2.0-4-amd64 i686 Debian
-Current Operating System: Linux duo 3.10.0+ #293 SMP Sun Jul 14 22:44:49 CEST 2013 i686
-Kernel command line: BOOT_IMAGE=(hd0,3)/boot/vmlinuz-3.10 root=/dev/sda3 resume=/dev/sda1 psmouse.psmouse_proto=imps psmouse_proto=imps psmouse.proto=imps acpi_sleep=s3_bios,s3_mode no_console_suspend i915.modeset=1 video=inteldrmfb:mode=1024x768 fbcon=scrollback:64k
+Current Operating System: Linux duo 3.16.0-rc1+ #373 SMP Sat Jun 21 20:46:47 CEST 2014 i686
+Kernel command line: BOOT_IMAGE=(hd0,2)/l/linux-good/arch/x86/boot/bzImage root=/dev/sda3 resume=/dev/sda1 psmouse.psmouse_proto=imps psmouse_proto=imps psmouse.proto=imps acpi_sleep=s3_bios,s3_mode no_console_suspend i915.modeset=1 video=inteldrmfb:mode=1024x768 fbcon=scrollback:64k
 Build Date: 17 December 2013  08:26:59PM
 xorg-server 2:1.7.7-18 (Julien Cristau <jcristau@debian.org>) 
 Current version of pixman: 0.16.4
@@ -13,7 +13,7 @@
 Markers: (--) probed, (**) from config file, (==) default setting,
 	(++) from command line, (!!) notice, (II) informational,
 	(WW) warning, (EE) error, (NI) not implemented, (??) unknown.
-(==) Log file: "/var/log/Xorg.0.log", Time: Sat Jun 21 22:23:28 2014
+(==) Log file: "/var/log/Xorg.0.log", Time: Sat Jun 21 21:04:49 2014
 (==) Using system config directory "/usr/share/X11/xorg.conf.d"
 (==) No Layout section.  Using the first Screen section.
 (==) No screen section available. Using defaults.
@@ -402,10 +402,17 @@
 (II) intel(0): Modeline "800x600"x0.0   40.00  800 840 968 1056  600 601 605 628 +hsync +vsync (37.9 kHz)
 (II) intel(0): Modeline "640x480"x0.0   25.18  640 656 752 800  480 490 492 525 -hsync -vsync (31.5 kHz)
 (II) intel(0): Modeline "1024x768"x0.0   65.00  1024 1048 1184 1344  768 771 777 806 -hsync -vsync (48.4 kHz)
-(II) intel(0): EDID vendor "LEN", prod id 16384
-(II) intel(0): Printing DDC gathered Modelines:
-(II) intel(0): Modeline "1024x768"x0.0   54.16  1024 1048 1184 1344  768 771 777 806 -hsync -vsync (40.3 kHz)
-(II) intel(0): Modeline "1024x768"x0.0   43.33  1024 1048 1184 1344  768 771 777 806 -hsync -vsync (32.2 kHz)
-(II) intel(0): Modeline "800x600"x0.0   40.00  800 840 968 1056  600 601 605 628 +hsync +vsync (37.9 kHz)
-(II) intel(0): Modeline "640x480"x0.0   25.18  640 656 752 800  480 490 492 525 -hsync -vsync (31.5 kHz)
-(II) intel(0): Modeline "1024x768"x0.0   65.00  1024 1048 1184 1344  768 771 777 806 -hsync -vsync (48.4 kHz)
+(II) Power Button: Close
+(II) UnloadModule: "evdev"
+(II) Video Bus: Close
+(II) UnloadModule: "evdev"
+(II) Sleep Button: Close
+(II) UnloadModule: "evdev"
+(II) AT Translated Set 2 keyboard: Close
+(II) UnloadModule: "evdev"
+(II) PS/2 Generic Mouse: Close
+(II) UnloadModule: "evdev"
+(II) ThinkPad Extra Buttons: Close
+(II) UnloadModule: "evdev"
+(II) ACPI Virtual Keyboard Device: Close
+(II) UnloadModule: "evdev"


-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: 3.16, i915: less colors in X?

[Chris Wilson]

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 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...?
> 
> This is thinkpad x60 with Debian 6.0.9.
> 
> Any ideas?

That suggests that the panel dithering changed. Compare intel_reg_dumper
output for both kernels, especially PIPE.CONF.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre

Re: 3.16, i915: less colors in X?

[Martin Steigerwald]

Am Samstag, 21. Juni 2014, 22:29:01 schrieb Pavel Machek:
> 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...?

I think:

martin@merkaba:~> xdpyinfo | grep -i "depth of root"
  depth of root window:    24 planes

but am not completely sure.
 
> This is thinkpad x60 with Debian 6.0.9.

Ciao,
-- 
Martin 'Helios' Steigerwald - http://www.Lichtvoll.de
GPG: 03B0 0D6C 0040 0710 4AFA  B82F 991B EAAC A599 84C7

Re: 3.16, i915: less colors in X?

[Thomas Richter]

Hi Martin,

>> I'm trying to figure out how to ask X what color depth it is using...?
>
> I think:
>
> martin@merkaba:~> xdpyinfo | grep -i "depth of root"
>    depth of root window:    24 planes
>
> but am not completely sure.
>
>> This is thinkpad x60 with Debian 6.0.9.

AFAIK the 830GM chipset does not offer any support for hardware 
dithering. Whether the panel in the x60 does I do not know, though.

However, what is remarkable is that graphics on a 16 bit(!) screen may 
look more pleasing than graphics on a 24 bit screen, at least for such 
ancient machines. The reason is that the panel cuts the bitdepth down 
from 8 to 6 bits, without any dithering, just by cutting off the LSBs. 
However, if you select a 16bpp mode to begin with, some desktop 
environments (specifically gnome) apply a dithering of their own, even 
though the output is only 5 bit per component.

This is at least what I see here on the IBM R31 and the Fujitsu S6010: 
Gnome desktop at 16bpp looks better than the desktop at 8bpp, due to the 
lack of hardware dithering.

The X11 intel driver had an option "Dac6Bit" to signal the 6 bit panel 
resolution to X (even though the display pipeline operates in 8 bit 
mode), but I have never seen this working in the past time. It seems not 
to be supported anymore. Probably that's the culprit.

Martin, you should probably test Ville's alm_fixes5 kernel branch, its 
support for the 830GM chipset of the X30 is in my experience much better 
than that of the drm-intel-nightly or official kernels.

Greetings,
	Thomas

Re: 3.16, i915: less colors in X?

[Martin Steigerwald]

Am Sonntag, 22. Juni 2014, 00:51:55 schrieb Thomas Richter:
> Hi Martin,

Hi Thomas,

> >> I'm trying to figure out how to ask X what color depth it is using...?
> > 
> > I think:
> > 
> > martin@merkaba:~> xdpyinfo | grep -i "depth of root"
> > 
> >    depth of root window:    24 planes
> > 
> > but am not completely sure.
> > 
> >> This is thinkpad x60 with Debian 6.0.9.
> 
> AFAIK the 830GM chipset does not offer any support for hardware
> dithering. Whether the panel in the x60 does I do not know, though.
> 
> However, what is remarkable is that graphics on a 16 bit(!) screen may
> look more pleasing than graphics on a 24 bit screen, at least for such
> ancient machines. The reason is that the panel cuts the bitdepth down
> from 8 to 6 bits, without any dithering, just by cutting off the LSBs.
> However, if you select a 16bpp mode to begin with, some desktop
> environments (specifically gnome) apply a dithering of their own, even
> though the output is only 5 bit per component.
> 
> This is at least what I see here on the IBM R31 and the Fujitsu S6010:
> Gnome desktop at 16bpp looks better than the desktop at 8bpp, due to the
> lack of hardware dithering.
> 
> The X11 intel driver had an option "Dac6Bit" to signal the 6 bit panel
> resolution to X (even though the display pipeline operates in 8 bit
> mode), but I have never seen this working in the past time. It seems not
> to be supported anymore. Probably that's the culprit.
> 
> Martin, you should probably test Ville's alm_fixes5 kernel branch, its
> support for the 830GM chipset of the X30 is in my experience much better
> than that of the drm-intel-nightly or official kernels.

I didn´t report this. I just mentioned how to find out the screen depth. Pavel 
reported this. On my ThinkPad T42 I do not compile own kernels anymore and on 
this ThinkPad T520 I will wait till 3.16-rc2.

Thanks,
-- 
Martin 'Helios' Steigerwald - http://www.Lichtvoll.de
GPG: 03B0 0D6C 0040 0710 4AFA  B82F 991B EAAC A599 84C7

Re: 3.16, i915: less colors in X?

[Pavel Machek]

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 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...?
> > 
> > This is thinkpad x60 with Debian 6.0.9.
> > 
> > Any ideas?
> 
> That suggests that the panel dithering changed. Compare intel_reg_dumper
> output for both kernels, especially PIPE.CONF.

Hmm, I tried:

root@duo:/sys/power# mount -t debugfs debugfs /sys/kernel/debug
root@duo:/sys/power# intel_gpu_dump 
Error opening /sys/kernel/debug/dri/0/i915_ringbuffer_info: No such
file or directory

Perhaps your i915 kernel driver has no support for dumping batchbuffer
data?
(In kernels prior to 2.6.30 this requires manually-applied patches.)
root@duo:/sys/power# ls -al /sys/kernel/debug/dri/0/
bufs                       i915_gem_gtt               i915_pc8_status
clients                    i915_gem_hws               i915_pipe_A_crc
gem_names                  i915_gem_hws_blt           i915_pipe_B_crc
i915_cache_sharing         i915_gem_hws_bsd           i915_pipe_C_crc
i915_capabilities          i915_gem_hws_vebox
i915_power_domain_info
i915_context_status        i915_gem_inactive          i915_ppgtt_info
i915_cur_wm_latency        i915_gem_interrupt
i915_pri_wm_latency
i915_delayfreq_table       i915_gem_objects
i915_ring_freq_table
i915_display_crc_ctl       i915_gem_pageflip
i915_ring_missed_irq
i915_display_info          i915_gem_pinned            i915_ring_stop
i915_drpc_info             i915_gem_request
i915_ring_test_irq
i915_edp_psr_status        i915_gem_seqno
i915_rstdby_delays
i915_emon_status           i915_gem_stolen
i915_sink_crc_eDP1
i915_energy_uJ             i915_gen6_forcewake_count
i915_spr_wm_latency
i915_error_state           i915_gfxec                 i915_sr_status
i915_fbc_status            i915_inttoext_table
i915_swizzle_info
i915_forcewake_user        i915_ips_status            i915_wedged
i915_frequency_info        i915_llc                   name
i915_gem_active            i915_max_freq              vm
i915_gem_drop_caches       i915_min_freq              vma
i915_gem_fence_regs        i915_next_seqno            
i915_gem_framebuffer       i915_opregion              

root@duo:/sys/power# intel_gpu_dump --help
Error opening --help: No such file or directory

root@duo:/sys/power# hexdump /sys/kernel/debug/dri/0/i915_pipe_*_crc
hexdump: /sys/kernel/debug/dri/0/i915_pipe_C_crc: No such device
root@duo:/sys/power# 

I also tried to download the git tree with intel_gpu_dump, but:

pavel@duo:~/g/intel-gpu-tools$ ./autogen.sh 
autoreconf: Entering directory `.'
autoreconf: configure.ac: not using Gettext
autoreconf: running: aclocal ${ACLOCAL_FLAGS} -I m4
configure.ac:68: error: must install xorg-macros 1.16 or later before
running autoconf/autogen
configure.ac:68: the top level
autom4te: /usr/bin/m4 failed with exit status: 1
aclocal: /usr/bin/autom4te failed with exit status: 1
autoreconf: aclocal failed with exit status: 1
pavel@duo:~/g/intel-gpu-tools$ 

Trying to bypass configure script:

pavel@duo:~/g/intel-gpu-tools/tools$ gcc  -I ../lib intel_reg_dumper.c
2>&1  | less

In file included from ../lib/drmtest.h:37,
                 from intel_reg_dumper.c:39:
/usr/include/xf86drm.h:40:17: error: drm.h: No such file or directory
In file included from ../lib/drmtest.h:37,
                 from intel_reg_dumper.c:39:
/usr/include/xf86drm.h:268: error: expected specifier-qualifier-list
                 before ‘drm_context_t’
/usr/include/xf86drm.h:281: error: expected specifier-qualifier-list
                 before ‘drm_handle_t’
/usr/include/xf86drm.h:546: error: expected declaration specifiers or
                 ‘...’ before ‘drm_magic_t’


Is there way to get required info manually?
									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

regression: 3.16, i915: less colors in X?, caused by 773875bfb6737982903c42d1ee88cf60af80089c

[Pavel Machek]

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...?
> > > 
> > > This is thinkpad x60 with Debian 6.0.9.
> > > 
> > > Any ideas?
> > 
> > That suggests that the panel dithering changed. Compare intel_reg_dumper
> > output for both kernels, especially PIPE.CONF.

intel_reg_dumper has so many dependencies that it is basically
impossible to get working :-(.

Anyway, this seems to be the problem; if I revert it, my colors are
back.

commit 773875bfb6737982903c42d1ee88cf60af80089c
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date:   Mon Jan 27 10:00:30 2014 +0100

    drm/i915: Don't set the 8to6 dither flag when not scaling
    
    Apparently we really only need this when the pfit is enabled, at
    least
    I couldn't dicern any difference here. Furthermore the hacks we
    have
    to reconstruct this bit is a bit glaring, and probably only works
    because we can't move the lvds port to any other pipe than pipe B
    on
    gen2/3.
    
    So let's just rip this out.
    
    Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=77137 (the
    LVDS
    WARNING log, not the main "VGA can't be turned on" issue).
    Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: 3.15-rc: regression in suspend

[Pavel Machek]

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 likes 25f397a429dfa43f22c278d0119a60 - you're about
> > > the 5th report or so that claims this is the culprit but it's
> > > something else. The above code is definitely not used in i915 so bogus
> > > bisect result.
> > 
> > Note I did not do the bisect, I only attempted revert and test.
> > 
> > And did three boots of successful s2ram.. only to find out that it
> > does not really fix s2ram, I was just lucky :-(.
> > 
> > Unfortunately, this means my s2ram problem will be tricky/impossible
> > to bisect :-(.
> 
> Welcome to the situation I have been in for past several months.

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 not be fun, anyway...

										Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: 3.15-rc: regression in suspend

[Jiri Kosina]

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 not be fun, 
> anyway...

I am still seeing the problem with 3.16-rc2.

-- 
Jiri Kosina
SUSE Labs

Re: 3.15-rc: regression in suspend

[Daniel Vetter]

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 not be fun, 
> > anyway...
> 
> I am still seeing the problem with 3.16-rc2.

I'm confused now. Is the bisect result

commit 773875bfb6737982903c42d1ee88cf60af80089c
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date:   Mon Jan 27 10:00:30 2014 +0100

    drm/i915: Don't set the 8to6 dither flag when not scaling

now the culprit or not? Or do we have 2 different bugs at hand here?
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

Re: 3.15-rc: regression in suspend

[Pavel Machek]

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 not be fun, 
> > > anyway...
> > 
> > I am still seeing the problem with 3.16-rc2.
> 
> I'm confused now. Is the bisect result
> 
> commit 773875bfb6737982903c42d1ee88cf60af80089c
> Author: Daniel Vetter <daniel.vetter@ffwll.ch>
> Date:   Mon Jan 27 10:00:30 2014 +0100
> 
>     drm/i915: Don't set the 8to6 dither flag when not scaling
> 
> now the culprit or not? Or do we have 2 different bugs at hand here?

Three different issues, it seems. Two ring initialization problems,
one went away in 3.16 (for me), second did not (suspend for jikos),
third -- trivial issue with 8to6 dither.

									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: 3.15-rc: regression in suspend

[Jiri Kosina]

On Fri, 11 Jul 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 not be fun, 
> > > > anyway...
> > > 
> > > I am still seeing the problem with 3.16-rc2.
> > 
> > I'm confused now. Is the bisect result
> > 
> > commit 773875bfb6737982903c42d1ee88cf60af80089c
> > Author: Daniel Vetter <daniel.vetter@ffwll.ch>
> > Date:   Mon Jan 27 10:00:30 2014 +0100
> > 
> >     drm/i915: Don't set the 8to6 dither flag when not scaling
> > 
> > now the culprit or not? Or do we have 2 different bugs at hand here?
> 
> Three different issues, it seems. Two ring initialization problems,
> one went away in 3.16 (for me), second did not (suspend for jikos),
> third -- trivial issue with 8to6 dither.

That's correct assesment.

The ring initialization failure I reported is still there.

-- 
Jiri Kosina
SUSE Labs

Re: 3.15-rc: regression in suspend

[Jiri Kosina]

On Fri, 11 Jul 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 not be fun, 
> > > > anyway...
> > > 
> > > I am still seeing the problem with 3.16-rc2.
> > 
> > I'm confused now. Is the bisect result
> > 
> > commit 773875bfb6737982903c42d1ee88cf60af80089c
> > Author: Daniel Vetter <daniel.vetter@ffwll.ch>
> > Date:   Mon Jan 27 10:00:30 2014 +0100
> > 
> >     drm/i915: Don't set the 8to6 dither flag when not scaling
> > 
> > now the culprit or not? Or do we have 2 different bugs at hand here?
> 
> Three different issues, it seems. Two ring initialization problems,
> one went away in 3.16 (for me), second did not (suspend for jikos),
> third -- trivial issue with 8to6 dither.

The patch below seems to finally cure the problem at my system; I've just 
attached it to freedesktop bugzilla, but sending it to this thread as well 
to hopefully get as much testing coverage by affected people as possible.

I am going on with testing whether it really completely fixes the problem 
or just made it less likely.





From: Jiri Kosina <jkosina@suse.cz>
Subject: [PATCH] drm/i915: read HEAD register back in init_ring_common() to enforce ordering

Withtout this, ring initialization fails reliabily during resume with

	[drm:init_ring_common] *ERROR* render ring initialization failed ctl 0001f001 head ffffff8804 tail 00000000 start 000e4000

Signed-off-by: Jiri Kosina <jkosina@suse.cz>
---
 drivers/gpu/drm/i915/intel_ringbuffer.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c b/drivers/gpu/drm/i915/intel_ringbuffer.c
index 279488a..7add7ee 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.c
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
@@ -517,6 +517,9 @@ static int init_ring_common(struct intel_engine_cs *ring)
 	else
 		ring_setup_phys_status_page(ring);
 
+	/* Enforce ordering by reading HEAD register back */
+	I915_READ_HEAD(ring);
+
 	/* Initialize the ring. This must happen _after_ we've cleared the ring
 	 * registers with the above sequence (the readback of the HEAD registers
 	 * also enforces ordering), otherwise the hw might lose the new ring

-- 
Jiri Kosina
SUSE Labs

Re: 3.15-rc: regression in suspend

[Jiri Kosina]

On Thu, 7 Aug 2014, Jiri Kosina wrote:

> The patch below seems to finally cure the problem at my system; I've just 
> attached it to freedesktop bugzilla, but sending it to this thread as well 
> to hopefully get as much testing coverage by affected people as possible.
> 
> I am going on with testing whether it really completely fixes the problem 
> or just made it less likely.

Okay, after 31 suspend-resume cycles, the problem appeared again (while 
without the patch, it triggers with 100% reliability). So it's not a 
complete fix, it just makes the problem much less visible.

Going back to bugzilla discussion.

> 
> From: Jiri Kosina <jkosina@suse.cz>
> Subject: [PATCH] drm/i915: read HEAD register back in init_ring_common() to enforce ordering
> 
> Withtout this, ring initialization fails reliabily during resume with
> 
> 	[drm:init_ring_common] *ERROR* render ring initialization failed ctl 0001f001 head ffffff8804 tail 00000000 start 000e4000
> 
> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
> ---
>  drivers/gpu/drm/i915/intel_ringbuffer.c | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c b/drivers/gpu/drm/i915/intel_ringbuffer.c
> index 279488a..7add7ee 100644
> --- a/drivers/gpu/drm/i915/intel_ringbuffer.c
> +++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
> @@ -517,6 +517,9 @@ static int init_ring_common(struct intel_engine_cs *ring)
>  	else
>  		ring_setup_phys_status_page(ring);
>  
> +	/* Enforce ordering by reading HEAD register back */
> +	I915_READ_HEAD(ring);
> +
>  	/* Initialize the ring. This must happen _after_ we've cleared the ring
>  	 * registers with the above sequence (the readback of the HEAD registers
>  	 * also enforces ordering), otherwise the hw might lose the new ring

-- 
Jiri Kosina
SUSE Labs

Re: 3.15-rc: regression in suspend

[Daniel Vetter]

On Thu, Aug 07, 2014 at 02:47:21PM +0200, Jiri Kosina wrote:
> On Fri, 11 Jul 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 not be fun, 
> > > > > anyway...
> > > > 
> > > > I am still seeing the problem with 3.16-rc2.
> > > 
> > > I'm confused now. Is the bisect result
> > > 
> > > commit 773875bfb6737982903c42d1ee88cf60af80089c
> > > Author: Daniel Vetter <daniel.vetter@ffwll.ch>
> > > Date:   Mon Jan 27 10:00:30 2014 +0100
> > > 
> > >     drm/i915: Don't set the 8to6 dither flag when not scaling
> > > 
> > > now the culprit or not? Or do we have 2 different bugs at hand here?
> > 
> > Three different issues, it seems. Two ring initialization problems,
> > one went away in 3.16 (for me), second did not (suspend for jikos),
> > third -- trivial issue with 8to6 dither.
> 
> The patch below seems to finally cure the problem at my system; I've just 
> attached it to freedesktop bugzilla, but sending it to this thread as well 
> to hopefully get as much testing coverage by affected people as possible.
> 
> I am going on with testing whether it really completely fixes the problem 
> or just made it less likely.

Picked up for -fixes, thanks for the patch.
-Daniel
> 
> 
> 
> 
> 
> From: Jiri Kosina <jkosina@suse.cz>
> Subject: [PATCH] drm/i915: read HEAD register back in init_ring_common() to enforce ordering
> 
> Withtout this, ring initialization fails reliabily during resume with
> 
> 	[drm:init_ring_common] *ERROR* render ring initialization failed ctl 0001f001 head ffffff8804 tail 00000000 start 000e4000
> 
> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
> ---
>  drivers/gpu/drm/i915/intel_ringbuffer.c | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c b/drivers/gpu/drm/i915/intel_ringbuffer.c
> index 279488a..7add7ee 100644
> --- a/drivers/gpu/drm/i915/intel_ringbuffer.c
> +++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
> @@ -517,6 +517,9 @@ static int init_ring_common(struct intel_engine_cs *ring)
>  	else
>  		ring_setup_phys_status_page(ring);
>  
> +	/* Enforce ordering by reading HEAD register back */
> +	I915_READ_HEAD(ring);
> +
>  	/* Initialize the ring. This must happen _after_ we've cleared the ring
>  	 * registers with the above sequence (the readback of the HEAD registers
>  	 * also enforces ordering), otherwise the hw might lose the new ring
> 
> -- 
> Jiri Kosina
> SUSE Labs
> _______________________________________________
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx

-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch