Bug 599190 - Issue with kslowd and kernel 2.3.34-14 an newer
Issue with kslowd and kernel 2.3.34-14 an newer
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
14
All Linux
low Severity medium
: ---
: ---
Assigned To: Kyle McMartin
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2010-06-02 16:02 EDT by Karsten Roch
Modified: 2015-08-31 23:53 EDT (History)
14 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2010-08-07 00:26:34 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Karsten Roch 2010-06-02 16:02:51 EDT
Description of problem:

I updated rawhide from kernel 2.6.34-11.fc14.i686 to 2.6.34-14.fc14.i686. Since then, i see a short flickering of the screen each 5-10 seconds. The programm "top" shows me a process "kslowd000" or "kslowd001", which pops up at top of the list for a few moments, each time the screen is flickering. 

My old kernel 2.6.34-11.fc14.i686 doesn't show this behaviour. Today i installed kernel-2.6.34-18.fc14.i686, this kernel shows the same problem.
 

Version-Release number of selected component (if applicable):
kernel 2.6.34-14.fc14.i686
kslowd

How reproducible:
Always.

Steps to Reproduce:
1. Boot into rawhide, watch the screen flickering every few seconds.
2.
3.
  
Actual results:
watch the screen flickering every few seconds.

Expected results:
No flickering of the screen.



Additional info:
Hardware: AMD Athlon(tm) 64 X2 Dual Core Processor 4200+, nVidia Corporation G98 [GeForce 8400 GS] (rev a1)
Comment 1 Stanislaw Gruszka 2010-06-05 07:03:34 EDT
From change log:

* Mon May 31 2010 Kyle McMartin <kyle@redhat.com> 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@redhat.com>
- config-generic: Stop building i830.ko

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

* Fri May 21 2010 Roland McGrath <roland@redhat.com> 2.6.34-11
- utrace update

I suppose drm-next patch make troubles here.
Comment 2 Kyle McMartin 2010-06-06 05:41:21 EDT
Update to the one with radeon_pm off.
Comment 3 Karsten Roch 2010-06-07 15:55:28 EDT
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
Comment 4 Kyle McMartin 2010-06-07 17:46:27 EDT
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
Comment 5 Karsten Roch 2010-06-08 13:55:43 EDT
Sure, let me know, what to test. 

Karsten
Comment 6 Nicolas Kaiser 2010-06-18 14:16:23 EDT
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
Comment 7 Nicolas Kaiser 2010-06-18 16:57:01 EDT
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.
Comment 8 Francesco Frassinelli (frafra) 2010-06-19 04:27:26 EDT
Same problem here, with an HDMI monitor.
Comment 9 Kyle McMartin 2010-06-21 09:08:49 EDT
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
Comment 10 Nicolas Kaiser 2010-06-21 14:59:35 EDT
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.
Comment 11 Karsten Roch 2010-06-21 15:30:57 EDT
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
Comment 12 Kyle McMartin 2010-06-21 16:11:46 EDT
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.)
Comment 13 Kyle McMartin 2010-06-21 18:05:15 EDT
http://koji.fedoraproject.org/koji/taskinfo?taskID=2263689 if you please.
Comment 14 Francesco Frassinelli (frafra) 2010-07-13 07:24:40 EDT
Here in Rawhide (2.6.35-0.31.rc4.git4.fc14.i686) it's fixed :)
Comment 15 Dave Airlie 2010-07-20 01:19:59 EDT
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.
Comment 16 Bug Zapper 2010-07-30 07:47:38 EDT
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
Comment 17 Jaroslav Pulchart 2010-11-03 08:19:11 EDT
I experienced this issue in F14 with kernel 2.6.35.6-48.fc14.x86_64 on my laptop (Lenovo T400).
Comment 18 Adam Stokes 2010-12-22 11:59:19 EST
(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.

Note You need to log in before you can comment on or make changes to this bug.