Hi Chris and all,
I have tried the latest git (-rc3) and I get a complete freeze when X starts.
I've bisected it and the first bad commit is this:
commit d5bb081b027b520f9e59b4fb8faea83a136ec15e Author: Jesse Barnes jbarnes@virtuousgeek.org Date: Wed Jan 5 12:01:26 2011 -0800
drm/i915: cleanup rc6 code
Cleanup several aspects of the rc6 code: - misnamed intel_disable_clock_gating function (was only about rc6) - remove commented call to intel_disable_clock_gating - rc6 enabling code belongs in its own function (allows us to move the actual clock gating enable call back into restore_state) - allocate power & render contexts up front, only free on unload (avoids ugly lazy init at rc6 enable time)
Signed-off-by: Jesse Barnes jbarnes@virtuousgeek.org [ickle: checkpatch cleanup] Signed-off-by: Chris Wilson chris@chris-wilson.co.uk
I've tried to revert it on top of -rc3 and everything works great.
I don't know which part of the code is wrong, could you please check it? If you need more information just ask.
Thanks.
Bye Francesco
On Tue, 1 Feb 2011 12:22:02 +0100, Francesco Allertsen fallertsen@gmail.com wrote:
Hi Chris and all,
I have tried the latest git (-rc3) and I get a complete freeze when X starts.
It would be useful to give us a few more details, such the drm.debug=0xe dmesg and the Xorg.log (from when it does starts!), and explain what you mean by complete freeze? Such as is the machine still accessible over the network, did it die whilst oopsing, etc.
Several other 'hangs when X starts' were resolved with
commit 9334ef755f060e251f3f395caeda1a58b6834ea3 Author: Chris Wilson chris@chris-wilson.co.uk Date: Fri Jan 28 11:53:03 2011 +0000
drm: Don't switch fb when disabling an output
Anyway, I look forward to seeing your debug logs. -Chris
On Tue, Feb 01, 2011 at 12:05:52PM +0000, Chris Wilson wrote:
It would be useful to give us a few more details, such the drm.debug=0xe dmesg and the Xorg.log (from when it does starts!), and explain what you mean by complete freeze? Such as is the machine still accessible over the network, did it die whilst oopsing, etc.
I've tried to use netconsole to get the output of dmesg, but there is no output.
Attached there is the Xorg.log, but I don't see any useful infomation.
The freeze means that nothing respond after less than a second, there are no oops and no network access and even the sysrq doesn't work.
Bye Francesco
On Tue, 1 Feb 2011 13:29:45 +0100, Francesco Allertsen fallertsen@gmail.com wrote:
On Tue, Feb 01, 2011 at 12:05:52PM +0000, Chris Wilson wrote:
It would be useful to give us a few more details, such the drm.debug=0xe dmesg and the Xorg.log (from when it does starts!), and explain what you mean by complete freeze? Such as is the machine still accessible over the network, did it die whilst oopsing, etc.
I've tried to use netconsole to get the output of dmesg, but there is no output.
Attached there is the Xorg.log, but I don't see any useful infomation.
Useful for me. Just confirms that you have an equivalent machine to this Lenovo x201s, on which those patches were tested after receiving from Jesse. :|
The dmesg would have been useful to know whether the i915.ko module is loaded during X startup, and so reveal some information about the sequence of function calls (i.e. whether the modified routines were running at the time of the hang, or whether they had completed much earlier during boot). The drm.debug dmesg is usually a gold mine of information.
Another useful test is whether i915.powersave=0 also prevents the hang? -Chris
On Tue, Feb 01, 2011 at 01:16:01PM +0000, Chris Wilson wrote:
Useful for me. Just confirms that you have an equivalent machine to this Lenovo x201s, on which those patches were tested after receiving from Jesse. :|
Yes, I have a Lenovo x201s :-P.
The dmesg would have been useful to know whether the i915.ko module is loaded during X startup, and so reveal some information about the sequence of function calls (i.e. whether the modified routines were running at the time of the hang, or whether they had completed much earlier during boot). The drm.debug dmesg is usually a gold mine of information.
Attacched there is the full dmesg log.
Another useful test is whether i915.powersave=0 also prevents the hang?
No, it doesn't have any effect.
Bye Francesco
On Tue, 1 Feb 2011 15:07:55 +0100 Francesco Allertsen fallertsen@gmail.com wrote:
On Tue, Feb 01, 2011 at 01:16:01PM +0000, Chris Wilson wrote:
Useful for me. Just confirms that you have an equivalent machine to this Lenovo x201s, on which those patches were tested after receiving from Jesse. :|
Yes, I have a Lenovo x201s :-P.
The dmesg would have been useful to know whether the i915.ko module is loaded during X startup, and so reveal some information about the sequence of function calls (i.e. whether the modified routines were running at the time of the hang, or whether they had completed much earlier during boot). The drm.debug dmesg is usually a gold mine of information.
Attacched there is the full dmesg log.
Another useful test is whether i915.powersave=0 also prevents the hang?
No, it doesn't have any effect.
Yeah I don't think we use that flag for rc6, though we probably should.
The bisect is interesting, I'd have expected a failure when we re-enabled rc6 on ILK or when we fixed up the ring buffer init.
The cleanup patch should be just that, but at least reverting it shouldn't cause any trouble.
On Tue, 1 Feb 2011 08:31:12 -0800, Jesse Barnes jbarnes@virtuousgeek.org wrote:
The bisect is interesting, I'd have expected a failure when we re-enabled rc6 on ILK or when we fixed up the ring buffer init.
Yes, that was my instinct as well.
Though that patch does do have one subtlety:
ironlake_enable_rc6(): + I915_WRITE(RSTDBYCTL, I915_READ(RSTDBYCTL) & ~RCX_SW_EXIT);
So it appears the patch may in fact be enabling render standby, when it was actually dropped in
commit 88271da3f3da75d6eaef5e768c82a1627edf7088 Author: Jesse Barnes jbarnes@virtuousgeek.org Date: Wed Jan 5 12:01:24 2011 -0800
drm/i915: re-enable rc6 support for Ironlake+
intel_enable_clock_gating(): - I915_WRITE(MCHBAR_RENDER_STANDBY, - I915_READ(MCHBAR_RENDER_STANDBY) & ~RCX_SW_EXIT);
So, if this is the issue, then simply commenting out the tweaking of RSTDBYCTL in ironlake_enable_rc6() should prevent the hang. -Chris
On Tue, 01 Feb 2011 16:57:37 +0000 Chris Wilson chris@chris-wilson.co.uk wrote:
On Tue, 1 Feb 2011 08:31:12 -0800, Jesse Barnes jbarnes@virtuousgeek.org wrote:
The bisect is interesting, I'd have expected a failure when we re-enabled rc6 on ILK or when we fixed up the ring buffer init.
Yes, that was my instinct as well.
Though that patch does do have one subtlety:
ironlake_enable_rc6():
I915_WRITE(RSTDBYCTL, I915_READ(RSTDBYCTL) & ~RCX_SW_EXIT);So it appears the patch may in fact be enabling render standby, when it was actually dropped in
commit 88271da3f3da75d6eaef5e768c82a1627edf7088 Author: Jesse Barnes jbarnes@virtuousgeek.org Date: Wed Jan 5 12:01:24 2011 -0800
drm/i915: re-enable rc6 support for Ironlake+intel_enable_clock_gating():
- I915_WRITE(MCHBAR_RENDER_STANDBY,
I915_READ(MCHBAR_RENDER_STANDBY) & ~RCX_SW_EXIT);So, if this is the issue, then simply commenting out the tweaking of RSTDBYCTL in ironlake_enable_rc6() should prevent the hang.
IIRC that really was a cleanup, clearing RCX_SW_EXIT on my machine was unnecessary, since it was already clear. But it's worth trying anyway...
On Tue, Feb 01, 2011 at 04:57:37PM +0000, Chris Wilson wrote:
So, if this is the issue, then simply commenting out the tweaking of RSTDBYCTL in ironlake_enable_rc6() should prevent the hang.
I've tried the following patch
diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c index d7f237d..7769768 100644 --- a/drivers/gpu/drm/i915/intel_display.c +++ b/drivers/gpu/drm/i915/intel_display.c @@ -6527,7 +6527,6 @@ void ironlake_enable_rc6(struct drm_device *dev) ADVANCE_LP_RING();
I915_WRITE(PWRCTXA, dev_priv->pwrctx->gtt_offset | PWRCTX_EN); - I915_WRITE(RSTDBYCTL, I915_READ(RSTDBYCTL) & ~RCX_SW_EXIT); }
/* Set up chip specific display functions */
And it still hangs.
Bye Francesco
On Wed, 2 Feb 2011 10:56:57 +0100, Francesco Allertsen fallertsen@gmail.com wrote:
On Tue, Feb 01, 2011 at 04:57:37PM +0000, Chris Wilson wrote:
So, if this is the issue, then simply commenting out the tweaking of RSTDBYCTL in ironlake_enable_rc6() should prevent the hang.
I've tried the following patch
diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c index d7f237d..7769768 100644 --- a/drivers/gpu/drm/i915/intel_display.c +++ b/drivers/gpu/drm/i915/intel_display.c @@ -6527,7 +6527,6 @@ void ironlake_enable_rc6(struct drm_device *dev) ADVANCE_LP_RING();
I915_WRITE(PWRCTXA, dev_priv->pwrctx->gtt_offset | PWRCTX_EN);
- I915_WRITE(RSTDBYCTL, I915_READ(RSTDBYCTL) & ~RCX_SW_EXIT);
}
/* Set up chip specific display functions */
And it still hangs.
Hmm, that was the only change I could spot between the two patches. Care to disable that function and see what happens? [i.e. put a return before we write anything to the ring] -Chris
On Wed, Feb 02, 2011 at 09:59:54AM +0000, Chris Wilson wrote:
Hmm, that was the only change I could spot between the two patches. Care to disable that function and see what happens? [i.e. put a return before we write anything to the ring]
I've tried with the following patch
diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c index 7769768..2ef0333 100644 --- a/drivers/gpu/drm/i915/intel_display.c +++ b/drivers/gpu/drm/i915/intel_display.c @@ -6505,6 +6505,8 @@ void ironlake_enable_rc6(struct drm_device *dev) struct drm_i915_private *dev_priv = dev->dev_private; int ret;
+ return; + /* * GPU can automatically power down the render unit if given a page * to save state.
So to return at the beginning of the function, and everything works again.
Bye Francesco
On Wed, Feb 02, 2011 at 09:59:54AM +0000, Chris Wilson wrote:
Hmm, that was the only change I could spot between the two patches. Care to disable that function and see what happens? [i.e. put a return before we write anything to the ring]
Ping?
I've tried the -rc4 (there are some drm updates) but I get the same hang.
Bye Francesco
On Wed, 9 Feb 2011 13:52:38 +0100, Francesco Allertsen fallertsen@gmail.com wrote:
On Wed, Feb 02, 2011 at 09:59:54AM +0000, Chris Wilson wrote:
Hmm, that was the only change I could spot between the two patches. Care to disable that function and see what happens? [i.e. put a return before we write anything to the ring]
Ping?
I was optimistic that we might spot the real issue... However, you appear to be not alone and so I've pushed a disabling patch onto -fixes:
commit ac66808814036b4c33dd98091b2176ae6157f1a8 Author: Chris Wilson chris@chris-wilson.co.uk Date: Wed Feb 9 16:15:32 2011 +0000
drm/i915: Disable RC6 on Ironlake
The automatic powersaving feature is once again causing havoc, with 100% reliable hangs on boot and resume on affected machines.
Reported-by: Francesco Allertsen fallertsen@gmail.com Reported-by: Gui Rui chaos.proton@gmail.com Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=28582 Signed-off-by: Chris Wilson chris@chris-wilson.co.uk
That should work its way upstream shortly. -Chris
On Wed, 09 Feb 2011 17:09:10 +0000 Chris Wilson chris@chris-wilson.co.uk wrote:
On Wed, 9 Feb 2011 13:52:38 +0100, Francesco Allertsen fallertsen@gmail.com wrote:
On Wed, Feb 02, 2011 at 09:59:54AM +0000, Chris Wilson wrote:
Hmm, that was the only change I could spot between the two patches. Care to disable that function and see what happens? [i.e. put a return before we write anything to the ring]
Ping?
I was optimistic that we might spot the real issue... However, you appear to be not alone and so I've pushed a disabling patch onto -fixes:
commit ac66808814036b4c33dd98091b2176ae6157f1a8 Author: Chris Wilson chris@chris-wilson.co.uk Date: Wed Feb 9 16:15:32 2011 +0000
drm/i915: Disable RC6 on Ironlake The automatic powersaving feature is once again causing havoc, with 100% reliable hangs on boot and resume on affected machines. Reported-by: Francesco Allertsen <fallertsen@gmail.com> Reported-by: Gui Rui <chaos.proton@gmail.com> Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=28582 Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>That should work its way upstream shortly.
reverting the cleanup wasn't sufficient?
Francesco, if you revert the cleanup patch you bisected to, what does /sys/kernel/debug/dri/0/i915_drpc_info report?
On Wed, 9 Feb 2011 09:50:47 -0800 Jesse Barnes jbarnes@virtuousgeek.org wrote:
On Wed, 09 Feb 2011 17:09:10 +0000 Chris Wilson chris@chris-wilson.co.uk wrote:
On Wed, 9 Feb 2011 13:52:38 +0100, Francesco Allertsen fallertsen@gmail.com wrote:
On Wed, Feb 02, 2011 at 09:59:54AM +0000, Chris Wilson wrote:
Hmm, that was the only change I could spot between the two patches. Care to disable that function and see what happens? [i.e. put a return before we write anything to the ring]
Ping?
I was optimistic that we might spot the real issue... However, you appear to be not alone and so I've pushed a disabling patch onto -fixes:
commit ac66808814036b4c33dd98091b2176ae6157f1a8 Author: Chris Wilson chris@chris-wilson.co.uk Date: Wed Feb 9 16:15:32 2011 +0000
drm/i915: Disable RC6 on Ironlake The automatic powersaving feature is once again causing havoc, with 100% reliable hangs on boot and resume on affected machines. Reported-by: Francesco Allertsen <fallertsen@gmail.com> Reported-by: Gui Rui <chaos.proton@gmail.com> Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=28582 Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>That should work its way upstream shortly.
reverting the cleanup wasn't sufficient?
Francesco, if you revert the cleanup patch you bisected to, what does /sys/kernel/debug/dri/0/i915_drpc_info report?
In particular, I'm curious if it reports that you're in RC6, so you might need to cat it a couple of times while gfx is idle (like from the console or an ssh session while nothing is drawing).
On Wed, 9 Feb 2011 09:53:26 -0800 Jesse Barnes jbarnes@virtuousgeek.org wrote:
On Wed, 9 Feb 2011 09:50:47 -0800 Jesse Barnes jbarnes@virtuousgeek.org wrote:
On Wed, 09 Feb 2011 17:09:10 +0000 Chris Wilson chris@chris-wilson.co.uk wrote:
On Wed, 9 Feb 2011 13:52:38 +0100, Francesco Allertsen fallertsen@gmail.com wrote:
On Wed, Feb 02, 2011 at 09:59:54AM +0000, Chris Wilson wrote:
Hmm, that was the only change I could spot between the two patches. Care to disable that function and see what happens? [i.e. put a return before we write anything to the ring]
Ping?
I was optimistic that we might spot the real issue... However, you appear to be not alone and so I've pushed a disabling patch onto -fixes:
commit ac66808814036b4c33dd98091b2176ae6157f1a8 Author: Chris Wilson chris@chris-wilson.co.uk Date: Wed Feb 9 16:15:32 2011 +0000
drm/i915: Disable RC6 on Ironlake The automatic powersaving feature is once again causing havoc, with 100% reliable hangs on boot and resume on affected machines. Reported-by: Francesco Allertsen <fallertsen@gmail.com> Reported-by: Gui Rui <chaos.proton@gmail.com> Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=28582 Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>That should work its way upstream shortly.
reverting the cleanup wasn't sufficient?
Francesco, if you revert the cleanup patch you bisected to, what does /sys/kernel/debug/dri/0/i915_drpc_info report?
In particular, I'm curious if it reports that you're in RC6, so you might need to cat it a couple of times while gfx is idle (like from the console or an ssh session while nothing is drawing).
Oh and one more request, what does "intel_reg_read 0x111b8" return on your system?
I really don't want to disable RC6; it saves way too much power. So I'd like to understand what's going on here so we can either fix your system or reliably find a way to disable it on systems where the BIOS isn't allowing it...
Thanks,
On Wed, 9 Feb 2011 09:50:47 -0800, Jesse Barnes jbarnes@virtuousgeek.org wrote:
On Wed, 09 Feb 2011 17:09:10 +0000 Chris Wilson chris@chris-wilson.co.uk wrote:
I was optimistic that we might spot the real issue... However, you appear to be not alone and so I've pushed a disabling patch onto -fixes:
commit ac66808814036b4c33dd98091b2176ae6157f1a8 Author: Chris Wilson chris@chris-wilson.co.uk Date: Wed Feb 9 16:15:32 2011 +0000
drm/i915: Disable RC6 on Ironlakereverting the cleanup wasn't sufficient?
Considering we've been burnt badly by rc6 in the past, and we now have two independent regression reports of hard hangs at completely different stages, disabling it seemed the prudent course. I left a switch in place so we can continue testing. -Chris
On Wed, Feb 09, 2011 at 05:09:10PM +0000, Chris Wilson wrote:
I was optimistic that we might spot the real issue... However, you appear to be not alone and so I've pushed a disabling patch onto -fixes:
commit ac66808814036b4c33dd98091b2176ae6157f1a8 Author: Chris Wilson chris@chris-wilson.co.uk Date: Wed Feb 9 16:15:32 2011 +0000
drm/i915: Disable RC6 on Ironlake The automatic powersaving feature is once again causing havoc, with 100% reliable hangs on boot and resume on affected machines. Reported-by: Francesco Allertsen <fallertsen@gmail.com> Reported-by: Gui Rui <chaos.proton@gmail.com> Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=28582 Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>That should work its way upstream shortly.
I've tried to apply it on top of 2.6.38-rc4, and now it doesn't hang when I start X, but it hangs when I resume from suspend to RAM.
Bye Francesco
On Thu, 10 Feb 2011 13:10:26 +0100 Francesco Allertsen fallertsen@gmail.com wrote:
On Wed, Feb 09, 2011 at 05:09:10PM +0000, Chris Wilson wrote:
I was optimistic that we might spot the real issue... However, you appear to be not alone and so I've pushed a disabling patch onto -fixes:
commit ac66808814036b4c33dd98091b2176ae6157f1a8 Author: Chris Wilson chris@chris-wilson.co.uk Date: Wed Feb 9 16:15:32 2011 +0000
drm/i915: Disable RC6 on Ironlake The automatic powersaving feature is once again causing havoc, with 100% reliable hangs on boot and resume on affected machines. Reported-by: Francesco Allertsen <fallertsen@gmail.com> Reported-by: Gui Rui <chaos.proton@gmail.com> Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=28582 Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>That should work its way upstream shortly.
I've tried to apply it on top of 2.6.38-rc4, and now it doesn't hang when I start X, but it hangs when I resume from suspend to RAM.
Since intel_reg_read won't work, can you try this patch instead? Just patch it in, then cat /sys/kernel/debug/dri/0/i915_drpc_info
Thanks,
On Thu, Feb 10, 2011 at 10:34:43AM -0800, Jesse Barnes wrote:
Since intel_reg_read won't work, can you try this patch instead? Just patch it in, then cat /sys/kernel/debug/dri/0/i915_drpc_info
This is the output:
--- HD boost: yes Boost freq: 3 HW control enabled: no SW control enabled: yes Gated voltage change: no Starting frequency: P9 Max P-state: P0 Min P-state: P9 RS1 VID: 0 RS2 VID: 8 Render standby enabled: yes Current RS state: RS2 (RC6) RSTDBYCTL: 0x474c3000 ---
Bye Francesco
On Fri, 11 Feb 2011 00:23:09 +0100 Francesco Allertsen fallertsen@gmail.com wrote:
On Thu, Feb 10, 2011 at 10:34:43AM -0800, Jesse Barnes wrote:
Since intel_reg_read won't work, can you try this patch instead? Just patch it in, then cat /sys/kernel/debug/dri/0/i915_drpc_info
This is the output:
HD boost: yes Boost freq: 3 HW control enabled: no SW control enabled: yes Gated voltage change: no Starting frequency: P9 Max P-state: P0 Min P-state: P9 RS1 VID: 0 RS2 VID: 8 Render standby enabled: yes Current RS state: RS2 (RC6) RSTDBYCTL: 0x474c3000
Does this kernel have the problem patch included? Or is it reverted?
Thanks,
On Thu, Feb 10, 2011 at 03:25:33PM -0800, Jesse Barnes wrote:
Does this kernel have the problem patch included? Or is it reverted?
That was without the patch reverted, now I've reverted it and this is the output:
--- HD boost: yes Boost freq: 3 HW control enabled: no SW control enabled: yes Gated voltage change: no Starting frequency: P9 Max P-state: P0 Min P-state: P9 RS1 VID: 0 RS2 VID: 8 Render standby enabled: yes Current RS state: RS2 (RC6) RSTDBYCTL: 0x474c3000 ---
It seems the same.
Bye Francesco
On Fri, 11 Feb 2011 08:28:37 +0100 Francesco Allertsen fallertsen@gmail.com wrote:
On Thu, Feb 10, 2011 at 03:25:33PM -0800, Jesse Barnes wrote:
Does this kernel have the problem patch included? Or is it reverted?
That was without the patch reverted, now I've reverted it and this is the output:
HD boost: yes Boost freq: 3 HW control enabled: no SW control enabled: yes Gated voltage change: no Starting frequency: P9 Max P-state: P0 Min P-state: P9 RS1 VID: 0 RS2 VID: 8 Render standby enabled: yes Current RS state: RS2 (RC6) RSTDBYCTL: 0x474c3000
It seems the same.
Interesting, so your RSTDBYCTL is the same and you're still in RC6. So something else in the cleanup patch is causing trouble.
Francesco, if you revert d5bb081b027b520f9e59b4fb8faea83a136ec15e do both the hangs at X startup and suspend/resume go away?
Gui, same question for you. And can you try this patch and dump the contents of /sys/kernel/debug/dri/0/i915_drpc_info as well? Your settings are probably the same but I want to double check.
Thanks,
On Sat, Feb 12, 2011 at 1:16 AM, Jesse Barnes jbarnes@virtuousgeek.org wrote:
On Fri, 11 Feb 2011 08:28:37 +0100 Francesco Allertsen fallertsen@gmail.com wrote:
On Thu, Feb 10, 2011 at 03:25:33PM -0800, Jesse Barnes wrote:
Does this kernel have the problem patch included? Or is it reverted?
That was without the patch reverted, now I've reverted it and this is the output:
HD boost: yes Boost freq: 3 HW control enabled: no SW control enabled: yes Gated voltage change: no Starting frequency: P9 Max P-state: P0 Min P-state: P9 RS1 VID: 0 RS2 VID: 8 Render standby enabled: yes Current RS state: RS2 (RC6) RSTDBYCTL: 0x474c3000
It seems the same.
Interesting, so your RSTDBYCTL is the same and you're still in RC6. So something else in the cleanup patch is causing trouble.
Francesco, if you revert d5bb081b027b520f9e59b4fb8faea83a136ec15e do both the hangs at X startup and suspend/resume go away?
Gui, same question for you. And can you try this patch and dump the contents of /sys/kernel/debug/dri/0/i915_drpc_info as well? Your settings are probably the same but I want to double check.
I'm new in this thread so I found the patch by myself. I hope it's the right one:
http://www.spinics.net/lists/dri-devel/msg08028.html
But that patch doesn't apply to latest git, so I just added the seq_printf call to the end of the swith of i915_drpc_info.
I finally found the way setup /sys/kernel/debug... My /sys/kernel/debug/dri/0/i915_drpc_info is:
HD boost: no Boost freq: 6 HW control enabled: no SW control enabled: yes Gated voltage change: no Starting frequency: P5 Max P-state: P0 Min P-state: P7 RS1 VID: 0 RS2 VID: 8 Render standby enabled: yes Current RS state: RS2 (RC6) RSTDBYCTL: 0x474c3000
And there is a /sys/kernel/debug/dri/64/i915_drpc_info with the same content. Whether X is running or not, the result is the same.
But even with d5bb081b027b52 reverted, the system could not resume from suspend. I haven't checked it before so I've no idea about this.
Please keep me informed, thanks a lot ;-)
On Fri, Feb 11, 2011 at 09:16:33AM -0800, Jesse Barnes wrote:
On Fri, 11 Feb 2011 08:28:37 +0100 Francesco Allertsen fallertsen@gmail.com wrote:
On Thu, Feb 10, 2011 at 03:25:33PM -0800, Jesse Barnes wrote:
Does this kernel have the problem patch included? Or is it reverted?
That was without the patch reverted, now I've reverted it and this is the output:
HD boost: yes Boost freq: 3 HW control enabled: no SW control enabled: yes Gated voltage change: no Starting frequency: P9 Max P-state: P0 Min P-state: P9 RS1 VID: 0 RS2 VID: 8 Render standby enabled: yes Current RS state: RS2 (RC6) RSTDBYCTL: 0x474c3000
It seems the same.
Interesting, so your RSTDBYCTL is the same and you're still in RC6. So something else in the cleanup patch is causing trouble.
Francesco, if you revert d5bb081b027b520f9e59b4fb8faea83a136ec15e do both the hangs at X startup and suspend/resume go away?
I've tried to revert it and it hangs the same on the suspend/resume, so I've setted inittab to work only in tty mode, and bisected the suspend/resume problem from -rc4.
The bad commit is another:
commit 88271da3f3da75d6eaef5e768c82a1627edf7088 Author: Jesse Barnes jbarnes@virtuousgeek.org Date: Wed Jan 5 12:01:24 2011 -0800
drm/i915: re-enable rc6 support for Ironlake+
Re-enable rc6 support on Ironlake for power savings. Adds a debugfs file to check current RC state, adds a missing workaround for Ironlake MI_SET_CONTEXT instructions, and renames MCHBAR_RENDER_STANDBY to RSTDBYCTL to match the docs.
Keep RC6 and the power context disabled on pre-ILK. It only seems to hang and doesn't save any power.
Signed-off-by: Jesse Barnes jbarnes@virtuousgeek.org Signed-off-by: Chris Wilson chris@chris-wilson.co.uk
I've tried to rever it on top of -rc4 to check if the suspend/resume works, but it doesn't revert clean, and now I don't have the time to check.
If you need some more information just let me know, anyway this seems another unrelated problem.
Bye Francesco
On Tue, Feb 01, 2011 at 12:05:52PM +0000, Chris Wilson wrote:
It would be useful to give us a few more details, such the drm.debug=0xe dmesg and the Xorg.log (from when it does starts!)
Sorry, I forgot to turn on the debug last time, this is the dmesg output from when I start X.
Other (hope useful) information: the frame buffer works perfect.
Bye Francesco
On Tue, 1 Feb 2011 14:00:41 +0100, Francesco Allertsen fallertsen@gmail.com wrote:
On Tue, Feb 01, 2011 at 12:05:52PM +0000, Chris Wilson wrote:
It would be useful to give us a few more details, such the drm.debug=0xe dmesg and the Xorg.log (from when it does starts!)
Sorry, I forgot to turn on the debug last time, this is the dmesg output from when I start X.
Can you attach the dmesg from when the module loads as well? -Chris
dri-devel@lists.freedesktop.org
-
Chris Wilson -
Francesco Allertsen -
Grissiom -
Jesse Barnes