Bug 599190

From change log:

* Mon May 31 2010 Kyle McMartin <kyle> 2.6.34-14
- re-add drm-next.patch, should be in sync with 2.6.35 and what
  was backported to Fedora 13.
- drop patches merged in drm-next to 2.6.35
- rebase relevant iwl fixes on top of 2.6.34 from the ones committed
  to F-13 by linville.

* Wed May 26 2010 Adam Jackson <ajax>
- config-generic: Stop building i830.ko

* Wed May 26 2010 Kyle McMartin <kyle>
- iwlwifi-recover_from_tx_stall.patch: copy from F-13.

* Fri May 21 2010 Roland McGrath <roland> 2.6.34-11
- utrace update

I suppose drm-next patch make troubles here.

Update to the one with radeon_pm off.

Today i found a really surprising solution. I used a different monitor (an ASUS VW 221, which fully supports edid-modes) and the flickering was gone. Changing back to the original monitor (an LG Flatron M1917A, which not supports edid-modes very well) on the fly, automatically brings up the flickering again. I'm not sure, what i should think about this...

I used kernel 2.6.34-20.fc14.i686 for my little test, this kernel shows the same behaviour like 2.6.34-14 and 2.6.34-18


Cordialement
Karsten

Thanks for the data point, I need to pull in some more of the drm fixes from 2.6.35-rc2, so can I get you to test a followup kernel on the original model in a day or so?

--Kyle

Sure, let me know, what to test. 

Karsten

Looks exactly like what I'm seeing here with kernel 2.6.35-rc3.

I ran latencytop, which reports kslowd000 and kslowd001 like this:

atom_op_delay atom_execute_table_locked atom_execu  6.8 msec        100.0 %detect radeon_vga_detect output_poll_execute slow_work_execute slow_work_thread kthread kernel_thread_helper

atom_op_delay atom_execute_table_locked atom_execu  5.7 msec        100.0 %detect radeon_vga_detect output_poll_execute slow_work_execute slow_work_thread kthread kernel_thread_helper


Hardware: AMD Phenom(tm) 9350e, ATI Radeon HD 3200
A single Monitor connected via HDMI, and there's an unused VGA connector:

[drm] Radeon Display Connectors
[drm] Connector 0:
[drm]   VGA
[drm]   DDC: 0x7e40 0x7e40 0x7e44 0x7e44 0x7e48 0x7e48 0x7e4c 0x7e4c
[drm]   Encoders:
[drm]     CRT1: INTERNAL_KLDSCP_DAC1
[drm] Connector 1:
[drm]   HDMI-A
[drm]   HPD3
[drm]   DDC: 0x7e50 0x7e50 0x7e54 0x7e54 0x7e58 0x7e58 0x7e5c 0x7e5c
[drm]   Encoders:
[drm]     DFP1: INTERNAL_KLDSCP_LVTMA

I just found out that connecting the monitor via VGA instead of HDMI, here this latency is gone.

The monitor is a Samsung SyncMaster T260.

Same problem here, with an HDMI monitor.

http://koji.fedoraproject.org/koji/taskinfo?taskID=2262023

I think this is caused by fbf8176. Please try this build (2.6.34-44) with it reverted and let me know if it fixes the flickering.

If not, please note which driver you are using (radeon, nouveau, or i915) and which connectors you are using (dvi, vga, hdmi, dp, etc.)

regards, Kyle

Thanks for your effort, but it didn't help.

I bisected the flickering to commit eb1f8e4f3be898df808e2dfc131099f5831d491d
"drm/fbdev: rework output polling to be back in the core. (v4)"

Driver radeon, connectors as above.

I tried today the following:



Using kernel 2.6.34-44 with the D-Sub 15 analog output on my nvidia GS8400 with driver nouveau:  Flickering gone.

Using kernel 2.6.34-44 with the DVI output (DVI-to-DSUB 15 cable) on my nvidia GS8400 with driver nouveau:  Flickering exists.


Using kernel 2.6.34-44 with the DVI output (DVI Adapter with DSUB 15 cable) on my nvidia GS8400 with driver nouveau:  Flickering exists.


Using kernel 2.6.34-43 with the D-Sub 15 analog output on my nvidia GS8400 with driver nouveau:  Flickering gone.

Using kernel 2.6.34-43 with the DVI output (DVI-to-DSUB 15 cable) on my nvidia GS8400 with driver nouveau:  Flickering exists.


Using kernel 2.6.34-43 with the DVI output (DVI Adapter with DSUB 15 cable) on my nvidia GS8400 with driver nouveau:  Flickering exists.


So it seems, the problem is related to the DVI-Output, at least on my existing configuration. 


Regards
Karsten

Thanks, I'm doing a test build to confirm I reverted it properly on top of the other fixes... If it succeeds I'll commit it and push it out. (Sorry, I can't test it locally, it only appears to strike nouveau/radeon as opposed to i915.)

http://koji.fedoraproject.org/koji/taskinfo?taskID=2263689 if you please.

Here in Rawhide (2.6.35-0.31.rc4.git4.fc14.i686) it's fixed :)

I'm not sure this commit is the problem it doesn't make much sense to cause any issues since it is only called on switchable GPU notebooks.

This bug appears to have been reported against 'rawhide' during the Fedora 14 development cycle.
Changing version to '14'.

More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

I experienced this issue in F14 with kernel 2.6.35.6-48.fc14.x86_64 on my laptop (Lenovo T400).

(In reply to comment #17)
> I experienced this issue in F14 with kernel 2.6.35.6-48.fc14.x86_64 on my
> laptop (Lenovo T400).

Still seeing this on T400 with -68 kernel. The screen flickering is not as much of a concern as kslowdX using up all available cpu cycles and causing the OS to respond sluggishly.

Also reproducing this problem on a T400 is as simple as putting the laptop into suspend and waking up.