Bug 34618 - Slow text scrolling on tty after suspend-cycle
Summary: Slow text scrolling on tty after suspend-cycle
Status: RESOLVED FIXED
Alias: None
Product: DRI
Classification: Unclassified
Component: DRM/Radeon (show other bugs)
Version: XOrg git
Hardware: x86-64 (AMD64) Linux (All)
: medium normal
Assignee: Default DRI bug account
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-02-23 07:26 UTC by Peter Weber
Modified: 2011-04-11 00:17 UTC (History)
0 users

See Also:
i915 platform:
i915 features:


Attachments
output of glxinfo (23.62 KB, text/plain)
2011-02-23 08:05 UTC, Peter Weber
no flags Details
output of dmesg (53.75 KB, text/plain)
2011-02-23 08:05 UTC, Peter Weber
no flags Details
.config of kernel 2.6.38-rc6 (63.65 KB, application/octet-stream)
2011-02-23 08:06 UTC, Peter Weber
no flags Details
output of lspci (2.11 KB, text/plain)
2011-02-23 08:06 UTC, Peter Weber
no flags Details
list of installed packages (13.15 KB, text/plain)
2011-02-23 08:07 UTC, Peter Weber
no flags Details
lowres video mpeg (719.68 KB, application/octet-stream)
2011-02-23 11:47 UTC, Peter Weber
no flags Details
dmesg from kernel 2.6.37.2 (scrolling fine) (47.24 KB, application/octet-stream)
2011-03-05 05:17 UTC, Peter Weber
no flags Details
dmesg of kernel 2.6.39-rc1 with x86 PAT (37.10 KB, text/plain)
2011-03-31 10:07 UTC, Peter Weber
no flags Details
dmesg of kernel 2.6.39-rc1 without x86 PAT (44.34 KB, text/plain)
2011-03-31 10:08 UTC, Peter Weber
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Peter Weber 2011-02-23 07:26:20 UTC
Hello,
I upgraded from kernel-2.6.37 to kernel-2.6.38-rc6 today, before that upgrade the bug was also present but only sometimes (1 in 10). Because this now happens while after every suspsend-cycle this is definitely reproduceable. When I suspend with "pm-suspend" and resume the computer from suspend, the scrolling on the tty windows is extremly slow.

Reproduce:
1. Use a tty with KMS
2. #pm-suspend
3. resume from suspend
4. launch a command which requires to scroll the output on the tty, like "dmesg"

Other applications also draw "slow" like fbi (part of fbida, a imageviewer for the framebuffer).
Comment 1 Peter Weber 2011-02-23 08:05:12 UTC
Created attachment 43705 [details]
output of glxinfo
Comment 2 Peter Weber 2011-02-23 08:05:47 UTC
Created attachment 43706 [details]
output of dmesg
Comment 3 Peter Weber 2011-02-23 08:06:11 UTC
Created attachment 43707 [details]
.config of kernel 2.6.38-rc6
Comment 4 Peter Weber 2011-02-23 08:06:30 UTC
Created attachment 43708 [details]
output of lspci
Comment 5 Peter Weber 2011-02-23 08:07:02 UTC
Created attachment 43709 [details]
list of installed packages
Comment 6 Peter Weber 2011-02-23 08:08:59 UTC
Following environment variables are set:

export R600_ENABLE_S3TC=1
export vblank_mode=0
Comment 7 Alex Deucher 2011-02-23 08:11:42 UTC
Just to clarify, is scrolling slow in X or the console after resume?  Can you bisect?
Comment 8 Peter Weber 2011-02-23 09:06:36 UTC
Console! On X11 everything seems still to be fine.

At the moment I have not enough time for bisect, maybe at the weekend. But to clarify, the bug itself exists a long time ago (as far as I remember), but with the current 2.6.38-r6 is reproducable:
Because it occours now after nearly every suspend cycle (9 of 10, and not like before in 1 of 10)
Comment 9 Peter Weber 2011-02-23 10:53:55 UTC
http://linux.derkeiler.com/Mailing-Lists/Kernel/2011-01/msg00351.html

Looks very similar.
I can't approve that pressing a single button or generating load on the machine speeds up scrolling, but after changing the tty and switching back the output is (of course) completely printed to the terminal.
Comment 10 Alex Deucher 2011-02-23 11:00:09 UTC
I'm guessing this is an issue with pat or mtrrs on the fb mapping after resume.
Comment 11 Peter Weber 2011-02-23 11:06:54 UTC
Should I compile a kernel without MTRR an test it? I don't know how to switch of PAT, does it depend on MTRR?
Comment 12 Peter Weber 2011-02-23 11:46:18 UTC
I will try to give you some more "input":
I rebootet my computer, started "dmesg" on different tty's =
everyting fine.
Than I suspend the machine three times =
everything fine (I expected slow scrolling on all tty's!)
Than I suspend the machine on tty1 while leaving fbi open with a picture on tty2 =
scrolling fine on tty2, scrolling slow on tty1

Now I logged in X11 (Gnome) and tty3 (by the way, scrolling on tty3 was fast).
Than I suspend the machine again =
scrolling again slow on tty1, again fast on tty2 and slow on tty3


It so - uncertain. So I decided to do some reboots and tests, I also captured two videos!
I've rebooted three times, suspended the computer and every time the output on all tty's were scrolling slow!

I have taken two videos, one lowres (160x mpg) and one highres (640x mpg). I will upload the lowres if bugzilla allows this.
Comment 13 Peter Weber 2011-02-23 11:47:23 UTC
Created attachment 43725 [details]
lowres video mpeg
Comment 14 Peter Weber 2011-02-23 11:55:23 UTC
You can "see":
1. computer after bootup and login on tty1-tty4
2. tty2: dmesg (scrolling fast)
3. tty2: pm-suspend
4. tty2: resume from suspend (thanks to your prior work very fast)
5. tty2: dmesg (scrolling slow)
6. tty2: switch to tty1 // if done this, because dmesg needs a half minute or more with slow scrolling
7. tty1: switch to tty2
8. tty2: complete ouput of dmesg
Comment 15 Alex Deucher 2011-02-23 11:59:40 UTC
(In reply to comment #11)
> Should I compile a kernel without MTRR an test it? I don't know how to switch
> of PAT, does it depend on MTRR?

If you disable pat or mtrrs it will likely be slow since you won't get write combining on the mmaped fb.
Comment 16 Peter Weber 2011-02-23 12:01:33 UTC
So I will not do this.
Comment 17 Peter Weber 2011-02-25 00:07:48 UTC
Tomorrow I have maybe time for bisect. Can you tell me directory-paths to constrain the search?
Comment 18 Peter Weber 2011-02-25 00:16:40 UTC
Kerneltrap seem to be the better source:
http://kerneltrap.org/mailarchive/linux-kernel/2011/1/4/4665968
Comment 19 Peter Weber 2011-03-05 05:17:08 UTC
Downgraded to 2.6.37.2 scrolling okay after suspsend-cycle.
Upgraded to 2.6.38-rc7 scrolling slow after suspend-cycle.

I can confirm that pressing any button for some seconds will speed up the terminal output to normal behaviour.

In some situations scrolling gets not immediately slow after resume form suspend, it occour after some seconds. I added a dmesg from 2.6.37.2 as comparsion.
Comment 20 Peter Weber 2011-03-05 05:17:55 UTC
Created attachment 44149 [details]
dmesg from kernel 2.6.37.2 (scrolling fine)
Comment 21 Peter Weber 2011-03-12 10:33:04 UTC
Still occurs with Linux-Kernel 2.6.38-rc8
Comment 22 Peter Weber 2011-03-30 06:56:43 UTC
Scrolling is still painfully slow after a suspend-cycle with kernel 2.6.39-rc1. Working with tools like less is impossible :-(

Interesting: After a suspend-cycle normally not every virtual-terminal is affected, most times one or two vt still working fast. Here an example:
1. Boot
2. pm-suspend on vt2
3. resume from suspend
4. everyting still works fine!
5. pm-suspend on vt2
6. resume from suspend
7. scrolling is slow on vt1, vt3, vt4 but not on vt2

Sometimes pressing a button helps to speed up the scrolling. Not always, after a logout/login on a vt pressing a button while scrolling maybe doesn't work anymore.
Comment 23 Ortwin Glück 2011-03-31 00:07:14 UTC
Could it be messed up MTRRs? Just an idea...
Comment 24 Peter Weber 2011-03-31 09:25:29 UTC
(In reply to comment #10)
> I'm guessing this is an issue with pat or mtrrs on the fb mapping after resume.

(In reply to comment #23)
> Could it be messed up MTRRs? Just an idea...

The bug is caused by PAT and not MTRR!

I decided switching off MTRR was a try worth. The terminal scrolls without MTRR as slow as after a suspend-cycle, so I played around with the options: And finally switch on MTRR but PAT off!



1. General Setup
 [*]Configure standard kernel features (expert...)
2. Processor type and features
 [*]MTRR support
 [*]MTRR cleanup
 [ ]x86 PAT support

I'am so glad to know what causes this problem.

PS: I think my average fps in ioquake3 increased about 5% without x86 PAT.
Comment 25 Peter Weber 2011-03-31 10:07:47 UTC
Created attachment 45094 [details]
dmesg of kernel 2.6.39-rc1 with x86 PAT
Comment 26 Peter Weber 2011-03-31 10:08:26 UTC
Created attachment 45096 [details]
dmesg of kernel 2.6.39-rc1 without x86 PAT
Comment 27 Peter Weber 2011-04-05 07:56:07 UTC
No ideas?
Comment 28 Peter Weber 2011-04-09 12:12:42 UTC
Bug seem to be completely fixed with vanilla kernel-2.6.39-rc2.
I will review the changelog, maybe I find something.


:-)
Comment 29 Peter Weber 2011-04-11 00:17:02 UTC
commit 84ac7cdbdd0f04df6b96153f7a79127fd6e45467
Author: Suresh Siddha <suresh.b.siddha@intel.com>
Date:   Tue Mar 29 15:38:12 2011 -0700

    x86, mtrr, pat: Fix one cpu getting out of sync during resume
    
    On laptops with core i5/i7, there were reports that after resume
    graphics workloads were performing poorly on a specific AP, while
    the other cpu's were ok. This was observed on a 32bit kernel
    specifically.
    
    Debug showed that the PAT init was not happening on that AP
    during resume and hence it contributing to the poor workload
    performance on that cpu.
    
    On this system, resume flow looked like this:
    
    1. BP starts the resume sequence and we reinit BP's MTRR's/PAT
       early on using mtrr_bp_restore()
    
    2. Resume sequence brings all AP's online
    
    3. Resume sequence now kicks off the MTRR reinit on all the AP's.
    
    4. For some reason, between point 2 and 3, we moved from BP
       to one of the AP's. My guess is that printk() during resume
       sequence is contributing to this. We don't see similar
       behavior with the 64bit kernel but there is no guarantee that
       at this point the remaining resume sequence (after AP's bringup)
       has to happen on BP.
    
    5. set_mtrr() was assuming that we are still on BP and skipped the
       MTRR/PAT init on that cpu (because of 1 above)
    
    6. But we were on an AP and this led to not reprogramming PAT
       on this cpu leading to bad performance.
    
    Fix this by doing unconditional mtrr_if->set_all() in set_mtrr()
    during MTRR/PAT init. This might be unnecessary if we are still
    running on BP. But it is of no harm and will guarantee that after
    resume, all the cpu's will be in sync with respect to the
    MTRR/PAT registers.
    
    Signed-off-by: Suresh Siddha <suresh.b.siddha@intel.com>
    LKML-Reference: <1301438292-28370-1-git-send-email-eric@anholt.net>
    Signed-off-by: Eric Anholt <eric@anholt.net>
    Tested-by: Keith Packard <keithp@keithp.com>
    Cc: stable@kernel.org	[v2.6.32+]
    Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>


-------------------------------------------------------------------------------
I will write an email to everyone, that this bug occurs also on Corei5/7 in 64bit Long-Mode.

Thanks for your help.


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.