Re: [Intel-gfx] [REGRESSION 4.19-rc2] sometimes hangs with black screen when resuming from suspend or hibernation (was: Re: Linux 4.19-rc2)

[Martin Steigerwald]

Ville Syrjälä - 12.09.18, 19:10:
> On Tue, Sep 11, 2018 at 12:17:05PM +0200, Martin Steigerwald wrote:
> > Cc´d Intel Gfx mailing list, in case somebody there knows something:
> > 
> > Cc´d Thorsten for regression tracking… forgot initially. Can also
> > open bug report at a later time but so far I cannot provide many
> > details about the issue.
> > 
> > Rafael J. Wysocki - 11.09.18, 10:17:
> > > On Tue, Sep 11, 2018 at 10:01 AM Martin Steigerwald
> > 
> >  wrote:
> > > > Hi.
> > > > 
> > > > Linus Torvalds - 02.09.18, 23:45:
> > > > > As usual, the rc2 release is pretty small. People are taking a
> > > > 
> > > > With 4.19-rc2 this ThinkPad T520 with i5 Sandybrdige sometimes
> > > > hangs
> > > > with black screen when resuming from suspend or hibernation. 
> > > > With
> > > > 4.18.1 it did not. Of course there have been userspace related
> > > > updates that could be related.
> > > > 
> > > > I currently have no time to dig into this and on this production
> > > > laptop I generally do not do bisects between major kernel
> > > > releases.
> > > > So currently I only answer questions that do not require much
> > > > time
> > > > to answer.
> > > > 
> > > > For now I switched back to 4.18. If that is stable – and thus
> > > > likely
> > > > no userspace component is related –, I go with 4.19-rc3 or
> > > > whatever
> > > > is most recent version to see if the issue has been fixed
> > > > already.
> > > 
> > > There were almost no general changes related to system-wide PM
> > > between 4.18 and current, so I would suspect one of the device
> > > drivers or the x86 core.  It also may be something like CPU
> > > online/offline, however.> 
> > I see. I wondered about intel-gfx driver already. Of course it could
> > also be something else.
> > 
> > I forgot to mention: The mouse pointer was visible, but the screen
> > remained black.
> 
> Did the mouse cursor still move or not?

No, it did not move.

> Could also try suspend without any GUI stuff in the way. Or try the
> intel ddx instead of the modesetting ddx (assuming that's what
> you're using now) and no compositor to rule out GPU hangs killing
> the compositor. The intel ddx can also deal with the GPU not
> recovering from a hang by switching to software rendering,
> whereas modesetting cannot.

Thanks for these suggestions. Currently laptop is still on 4.18 again 
(4.18.7) and I did not see this hang after resume so far. If it 
continues to be stable for a few more days, I try with latest 4.19 again 
as then its very likely kernel related.

> Hmm. Also T520 is an optimus laptop maybe? If there's an nvidia
> GPU involved it's going to be hard to get anyone to care. Better
> switch that off in the BIOS if you haven't already.

I decided back then for Intel only graphics. I never regretted this.

For me NVidia graphics is not an option, unless NVidia significantly 
changes their policy regarding free software drivers.

Thanks,
-- 
Martin


___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [REGRESSION 4.19-rc2] sometimes hangs with black screen when resuming from suspend or hibernation (was: Re: Linux 4.19-rc2)

[Martin Steigerwald]

Cc´d Intel Gfx mailing list, in case somebody there knows something:

Cc´d Thorsten for regression tracking… forgot initially. Can also open 
bug report at a later time but so far I cannot provide many details 
about the issue.

Rafael J. Wysocki - 11.09.18, 10:17:
> On Tue, Sep 11, 2018 at 10:01 AM Martin Steigerwald 
 wrote:
> > Hi.
> > 
> > Linus Torvalds - 02.09.18, 23:45:
> > > As usual, the rc2 release is pretty small. People are taking a
> > 
> > With 4.19-rc2 this ThinkPad T520 with i5 Sandybrdige sometimes hangs
> > with black screen when resuming from suspend or hibernation.  With
> > 4.18.1 it did not. Of course there have been userspace related
> > updates that could be related.
> > 
> > I currently have no time to dig into this and on this production
> > laptop I generally do not do bisects between major kernel releases.
> > So currently I only answer questions that do not require much time
> > to answer.
> > 
> > For now I switched back to 4.18. If that is stable – and thus likely
> > no userspace component is related –, I go with 4.19-rc3 or whatever
> > is most recent version to see if the issue has been fixed already.
> 
> There were almost no general changes related to system-wide PM between
> 4.18 and current, so I would suspect one of the device drivers or the
> x86 core.  It also may be something like CPU online/offline, however.

I see. I wondered about intel-gfx driver already. Of course it could 
also be something else.

I forgot to mention: The mouse pointer was visible, but the screen 
remained black. That may again point away from Intel gfx driver. There 
has been a MESA update in between in userspace.

Currently running 4.18.7 to make sure it is no userspace issue.

Thanks,
-- 
Martin


___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [REGRESSION] Black screen after switching desktop session (was: Re: Linux 4.10-rc5)

[Martin Steigerwald]

Am Mittwoch, 1. Februar 2017, 14:11:22 CET schrieb David Weinehall:
> On Wed, Jan 25, 2017 at 01:10:26PM +0100, Martin Steigerwald wrote:
> > Am Sonntag, 22. Januar 2017, 13:32:08 CET schrieb Linus Torvalds:
> > > Things seem to be calming down a bit, and everything looks nominal.
> > > 
> > > There's only been about 250 changes (not counting merges) in the last
> > > week, and the diffstat touches less than 300 files (with drivers and
> > > architecture updates being the bulk, but there's tooling, networking
> > > and filesystems in there too).
> > > 
> > > So keep testing, and I think we'll have a regular release schedule.
> > 
> > Testing this is no fun:
> > 
> > Bug 99533 - black screen after switching session
> > https://bugs.freedesktop.org/99533
> > 
> > 
> > This after GPU hang/lockups with Kernel 4.9 reported as for example:
> > 
> > Bug 98922 - [snb] GPU hang on PlaneShift
> > https://bugs.freedesktop.org/98922
> > 
> > Which may be a duplicate of #98747, #98794, #98860, #98891, #98288.
> > 
> > 
> > I am back at kernel 4.8.15 as I need this machine for production work.
> > 
> > Sometimes I wish for a microkernel that might be able to reincarnate
> > drivers that hang or do wierd things like that. That may at least give a
> > way to actually do some debugging or even get the desktop session back
> > without loosing its state. Especially for graphics drivers and
> > hibernating/resuming from hibernations which also occasionally fails –
> > again without leaving a way to interact with the machine to do further
> > debugging. Linux kernel usually just crashes completely, not even a ping
> > or ssh possible, or it at least stuck with a black display without any
> > way to restart the graphics driver cause it seems to be in some undefined
> > state. Combined with occasionally happening bugs this makes triaging bugs
> > time consuming and risky. I do like to help testing, but maybe its time
> > to just switch to distro kernels and be done about it, as I regularily
> > come across bugs that are too expensive for me to triage.
> > 
> > Please understand that I am not willing to bisect these occasionally
> > happening bugs with have the potential to cause data loss due to having
> > to switch off the machine forcefully. Fortunately at least KMail saves a
> > mail I write from time to time and also Kate does swap files.
> > 
> > I am also a bit unwilling to do further debugging of this one as I usually
> > use two sessions when I am at work and I risk loosing data I work on.
> > But… at least with this issue it seems I would have a way to SSH into the
> > machine before kicking it.
> > 
> > 
> > I am dissatisfied with the state of the Intel graphics driver on this
> > ThinkPad T520 with Sandybridge since kernel 4.9 and wonder whether you
> > guys at Intel really test things with older hardware versions.
> 
> Yes, we do. But for practical reasons we can only do testing for things
> that we actually have testcases for, and obviously we don't have the
> manpower to actually do *manual* testing on every platform, so issues
> for older platforms that are only triggered by manual interaction tend
> to slip under the radar.
> 
> We have a testfarm that tests every nightly build on all platforms we
> have test machines for. The testcases are publicly available here:
> 
> https://cgit.freedesktop.org/xorg/app/intel-gpu-tools/
> 
> Obviously most of our manpower is spent on development and testing for
> current and future platforms, so for issues that involve older platforms,
> especially something as old as Sandybridge (which is, by now, 6 years old)
> we are happy for help with testing and bisection.
> 
> If the issues are specific to certain subsets of a platform it obviously
> gets even more complex; it'd be a combinatorial nightmare to build a
> testfarm that could test every variation of every platform.
> 
> If I got the count right the i915 driver supports around a hundred
> different varieties of Intel graphics; combine that with the number of
> different displays people connect, the number of eDP display that the
> vendors connect, the different BIOSes that vendors use, etc., and I
> think you'll begin to see what we're combating) -- to make things even
> more complex you can connect several displays to each graphics card
> (possibly via adapters), displays that don't always meet the standards
> that they claim to meet.  Due to limited room we are also a bit limited
> when it comes to testing with multi-monitor setups.
> 
> This is why any help is welcome

[Intel-gfx] [REGRESSION] Black screen after switching desktop session (was: Re: Linux 4.10-rc5)

[Martin Steigerwald]

Am Sonntag, 22. Januar 2017, 13:32:08 CET schrieb Linus Torvalds:
> Things seem to be calming down a bit, and everything looks nominal.
> 
> There's only been about 250 changes (not counting merges) in the last
> week, and the diffstat touches less than 300 files (with drivers and
> architecture updates being the bulk, but there's tooling, networking
> and filesystems in there too).
> 
> So keep testing, and I think we'll have a regular release schedule.

Testing this is no fun:

Bug 99533 - black screen after switching session
https://bugs.freedesktop.org/99533


This after GPU hang/lockups with Kernel 4.9 reported as for example:

Bug 98922 - [snb] GPU hang on PlaneShift
https://bugs.freedesktop.org/98922

Which may be a duplicate of #98747, #98794, #98860, #98891, #98288.


I am back at kernel 4.8.15 as I need this machine for production work.

Sometimes I wish for a microkernel that might be able to reincarnate drivers 
that hang or do wierd things like that. That may at least give a way to 
actually do some debugging or even get the desktop session back without 
loosing its state. Especially for graphics drivers and hibernating/resuming 
from hibernations which also occasionally fails – again without leaving a way 
to interact with the machine to do further debugging. Linux kernel usually 
just crashes completely, not even a ping or ssh possible, or it at least stuck 
with a black display without any way to restart the graphics driver cause it 
seems to be in some undefined state. Combined with occasionally happening bugs 
this makes triaging bugs time consuming and risky. I do like to help testing, 
but maybe its time to just switch to distro kernels and be done about it, as I 
regularily come across bugs that are too expensive for me to triage.

Please understand that I am not willing to bisect these occasionally happening 
bugs with have the potential to cause data loss due to having to switch off 
the machine forcefully. Fortunately at least KMail saves a mail I write from 
time to time and also Kate does swap files.

I am also a bit unwilling to do further debugging of this one as I usually use 
two sessions when I am at work and I risk loosing data I work on. But… at 
least with this issue it seems I would have a way to SSH into the machine 
before kicking it.


I am dissatisfied with the state of the Intel graphics driver on this ThinkPad 
T520 with Sandybridge since kernel 4.9 and wonder whether you guys at Intel 
really test things with older hardware versions.

Thanks,
-- 
Martin
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [REGRESSION] Linux 4.9-rc4: gfx glitches on Intel Sandybridge (was: Re: Linux 4.9-rc4)

[Martin Steigerwald]

Am Mittwoch, 9. November 2016, 11:42:36 CET schrieb Jani Nikula:
> > *However*, I got a soft freeze and a hard freeze (well after about a
> > minute I gave up and rebooted by pressing power button long enough to
> > forcefully switch off the laptop) when playing PlaneShift using
> > drm-intel-fixes branch.
> > 
> > Unfortunately I have no further time to debug any of this week, but it
> > seems not all fixes are there are ready for next stable kernel.
> 
> Current drm-intel-fixes is just six commits on top of -rc4, and it's
> very hard for me to believe any of those would cause the symptoms you
> see. I presume the problem, whatever it is, is already in -rc4.
> 
> That, of course, is not a happy thing per se, but please don't block the
> current batch of fixes by making unsubstantiated claims. Please do file
> a bug about that issue over at [1] so we don't hijack this thread.

You are right. I have no comparison with 4.9-rc4 due to the graphics glitches 
I had in it.

-- 
Martin
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [REGRESSION] Linux 4.9-rc4: gfx glitches on Intel Sandybridge (was: Re: Linux 4.9-rc4)

[Martin Steigerwald]

Am Dienstag, 8. November 2016, 16:17:59 CET schrieb Martin Steigerwald:
> Am Dienstag, 8. November 2016, 16:11:31 CET schrieb Martin Steigerwald:
> > Am Montag, 7. November 2016, 19:09:36 CET schrieb Jani Nikula:
> > > On Mon, 07 Nov 2016, Martin Steigerwald <mar...@lichtvoll.de> wrote:
> > > > It is also the same kind of corruptions as shown in
> > > > 
> > > > [Bug 177701] warning in intel_dp_aux_transfer
> > > > https://bugzilla.kernel.org/show_bug.cgi?id=177701
> > > > 
> > > > Just compare
> > > > 
> > > > https://bugzilla.kernel.org/attachment.cgi?id=241801
> > > > 
> > > > with
> > > > 
> > > > https://martin-steigerwald.de/tmp/display-issues-with-kernel-4.9-rc4.p
> > > > ng
> > > > 
> > > > 
> > > > However that bug report links to
> > > > 
> > > > https://bugs.freedesktop.org/show_bug.cgi?id=97344
> > > > 
> > > > yet the patch mentioned in there does not fix the issue. So I wonder
> > > > whether bug #97344 and bug #177701 are really the same.
> > > 
> > > They are the same, it's just that #177701 conflates two issues, a
> > > warning (tracked at fdo #973449) and a graphics corruption. The latter
> > > appears to be https://bugs.freedesktop.org/show_bug.cgi?id=98402.
> > > 
> > > The fix has now been pushed to drm-intel-fixes branch of
> > > http://cgit.freedesktop.org/drm-intel, which is -rc4 plus half a dozen
> > > latest fixes. Please try that and report back.
> > 
> > For now commit 54905ab5fe7aa453610e31cec640e528aaedb2e2 of drm-intel-fixes
> 
> I ment not exactly this commit, but this is the last commit in the branch as
> I compiled the kernel.
> 
> > branch seems to work okay. I can only test with laptop display at the
> > moment. But I will test with external display this evening – in case the
> > issue at hand is DisplayPort related.

Also no graphics glitches with external DisplayPort connected display.

*However*, I got a soft freeze and a hard freeze (well after about a minute I 
gave up and rebooted by pressing power button long enough to forcefully switch 
off the laptop) when playing PlaneShift using drm-intel-fixes branch.

Unfortunately I have no further time to debug any of this week, but it seems 
not all fixes are there are ready for next stable kernel.

Ciao,
Martin

> > I will add this information to fdo bug 98402 as well.
> > 
> > Thanks,
> > Martin
> > 
> > > > Of course I can report a bug at fdo as well, but I am a bit confused
> > > > whether it may not already have been reported. Well I hope I get a
> > > > chance to report it there as well and you get to decide.
> > > 
> > > If drm-intel-fixes doesn't fix the issue for you, please file a *new*
> > > bug over at the freedesktop.org bugzilla.
> > > 
> > > BR,
> > > Jani.


-- 
Martin
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [REGRESSION] Linux 4.9-rc4: gfx glitches on Intel Sandybridge (was: Re: Linux 4.9-rc4)

[Martin Steigerwald]

Am Dienstag, 8. November 2016, 16:11:31 CET schrieb Martin Steigerwald:
> Am Montag, 7. November 2016, 19:09:36 CET schrieb Jani Nikula:
> > On Mon, 07 Nov 2016, Martin Steigerwald <mar...@lichtvoll.de> wrote:
> > > It is also the same kind of corruptions as shown in
> > > 
> > > [Bug 177701] warning in intel_dp_aux_transfer
> > > https://bugzilla.kernel.org/show_bug.cgi?id=177701
> > > 
> > > Just compare
> > > 
> > > https://bugzilla.kernel.org/attachment.cgi?id=241801
> > > 
> > > with
> > > 
> > > https://martin-steigerwald.de/tmp/display-issues-with-kernel-4.9-rc4.png
> > > 
> > > 
> > > However that bug report links to
> > > 
> > > https://bugs.freedesktop.org/show_bug.cgi?id=97344
> > > 
> > > yet the patch mentioned in there does not fix the issue. So I wonder
> > > whether bug #97344 and bug #177701 are really the same.
> > 
> > They are the same, it's just that #177701 conflates two issues, a
> > warning (tracked at fdo #973449) and a graphics corruption. The latter
> > appears to be https://bugs.freedesktop.org/show_bug.cgi?id=98402.
> > 
> > The fix has now been pushed to drm-intel-fixes branch of
> > http://cgit.freedesktop.org/drm-intel, which is -rc4 plus half a dozen
> > latest fixes. Please try that and report back.
> 
> For now commit 54905ab5fe7aa453610e31cec640e528aaedb2e2 of drm-intel-fixes

I ment not exactly this commit, but this is the last commit in the branch as I 
compiled the kernel.

> branch seems to work okay. I can only test with laptop display at the
> moment. But I will test with external display this evening – in case the
> issue at hand is DisplayPort related.
> 
> I will add this information to fdo bug 98402 as well.
> 
> Thanks,
> Martin
> 
> > > Of course I can report a bug at fdo as well, but I am a bit confused
> > > whether it may not already have been reported. Well I hope I get a
> > > chance to report it there as well and you get to decide.
> > 
> > If drm-intel-fixes doesn't fix the issue for you, please file a *new*
> > bug over at the freedesktop.org bugzilla.
> > 
> > BR,
> > Jani.


-- 
Martin
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [REGRESSION] Linux 4.9-rc4: gfx glitches on Intel Sandybridge (was: Re: Linux 4.9-rc4)

[Martin Steigerwald]

Am Montag, 7. November 2016, 19:09:36 CET schrieb Jani Nikula:
> On Mon, 07 Nov 2016, Martin Steigerwald <mar...@lichtvoll.de> wrote:
> > It is also the same kind of corruptions as shown in
> > 
> > [Bug 177701] warning in intel_dp_aux_transfer
> > https://bugzilla.kernel.org/show_bug.cgi?id=177701
> > 
> > Just compare
> > 
> > https://bugzilla.kernel.org/attachment.cgi?id=241801
> > 
> > with
> > 
> > https://martin-steigerwald.de/tmp/display-issues-with-kernel-4.9-rc4.png
> > 
> > 
> > However that bug report links to
> > 
> > https://bugs.freedesktop.org/show_bug.cgi?id=97344
> > 
> > yet the patch mentioned in there does not fix the issue. So I wonder
> > whether bug #97344 and bug #177701 are really the same.
> 
> They are the same, it's just that #177701 conflates two issues, a
> warning (tracked at fdo #973449) and a graphics corruption. The latter
> appears to be https://bugs.freedesktop.org/show_bug.cgi?id=98402.
> 
> The fix has now been pushed to drm-intel-fixes branch of
> http://cgit.freedesktop.org/drm-intel, which is -rc4 plus half a dozen
> latest fixes. Please try that and report back.

For now commit 54905ab5fe7aa453610e31cec640e528aaedb2e2 of drm-intel-fixes 
branch seems to work okay. I can only test with laptop display at the moment. 
But I will test with external display this evening – in case the issue at hand 
is DisplayPort related.

I will add this information to fdo bug 98402 as well.

Thanks,
Martin

> > Of course I can report a bug at fdo as well, but I am a bit confused
> > whether it may not already have been reported. Well I hope I get a
> > chance to report it there as well and you get to decide.
> 
> If drm-intel-fixes doesn't fix the issue for you, please file a *new*
> bug over at the freedesktop.org bugzilla.
> 
> BR,
> Jani.


-- 
Martin
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [REGRESSION] Linux 4.9-rc4: gfx glitches on Intel Sandybridge (was: Re: Linux 4.9-rc4)

[Martin Steigerwald]

Am Montag, 7. November 2016, 19:09:36 CET schrieb Jani Nikula:
> On Mon, 07 Nov 2016, Martin Steigerwald <mar...@lichtvoll.de> wrote:
> > It is also the same kind of corruptions as shown in
> > 
> > [Bug 177701] warning in intel_dp_aux_transfer
> > https://bugzilla.kernel.org/show_bug.cgi?id=177701
> > 
> > Just compare
> > 
> > https://bugzilla.kernel.org/attachment.cgi?id=241801
> > 
> > with
> > 
> > https://martin-steigerwald.de/tmp/display-issues-with-kernel-4.9-rc4.png
> > 
> > 
> > However that bug report links to
> > 
> > https://bugs.freedesktop.org/show_bug.cgi?id=97344
> > 
> > yet the patch mentioned in there does not fix the issue. So I wonder
> > whether bug #97344 and bug #177701 are really the same.
> 
> They are the same, it's just that #177701 conflates two issues, a
> warning (tracked at fdo #973449) and a graphics corruption. The latter
> appears to be https://bugs.freedesktop.org/show_bug.cgi?id=98402.
> 
> The fix has now been pushed to drm-intel-fixes branch of
> http://cgit.freedesktop.org/drm-intel, which is -rc4 plus half a dozen
> latest fixes. Please try that and report back.

Thanks for clearing that up, Jani.

I think I get a chance to compile from drm-intel tomorrow and test it. If it 
just happens on external displays – I didn´t actually check this – I can only 
test it in the evening.
 
> > Of course I can report a bug at fdo as well, but I am a bit confused
> > whether it may not already have been reported. Well I hope I get a
> > chance to report it there as well and you get to decide.
> 
> If drm-intel-fixes doesn't fix the issue for you, please file a *new*
> bug over at the freedesktop.org bugzilla.

Will do.

Thanks,
-- 
Martin
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [REGRESSION] Linux 4.9-rc4: gfx glitches on Intel Sandybridge (was: Re: Linux 4.9-rc4)

[Martin Steigerwald]

Am Montag, 7. November 2016, 13:04:16 CET schrieb Jani Nikula:
> On Sun, 06 Nov 2016, Martin Steigerwald <mar...@lichtvoll.de> wrote:
> > Hi.
> > 
> > Am Samstag, 5. November 2016, 16:46:33 CET schrieb Linus Torvalds:
> >> So it's once again a Saturday afternoon rather than Sunday, this time
> >> because I felt this rc was already big enough.
> > 
> > With kernel 4.9-rc4 I saw gfx corruptions like
> > 
> > https://martin-steigerwald.de/tmp/display-issues-with-kernel-4.9-rc4.png
> 
> Is this the same issue or a different issue from [1]? Since you mention
> -rc4, was this introduced in -rc4, or earlier?

Yes, the gfx corruption look similar. So I bet it is the same issue as in [1].


It is also the same kind of corruptions as shown in

[Bug 177701] warning in intel_dp_aux_transfer
https://bugzilla.kernel.org/show_bug.cgi?id=177701

Just compare

https://bugzilla.kernel.org/attachment.cgi?id=241801

with 

https://martin-steigerwald.de/tmp/display-issues-with-kernel-4.9-rc4.png


However that bug report links to

https://bugs.freedesktop.org/show_bug.cgi?id=97344

yet the patch mentioned in there does not fix the issue. So I wonder whether 
bug #97344 and bug #177701 are really the same.

> Please file a bug over at [2]. One issue per bug if this is different
> from [1].

As #177701 seem to have the same corruptions, yet I do not have any

merkaba:~#1> zgrep intel_dp_aux_transfer /var/log/kern.log*
merkaba:~#1>

Of course I can report a bug at fdo as well, but I am a bit confused whether 
it may not already have been reported. Well I hope I get a chance to report it 
there as well and you get to decide.

Thank you,
Martin

> [1] http://lkml.kernel.org/r/20161031215454.gb3...@suse.de
> [2]
> https://bugs.freedesktop.org/enter_bug.cgi?product=DRI=DRM/Intel
> > in Konversation, Konsole, Akregator and other KDE/Qt related apps up to
> > the
> > point of not being able to use these applications in a meaningful way.
> > 
> > I first thought this might be due to upgrading Qt from 5.6.1 to 5.7.1, yet
> > after rebooting into 4.8 Linux kernel as packaged in Debian I saw no gfx
> > glitches like that anymore.
> > 
> > Anything known about this?
> > 
> > Machine is ThinkPad T520 with Sandybridge graphics.
> > 
> > Kernel compiled with Debian distro GCC 6 but using no-pie makefile patch.
> > 
> > Next week and weekend will be pretty busy and this is a production
> > machine, so bisection or any other time-consuming work on this is out of
> > question for me. I can provide additional details in case they are easy
> > and quick enough to obtain.
> > 
> > 
> > System information (now back on 4.8 kernel):
> > 
> > # phoronix-test-suite system-info
> > 
> > Phoronix Test Suite v5.2.1
> > System Information
> > 
> > Hardware:
> > Processor: Intel Core i5-2520M @ 3.20GHz (4 Cores), Motherboard: LENOVO
> > 42433WG, Chipset: Intel 2nd Generation Core Family DRAM, Memory: 16384MB,
> > Disk: 300GB INTEL SSDSA2CW30 + 480GB Crucial_CT480M50, Graphics: Intel 2nd
> > Generation Core Family IGP, Audio: Conexant CX20590, Monitor: P24T-7 LED,
> > Network: Intel 82579LM Gigabit Connection + Intel Centrino Advanced-N 6205
> > 
> > Software:
> > OS: Debian unstable, Kernel: 4.8.0-1-amd64 (x86_64), Desktop: KDE
> > Frameworks 5, Display Server: X Server 1.18.4, Display Driver:
> > modesetting 1.18.4, OpenGL: 3.3 Mesa 12.0.3, Compiler: GCC 6.2.0
> > 20161103, File-System: btrfs, Screen Resolution: 3840x1080
> > 
> > 
> > # apt-show-versions | egrep
> > "(^libgl1-mesa-dri|^libdrm-intel1|xserver-xorg-
> > core)" | grep amd64
> > libdrm-intel1:amd64/sid 2.4.71-1 uptodate
> > libgl1-mesa-dri:amd64/sid 12.0.3-3 uptodate
> > xserver-xorg-core:amd64/sid 2:1.18.4-2 uptodate
> > 
> > 
> > Excerpt of glxinfo:
> > 
> > Extended renderer info (GLX_MESA_query_renderer):
> > Vendor: Intel Open Source Technology Center (0x8086)
> > Device: Mesa DRI Intel(R) Sandybridge Mobile  (0x126)
> > Version: 12.0.3
> > Accelerated: yes
> > Video memory: 1536MB
> > Unified memory: yes
> > Preferred profile: core (0x1)
> > Max core profile version: 3.3
> > Max compat profile version: 3.0
> > Max GLES1 profile version: 1.1
> > Max GLES[23] profile version: 3.0
> > 
> > X.org runs with modesetting driver (default was changed in Debian Sid a
> > while back).
> > 
> > Thanks,
> > ___
> > Intel-gfx mailing list
> > Intel-gfx@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/intel-gfx


-- 
Martin
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [REGRESSION] Linux 4.9-rc4: gfx glitches on Intel Sandybridge (was: Re: Linux 4.9-rc4)

[Martin Steigerwald]

Am Sonntag, 6. November 2016, 17:25:15 CET schrieb Mihai Donțu:
> On Sun, 06 Nov 2016 15:48:36 +0100 Martin Steigerwald wrote:
> > Hi.
> > 
> > Am Samstag, 5. November 2016, 16:46:33 CET schrieb Linus Torvalds:
> > > So it's once again a Saturday afternoon rather than Sunday, this time
> > > because I felt this rc was already big enough.
> > 
> > With kernel 4.9-rc4 I saw gfx corruptions like
> > 
> > https://martin-steigerwald.de/tmp/display-issues-with-kernel-4.9-rc4.png
> > 
> > in Konversation, Konsole, Akregator and other KDE/Qt related apps up to
> > the
> > point of not being able to use these applications in a meaningful way.
> > 
> > I first thought this might be due to upgrading Qt from 5.6.1 to 5.7.1, yet
> > after rebooting into 4.8 Linux kernel as packaged in Debian I saw no gfx
> > glitches like that anymore.
> > 
> > Anything known about this?
> 
> https://bugzilla.kernel.org/show_bug.cgi?id=177701
> 
> The proposed patch appears to be:
> https://patchwork.freedesktop.org/patch/116808/
> 
> Have not tested it yet.

This patch does not fix the issue for me. Still the same graphical glitches.

Thanks,
Martin

> > Machine is ThinkPad T520 with Sandybridge graphics.
> > 
> > Kernel compiled with Debian distro GCC 6 but using no-pie makefile patch.
> > 
> > Next week and weekend will be pretty busy and this is a production
> > machine, so bisection or any other time-consuming work on this is out of
> > question for me. I can provide additional details in case they are easy
> > and quick enough to obtain.
> > 
> > 
> > System information (now back on 4.8 kernel):
> > 
> > # phoronix-test-suite system-info
> > 
> > Phoronix Test Suite v5.2.1
> > System Information
> > 
> > Hardware:
> > Processor: Intel Core i5-2520M @ 3.20GHz (4 Cores), Motherboard: LENOVO
> > 42433WG, Chipset: Intel 2nd Generation Core Family DRAM, Memory: 16384MB,
> > Disk: 300GB INTEL SSDSA2CW30 + 480GB Crucial_CT480M50, Graphics: Intel 2nd
> > Generation Core Family IGP, Audio: Conexant CX20590, Monitor: P24T-7 LED,
> > Network: Intel 82579LM Gigabit Connection + Intel Centrino Advanced-N 6205
> > 
> > Software:
> > OS: Debian unstable, Kernel: 4.8.0-1-amd64 (x86_64), Desktop: KDE
> > Frameworks 5, Display Server: X Server 1.18.4, Display Driver:
> > modesetting 1.18.4, OpenGL: 3.3 Mesa 12.0.3, Compiler: GCC 6.2.0
> > 20161103, File-System: btrfs, Screen Resolution: 3840x1080
> > 
> > 
> > # apt-show-versions | egrep
> > "(^libgl1-mesa-dri|^libdrm-intel1|xserver-xorg-
> > core)" | grep amd64
> > libdrm-intel1:amd64/sid 2.4.71-1 uptodate
> > libgl1-mesa-dri:amd64/sid 12.0.3-3 uptodate
> > xserver-xorg-core:amd64/sid 2:1.18.4-2 uptodate
> > 
> > 
> > Excerpt of glxinfo:
> > 
> > Extended renderer info (GLX_MESA_query_renderer):
> > Vendor: Intel Open Source Technology Center (0x8086)
> > Device: Mesa DRI Intel(R) Sandybridge Mobile  (0x126)
> > Version: 12.0.3
> > Accelerated: yes
> > Video memory: 1536MB
> > Unified memory: yes
> > Preferred profile: core (0x1)
> > Max core profile version: 3.3
> > Max compat profile version: 3.0
> > Max GLES1 profile version: 1.1
> > Max GLES[23] profile version: 3.0
> > 
> > X.org runs with modesetting driver (default was changed in Debian Sid a
> > while back).


-- 
Martin
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [REGRESSION] Linux 4.9-rc4: gfx glitches on Intel Sandybridge (was: Re: Linux 4.9-rc4)

[Martin Steigerwald]

Am Sonntag, 6. November 2016, 17:25:15 CET schrieb Mihai Donțu:
> On Sun, 06 Nov 2016 15:48:36 +0100 Martin Steigerwald wrote:
> > Hi.
> > 
> > Am Samstag, 5. November 2016, 16:46:33 CET schrieb Linus Torvalds:
> > > So it's once again a Saturday afternoon rather than Sunday, this time
> > > because I felt this rc was already big enough.
> > 
> > With kernel 4.9-rc4 I saw gfx corruptions like
> > 
> > https://martin-steigerwald.de/tmp/display-issues-with-kernel-4.9-rc4.png
> > 
> > in Konversation, Konsole, Akregator and other KDE/Qt related apps up to
> > the
> > point of not being able to use these applications in a meaningful way.
> > 
> > I first thought this might be due to upgrading Qt from 5.6.1 to 5.7.1, yet
> > after rebooting into 4.8 Linux kernel as packaged in Debian I saw no gfx
> > glitches like that anymore.
> > 
> > Anything known about this?
> 
> https://bugzilla.kernel.org/show_bug.cgi?id=177701
> 
> The proposed patch appears to be:
> https://patchwork.freedesktop.org/patch/116808/
> 
> Have not tested it yet.

Thank you.

It applies cleanly. I think I get a chance to test it this week.

Thanks,
Martin

> > Machine is ThinkPad T520 with Sandybridge graphics.
> > 
> > Kernel compiled with Debian distro GCC 6 but using no-pie makefile patch.
> > 
> > Next week and weekend will be pretty busy and this is a production
> > machine, so bisection or any other time-consuming work on this is out of
> > question for me. I can provide additional details in case they are easy
> > and quick enough to obtain.
> > 
> > 
> > System information (now back on 4.8 kernel):
> > 
> > # phoronix-test-suite system-info
> > 
> > Phoronix Test Suite v5.2.1
> > System Information
> > 
> > Hardware:
> > Processor: Intel Core i5-2520M @ 3.20GHz (4 Cores), Motherboard: LENOVO
> > 42433WG, Chipset: Intel 2nd Generation Core Family DRAM, Memory: 16384MB,
> > Disk: 300GB INTEL SSDSA2CW30 + 480GB Crucial_CT480M50, Graphics: Intel 2nd
> > Generation Core Family IGP, Audio: Conexant CX20590, Monitor: P24T-7 LED,
> > Network: Intel 82579LM Gigabit Connection + Intel Centrino Advanced-N 6205
> > 
> > Software:
> > OS: Debian unstable, Kernel: 4.8.0-1-amd64 (x86_64), Desktop: KDE
> > Frameworks 5, Display Server: X Server 1.18.4, Display Driver:
> > modesetting 1.18.4, OpenGL: 3.3 Mesa 12.0.3, Compiler: GCC 6.2.0
> > 20161103, File-System: btrfs, Screen Resolution: 3840x1080
> > 
> > 
> > # apt-show-versions | egrep
> > "(^libgl1-mesa-dri|^libdrm-intel1|xserver-xorg-
> > core)" | grep amd64
> > libdrm-intel1:amd64/sid 2.4.71-1 uptodate
> > libgl1-mesa-dri:amd64/sid 12.0.3-3 uptodate
> > xserver-xorg-core:amd64/sid 2:1.18.4-2 uptodate
> > 
> > 
> > Excerpt of glxinfo:
> > 
> > Extended renderer info (GLX_MESA_query_renderer):
> > Vendor: Intel Open Source Technology Center (0x8086)
> > Device: Mesa DRI Intel(R) Sandybridge Mobile  (0x126)
> > Version: 12.0.3
> > Accelerated: yes
> > Video memory: 1536MB
> > Unified memory: yes
> > Preferred profile: core (0x1)
> > Max core profile version: 3.3
> > Max compat profile version: 3.0
> > Max GLES1 profile version: 1.1
> > Max GLES[23] profile version: 3.0
> > 
> > X.org runs with modesetting driver (default was changed in Debian Sid a
> > while back).


-- 
Martin
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [REGRESSION] Linux 4.9-rc4: gfx glitches on Intel Sandybridge (was: Re: Linux 4.9-rc4)

[Martin Steigerwald]

Hi.

Am Samstag, 5. November 2016, 16:46:33 CET schrieb Linus Torvalds:
> So it's once again a Saturday afternoon rather than Sunday, this time
> because I felt this rc was already big enough.

With kernel 4.9-rc4 I saw gfx corruptions like

https://martin-steigerwald.de/tmp/display-issues-with-kernel-4.9-rc4.png

in Konversation, Konsole, Akregator and other KDE/Qt related apps up to the 
point of not being able to use these applications in a meaningful way.

I first thought this might be due to upgrading Qt from 5.6.1 to 5.7.1, yet 
after rebooting into 4.8 Linux kernel as packaged in Debian I saw no gfx 
glitches like that anymore.

Anything known about this?

Machine is ThinkPad T520 with Sandybridge graphics.

Kernel compiled with Debian distro GCC 6 but using no-pie makefile patch.

Next week and weekend will be pretty busy and this is a production machine, so 
bisection or any other time-consuming work on this is out of question for me. 
I can provide additional details in case they are easy and quick enough to 
obtain.


System information (now back on 4.8 kernel):

# phoronix-test-suite system-info

Phoronix Test Suite v5.2.1
System Information

Hardware:
Processor: Intel Core i5-2520M @ 3.20GHz (4 Cores), Motherboard: LENOVO 
42433WG, Chipset: Intel 2nd Generation Core Family DRAM, Memory: 16384MB, 
Disk: 300GB INTEL SSDSA2CW30 + 480GB Crucial_CT480M50, Graphics: Intel 2nd 
Generation Core Family IGP, Audio: Conexant CX20590, Monitor: P24T-7 LED, 
Network: Intel 82579LM Gigabit Connection + Intel Centrino Advanced-N 6205

Software:
OS: Debian unstable, Kernel: 4.8.0-1-amd64 (x86_64), Desktop: KDE Frameworks 
5, Display Server: X Server 1.18.4, Display Driver: modesetting 1.18.4, 
OpenGL: 3.3 Mesa 12.0.3, Compiler: GCC 6.2.0 20161103, File-System: btrfs, 
Screen Resolution: 3840x1080


# apt-show-versions | egrep "(^libgl1-mesa-dri|^libdrm-intel1|xserver-xorg-
core)" | grep amd64
libdrm-intel1:amd64/sid 2.4.71-1 uptodate
libgl1-mesa-dri:amd64/sid 12.0.3-3 uptodate
xserver-xorg-core:amd64/sid 2:1.18.4-2 uptodate


Excerpt of glxinfo:

Extended renderer info (GLX_MESA_query_renderer):
Vendor: Intel Open Source Technology Center (0x8086)
Device: Mesa DRI Intel(R) Sandybridge Mobile  (0x126)
Version: 12.0.3
Accelerated: yes
Video memory: 1536MB
Unified memory: yes
Preferred profile: core (0x1)
Max core profile version: 3.3
Max compat profile version: 3.0
Max GLES1 profile version: 1.1
Max GLES[23] profile version: 3.0

X.org runs with modesetting driver (default was changed in Debian Sid a while 
back).

Thanks,
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

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

[Martin Steigerwald]

Am Mittwoch, 14. September 2016, 14:14:35 CEST schrieb Jani Nikula:
> On Wed, 14 Sep 2016, Jani Nikula  wrote:
> > On Wed, 14 Sep 2016, Pavel Machek  wrote:
> >> For the "sometimes need xrandr after resume": I don't think I can
> >> bisect that. It only happens sometimes :-(. But there's something
> >> helpful in the logs:
> >> 
> >> [ 1856.218863] [drm:drm_edid_block_valid] *ERROR* EDID checksum is
> >> invalid, remainder is 130
> >> [ 1856.218863] Raw EDID:
> >> [ 1856.218863] 00 ff ff ff ff ff ff 00 ff ff ff ff ff ff ff ff
> >> [ 1856.218863] ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> >> [ 1856.218863] ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> >> [ 1856.218863] ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> >> [ 1856.218863] ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> >> [ 1856.218863] ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> >> [ 1856.218863] ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> >> [ 1856.218863] ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> >> [ 1856.218863] [drm:drm_edid_block_valid] *ERROR* EDID checksum is
> >> invalid, remainder is 130
> >> [ 1856.218863] Raw EDID:
> >> [ 1856.218863] 00 ff ff ff ff ff ff 00 ff ff ff ff ff ff ff ff
> >> [ 1856.218863] ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> >> [ 1856.218863] ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> >> [ 1856.218863] ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> >> [ 1856.218863] ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> >> [ 1856.218863] ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> >> [ 1856.218863] ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> >> [ 1856.218863] ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> >> [ 1856.218863] [drm:drm_edid_block_valid] *ERROR* EDID checksum is
> >> invalid, remainder is 130
> >> [ 1856.218863] Raw EDID:
> >> [ 1856.218863] 00 ff ff ff ff ff ff 00 ff ff ff ff ff ff ff ff
> >> [ 1856.218863] ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> >> [ 1856.218863] ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> >> [ 1856.218863] ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> >> [ 1856.218863] ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> >> [ 1856.218863] ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> >> [ 1856.218863] ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> >> [ 1856.218863] ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> >> [ 1856.218863] [drm:drm_edid_block_valid] *ERROR* EDID checksum is
> >> invalid, remainder is 130
> >> [ 1856.218863] Raw EDID:
> >> [ 1856.218863] 00 ff ff ff ff ff ff 00 ff ff ff ff ff ff ff ff
> >> [ 1856.218863] ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> >> [ 1856.218863] ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> >> [ 1856.218863] ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> >> [ 1856.218863] ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> >> [ 1856.218863] ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> >> [ 1856.218863] ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> >> [ 1856.218863] ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> >> [ 1856.218863] i915 :00:02.0: HDMI-A-1: EDID block 0 invalid.
> > 
> > Pavel, Martin, do you always see this when the display fails to resume?
> > Is it HDMI/DVI for both of you?
> 
> Please try this patch, backported from our next.

Was busy up to now, and weekend also quite full already.

Thing is: I didn´t see this blank screen thing with 4.8-rc6 so far. And I did 
not have above EDID stuff in my log either. So I first wait whether I see 
blank screen again and if so, then know that a test would make sense. Maybe I 
see it before I complete a rc7 or rc8 (if there will be one), then I would 
include the patch of course.

-- 
Martin
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

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

[Martin Steigerwald]

Am Mittwoch, 14. September 2016, 12:17:53 CEST schrieb Jani Nikula:
> On Wed, 14 Sep 2016, Pavel Machek  wrote:
> > For the "sometimes need xrandr after resume": I don't think I can
> > bisect that. It only happens sometimes :-(. But there's something
> > helpful in the logs:
> > 
> > [ 1856.218863] [drm:drm_edid_block_valid] *ERROR* EDID checksum is
> > invalid, remainder is 130
> > [ 1856.218863] Raw EDID:
> > [ 1856.218863] 00 ff ff ff ff ff ff 00 ff ff ff ff ff ff ff ff
> > [ 1856.218863] ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> > [ 1856.218863] ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> > [ 1856.218863] ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> > [ 1856.218863] ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> > [ 1856.218863] ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> > [ 1856.218863] ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> > [ 1856.218863] ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> > [ 1856.218863] [drm:drm_edid_block_valid] *ERROR* EDID checksum is
> > invalid, remainder is 130
> > [ 1856.218863] Raw EDID:
> > [ 1856.218863] 00 ff ff ff ff ff ff 00 ff ff ff ff ff ff ff ff
> > [ 1856.218863] ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> > [ 1856.218863] ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> > [ 1856.218863] ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> > [ 1856.218863] ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> > [ 1856.218863] ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> > [ 1856.218863] ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> > [ 1856.218863] ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> > [ 1856.218863] [drm:drm_edid_block_valid] *ERROR* EDID checksum is
> > invalid, remainder is 130
> > [ 1856.218863] Raw EDID:
> > [ 1856.218863] 00 ff ff ff ff ff ff 00 ff ff ff ff ff ff ff ff
> > [ 1856.218863] ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> > [ 1856.218863] ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> > [ 1856.218863] ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> > [ 1856.218863] ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> > [ 1856.218863] ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> > [ 1856.218863] ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> > [ 1856.218863] ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> > [ 1856.218863] [drm:drm_edid_block_valid] *ERROR* EDID checksum is
> > invalid, remainder is 130
> > [ 1856.218863] Raw EDID:
> > [ 1856.218863] 00 ff ff ff ff ff ff 00 ff ff ff ff ff ff ff ff
> > [ 1856.218863] ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> > [ 1856.218863] ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> > [ 1856.218863] ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> > [ 1856.218863] ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> > [ 1856.218863] ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> > [ 1856.218863] ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> > [ 1856.218863] ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> > [ 1856.218863] i915 :00:02.0: HDMI-A-1: EDID block 0 invalid.
> 
> Pavel, Martin, do you always see this when the display fails to resume?
> Is it HDMI/DVI for both of you?

According to zgrep "EDID" /var/log/kern* I don´t have any EDID related error 
messages. I am using DisplayPort cable via ThinkPad Minidock Plus (dock for 
ThinkPad T520) or what it was named.

-- 
Martin
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

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

[Martin Steigerwald]

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 (rev 03)

00:02.0 VGA compatible controller [0300]: Intel Corporation 2nd Generation 
Core Processor Family Integrated Graphics Controller [8086:0126] (rev 09)

Phoronix Test Suite system-info:

System Information

Hardware:
Processor: Intel Core i5-2520M @ 3.20GHz (4 Cores), Motherboard: LENOVO 
42433WG, Chipset: Intel 2nd Generation Core Family DRAM, Memory: 16384MB, 
Disk: 300GB INTEL SSDSA2CW30 + 480GB Crucial_CT480M50, Graphics: Intel 2nd 
Generation Core Family IGP, Audio: Conexant CX20590, Monitor: P24T-7 LED, 
Network: Intel 82579LM Gigabit Connection + Intel Centrino Advanced-N 6205

Software:
OS: Debian unstable, Kernel: 4.8.0-rc6-tp520-btrfstrim+ (x86_64), Desktop: KDE 
Frameworks 5, Display Server: X Server 1.18.4, Display Driver: modesetting 
1.18.4, OpenGL: 3.3 Mesa 12.0.2, Compiler: GCC 6.2.0 20160901, File-System: 
btrfs, Screen Resolution: 3840x1080

> 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 secondary monitor (VGA). Running
> "xrandr" fixes that.

I have seen this in 4.8 up to rc5 as well. I am not sure yet about rc6 which I 
am currently running.

I didn´t run xrandr by hand. But I ran systemsettings, dragged the second, 
deactivated external display back beneath the internal laptop display, 
activated it again and applied this changes. I think this has a somewhat 
similar effect as Plasma uses RANDR as well.
 
> I'll update to newer rc and see if it happens again, but if you have
> any ideas, now would be good time.

No ideas, sorry.

Thanks,
-- 
Martin
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [REGRESSION] [SNB] Scaling in VLC 2.2.2 does not work with Linux 4.6-rc2

[Martin Steigerwald]

Hello!

As I don´t know how much you use or look into the bug tracker, I just ask here 
as well.

Any idea about this one?

Bug 94978 - [SNB] Scaling in VLC 2.2.2 does not work with Linux 4.6-rc2 (edit)
https://bugs.freedesktop.org/show_bug.cgi?id=94978


Paste from report in case you prefer handling by mail:

Yesterday I took more than one hour to persuade my X86_64 Debian GNU/Linux 
Sid/Experimental system to play back a DVD. VLC 2.2.2 on that machine didn´t 
scale the video to the screen size. Also any manual zoom options did not have 
any effect.

After trying a bunch of other media players which have broken DVD menu support 
or other serious issues, I finally rebooted into a 4.5 kernel and there 
scaling in VLC 2.2.2 worked out of the box and we were finally able to watch 
the movie.

martin@merkaba:~> apt-show-versions | egrep "libva-|libva1|va-driver"
i965-va-driver:amd64/sid 1.7.0-1 uptodate
i965-va-driver:i386/sid 1.7.0-1 uptodate
libva-drm1:amd64/sid 1.7.0-1 uptodate
libva-drm1:i386 not installed
libva-glx1:amd64/sid 1.7.0-1 uptodate
libva-glx1:i386 not installed
libva-wayland1:amd64/sid 1.7.0-1 uptodate
libva-wayland1:i386 not installed
libva-x11-1:amd64/sid 1.7.0-1 uptodate
libva-x11-1:i386/sid 1.7.0-1 uptodate
libva1:amd64/sid 1.7.0-1 uptodate
libva1:i386/sid 1.7.0-1 uptodate
va-driver-all:amd64 not installed
va-driver-all:i386/sid 1.7.0-1 uptodate
vdpau-va-driver:amd64 not installed
vdpau-va-driver:i386/sid 0.7.4-4 uptodate

This happened on ThinkPad T520 on internal and external display.

martin@merkaba:~> phoronix-test-suite system-info

Phoronix Test Suite v5.2.1
System Information

Hardware:
Processor: Intel Core i5-2520M @ 3.20GHz (4 Cores), Motherboard: LENOVO 
42433WG, Chipset: Intel 2nd Generation Core Family DRAM, Memory: 16384MB, 
Disk: 300GB INTEL SSDSA2CW30 + 480GB Crucial_CT480M50, Graphics: Intel HD 3000 
(1300MHz), Audio: Conexant CX20590, Monitor: P24T-7 LED, Network: Intel 
82579LM Gigabit Connection + Intel Centrino Advanced-N 6205

Software:
OS: Debian unstable, Kernel: 4.5.0-tp520-btrfstrim+ (x86_64), Desktop: KDE 
Frameworks 5, Display Server: X Server 1.18.3, Display Driver: intel 2.99.917, 
OpenGL: 3.3 Mesa 11.1.2, Compiler: GCC 5.3.1 20160409, File-System: btrfs, 
Screen Resolution: 3840x1080

Kernels are both self-compiled. I can attach config if needed.


Hmmm, just found vainfo command, maybe the information in there help:

# vainfo
libva info: VA-API version 0.39.0
libva info: va_getDriverName() returns 0
libva info: Trying to open /usr/lib/x86_64-linux-gnu/dri/i965_drv_video.so
libva info: Found init function __vaDriverInit_0_39
libva info: va_openDriver() returns 0
vainfo: VA-API version: 0.39 (libva 1.7.0)
vainfo: Driver version: Intel i965 driver for Intel(R) Sandybridge Mobile - 
1.7.0
vainfo: Supported profile and entrypoints
  VAProfileMPEG2Simple: VAEntrypointVLD
  VAProfileMPEG2Main  : VAEntrypointVLD
  VAProfileH264ConstrainedBaseline: VAEntrypointVLD
  VAProfileH264ConstrainedBaseline: VAEntrypointEncSlice
  VAProfileH264Main   : VAEntrypointVLD
  VAProfileH264Main   : VAEntrypointEncSlice
  VAProfileH264High   : VAEntrypointVLD
  VAProfileH264High   : VAEntrypointEncSlice
  VAProfileH264StereoHigh : VAEntrypointVLD
  VAProfileVC1Simple  : VAEntrypointVLD
  VAProfileVC1Main: VAEntrypointVLD
  VAProfileVC1Advanced: VAEntrypointVLD
  VAProfileNone   : VAEntrypointVideoProc

Thanks,
-- 
Martin
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] Approximately every other day video will freeze for no reason at all and no specific time between freezes.

[Martin Steigerwald]

Hi Chris, hi Intel graphics developers,

Am Freitag, 2. Oktober 2015, 16:06:30 CEST schrieb Chris:
> To elaborate on this. The video is frozen to include the clock however I
> can move the mouse cursor around the screen. I can not however switch
> between window desktops. This happened on 28 Sept 2015 after an uptime

I have seen exactly this issue on ThinkPad T520 with Sandybridge graphics.

With one exception: At least sometimes I have been able to switch to tty1 and 
do killall -u  to get back to sddm login screen.

I didn´t do anything about it so far. Driver is running in uxa mode, cause 
with sna I experienced hard freezes with mouse freezing and even data loss. I 
lost my GPG public key ring after a hard freeze after a gpg --recv-keys 
operation (restored from backup meanwhile). This was at DebConf and a 
developer I worked with recommended me to switch from SNA to UXA. And some 
time ago I had it that kwin sometimes told me it restarted compositing due to 
a hang in the graphics driver.

I find freezing issues extremely hard to debug. First off often they happen 
when I am not willing to spend even a single minute on them. Second: What to 
do anyway? On a hard freeze, I could try Sys-Rq key combo to sync disk 
contents, and I think I may better enable it anyway to avoid data loss in 
those situations, and hope that *some* information on *why* the hard freeze 
happened still lands in kern.log or Xorg log. On soft freezes I can do 
something if I can still switch to tty1. But what? I have no idea what 
information I can gather *efficiently* to provide at least a somewhat 
meaningful initial bug report within less than 15 to 30 minutes. I don´t just 
want to do *something* in that case, but I want something that has a good 
chance on giving a real insight on why the bug is happened and a good hint at 
what can be done to fix it.

git-bisect is out of question for me for something that happens so 
irregularily. It would take an insane amount of time with running kernels that 
are probably way to unstable for production use – as it may include pre-rc1 
kernels - anyway. Even tough I go to the limits on this machine regarding 
production use, this is still a production machine and I usually wait till rc2 
kernels to try out a new kernel.

So I appreciate any pointers what to *efficiently* do about issues like this. 
In case I miss any documentated bug triaging howto please point me to it. 
Ideally some kind of bug-reporting tool would be nice. Just run a script which 
collects all data that can be helpful into a file that I can attach to a bug 
report.


That said in general I am really quite happy with the Intel drivers.


martin@merkaba:~> phoronix-test-suite system-info

Phoronix Test Suite v5.2.1
System Information

Hardware:
Processor: Intel Core i5-2520M @ 3.20GHz (4 Cores), Motherboard: LENOVO 
42433WG, Chipset: Intel 2nd Generation Core Family DRAM, Memory: 16384MB, 
Disk: 300GB INTEL SSDSA2CW30 + 480GB Crucial_CT480M50, Graphics: Intel HD 3000 
(1300MHz), Audio: Conexant CX20590, Monitor: P24T-7 LED, Network: Intel 
82579LM Gigabit Connection + Intel Centrino Advanced-N 6205

Software:
OS: Debian unstable, Kernel: 4.3.0-rc3-tp520-btrfstrim+ (x86_64), Desktop: KDE 
Frameworks 5, Display Server: X Server 1.17.2, Display Driver: intel 2.99.917, 
OpenGL: 3.3 Mesa 11.0.2, Compiler: GCC 5.2.1 20150911, File-System: btrfs, 
Screen Resolution: 3840x1080

lspci -nnv:

00:02.0 VGA compatible controller [0300]: Intel Corporation 2nd Generation 
Core Processor Family Integrated Graphics Controller [8086:0126] (rev 09) 
(prog-if 00 [VGA controller])
Subsystem: Lenovo Device [17aa:21cf]
Flags: bus master, fast devsel, latency 0, IRQ 26
Memory at f000 (64-bit, non-prefetchable) [size=4M]
Memory at e000 (64-bit, prefetchable) [size=256M]
I/O ports at 5000 [size=64]
Expansion ROM at  [disabled]
Capabilities: [90] MSI: Enable+ Count=1/1 Maskable- 64bit-
Capabilities: [d0] Power Management version 2
Capabilities: [a4] PCI Advanced Features
Kernel driver in use: i915

Ciao,
-- 
Martin
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [REGRESSION] fdo bug 86565 - black screen after resume from hibernation since linux kernel 3.18

[Martin Steigerwald]

Hi!

I reported this with fdo for intel drivers back then as

https://bugs.freedesktop.org/86565

as I thought it to likely be an intel driver bug.


As it still happens and I am not sure of that anymore, I report here as 
well. I still CC intel gfx list as well, as I didn´t get a comment on the 
debug log I attached to the bug report till now.


Since linux kernel 3.18-rc2 I sometimes get a black screen after resuming 
from hibernation via in-kernel-suspend. With 3.17 I didn't have this 
issue. Additionally, sometimes on hibernation the machine after writing 
the image does not switch off, but stays on with the power LED blinking. I 
then usually switch it off manually by pressing power button longer and it 
usually resumes just fine after it.

The first issue is most annoying and it seems they are unrelated, cause as 
I found now, the first issue happens even if the second one didn´t happen 
before. When the screen is black it takes some minutes usually and then  
it displays the lock screen again. As it doesn´t happen on every resume 
from hibernation and it may work okay for five or more attempts, bisecting 
this likely would take ages.

This is with a ThinkPad T520 with BIOS Version: 8AET63WW (1.43 ), Release 
Date: 05/08/2013. The black screen happens with 3.18-rc2 upto 3.19-rc7. 
With Intel Sandybridge graphics (no nvidia optimus).


I think it may be more of a general PM management issue, as I now heard 
the the laptop was making the usual resume audio signal *after* the black 
screen delay. Thus I thought it may be stuck in general resume.


In comment #8 I attached a debug log with no_console_suspend drm.debug=0xe 
initcall_debug as being asked for:

https://bugs.freedesktop.org/show_bug.cgi?id=86565#c8


I didn´t yet receive any comment on this.

Any further ideas?


If not I will test with 3.20-rc2 again and also try the patch Jani 
mentioned in comment #7 in case its not in there.

Thanks,
-- 
Martin 'Helios' Steigerwald - http://www.Lichtvoll.de
GPG: 03B0 0D6C 0040 0710 4AFA  B82F 991B EAAC A599 84C7
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] 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
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [REGRESSION] 3.13-rc2: locks up hard on trying to transfer a file to mmc based internal SD card slot

[Martin Steigerwald]

Am Samstag, 30. November 2013, 14:53:51 schrieb Martin Steigerwald:
 Just added linux-mmc. And I might git-bisect that at some time, but I do not
 intend to do it during my precious weekend. The chances of me bisecting it
 increase with workable suggestions on how to cut down the amount of
 iterations needed and avoid testing highly experimental between 3.12 and
 3.13-rc1 kernels on a production laptop. I may be willing to test a patch
 or two. As I see there seem to have been quite some changes in MMC
 subsystem.
 
 
 
 
 Hi!
 
 Just does that on a ThinkPad T520 with:
 
 merkaba:~ lspci -nn | grep MMC
 0d:00.0 System peripheral [0880]: Ricoh Co Ltd PCIe SDXC/MMC Host Controller
 [1180:e823] (rev 08)
 
 Mouse pointer freezes, no Ctrl-Alt-F1.

It just does that with

Linux version 3.13.0-rc6-tp520 (martin@merkaba) (gcc version 4.8.2 (Debian 
4.8.2-10) ) #41 SMP PREEMPT Mon Dec 30 13:39:07 CET 2013

as well.

But, only when trying to write a file via desktop environment via dolphin from 
KDE in that case. When I am on tty1 it seems to be stable to write to the SD 
card. But with dolphin on writing a large few files vom /usr/bin mouse pointer 
froze again. But according to harddisk led from ThinkPad T520 there has been 
some write activity afterwards. The LED also lits up for MMC card accesses. 
Still after reboot there is none of the copied files visible on the FAT32 
formatted SD card.

Thus adding Intel gfx and dri devel lists to CC.


This crashing only under GUI might still be a coindidence. I only tried once. 
But since the crash usually came almost immediately and it didn´t crash with 
reading or writing files on TTY1 and it somehow continued I/O according to 
harddisk led instead of seeming to be completely stopped… well I can try again 
to make sure. Would be good to make it crash on TTY1 since then I might see 
some kernel output.


Back to 3.12.6 for now. I just tried the same with that kernel and there the 
copying just works nice.

I can also report a bug at bugzilla.kernel.org if needed.


May comments about bisecting still applies. I do not feel comfortable with 
doing it on this production machine with production data on it… especially 
given the major block layer changes. There may be points in history were the 
kernel produces data corruption or so.

Thanks,
Martin



 
 
 merkaba:~ fdisk -l /dev/mmcblk0
 
 Disk /dev/mmcblk0: 31.4 GB, 31439454208 bytes
 255 heads, 63 sectors/track, 3822 cylinders, total 61405184 sectors
 Units = sectors of 1 * 512 = 512 bytes
 Sector size (logical/physical): 512 bytes / 512 bytes
 I/O size (minimum/optimal): 512 bytes / 512 bytes
 Disk identifier: 0x
 
 Device Boot  Start End  Blocks   Id  System
 /dev/mmcblk0p181926140518330698496c  W95 FAT32 (LBA
 
 
 merkaba:/sys/block/mmcblk0#2 grep . * 2/dev/null
 alignment_offset:0
 capability:10
 dev:179:0
 discard_alignment:0
 ext_range:8
 force_ro:0
 inflight:   00
 range:8
 removable:0
 ro:0
 size:61405184
 stat: 176   33 1672  1020000
 0  102  102
 uevent:MAJOR=179
 uevent:MINOR=0
 uevent:DEVNAME=mmcblk0
 uevent:DEVTYPE=disk
 
 
 I do not want to take the time to diagnose this further, especially as its
 one of those nasty I just lock up and I don´t tell you what went wrong
 kind of bugs. Thats just not a nice way to tell that there has been an
 error.
 
 
 If there is any five or ten minute information gathering task, I am willing
 to provide more information, but right now there is no chance on Earth that
 I will be bisecting while having a long list of more interesting things to
 do than that.
 
 
 Thus for now I just use 3.12 kernel again. Maybe I will try with some rc5 or
 so again.
 
 Ciao,

-- 
Martin 'Helios' Steigerwald - http://www.Lichtvoll.de
GPG: 03B0 0D6C 0040 0710 4AFA  B82F 991B EAAC A599 84C7
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [REGRESSION] 3.13-rc2: locks up hard on trying to transfer a file to mmc based internal SD card slot [FOUND]

[Martin Steigerwald]

Am Dienstag, 31. Dezember 2013, 13:52:05 schrieb Martin Steigerwald:
 Am Dienstag, 31. Dezember 2013, 13:41:22 schrieb Martin Steigerwald:
  Am Samstag, 30. November 2013, 14:53:51 schrieb Martin Steigerwald:
   Just added linux-mmc. And I might git-bisect that at some time, but I do
   not intend to do it during my precious weekend. The chances of me
   bisecting it increase with workable suggestions on how to cut down the
   amount of iterations needed and avoid testing highly experimental
   between
   3.12 and 3.13-rc1 kernels on a production laptop. I may be willing to
   test a patch or two. As I see there seem to have been quite some changes
   in MMC subsystem.
   
   
   
   
   Hi!
   
   Just does that on a ThinkPad T520 with:
   
   merkaba:~ lspci -nn | grep MMC
   0d:00.0 System peripheral [0880]: Ricoh Co Ltd PCIe SDXC/MMC Host
   Controller [1180:e823] (rev 08)
   
   Mouse pointer freezes, no Ctrl-Alt-F1.
  
  It just does that with
  
  Linux version 3.13.0-rc6-tp520 (martin@merkaba) (gcc version 4.8.2 (Debian
  4.8.2-10) ) #41 SMP PREEMPT Mon Dec 30 13:39:07 CET 2013
  
  as well.
 
 I missed some important data. Kernel runs with threadirqs:
 
 merkaba:~ cat /proc/cmdline
 BOOT_IMAGE=/vmlinuz-3.12.6-tp520
 root=UUID=2f5c334d-249b-4c89-95cc-18572f750bd7 ro rootflags=subvol=root
 resume=/dev/mapper/merkaba-swap threadirqs i915_enable_rc6=7
 
 Oh, and I see i915_enable_rc6=7. This always worked flawlessly. But maybe
 this changed? Cause according to powertop the GPU never entered deeper
 sleep states anyway. Maybe this now works (and thus may hang)?
 
 These are values on 3.12.6:
 | GPU |
 | 
 | Powered On 96,3%|
 | RC6 3,7%|
 | RC6p0,0%|
 | RC6pp   0,0%|
 
 I also attach kernel configs of non working 3.13-rc6 and working 3.12.6
 kernels.
 
 Its a ThinkPad T520 with Sandybridge:
 
 merkaba:~ lspci -nn | grep VGA
 00:02.0 VGA compatible controller [0300]: Intel Corporation 2nd Generation
 Core Processor Family Integrated Graphics Controller [8086:0126] (rev 09)
 
 Debian kernel packages available. But well… optimized for ThinkPad T520, may
 not run nicely otherwere.
 
 
 Please give suggestions on what to try next. Whats comes to mind is tryining
 without rc6_enable option and then without threadirq option.
 
 Any other idea?

So there we go:

1) Without kernel options (except resume option) copying works in desktop.

2) But then otherwise as I expected: With just threadirqs kernel option it 
hangs. I would have suspected the i915_enable_rc6 option instead.

3) But only when triggering copy via KDE desktop dolphin´s file manager. I 
tried copying on tty1 again and no hang there. Also again I/O seemed to go on 
after mouse pointer freeze (without Ctrl-Alt-F1) working. kwin ran in 
compositing mode.

4) With just i915_enable_rc6=7 it works. But since according to powertop 
that option doesn´t give me the benefit of doing into deeper GPU sleep states 
anyway, I removed that one now as well.


So my laptop is on 3.13-rc6 now without any special options and I learned 
again:

Never try to tune the kernel :)

And if still tuning it: First remove any kernel option when facing any issue. 
Sorry for the noise that not adhering to this has caused.


This is second time that threadirqs option caused problems here. Thus CCing 
rt-users mailing list as well.

If wished I compile this all into a bugzilla.kernel.org bug report in a 
concise format as well. But thats for another day :)

Have a good shift into new year if not already in it… otherwise a happy new 
year,
Martin


 
 Ciao,
 Martin
 
  But, only when trying to write a file via desktop environment via dolphin
  from KDE in that case. When I am on tty1 it seems to be stable to write to
  the SD card. But with dolphin on writing a large few files vom /usr/bin
  mouse pointer froze again. But according to harddisk led from ThinkPad
  T520
  there has been some write activity afterwards. The LED also lits up for
  MMC
  card accesses. Still after reboot there is none of the copied files
  visible
  on the FAT32 formatted SD card.
  
  Thus adding Intel gfx and dri devel lists to CC.
  
  
  This crashing only under GUI might still be a coindidence. I only tried
  once. But since the crash usually came almost immediately and it didn´t
  crash with reading or writing files on TTY1 and it somehow continued I/O
  according to harddisk led instead of seeming to be completely stopped…
  well
  I can try again to make sure. Would be good to make it crash on TTY1 since
  then I might see some kernel output.
  
  
  Back to 3.12.6 for now. I just tried the same with that kernel and there
  the copying just works nice.
  
  I can also report a bug at bugzilla.kernel.org if needed.
  
  
  May comments about bisecting still applies. I do not feel comfortable with
  doing

Re: [Intel-gfx] Linux 3.11-rc2 (acpi backlight, revert)

[Martin Steigerwald]

Am Freitag, 26. Juli 2013, 14:40:58 schrieb Rafael J. Wysocki:
 On Friday, July 26, 2013 02:09:08 PM Martin Steigerwald wrote:
  Am Donnerstag, 25. Juli 2013, 15:00:26 schrieb Rafael J. Wysocki:
   On Monday, July 22, 2013 09:54:21 PM Rafael J. Wysocki wrote:
On Monday, July 22, 2013 11:11:54 AM Linus Torvalds wrote:
 On Mon, Jul 22, 2013 at 6:02 AM, Rafael J. Wysocki r...@sisk.pl 
wrote:
  Linus, do you want me to send a pull request reverting 8c5bd7a and
  efaa14c?
 
 Yes, but let's wait a while. Not because I think we'll fix the
 problem
 (hey, miracles might happen), but because I think it would be useful
 to couple the reverts with information about the particular machines
 that broke (and the people who reported it). So that when we
 inevitably try again, we can perhaps get some testing effort with
 those machines/people.
 
 It doesn't seem to be a show-stopped for a large number of people,
 so
 there's no huge hurry. I'd suggest doing the revert just in time for
 rc3, but waiting until then to gather info about people who see
 breakage.
 
 Sound like a plan?

Yes, it does.
   
   OK, time to revert I guess.
   
   James, Kamal, Steven, Jörg, Martin, Kalle, please check if the apppended
   patch fixes the backlight for you.
  
  Rafael, do you still need more testing urgently? Otherwise I´d wait till
  its in some next 3.11 rc and test then.
 
 Well, it seems to work for everybody else (Steven, Joerg, thanks for your
 reports!), so I don't think you need to test it urgently.

Just a late confirmation: With 3.11-rc3 back light stuff is working nicely on 
this ThinkPad T520.

Thanks,
-- 
Martin 'Helios' Steigerwald - http://www.Lichtvoll.de
GPG: 03B0 0D6C 0040 0710 4AFA  B82F 991B EAAC A599 84C7
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] Linux 3.11-rc2 (acpi backlight, revert)

[Martin Steigerwald]

Am Donnerstag, 25. Juli 2013, 15:00:26 schrieb Rafael J. Wysocki:
 On Monday, July 22, 2013 09:54:21 PM Rafael J. Wysocki wrote:
  On Monday, July 22, 2013 11:11:54 AM Linus Torvalds wrote:
   On Mon, Jul 22, 2013 at 6:02 AM, Rafael J. Wysocki r...@sisk.pl wrote:
Linus, do you want me to send a pull request reverting 8c5bd7a and
efaa14c?
   
   Yes, but let's wait a while. Not because I think we'll fix the problem
   (hey, miracles might happen), but because I think it would be useful
   to couple the reverts with information about the particular machines
   that broke (and the people who reported it). So that when we
   inevitably try again, we can perhaps get some testing effort with
   those machines/people.
   
   It doesn't seem to be a show-stopped for a large number of people, so
   there's no huge hurry. I'd suggest doing the revert just in time for
   rc3, but waiting until then to gather info about people who see
   breakage.
   
   Sound like a plan?
  
  Yes, it does.
 
 OK, time to revert I guess.
 
 James, Kamal, Steven, Jörg, Martin, Kalle, please check if the apppended
 patch fixes the backlight for you.

Rafael, do you still need more testing urgently? Otherwise I´d wait till its 
in some next 3.11 rc and test then.

Thanks,
-- 
Martin 'Helios' Steigerwald - http://www.Lichtvoll.de
GPG: 03B0 0D6C 0040 0710 4AFA  B82F 991B EAAC A599 84C7
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx