Can you attach your video rom to the bug?

# cd /sys/devices/pci0000\:00/0000\:00\:02.0/
# echo 1 > rom
# cat rom > /tmp/rom.bin
# echo 0 > rom

Created attachment 20064 [details]
Video ROM

(In reply to comment #1)
> Can you attach your video rom to the bug?
 
Video ROM was attached.  Is there anything else I can help with on this issue (e.g. verify anything in gdb, or whatever)?

Note that "bad" Xorg.log mentions
(WW) intel(0): Chosen PLL clock of 66.5 Mhz more than 2% away from desired 65.0 Mhz

I wonder if the mode detection ordering change is what bit you here.  If so, this patch might help, can you give it a try?  Also I think there might be a use after free bug in the code (now that I review it again), so the xf86DuplicateMode change might help with that.

diff --git a/src/i830_lvds.c b/src/i830_lvds.c       
index 0d67d50..7f632f1 100644                        
--- a/src/i830_lvds.c                                
+++ b/src/i830_lvds.c                                
@@ -1281,12 +1281,14 @@ i830_lvds_init(ScrnInfoPtr pScrn)
            scan->prev = scan->next;                     
        if (scan->next != NULL)                          
            scan->next = scan->prev;                     
-       lvds_ddc_mode = scan;                            
+       lvds_ddc_mode = xf86DuplicateMode(scan);         
     }                                                   
     /* Delete the mode list */                          
     while (modes != NULL)                               
        xf86DeleteMode(&modes, modes);                   
                                                         
+    pI830->lvds_fixed_mode = lvds_ddc_mode = NULL;      
+                                                        
     if (lvds_ddc_mode) {                                
            pI830->lvds_fixed_mode = lvds_ddc_mode;      
            goto found_mode;                             

(In reply to comment #4)
> I wonder if the mode detection ordering change is what bit you here.  If so,
> this patch might help, can you give it a try?  Also I think there might be a
> use after free bug in the code (now that I review it again), so the
> xf86DuplicateMode change might help with that.

I have built current 2.4 branch with this patch and the described problem is gone for me (previously it was experienced with every X start).  The (probably unrelated) only symptom left is random black&white dots in text console after VT switch, but I absolutely do not mind ).

xrandr output is back to normal, and the mentioned warning is gone from Xorg.log.

Does the problem come back if you remove the
  pI830->lvds_fixed_mode = lvds_ddc_mode = NULL;
line?

(In reply to comment #6)
> Does the problem come back if you remove the
>   pI830->lvds_fixed_mode = lvds_ddc_mode = NULL;
> line?
> 

Yes it does.

I raised the original Ubuntu bug report.. do you have a build I can test? my xrandr output is different between hardy and intrepid, but not as obviously different as your machine..

(In reply to comment #4)
> I wonder if the mode detection ordering change is what bit you here.  If so,
> this patch might help, can you give it a try?  Also I think there might be a
> use after free bug in the code (now that I review it again), so the
> xf86DuplicateMode change might help with that.

sorry, tried this on my laptop and it still flickers.. xrandr output is unchanged, still only one frequency listed, which is not the same as when I run hardy (no flicker).

intrepid xrandr:

Screen 0: minimum 320 x 200, current 1280 x 800, maximum 1280 x 1280
VGA disconnected (normal left inverted right x axis y axis)
LVDS connected 1280x800+0+0 (normal left inverted right x axis y axis) 331mm x 207mm
   1280x800       60.0*+
   1024x768       60.0  
   800x600        60.3  
   640x480        59.9  

hardy xrandr:

Screen 0: minimum 320 x 200, current 1280 x 800, maximum 1280 x 1280
VGA disconnected (normal left inverted right x axis y axis)
LVDS connected 1280x800+0+0 (normal left inverted right x axis y axis) 331mm x 207mm
   1280x800       60.0*+   60.0  
   1280x768       60.0  
   1024x768       60.0  
   800x600        60.3  
   640x480        59.9  

the other thing that is odd is the modeline being reported in the Xorg log:

(II) intel(0): Modeline "1280x800"x0.0   68.90  1280 1301 1333 1408  800 804 808 816 -hsync -vsync (48.9 kHz)

isn't that asking for a 68.9Hz refresh rate?

I have build versions 2.4.1 (Ubuntu 8.10) and 2.5.0 (Fedora 10) with patch from comment #4, but flickering is still here, in both cases

Created attachment 21283 [details] [review]
adjust display clock calculation values

Ahh, so actually it looks like the pixel clock calculation might be to blame here.  We set it higher than it should be and it looks like that causes pipe underruns which would cause flickering.

Can you try this patch from Ma Ling that adjusts our calculations a little?

Adding Ma Ling to CC list.

(In reply to comment #11)
> Created an attachment (id=21283) [details]
> adjust display clock calculation values
> 
> Ahh, so actually it looks like the pixel clock calculation might be to blame
> here.  We set it higher than it should be and it looks like that causes pipe
> underruns which would cause flickering.
> 
> Can you try this patch from Ma Ling that adjusts our calculations a little?

tried it.. still flickers. sorry. anything I can get which might help with diagnosis? this was actually with both patches applied, BTW.

I'm getting the same problem. 
Using Arch Linux and when they updated the intel driver it started flickering.
Tried using the latest driver from GIT and it made no difference.
Tried applying the patch mentioned and it made no difference.
Only thing that fixed it was reverting to an older driver. 
Bug still flagged as NEEDINFO, what information could I supply that would help?
Thanks
Dave

*** Bug 19703 has been marked as a duplicate of this bug. ***

Created attachment 22327 [details] [review]
dump FIFO watermark values

So far, all we know is that people are seeing lots of underruns with the VBT derived mode line, and that one difference is that with the VBT modeline we get a higher pixelclock value than we used to.  This patch should make the intel_reg_dumper too dump the FWATER_BLC values, can someone apply it and attach the output of the tool to this bug?  (You only need to apply the i830_debug.c portion of the patch, though the other bits might be fun to play with too.)

(In reply to comment #16)
> Created an attachment (id=22327) [details]
> dump FIFO watermark values
> 
> So far, all we know is that people are seeing lots of underruns with the VBT
> derived mode line, and that one difference is that with the VBT modeline we get
> a higher pixelclock value than we used to.  This patch should make the
> intel_reg_dumper too dump the FWATER_BLC values, can someone apply it and
> attach the output of the tool to this bug?  (You only need to apply the
> i830_debug.c portion of the patch, though the other bits might be fun to play
> with too.)

OK, I've attached the output under both ubuntu intrepid (flicker), and I managed to hack a version that will run on ubuntu hardy too. it's clear from diffing the two dumps that under hardy, pipe A is marked as disabled in several places - in intrepid, it's enabled. also, the dot clock on pipe B is very different (intrepid: 45459, hardy: 69142). the patch for showing the FWATER_BLC variables shows they are the same on both..

Created attachment 22789 [details]
intel register dump under ubuntu hardy

Created attachment 22790 [details]
intel register dump under ubuntu intrepid

Created attachment 22791 [details]
intel_reg_dumper

this is a static build of the intel_reg_dumper that will work on both ubuntu hardy and intrepid.

obviously, you should think carefully before running (as root!) an untrusted binary you just found on a website...

OTOH it might be helpful for tracking this bug down..

might be an ssc clock issue as well...? 852 isn't set to use 66/48 , rather use 100/96, which seems wrong...

Created attachment 23742 [details]
please try the patch on your machine

An external SSC clock synthesizer can be used to provide the 48/66-MHz reference clock into the GMCH Pipe B PLL.

thanks
Ma Ling

ping ~

@MaLing:

i confirm your patch fixes the flickering for me !

i tested your patch on the 2.6.3 version (i patched the ubuntu jaunty xserver-xorg-video-intel_2.6.3-0ubuntu2)

being forced to use the vesa driver for about a year now, i'm happy to use the intel driver again, thanks !

I forgot to mention that i tested the patch with the following hw:
Intel Corporation 82852/855GM Integrated Graphics Device (rev 02)

Great, looks like a good patch.  I'll go ahead and push it.

commit 85e6b528582c2397ee9eb2132cd0d05ce12eb43d                                 
Author: Ma Ling <ling.ma@intel.com>                                             
Date:   Thu Mar 19 09:10:19 2009 -0700                                          

    Set SSC frequency for 8xx chips correctly

(In reply to comment #27)
> commit 85e6b528582c2397ee9eb2132cd0d05ce12eb43d                                 
> Author: Ma Ling <ling.ma@intel.com>                                             
> Date:   Thu Mar 19 09:10:19 2009 -0700                                          
> 
>     Set SSC frequency for 8xx chips correctly
> 

apologies for the delay.. but your patch fixes the flicker issue for me too... fantastic. I've tried it on ubuntu intrepid - that's v2.4.1 of the driver.

I still get occasional warnings in the log.. don't know if they are serious?

(EE) intel(0): tried to update DSPARB with both planes enabled!
(II) intel(0): EDID vendor "AUO", prod id 3853
(II) intel(0): Printing DDC gathered Modelines:
(II) intel(0): Modeline "1280x800"x0.0   68.90  1280 1301 1333 1408  800 804 808 816 -hsync -vsync (48.9 kHz)
(II) intel(0): EDID vendor "AUO", prod id 3853

Created attachment 24064 [details]
just for completeness, the intel_reg_dumper output with the fix applied

(In reply to comment #28)
> I still get occasional warnings in the log.. don't know if they are serious?
> 
> (EE) intel(0): tried to update DSPARB with both planes enabled!

I think this is fixed in master as well, or is this log from master?

(In reply to comment #30)
> (In reply to comment #28)
> > I still get occasional warnings in the log.. don't know if they are serious?
> > 
> > (EE) intel(0): tried to update DSPARB with both planes enabled!
> 
> I think this is fixed in master as well, or is this log from master?

ahh, no, this is with the patch applied to the ubuntu intrepid 2.4.1 version.. so there's a good chance it's missing other patches. that's fine..