Bug 20666

doing 
# opcontrol --start; dmesg; opcontrol --stop; opcontrol --dump;

and then 

# opreport -l   | head -n 20
[snip warnings] 
CPU: Core 2, speed 2201 MHz (estimated)
Counted CPU_CLK_UNHALTED events (Clock cycles when not halted) with a unit mask of 0x00 (Unhalted core cycles) count 100000
samples  %        app name                 symbol name
421      30.2660  librxvt.so.1.0.0         rxvt_scroll_text
207      14.8814  libc-2.8.so              (no symbols)
127       9.1301  bash                     (no symbols)
127       9.1301  oprofiled                (no symbols)
76        5.4637  libfb.so                 (no symbols)
67        4.8167  ld-2.8.so                (no symbols)
67        4.8167  libpixman-1.so.0.15.1    pixmanFillsse2
28        2.0129  librxvt.so.1.0.0         rxvt_scr_refresh
27        1.9410  ISO8859-15.so            (no symbols)
22        1.5816  libglib-2.0.so.0.1600.6  (no symbols)
21        1.5097  ehci_hcd                 (no symbols)
19        1.3659  libmozjs.so              (no symbols)
18        1.2940  tg3                      (no symbols)
15        1.0784  libdbus-1.so.3.4.0       (no symbols)
13        0.9346  Xorg                     (no symbols)
10        0.7189  dbus-daemon              (no symbols)
10        0.7189  dmesg                    (no symbols)

i don't know if this helps... is there some other info thats interesting? perhaps libfb.so debug symbols? hm...

i will investigate tomorrow further, as i have to go to sleep now..

alright, here is the same profile (without kms) for the fast rxvt dmesg scroll. looks the same? but takes only a fraction of a second to finish... :?


schatten dmk # opreport -l | head -n 20
CPU: Core 2, speed 2201 MHz (estimated)
Counted CPU_CLK_UNHALTED events (Clock cycles when not halted) with a unit mask                                                                                                                                                                of 0x00 (Unhalted core cycles) count 100000
samples  %        app name                 symbol name
536      36.2162  librxvt.so.1.0.0         rxvt_scroll_text
274      18.5135  libfb.so                 (no symbols)
224      15.1351  libpixman-1.so.0.15.1    pixmanFillsse2
138       9.3243  libc-2.8.so              (no symbols)
122       8.2432  bash                     (no symbols)
52        3.5135  ld-2.8.so                (no symbols)
30        2.0270  ISO8859-15.so            (no symbols)
22        1.4865  libpixman-1.so.0.15.1    pixman_region_contains_rectangle
17        1.1486  librxvt.so.1.0.0         rxvt_scr_refresh
16        1.0811  Xorg                     (no symbols)
8         0.5405  oprofiled                (no symbols)
6         0.4054  ehci_hcd                 (no symbols)
6         0.4054  intel_drv.so             (no symbols)
6         0.4054  librxvt.so.1.0.0         rxvt_scr_add_lines
4         0.2703  dmesg                    (no symbols)
4         0.2703  gawk-3.1.6               (no symbols)
3         0.2027  grep                     (no symbols)

Created attachment 24040 [details]
kernel functiongraphtracer for rxvt dmesg

i just attached a functiongraphtracer ... it shows the whole 9 seconds dmesg-movie and hopefully gives somebody a clue of what the problem is.

I also experience slow X rendering and imho its IRQ problem as things get rendered when I move mouse. Also output from /proc/intterupts is different for KMS-enabled and KMS-disabled kernels.

As reference http://bugzilla.kernel.org/show_bug.cgi?id=12924

i just tested and no. 
Wiggling the mouse like crazy dosn't speed up ''time dmesg'' in rxvt. 

Created attachment 24230 [details]
my kernel config

i just  tested with linus newest kernel 0d34fb8e93c (this is after linus merged erics drm-intel-next ) and the problem persists.

i then updated my xorg-server to head of master and my xf86-video-intel to the current head of 2.7 branch (as master didn't work anymore with kms) and the problem persists. 

since this is also a bug in 2.7 i added carl worth to the cc (is this ok?)


to summarize my current setup: 

- current linus kernel-git version + :
  Revert "drm/i915: Fix lock order reversal in GEM relocation entry copying."
      This reverts commit 40a5f0decdf050785ebd62b36ad48c869ee4b384.
  (because it makes X hang, see http://marc.info/?l=dri-devel&m=123841059904877&w=2)

- xorg-server git head, 
- intel-driver git 2.7 branch head 

and this is a somewhat complete list of packages i have installed from git: 
[I] x11-proto/dri2proto (9999[1]@03/13/2009): X.Org DRI2 protocol headers
[I] x11-proto/inputproto (9999[1]@03/13/2009): X.Org Input protocol headers
[I] x11-libs/libdrm (9999[1]@03/13/2009): X.Org libdrm library
[I] x11-libs/libXcomposite (9999[1]@03/13/2009): X.Org Xcomposite library
[I] x11-libs/libXdamage (9999[1]@03/13/2009): X.Org Xdamage library
[I] x11-libs/libXext (9999[1]@03/13/2009): X.Org Xext library
[I] x11-libs/libXfixes (9999[1]@03/13/2009): X.Org Xfixes library
[I] x11-libs/libXi (9999[1]@03/16/2009): X.Org Xi library
[I] x11-libs/libXinerama (1.0.2@01/12/2008): X.Org Xinerama library
[I] x11-libs/libXrandr (9999[1]@03/13/2009): X.Org Xrandr library
[I] media-libs/mesa (9999[1]@03/13/2009): OpenGL-like graphic library for Linux
[I] media-libs/libpixman (0.1.3@03/18/2009): A generic library for manipulating pixel regions
[I] x11-libs/pixman (9999[1]@03/18/2009): Low-level pixel manipulation routines
[I] x11-proto/randrproto (9999[1]@03/13/2009): X.Org Randr protocol headers
[I] x11-proto/xextproto (9999[1]@03/13/2009): X.Org XExt protocol headers
[I] x11-drivers/xf86-input-evdev (9999[1]@03/13/2009): Generic Linux input driver
[I] x11-drivers/xf86-input-keyboard (9999[1]@01/05/2009): Keyboard input driver
[I] x11-drivers/xf86-input-mouse (9999[1]@01/05/2009): X.Org driver for mouse input devices
[I] x11-drivers/xf86-video-intel (9999[1]@03/30/2009): X.Org driver for Intel cards
[I] x11-misc/xinput (9999[1]@03/16/2009): Utility to set XInput device parameters
[I] x11-base/xorg-server (9999[1]@03/30/2009): X.Org X servers

the problem is fixed now. 

i don´t know if it was the newest kernelupgrade or some changes in xf86-video-intel master. but will follow up later on this.

thx!

bye

Thanks Florian.  If you find the commit (it's probably one of the last few in xf86-video-intel or the PAT fix in the kernel) please post it here.