https://bugs.freedesktop.org/show_bug.cgi?id=34618
Summary: Slow text scrolling on tty after suspend-cycle Product: DRI Version: XOrg CVS Platform: x86-64 (AMD64) OS/Version: Linux (All) Status: NEW Severity: normal Priority: medium Component: DRM/Radeon AssignedTo: dri-devel@lists.freedesktop.org ReportedBy: peterle@hottemptation.org
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).
https://bugs.freedesktop.org/show_bug.cgi?id=34618
--- Comment #1 from peterle@hottemptation.org 2011-02-23 08:05:12 PST --- Created an attachment (id=43705) --> (https://bugs.freedesktop.org/attachment.cgi?id=43705) output of glxinfo
https://bugs.freedesktop.org/show_bug.cgi?id=34618
--- Comment #2 from peterle@hottemptation.org 2011-02-23 08:05:47 PST --- Created an attachment (id=43706) --> (https://bugs.freedesktop.org/attachment.cgi?id=43706) output of dmesg
https://bugs.freedesktop.org/show_bug.cgi?id=34618
--- Comment #3 from peterle@hottemptation.org 2011-02-23 08:06:11 PST --- Created an attachment (id=43707) --> (https://bugs.freedesktop.org/attachment.cgi?id=43707) .config of kernel 2.6.38-rc6
https://bugs.freedesktop.org/show_bug.cgi?id=34618
--- Comment #4 from peterle@hottemptation.org 2011-02-23 08:06:30 PST --- Created an attachment (id=43708) --> (https://bugs.freedesktop.org/attachment.cgi?id=43708) output of lspci
https://bugs.freedesktop.org/show_bug.cgi?id=34618
--- Comment #5 from peterle@hottemptation.org 2011-02-23 08:07:02 PST --- Created an attachment (id=43709) --> (https://bugs.freedesktop.org/attachment.cgi?id=43709) list of installed packages
https://bugs.freedesktop.org/show_bug.cgi?id=34618
--- Comment #6 from peterle@hottemptation.org 2011-02-23 08:08:59 PST --- Following environment variables are set:
export R600_ENABLE_S3TC=1 export vblank_mode=0
https://bugs.freedesktop.org/show_bug.cgi?id=34618
--- Comment #7 from Alex Deucher agd5f@yahoo.com 2011-02-23 08:11:42 PST --- Just to clarify, is scrolling slow in X or the console after resume? Can you bisect?
https://bugs.freedesktop.org/show_bug.cgi?id=34618
--- Comment #8 from peterle@hottemptation.org 2011-02-23 09:06:36 PST --- 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)
https://bugs.freedesktop.org/show_bug.cgi?id=34618
--- Comment #9 from peterle@hottemptation.org 2011-02-23 10:53:55 PST --- 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.
https://bugs.freedesktop.org/show_bug.cgi?id=34618
--- Comment #10 from Alex Deucher agd5f@yahoo.com 2011-02-23 11:00:09 PST --- I'm guessing this is an issue with pat or mtrrs on the fb mapping after resume.
https://bugs.freedesktop.org/show_bug.cgi?id=34618
--- Comment #11 from peterle@hottemptation.org 2011-02-23 11:06:54 PST --- Should I compile a kernel without MTRR an test it? I don't know how to switch of PAT, does it depend on MTRR?
https://bugs.freedesktop.org/show_bug.cgi?id=34618
--- Comment #12 from peterle@hottemptation.org 2011-02-23 11:46:18 PST --- 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.
https://bugs.freedesktop.org/show_bug.cgi?id=34618
--- Comment #13 from peterle@hottemptation.org 2011-02-23 11:47:23 PST --- Created an attachment (id=43725) --> (https://bugs.freedesktop.org/attachment.cgi?id=43725) lowres video mpeg
https://bugs.freedesktop.org/show_bug.cgi?id=34618
--- Comment #14 from peterle@hottemptation.org 2011-02-23 11:55:23 PST --- 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
https://bugs.freedesktop.org/show_bug.cgi?id=34618
--- Comment #15 from Alex Deucher agd5f@yahoo.com 2011-02-23 11:59:40 PST --- (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.
https://bugs.freedesktop.org/show_bug.cgi?id=34618
--- Comment #16 from peterle@hottemptation.org 2011-02-23 12:01:33 PST --- So I will not do this.
https://bugs.freedesktop.org/show_bug.cgi?id=34618
--- Comment #17 from peterle@hottemptation.org 2011-02-25 00:07:48 PST --- Tomorrow I have maybe time for bisect. Can you tell me directory-paths to constrain the search?
https://bugs.freedesktop.org/show_bug.cgi?id=34618
--- Comment #18 from peterle@hottemptation.org 2011-02-25 00:16:40 PST --- Kerneltrap seem to be the better source: http://kerneltrap.org/mailarchive/linux-kernel/2011/1/4/4665968
https://bugs.freedesktop.org/show_bug.cgi?id=34618
--- Comment #19 from peterle@hottemptation.org 2011-03-05 05:17:08 PST --- 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.
https://bugs.freedesktop.org/show_bug.cgi?id=34618
--- Comment #20 from peterle@hottemptation.org 2011-03-05 05:17:55 PST --- Created an attachment (id=44149) --> (https://bugs.freedesktop.org/attachment.cgi?id=44149) dmesg from kernel 2.6.37.2 (scrolling fine)
https://bugs.freedesktop.org/show_bug.cgi?id=34618
--- Comment #21 from peterle@hottemptation.org 2011-03-12 10:33:04 PST --- Still occurs with Linux-Kernel 2.6.38-rc8
https://bugs.freedesktop.org/show_bug.cgi?id=34618
--- Comment #22 from peterle@hottemptation.org 2011-03-30 06:56:43 PDT --- 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.
https://bugs.freedesktop.org/show_bug.cgi?id=34618
--- Comment #23 from Ortwin Glück odi@odi.ch 2011-03-31 00:07:14 PDT --- Could it be messed up MTRRs? Just an idea...
https://bugs.freedesktop.org/show_bug.cgi?id=34618
--- Comment #24 from peterle@hottemptation.org 2011-03-31 09:25:29 PDT --- (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.
https://bugs.freedesktop.org/show_bug.cgi?id=34618
--- Comment #25 from peterle@hottemptation.org 2011-03-31 10:07:47 PDT --- Created an attachment (id=45094) --> (https://bugs.freedesktop.org/attachment.cgi?id=45094) dmesg of kernel 2.6.39-rc1 with x86 PAT
https://bugs.freedesktop.org/show_bug.cgi?id=34618
--- Comment #26 from peterle@hottemptation.org 2011-03-31 10:08:26 PDT --- Created an attachment (id=45096) --> (https://bugs.freedesktop.org/attachment.cgi?id=45096) dmesg of kernel 2.6.39-rc1 without x86 PAT
https://bugs.freedesktop.org/show_bug.cgi?id=34618
--- Comment #27 from peterle@hottemptation.org 2011-04-05 07:56:07 PDT --- No ideas?
https://bugs.freedesktop.org/show_bug.cgi?id=34618
--- Comment #28 from peterle@hottemptation.org 2011-04-09 12:12:42 PDT --- Bug seem to be completely fixed with vanilla kernel-2.6.39-rc2. I will review the changelog, maybe I find something.
:-)
https://bugs.freedesktop.org/show_bug.cgi?id=34618
peterle@hottemptation.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED
--- Comment #29 from peterle@hottemptation.org 2011-04-11 00:17:02 PDT --- 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.
dri-devel@lists.freedesktop.org
-
bugzilla-daemon＠freedesktop.org