Hi! I just tested kernel based modesetting with 2.6.29-rc8 (i915.modeset=1) and after some initial trouble it works just fine, except: rendering text in rxvt is sloooow ( dmesg about 10 seconds to finish ). konsole, gnome-terminal and xterm _don't_ exhibit this bug. for initial information you can see http://bugzilla.kernel.org/12596 (2009-02-01 08:40, git versions too) if you need more info please tell me what you need. chipset is 965gm. I'm on gentoo with the following packages from git (from yesterday) dri2proto inputproto libdrm libXcomposite libXdamage libXext libXfixes libXrandr mesa pixman randrproto xextproto xf86-input-evdev xf86-video-intel xorg-server Gruss, Florian
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.
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.