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).
Created attachment 43705 [details] output of glxinfo
Created attachment 43706 [details] output of dmesg
Created attachment 43707 [details] .config of kernel 2.6.38-rc6
Created attachment 43708 [details] output of lspci
Created attachment 43709 [details] list of installed packages
Following environment variables are set: export R600_ENABLE_S3TC=1 export vblank_mode=0
Just to clarify, is scrolling slow in X or the console after resume? Can you bisect?
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)
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.
I'm guessing this is an issue with pat or mtrrs on the fb mapping after resume.
Should I compile a kernel without MTRR an test it? I don't know how to switch of PAT, does it depend on MTRR?
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.
Created attachment 43725 [details] lowres video mpeg
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
(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.
So I will not do this.
Tomorrow I have maybe time for bisect. Can you tell me directory-paths to constrain the search?
Kerneltrap seem to be the better source: http://kerneltrap.org/mailarchive/linux-kernel/2011/1/4/4665968
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.
Created attachment 44149 [details] dmesg from kernel 2.6.37.2 (scrolling fine)
Still occurs with Linux-Kernel 2.6.38-rc8
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.
Could it be messed up MTRRs? Just an idea...
(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.
Created attachment 45094 [details] dmesg of kernel 2.6.39-rc1 with x86 PAT
Created attachment 45096 [details] dmesg of kernel 2.6.39-rc1 without x86 PAT
No ideas?
Bug seem to be completely fixed with vanilla kernel-2.6.39-rc2. I will review the changelog, maybe I find something. :-)
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.