On Tue, 28 Dec 2010 17:18:12 -0800 Linus Torvalds wrote:
Another week, another -rc. This should be the last for the 37 series, so I still expect the merge window to open early January when people are hopefully back to working order after having eaten (and drunk) too much.
The -rc8 release shouldn't be all that exciting. The most noticeable is probably the fact that hopefully the "blank screen" problem with intel graphics is fixed. But on the whole, it's all just a collection of random fixes all over.
I booted -rc8 and found that my video worked for only a few seconds, then it goes blank. -rc7 and -rc6 do the same. -rc5 is OK.
The only significant difference that I can see in the kernel message log is this:
from 2.6.37-rc5:
[drm] initialized overlay support i2c i2c-3: master_xfer[0] W, addr=0x50, len=1 i2c i2c-3: master_xfer[1] R, addr=0x50, len=1 i2c i2c-3: master_xfer[0] W, addr=0x50, len=1 i2c i2c-3: master_xfer[1] R, addr=0x50, len=128 fbcon: inteldrmfb (fb0) is primary device Console: switching to colour frame buffer device 160x64 fb0: inteldrmfb frame buffer device drm: registered panic notifier [drm] Initialized i915 1.6.0 20080730 for 0000:00:02.0 on minor 0
and from 2.6.37-rc6:
[drm] initialized overlay support No connectors reported connected with modes [drm] Cannot find any crtc or sizes - going 1024x768 fbcon: inteldrmfb (fb0) is primary device Console: switching to colour frame buffer device 128x48 fb0: inteldrmfb frame buffer device drm: registered panic notifier [drm] Initialized i915 1.6.0 20080730 for 0000:00:02.0 on minor 0
Full kernel boot logs are in http://www.xenotime.net/linux/logs/ (2637-rc5.notimes and 2637-rc6.notimes).
The 2.6.37-rc5 kernel config file is attached. It is close to an allmodconfig.
--- ~Randy *** Remember to use Documentation/SubmitChecklist when testing your code *** desserts: http://www.xenotime.net/linux/recipes/
On Wed, Dec 29, 2010 at 10:21 AM, Randy Dunlap randy.dunlap@oracle.com wrote:
The only significant difference that I can see in the kernel message log is this:
Hmm. I suspect that difference should have gone away with commit 92971021c6328 (Revert "drm: Don't try and disable an encoder that was never enabled"), but clearly that didn't fix your blank screen.
Does reverting commit 448f53a1ede54eb854d036abf54573281412d650 ("drm/i915/bios: Reverse order of 100/120 Mhz SSC clocks") fix it for you? It does for some people..
Chris - why did that lvds_ssc_freq thing suddenly start mattering? Can we please just disable spread-spectrum entirely? Or perhaps only if we notice that it was enabled already? Or something?
Linus
On Wed, 29 Dec 2010 11:40:04 -0800 Linus Torvalds torvalds@linux-foundation.org wrote:
On Wed, Dec 29, 2010 at 10:21 AM, Randy Dunlap randy.dunlap@oracle.com wrote:
The only significant difference that I can see in the kernel message log is this:
Hmm. I suspect that difference should have gone away with commit 92971021c6328 (Revert "drm: Don't try and disable an encoder that was never enabled"), but clearly that didn't fix your blank screen.
Does reverting commit 448f53a1ede54eb854d036abf54573281412d650 ("drm/i915/bios: Reverse order of 100/120 Mhz SSC clocks") fix it for you? It does for some people..
Chris - why did that lvds_ssc_freq thing suddenly start mattering? Can we please just disable spread-spectrum entirely? Or perhaps only if we notice that it was enabled already? Or something?
Randy, Jeff and Alex, does the below help at all? If so, it may be the minimal fix we want for 2.6.37.
diff --git a/drivers/gpu/drm/i915/intel_bios.c b/drivers/gpu/drm/i915/intel_bios index 2b20786..d27d016 100644 --- a/drivers/gpu/drm/i915/intel_bios.c +++ b/drivers/gpu/drm/i915/intel_bios.c @@ -263,6 +263,9 @@ parse_general_features(struct drm_i915_private *dev_priv, dev_priv->int_tv_support = general->int_tv_support; dev_priv->int_crt_support = general->int_crt_support; dev_priv->lvds_use_ssc = general->enable_ssc; + /* force disable until we can parse this correctly */ + if (IS_GEN5(dev) || IS_GEN6(dev)) + dev_priv->lvds_use_ssc = 0;
if (dev_priv->lvds_use_ssc) { if (IS_I85X(dev))
Le 29/12/10 21:16, Jesse Barnes a écrit :
On Wed, 29 Dec 2010 11:40:04 -0800 Linus Torvalds torvalds@linux-foundation.org wrote:
On Wed, Dec 29, 2010 at 10:21 AM, Randy Dunlap randy.dunlap@oracle.com wrote:
The only significant difference that I can see in the kernel message log is this:
Hmm. I suspect that difference should have gone away with commit 92971021c6328 (Revert "drm: Don't try and disable an encoder that was never enabled"), but clearly that didn't fix your blank screen.
Does reverting commit 448f53a1ede54eb854d036abf54573281412d650 ("drm/i915/bios: Reverse order of 100/120 Mhz SSC clocks") fix it for you? It does for some people..
Chris - why did that lvds_ssc_freq thing suddenly start mattering? Can we please just disable spread-spectrum entirely? Or perhaps only if we notice that it was enabled already? Or something?
Randy, Jeff and Alex, does the below help at all? If so, it may be the minimal fix we want for 2.6.37.
diff --git a/drivers/gpu/drm/i915/intel_bios.c b/drivers/gpu/drm/i915/intel_bios index 2b20786..d27d016 100644 --- a/drivers/gpu/drm/i915/intel_bios.c +++ b/drivers/gpu/drm/i915/intel_bios.c @@ -263,6 +263,9 @@ parse_general_features(struct drm_i915_private *dev_priv, dev_priv->int_tv_support = general->int_tv_support; dev_priv->int_crt_support = general->int_crt_support; dev_priv->lvds_use_ssc = general->enable_ssc;
/* force disable until we can parse this correctly */if (IS_GEN5(dev) || IS_GEN6(dev))dev_priv->lvds_use_ssc = 0; if (dev_priv->lvds_use_ssc) { if (IS_I85X(dev))
I also encountered the black screen problem after commit 448f53a1. I can confirm that the above patch solves the problem.
François Valenduc
On Wed, Dec 29, 2010 at 21:16, Jesse Barnes jbarnes@virtuousgeek.org wrote:
On Wed, 29 Dec 2010 11:40:04 -0800 Linus Torvalds torvalds@linux-foundation.org wrote:
Chris - why did that lvds_ssc_freq thing suddenly start mattering? Can we please just disable spread-spectrum entirely? Or perhaps only if we notice that it was enabled already? Or something?
Randy, Jeff and Alex, does the below help at all? If so, it may be the minimal fix we want for 2.6.37.
Something broke your patch: whitespace instead of tabs.
diff --git a/drivers/gpu/drm/i915/intel_bios.c b/drivers/gpu/drm/i915/intel_bios index 2b20786..d27d016 100644 --- a/drivers/gpu/drm/i915/intel_bios.c +++ b/drivers/gpu/drm/i915/intel_bios.c @@ -263,6 +263,9 @@ parse_general_features(struct drm_i915_private *dev_priv, dev_priv->int_tv_support = general->int_tv_support; dev_priv->int_crt_support = general->int_crt_support; dev_priv->lvds_use_ssc = general->enable_ssc;
- /* force disable until we can parse this correctly */
This comment seems to imply that SSC wasn't used at all until recently, right?
- if (IS_GEN5(dev) || IS_GEN6(dev))
- dev_priv->lvds_use_ssc = 0;
Doesn't change anything here. Display stays blank.
On Wed, 29 Dec 2010 22:11:09 +0100 Alex Riesen raa.lkml@gmail.com wrote:
On Wed, Dec 29, 2010 at 21:16, Jesse Barnes jbarnes@virtuousgeek.org wrote:
On Wed, 29 Dec 2010 11:40:04 -0800 Linus Torvalds torvalds@linux-foundation.org wrote:
Chris - why did that lvds_ssc_freq thing suddenly start mattering? Can we please just disable spread-spectrum entirely? Or perhaps only if we notice that it was enabled already? Or something?
Randy, Jeff and Alex, does the below help at all? If so, it may be the minimal fix we want for 2.6.37.
Something broke your patch: whitespace instead of tabs.
Yeah, just copy & pasted, sorry.
diff --git a/drivers/gpu/drm/i915/intel_bios.c b/drivers/gpu/drm/i915/intel_bios index 2b20786..d27d016 100644 --- a/drivers/gpu/drm/i915/intel_bios.c +++ b/drivers/gpu/drm/i915/intel_bios.c @@ -263,6 +263,9 @@ parse_general_features(struct drm_i915_private *dev_priv, dev_priv->int_tv_support = general->int_tv_support; dev_priv->int_crt_support = general->int_crt_support; dev_priv->lvds_use_ssc = general->enable_ssc;
- /* force disable until we can parse this correctly */
This comment seems to imply that SSC wasn't used at all until recently, right?
No, we enabled it previously, but it apparently doesn't work on all platforms, probably because we're either looking in the wrong place for the bit that tells us to enable it or not, or we're getting the wrong frequency on some platforms. Probably both (the VBIOS guys work closely with the Windows driver team that consumes this data, and don't always tell us when they make incompatible changes).
- if (IS_GEN5(dev) || IS_GEN6(dev))
- dev_priv->lvds_use_ssc = 0;
Doesn't change anything here. Display stays blank.
Sounds like your problem is separate from SSC then, more likely related to panel power or backlight control. Have you tried bisecting for the problem between 2.6.35 and 2.6.36?
Doesn't change anything here. Display stays blank.
Sounds like your problem is separate from SSC then, more likely related to panel power or backlight control. Have you tried bisecting for the problem between 2.6.35 and 2.6.36?
Nevermind, I just checked out the bug, looks like it is panel power related. Can you try this patch?
If it doesn't work, can you send me the output of intel_reg_dumper from before you turn off the display and after you try to turn it back on?
Thanks,
On Wed, Dec 29, 2010 at 22:53, Jesse Barnes jbarnes@virtuousgeek.org wrote:
Doesn't change anything here. Display stays blank.
Sounds like your problem is separate from SSC then, more likely related to panel power or backlight control. Have you tried bisecting for the problem between 2.6.35 and 2.6.36?
Nevermind, I just checked out the bug, looks like it is panel power related. Can you try this patch?
Tried. Does not work.
If it doesn't work, can you send me the output of intel_reg_dumper from before you turn off the display and after you try to turn it back on?
See the links below (sorry, they files are a bit large):
Before running "xset dpms force standby":
http://vin-soft.org/~raa/public/test/intel_gpu_dump-before
After running "sleep 3"
http://vin-soft.org/~raa/public/test/intel_gpu_dump-after-suspend
After running "xset dpms force on"
http://vin-soft.org/~raa/public/test/intel_gpu_dump-after-xset-on
After closing and opening the lid (displays backlight is back)
http://vin-soft.org/~raa/public/test/intel_gpu_dump-after-lid
On Thu, 30 Dec 2010 00:09:56 +0100 Alex Riesen raa.lkml@gmail.com wrote:
On Wed, Dec 29, 2010 at 22:53, Jesse Barnes jbarnes@virtuousgeek.org wrote:
Doesn't change anything here. Display stays blank.
Sounds like your problem is separate from SSC then, more likely related to panel power or backlight control. Have you tried bisecting for the problem between 2.6.35 and 2.6.36?
Nevermind, I just checked out the bug, looks like it is panel power related. Can you try this patch?
Tried. Does not work.
If it doesn't work, can you send me the output of intel_reg_dumper from before you turn off the display and after you try to turn it back on?
See the links below (sorry, they files are a bit large):
Before running "xset dpms force standby":
http://vin-soft.org/~raa/public/test/intel_gpu_dump-before
After running "sleep 3"
http://vin-soft.org/~raa/public/test/intel_gpu_dump-after-suspend
After running "xset dpms force on"
http://vin-soft.org/~raa/public/test/intel_gpu_dump-after-xset-on
After closing and opening the lid (displays backlight is back)
http://vin-soft.org/~raa/public/test/intel_gpu_dump-after-lid
I need the intel_reg_dumper output, not intel_gpu_dump. :)
On Thu, Dec 30, 2010 at 00:13, Jesse Barnes jbarnes@virtuousgeek.org wrote:
After closing and opening the lid (displays backlight is back)
http://vin-soft.org/~raa/public/test/intel_gpu_dump-after-lid
I need the intel_reg_dumper output, not intel_gpu_dump. :)
Hmm, there is no intel_reg_dumper in intel-gpu-tools-1.0.2, which is the latest on http://xorg.freedesktop.org/archive/individual/app/, so I assumed you just mistyped the name. Is it in git only? ... Yeah, look like it is in git only, which I have problems to compile (I have a bit of obsoleted system).
On Thu, Dec 30, 2010 at 00:20, Alex Riesen raa.lkml@gmail.com wrote:
On Thu, Dec 30, 2010 at 00:13, Jesse Barnes jbarnes@virtuousgeek.org wrote:
After closing and opening the lid (displays backlight is back)
http://vin-soft.org/~raa/public/test/intel_gpu_dump-after-lid
I need the intel_reg_dumper output, not intel_gpu_dump. :)
Hmm, there is no intel_reg_dumper in intel-gpu-tools-1.0.2, which is the latest on http://xorg.freedesktop.org/archive/individual/app/, so I assumed you just mistyped the name. Is it in git only? ... Yeah, look like it is in git only, which I have problems to compile (I have a bit of obsoleted system).
Is there any other way to get at the dump? Because it looks like it is plainly impossible to build the tools. A lot of dependencies, all really hard to get at on Ubuntu Jaunty.
On Thu, 30 Dec 2010 00:35:15 +0100 Alex Riesen raa.lkml@gmail.com wrote:
On Thu, Dec 30, 2010 at 00:20, Alex Riesen raa.lkml@gmail.com wrote:
On Thu, Dec 30, 2010 at 00:13, Jesse Barnes jbarnes@virtuousgeek.org wrote:
After closing and opening the lid (displays backlight is back)
http://vin-soft.org/~raa/public/test/intel_gpu_dump-after-lid
I need the intel_reg_dumper output, not intel_gpu_dump. :)
Hmm, there is no intel_reg_dumper in intel-gpu-tools-1.0.2, which is the latest on http://xorg.freedesktop.org/archive/individual/app/, so I assumed you just mistyped the name. Is it in git only? ... Yeah, look like it is in git only, which I have problems to compile (I have a bit of obsoleted system).
Is there any other way to get at the dump? Because it looks like it is plainly impossible to build the tools. A lot of dependencies, all really hard to get at on Ubuntu Jaunty.
That's the easiest way; I think there are existing packages available as well, but you may have to check Karmic or newer.
On Thu, Dec 30, 2010 at 01:02, Jesse Barnes jbarnes@virtuousgeek.org wrote:
That's the easiest way; I think there are existing packages available as well, but you may have to check Karmic or newer.
Never mind. I'm lazy (that's not to say someone is too).
I redid the test:
Before running "xset dpms force standby":
http://vin-soft.org/~raa/public/test/intel_reg_dumper-before
After running "sleep 3"
http://vin-soft.org/~raa/public/test/intel_reg_dumper-suspend
After running "xset dpms force on; sleep 3"
http://vin-soft.org/~raa/public/test/intel_reg_dumper-xset-on
After closing and opening the lid (displays backlight is back)
On Wed, Dec 29, 2010 at 22:18, Jesse Barnes jbarnes@virtuousgeek.org wrote:
- if (IS_GEN5(dev) || IS_GEN6(dev))
- dev_priv->lvds_use_ssc = 0;
Doesn't change anything here. Display stays blank.
Sounds like your problem is separate from SSC then, more likely related to panel power or backlight control. Have you tried bisecting for the problem between 2.6.35 and 2.6.36?
No. I assumed the bisection in the bug
https://bugzilla.kernel.org/show_bug.cgi?id=22672
was for the same problem as mine. It probably is not... I'm running a bisect right now.
On Wed, 29 Dec 2010 12:16:01 -0800 Jesse Barnes wrote:
On Wed, 29 Dec 2010 11:40:04 -0800 Linus Torvalds torvalds@linux-foundation.org wrote:
On Wed, Dec 29, 2010 at 10:21 AM, Randy Dunlap randy.dunlap@oracle.com wrote:
The only significant difference that I can see in the kernel message log is this:
Hmm. I suspect that difference should have gone away with commit 92971021c6328 (Revert "drm: Don't try and disable an encoder that was never enabled"), but clearly that didn't fix your blank screen.
Does reverting commit 448f53a1ede54eb854d036abf54573281412d650 ("drm/i915/bios: Reverse order of 100/120 Mhz SSC clocks") fix it for you? It does for some people..
Chris - why did that lvds_ssc_freq thing suddenly start mattering? Can we please just disable spread-spectrum entirely? Or perhaps only if we notice that it was enabled already? Or something?
Randy, Jeff and Alex, does the below help at all? If so, it may be the minimal fix we want for 2.6.37.
diff --git a/drivers/gpu/drm/i915/intel_bios.c b/drivers/gpu/drm/i915/intel_bios index 2b20786..d27d016 100644 --- a/drivers/gpu/drm/i915/intel_bios.c +++ b/drivers/gpu/drm/i915/intel_bios.c @@ -263,6 +263,9 @@ parse_general_features(struct drm_i915_private *dev_priv, dev_priv->int_tv_support = general->int_tv_support; dev_priv->int_crt_support = general->int_crt_support; dev_priv->lvds_use_ssc = general->enable_ssc;
/* force disable until we can parse this correctly */if (IS_GEN5(dev) || IS_GEN6(dev))dev_priv->lvds_use_ssc = 0; if (dev_priv->lvds_use_ssc) { if (IS_I85X(dev))--
Ugh, looks like I have confused things horribly. Sorry about this.
2.6.37-rc8 with no patches works for me. My original report was incorrect -- I was using -rc7 when I thought I was using -rc8. :(
Regrets, --- ~Randy *** Remember to use Documentation/SubmitChecklist when testing your code *** desserts: http://www.xenotime.net/linux/recipes/
diff --git a/drivers/gpu/drm/i915/intel_bios.c b/drivers/gpu/drm/i915/intel_bios index 2b20786..d27d016 100644 --- a/drivers/gpu/drm/i915/intel_bios.c +++ b/drivers/gpu/drm/i915/intel_bios.c @@ -263,6 +263,9 @@ parse_general_features(struct drm_i915_private *dev_priv, dev_priv->int_tv_support = general->int_tv_support; dev_priv->int_crt_support = general->int_crt_support; dev_priv->lvds_use_ssc = general->enable_ssc;
/* force disable until we can parse this correctly */if (IS_GEN5(dev) || IS_GEN6(dev))dev_priv->lvds_use_ssc = 0; if (dev_priv->lvds_use_ssc) { if (IS_I85X(dev))--
Ugh, looks like I have confused things horribly. Sorry about this.
2.6.37-rc8 with no patches works for me. My original report was incorrect -- I was using -rc7 when I thought I was using -rc8. :(
Can you confirm that the above doesn't break your setup just in case we need to apply it?
Thanks,
On Wed, 29 Dec 2010 14:46:14 -0800 Jesse Barnes wrote:
diff --git a/drivers/gpu/drm/i915/intel_bios.c b/drivers/gpu/drm/i915/intel_bios index 2b20786..d27d016 100644 --- a/drivers/gpu/drm/i915/intel_bios.c +++ b/drivers/gpu/drm/i915/intel_bios.c @@ -263,6 +263,9 @@ parse_general_features(struct drm_i915_private *dev_priv, dev_priv->int_tv_support = general->int_tv_support; dev_priv->int_crt_support = general->int_crt_support; dev_priv->lvds_use_ssc = general->enable_ssc;
/* force disable until we can parse this correctly */if (IS_GEN5(dev) || IS_GEN6(dev))dev_priv->lvds_use_ssc = 0; if (dev_priv->lvds_use_ssc) { if (IS_I85X(dev))--
Ugh, looks like I have confused things horribly. Sorry about this.
2.6.37-rc8 with no patches works for me. My original report was incorrect -- I was using -rc7 when I thought I was using -rc8. :(
Can you confirm that the above doesn't break your setup just in case we need to apply it?
Yes, confirmed, my test platform still works with this patch applied.
--- ~Randy *** Remember to use Documentation/SubmitChecklist when testing your code *** desserts: http://www.xenotime.net/linux/recipes/
On Wed, 29 Dec 2010 11:40:04 -0800, Linus Torvalds torvalds@linux-foundation.org wrote:
On Wed, Dec 29, 2010 at 10:21 AM, Randy Dunlap randy.dunlap@oracle.com wrote:
The only significant difference that I can see in the kernel message log is this:
Hmm. I suspect that difference should have gone away with commit 92971021c6328 (Revert "drm: Don't try and disable an encoder that was never enabled"), but clearly that didn't fix your blank screen.
Does reverting commit 448f53a1ede54eb854d036abf54573281412d650 ("drm/i915/bios: Reverse order of 100/120 Mhz SSC clocks") fix it for you? It does for some people..
Chris - why did that lvds_ssc_freq thing suddenly start mattering? Can we please just disable spread-spectrum entirely? Or perhaps only if we notice that it was enabled already? Or something?
It appeared to be the easiest fix for the machines I had to hand and was confirmed by several people with identical machines. However, it definitely caused a regression for working panels and therefore it will be reverted. -Chris
dri-devel@lists.freedesktop.org
-
Alex Riesen -
Chris Wilson -
François Valenduc -
Jesse Barnes -
Linus Torvalds -
Randy Dunlap