Bug 29821

Created attachment 38183 [details]
dmesg from last working kernel

Created attachment 38184 [details]
dmesg from jbarnes kernel

Created attachment 38185 [details]
intel_reg_dump from last working kernel

Created attachment 38186 [details]
intel_reg_dump from jbarnes kernel

Created attachment 38187 [details]
vbios from last working kernel

Created attachment 38188 [details]
vbios again...  I presume it shouldn't have changed ;-)

Consistency is the hobgoblins of this small mind.

Created attachment 38189 [details]
Xorg log file from last working kernel boot

Created attachment 38190 [details]
Xorg log file from jbarnes kernel

Created attachment 38191 [details]
xrandr from last working kernel

Created attachment 38192 [details]
xrandr from jbarnes kernel

System environment: 
-- chipset: Arrandale 
-- system architecture: x86_64
-- xf86-video-intel: 2:2.12.0-1ubuntu3
-- xserver: 2:1.9.0-0ubuntu1
-- mesa: 7.8.2-2ubuntu2
-- libdrm: 2.4.21-1ubuntu2
-- kernel: jbarnes kernel
-- Linux distribution: Ubuntu Maverick
-- Machine or mobo model: HP 2540p
-- Display connector: Internal

Reproducing steps:

Boot the system.  It starts flashing the screen almost immediately, long before X is running. (by flashing I mean the video seems to be turned on and off).  The flashing is non-periodic, around 1-2hz

Additional info:
The Ubuntu gradient background shows problems as well; it is not smooth, so something is pretty broken in video land.

Interestingly, a kernel I built yesterday with PREEMPT set does not flash.  It does show the other video problem (limited color depth resolution).

Yeah I've noticed something strange with the panel dithering on my system as well.

The fact that PREEMPT makes the flashing go away could indicate we're spending a lot of time blocked in the kernel somewhere.  Can you collect a profile or look at 'perf top' while the flashing is occurring?  It might give us a clue about where we're spending time.

Created attachment 38369 [details]
perf-top from a "flashing" kernel

OK, I loaded one of the N kernels I have that "flashes", and did a perf top on it.

File is attached.

I have the same problem with 2540P. I use Debian AMD64 Squeeze Version. I tried 2.6.35-trunk kernel from debian experimental. It flashes at bootup. Bot for me it seems that it only flashes in X. If I do suspend to ram and awake, flashing is nearly gone.
For me flashing means display on/off 2Hz for 2 seconds and then there could be a time period of 15-30 minutes where the display is OK.
I tried vanilla 2.6.35.3 kernel, flashing is there. I tried this kernel with PREEMPT, it does not bootup :(
TOday I tried 2.6.36 rc3 PREEMPT. It bootup. But flashes again.
Should I generate outputs?

Can you try the drm-ickle-next branch from
git://git.kernel.org/pub/scm/linux/kernel/git/jbarnes/drm-intel.git?

It has a couple more eDP related fixes and also includes a patch to disable self-refresh which prevents a lot of bad behavior.

(In reply to comment #16)
> Can you try the drm-ickle-next branch from
> git://git.kernel.org/pub/scm/linux/kernel/git/jbarnes/drm-intel.git?
> 
> It has a couple more eDP related fixes and also includes a patch to disable
> self-refresh which prevents a lot of bad behavior.

No luck; same flashing symptoms.  I think you did fix the dithering problem though...

I'm using Gnome. I did already mention that after resume from "suspend to ram" the flashing is gone. But if I wait for the screensaver/ display power off because of inactivity the display again flashes after pressing any key.

From looking at the date, the following commit seems to have been pulled into the kernel after 2.6.35-rc6.  Could it be the source of the flashing problem?

commit 5620ae29f1eabe655f44335231b580a78c8364ea
Author: Jesse Barnes
Date:   Mon Jul 26 13:51:22 2010 -0700

    drm/i915: make sure we shut off the panel in eDP configs
    
    Fix error from the last pull request.  Making sure we shut the panel off
    is more correct and saves power.
    
    Signed-off-by: Jesse Barnes
    Signed-off-by: Linus Torvalds

I would really like to help anyone working on this bug. Is there anything I can do? 

I still have this problem on a fully updated maverick on a HP Elitebook 2540p. I've tried all different kind of kernels, but the only one working (i.e., that does not have the flashing issue) for me, so far, is linux-image-2.6.35-020635rc6.

Thanks for doing all the hard work for us "ordinary" users!

(In reply to comment #20)
> I would really like to help anyone working on this bug. Is there anything I can
> do? 
> 

If you are up to building kernels from git, then join the #intel-gfx channel and help by testing.  Jesse Barnes (jbarnes) and Chris Wilson have a kernel that needs testing; I've not been feeling very well this week and have been busy on other things with the energy I have remaining, so haven't had a chance to test the kernel Jesse thinks might fix it.

There is stuff in the ubuntu wiki about building and testing such kernels; it's not terribly hard.

(In reply to comment #21)
> (In reply to comment #20)
> > I would really like to help anyone working on this bug. Is there anything I can
> > do? 
> > 
> 
> If you are up to building kernels from git, then join the #intel-gfx channel
> and help by testing.  Jesse Barnes (jbarnes) and Chris Wilson have a kernel
> that needs testing; I've not been feeling very well this week and have been
> busy on other things with the energy I have remaining, so haven't had a chance
> to test the kernel Jesse thinks might fix it.
> 
> There is stuff in the ubuntu wiki about building and testing such kernels; it's
> not terribly hard.

Jesse's latest patches in his git discussed in the thread "[Intel-gfx] PCH eDP fixes" worked for me, at least to give me a stable display.

Suspend does not work, however (of course, it didn't work on the much older kernel that ran, so we're still in better shape than we were...).

Great, thanks for confirming Jim.

OK, as you know, suspend and resume still doesn't work.

It also takes about five seconds from touching a key while the panel is turned off before it turns on.

dmesg is also telling me:

[16900.450801] [drm:ironlake_edp_panel_on] *ERROR* panel on wait timed out: 0xc0000008

Oops, my panel on timeout check isn't quite correct.  In your case the panel is ready as expected and the mask check isn't accounting for that.  Bitwise anding the idle_on_mask before checking for equality is probably the best fix.  That should get rid of your timeouts and speed up the DPMS on path for you.

Created attachment 39349 [details] [review]
split mask & idle bits

Even better to split the mask and bit check into separate vars.

Looks like you committed locally, but didn't push to kernel.org, either by mistake or by intention.  I'll test Monday in either case...
           - Jim


(In reply to comment #26)
> Created an attachment (id=39349) [details]
> split mask & idle bits
> 
> Even better to split the mask and bit check into separate vars.

I actually wasn't going to update the tree, but since you mentioned it, I went ahead and rebased to ickle's latest bits and pushed this patch (along with a couple of others).

OK, xset dpms force off causes the screen to go off immediately, pressing a key gets the panel on in about 1 second (much much faster than before, but not as fast as I'd expect.

Dmesg says:

[  271.381859] hda-intel: IRQ timing workaround is activated for card #0. Suggest a bigger bdl_pos_adj.

Same suspend problem as before.


It comes back now
(In reply to comment #28)
> I actually wasn't going to update the tree, but since you mentioned it, I went
> ahead and rebased to ickle's latest bits and pushed this patch (along with a
> couple of others).

Interesting; the laptop will suspend/resume properly if I 
 echo -n mem > /sys/power/state


But if I use the system->shutdown menu entry, I get the hang.

I wonder whats the difference?

Well, I did some more experiments: suspend is just plain flaky, no matter how invoked.

When it fails to suspend, the fan starts to run faster in the machine, and the panel remains lit (with just a "-" character on the screen).  I suspect the driver caught in a loop someplace, hoping the display will respond, FWIW.  I'd be less suspicious of the display driver if the display came back on promptly after being turned off; the current driver takes about a second to get the panel lit up on this machine.

(In reply to comment #30)
> Interesting; the laptop will suspend/resume properly if I 
>  echo -n mem > /sys/power/state
> 
> 
> But if I use the system->shutdown menu entry, I get the hang.
> 
> I wonder whats the difference?

Here's additional information:

Suspend/resume is "flaky"; suspend fails of order 1/2 the time.

Xrandr reports a (null):

root@jg:~/Videos# xrandr
Screen 0: minimum 320 x 200, current 1280 x 800, maximum 8192 x 8192
(null)1 connected 1280x800+0+0 (normal left inverted right x axis y axis) 260mm x 160mm
   1280x800       60.0*+   40.3  
VGA1 disconnected (normal left inverted right x axis y axis)
HDMI1 disconnected (normal left inverted right x axis y axis)
DP1 disconnected (normal left inverted right x axis y axis)
HDMI2 disconnected (normal left inverted right x axis y axis)
DP2 disconnected (normal left inverted right x axis y axis)

If  I've resumed, and tell the flash player to go full screen, it does, but playback frame rate is glacial and broken. (maybe 1fps).  Works fine on first boot before the suspend/resume cycle.

                - Jim

Re comment 22 - does this relate to comment 16?

Do you happen to know in which kernel RC this fix was introduced?