Bug 34618

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.