[drm] compiz animations cause temporary freezes with vblank

Bug #320813 reported by Khashayar Naderehvandi
76
This bug affects 6 people
Affects Status Importance Assigned to Milestone
xf86-video-intel
Fix Released
Critical
linux (Ubuntu)
Fix Released
High
Timo Aaltonen
Jaunty
Fix Released
High
Timo Aaltonen
mesa (Ubuntu)
Invalid
High
Unassigned
Jaunty
Invalid
High
Unassigned

Bug Description

Some compiz animations (most, though not all) cause temporary freezes. For example, when spinning the cube or switching between applications, everything on the screen suddenly freezes for a couple of seconds, and then it returns to normal. The desktop behaves sort of like a narcoleptic person would. Normally, this behavior starts a couple of minutes after X has started. That is, when logging in to a GNOME session, everything is smooth and
fine for a couple of minutes, and then this problem surfaces making compiz unusable. Furthermore, the problem only appears when using EXA. With UXA this particular problem does not appear.

Unfortunately, I haven't found anything of interest in the logs and don't know
where else from to get additional useful information. Please let me know how I
can help.

Xorg.0.log attached.

This is on Jaunty with the following packages.
libdrm: 2.4.4-0ubuntu2
libgl1-mesa-dri: 7.3~rc3-1ubuntu1
xserver-xorg-video-intel: 2:2.6.1-1ubuntu1
linux-image-2.6.28-5: 2.6.28-5.15

I reported the upstream bug as well, but with packages I had compiled myself for intrepid.

[lspci]
00:00.0 Host bridge [0600]: Intel Corporation Mobile 4 Series Chipset Memory Controller Hub [8086:2a40] (rev 07)
 Subsystem: ASUSTeK Computer Inc. Device [1043:19c7]
00:02.0 VGA compatible controller [0300]: Intel Corporation Mobile 4 Series Chipset Integrated Graphics Controller [8086:2a42] (rev 07)
 Subsystem: ASUSTeK Computer Inc. Device [1043:1862]

[update]
A kernel patch is available, which timo has confirmed solves the issue, however there is still discussion upstream whether this will be the final patch or needs further changes. Tim will wait to see if the upstream discussion gets to a resolution before we pull it in, and pull it in by alpha-6 at the latest.

Related branches

Revision history for this message
In , Martin Olsson (mnemo) wrote :

I can confirm this behavior with the exact same set of packages (this is what's in jaunty as of jan 24th), except that I actually have the 2.6.1 version of the intel ddx driver.

I see this on a desktop system with a Gigabyte GA-EG45M-DS2H motherboard (intel G45, GMA X4500HD).

Revision history for this message
In , Khashayar Naderehvandi (khashayar) wrote :

Tried with intel git master, problem is still there.

However, as per https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/320813, the following option in ~/.drirc solves the issue:

            <option name="vblank_mode" value="1" />

So perhaps this is to be considered a compiz bug?

Revision history for this message
Khashayar Naderehvandi (khashayar) wrote : with EXA compiz animations cause temporary freezes

Some compiz animations (most, though not all) cause temporary freezes. For example, when spinning the cube or switching between applications, everything on the screen suddenly freezes for a couple of seconds, and then it returns to normal. The desktop behaves sort of like a narcoleptic person would. Normally, this behavior starts a couple of minutes after X has started. That is, when logging in to a GNOME session, everything is smooth and
fine for a couple of minutes, and then this problem surfaces making compiz unusable. Furthermore, the problem only appears when using EXA. With UXA this particular problem does not appear.

Unfortunately, I haven't found anything of interest in the logs and don't know
where else from to get additional useful information. Please let me know how I
can help.

Xorg.0.log attached.

This is on Jaunty with the following packages.
libdrm: 2.4.4-0ubuntu2
libgl1-mesa-dri: 7.3~rc3-1ubuntu1
xserver-xorg-video-intel: 2:2.6.1-1ubuntu1
linux-image-2.6.28-5: 2.6.28-5.15

I reported the upstream bug as well, but with packages I had compiled myself for intrepid.

Revision history for this message
Khashayar Naderehvandi (khashayar) wrote :
Changed in xserver-xorg-video-intel:
status: Unknown → Confirmed
Revision history for this message
Martin Olsson (mnemo) wrote :

I can confirm this bug on a box with a Gigabyte GA-EG45M-DS2H board (i.e. intel G45 / GMA X4500HD), my cube is totally narcoleptic as well. While this temporary freeze happens no error or warning is printed to dmesg nor anything in xorg.log

Revision history for this message
Martin Olsson (mnemo) wrote :

If you actually have the 2.6.0 intel ddx driver (as you wrote in upstream report) then I suggest you upgrade to 2.6.1-1ubuntu1 which is available in apt already?

Revision history for this message
Martin Olsson (mnemo) wrote :

This is sort of unrelated to the bug but yesterday evening bryce, timo and some other folks discussed the fact that ubuntu now has vblank waiting enables. I've no idea what this really means but as far as I understood this means that for instance in glxgears will drastically reduce it's FPS because it knows that your screen can't show more than 75Hz anyway or so. A very simplified explanation of why this is done is because it taxes the CPU less and thus saves power.

Now, back to this bug. Since these temporary freezes sometimes lasts several seconds on my G45 quad core 2.6GHz I was able to attach gdb to X during the freeze using ssh from another machine. What I found was that the X server had this stack:

(gdb) bt
#0 0x00007f7fa26eadd7 in ioctl () from /lib/libc.so.6
#1 0x00007f7fa14d1464 in drmWaitVBlank () from /usr/lib/libdrm.so.2
#2 0x00007f7f9017a00e in ?? () from /usr/lib/dri/i965_dri.so
#3 0x00007f7f9017a233 in driWaitForVBlank () from /usr/lib/dri/i965_dri.so
#4 0x00007f7f90182189 in intelSwapBuffers () from /usr/lib/dri/i965_dri.so
#5 0x00007f7f9017a993 in ?? () from /usr/lib/dri/i965_dri.so
#6 0x00007f7fa1b2bb8f in __glXDRIdrawableSwapBuffers (basePrivate=0x15e1000) at ../../glx/glxdri.c:251
#7 0x00007f7fa1b1fbd6 in __glXDisp_SwapBuffers (cl=0xf36110, pc=<value optimized out>) at ../../glx/glxcmds.c:1436
#8 0x00007f7fa1b22ea2 in __glXDispatch (client=0xfb6280) at ../../glx/glxext.c:523
#9 0x000000000044e234 in Dispatch () at ../../dix/dispatch.c:437
#10 0x0000000000433c0d in main (argc=10, argv=0x7fffacb10968, envp=<value optimized out>) at ../../dix/main.c:383

For this reason I think it would be an interesting experient to disable this "wait for vblank" feature in drirc and see if these temporary freezes will go away.

Revision history for this message
Martin Olsson (mnemo) wrote :

To try this, open the file ~/.drirc and add:

<driconf>
    <device screen="0" driver="i965">
        <application name="Default">
            <option name="vblank_mode" value="0" />
        </application>
    </device>
</driconf>

And then reboot. Right now with this workaround I'm not seeing this problem, but since you said "this behavior starts a couple of minutes after X has started" I will give it some time to see if the bug will come back.

Revision history for this message
Khashayar Naderehvandi (khashayar) wrote :

martin: Very nice! I installed driconf and changed the option "Synchronization with vertical refresh (swap intervals) to "Initial swap interval 0, obey application's choice". Resulting in the following ~/.drirc:

<driconf>
    <device screen="0" driver="i965">
        <application name="Default">
            <option name="force_s3tc_enable" value="false" />
            <option name="no_rast" value="false" />
            <option name="fthrottle_mode" value="2" />
            <option name="bo_reuse" value="1" />
            <option name="vblank_mode" value="1" />
            <option name="allow_large_textures" value="2" />
        </application>
    </device>
</driconf>

With these settings, the problem is gone. Can you confirm it also?

Wrt the upstream bug report and intel 2.6.0. The changes between 2.6.0 and 2.6.1 are very small, but I've tried git as well. I'll update that report.

Also, perhaps there's a chance that we'll end up with with dri2+uxa as default for jaunty (depending on what updates go to intel 2.6.2, 2.6.3, and when). That would solve this issue as well.

Revision history for this message
Khashayar Naderehvandi (khashayar) wrote :

martin, you beat me to it :-)

(no reboot needed though, just restart compiz)

Revision history for this message
Geir Ove Myhr (gomyhr) wrote :

Khashayar, could you please also upload your output of `lspci -vvnn` and also /etc/X11/xorg.conf if you have made any changes to it.

Revision history for this message
Khashayar Naderehvandi (khashayar) wrote :

lspci -vvnn attached.

No changes to /etc/X11/xorg.conf

Revision history for this message
Martin Olsson (mnemo) wrote :

I'm also affected by this bug (using the ubuntu default config) and this is my "lspci -vvnn" output.

Revision history for this message
Geir Ove Myhr (gomyhr) wrote : Re: [GM45] with EXA compiz animations cause temporary freezes

Thanks, martin. Maybe you too could upload your Xorg.0.log? It seems you guys are already making progress on this bug - good work :-)

description: updated
Changed in xserver-xorg-video-intel:
status: New → Confirmed
Revision history for this message
Khashayar Naderehvandi (khashayar) wrote :

I was too quick there. The problem is still there, although it took much longer to surface with the drirc change.

Revision history for this message
In , Martin Olsson (mnemo) wrote :

The vblank_mode "workaround" might have been a false lead. See the launchpad bug for details. Basically, after xorg has been running for some time, the freezes seem to come back even with vblank_mode=1 or vblank_mode=0 in drirc.

Revision history for this message
Timo Aaltonen (tjaalton) wrote : Re: [GM45] with EXA compiz animations cause temporary freezes

the dri stuff is from mesa.

Changed in mesa:
importance: Undecided → High
Revision history for this message
Martin Olsson (mnemo) wrote :

Geir, I'm using stock xorg.conf (I'm trying to stick to the jaunty defaults except for short periods when I test specific workarounds etc).

Unfortunately, after more extensive testing I also have to report that the vblank_mode=0 trick only postpones the freezes a little bit but they do appear after running a while. I have also been running with Khashayar's drirc for a few hours and some thing there. The freezes re-appears after a while. Right now I have no way of reliably working around this bug, back to square one.

Cube spinning does seem to get slower if I have a lot of firefox windows on each cube side but in that case it gets sort of linearly slower and I never get complete freezes, still I have this unscientific feeling that having lots of windows up and possibly also running openGL apps like "chromium BSU" or the screensaver preview dialog will actually make the freezes reappear faster.

Revision history for this message
Timo Aaltonen (tjaalton) wrote :

I can only see this after a suspend/resume cycle. Could someone confirm?

Revision history for this message
In , Timo Aaltonen (tjaalton) wrote :

The freezes are confirmed to happen only after a suspend/resume cycle.

Revision history for this message
Austin Chu (eefi) wrote : Re: [GM45] with EXA compiz animations cause temporary freezes

Quick, non-exhaustive testing just now seems to confirm that this happens after a suspend/resume cycle. It doesn't seem to happen after a hibernation cycle, though. Hibernating after a suspend/resume cycle doesn't fix the problem, either, though.

Tested on a Lenovo ThinkPad X301.

Revision history for this message
Matteo Collina (matteo-collina) wrote :

No, that's not true. I have such a freeze even after a lot of activity, though. Certainly a suspend/resume cycle trigger the bug, but that's not the main cause.
If I have a lot of windows opened and I activate the "scale" compiz effect I'm almost certain that the animation will freeze.
Another condition consists in an opened Qt application.

Revision history for this message
In , Khashayar Naderehvandi (khashayar) wrote :

According to what's been going on in the launchpad bug referenced above, this is likely a bug in DRM.

From the launchpad bug: http://launchpadlibrarian.net/21654001/dmesg_low_memory_corrupt.txt

Revision history for this message
Austin Chu (eefi) wrote : Re: [GM45] with EXA compiz animations cause temporary freezes

Hrm... I now agree with Matteo that though a suspend/resume cycle seems to reliably trigger this, the problem can develop on its own otherwise. Also, it's probably because of compiz, but this bug also makes full screen Flash videos with compiz unwatchably jumpy.

Revision history for this message
Peter Clifton (pcjc2) wrote :

Can you check if there is anything untowards at the end of your dmesg output when this manifests?

Anything like:

[22892.778103] [drm:i915_gem_object_bind_to_gtt] *ERROR* GTT full, but LRU list empty

or similar complaints about drm, i915 or gem in general?

Revision history for this message
Matteo Collina (matteo-collina) wrote :

I only have this strange message:
mtrr: no MTRR for e0000000,10000000 found

~$ cat /proc/mtrr
reg00: base=0x000000000 ( 0MB), size=32768MB, count=1: write-back
reg01: base=0x0e0000000 ( 3584MB), size= 512MB, count=1: uncachable
reg02: base=0x0ddc00000 ( 3548MB), size= 4MB, count=1: uncachable
reg03: base=0x0de000000 ( 3552MB), size= 32MB, count=1: uncachable

Revision history for this message
Martin Olsson (mnemo) wrote :

I ran through a suspend/resume now as well and that did immediately trigger the bug. Afterwards I had this really nasty error in the dmesg saying something about "corruption on low memory". There is even two kernel callstacks in my dmesg it seems.

Revision history for this message
Timo Aaltonen (tjaalton) wrote :

Ok, this is looking more like a bug in the DRM driver. Could you also add that information to the upstream bug?

Changed in xserver-xorg-video-intel:
importance: Undecided → High
status: New → Triaged
Revision history for this message
Timo Aaltonen (tjaalton) wrote :

btw, can you boot an earlier kernel than -5.15? I'd been running the same userland modules (mesa, intel) for a week or so without problems, so I'm suspecting that the vblank patches in the kernel aren't complete and are causing this.

Revision history for this message
Khashayar Naderehvandi (khashayar) wrote :

Timo: Yes, you seem to be correct. With kernel 2.6.28-4.11 this problem isn't present (I don't even need a tweaked ~/.drirc). But now, I suspect I'm just waiting for LP 305979 to hit me again.

Revision history for this message
Khashayar Naderehvandi (khashayar) wrote :

Sorry, once again, I was too quick to shout "hey!".
Problem returned after only a few minutes with 2.6.28-4.11.

(Next time, I'm gonna take some time testing, promise! :-p)

Revision history for this message
Timo Aaltonen (tjaalton) wrote :

I guess the drirc doesn't work unless it's copied as /etc/drirc. I can't seem to be able to reproduce this problem anymore with it, so it must be a bug in the vblank implementation which was enabled with the mesa 7.3rc3 merge..

Revision history for this message
Khashayar Naderehvandi (khashayar) wrote :

Timo, I think it's safe to say that my results confirm yours. With ~/.drirc copied to /etc/drirc, I haven't seen this problem since your comment above.

I guess Jaunty is tracking mesa 7.4. Correct? Perhaps this will be fixed some time down the road (it's not fixed in 7.3 final, though).

Revision history for this message
Timo Aaltonen (tjaalton) wrote :

This is a bug in the kernel drm layer. I've got a patch from upstream that fixed it, but it's still unclear whether it is the final patch. I might upload a mesa with vblank disabled until the correct fix is in the kernel.

Changed in mesa:
status: Confirmed → Invalid
Revision history for this message
Bryce Harrington (bryce) wrote :

leann,

Could you help us find a kernel dev to take a look at integrating the kernel patch to fix this issue?

Revision history for this message
Leann Ogasawara (leannogasawara) wrote :

Just pasting the email timo forwarded to the ubuntu kernel team regarding this patch:

https://lists.ubuntu.com/archives/kernel-team/2009-February/004277.html

Revision history for this message
Bryce Harrington (bryce) wrote :

Timo, can you attach the kernel patch here?

Changed in linux:
milestone: none → jaunty-alpha-6
assignee: nobody → timg-tpi
description: updated
Revision history for this message
Timo Aaltonen (tjaalton) wrote :

actually, there's another proposed patch now, since the one I forwarded is 'only a workaround to hide the real bug'. Anyway, it's not yet clear what will be committed, so I'll just post the link to the discussion..

http://www.mail-archive.com/dri-devel%40lists.sourceforge.net/msg37900.html

Revision history for this message
Martin Pitt (pitti) wrote :

For the record, I can perfectly reproduce this after suspend when using EXA (GMA945).

I have used UXA since today, and with that suspend/resume with compiz works fine, i. e. this bug doesn't hit me with UXA.

As requested by Steve, I'll put this onto the release radar.

Revision history for this message
Till Kamppeter (till-kamppeter) wrote :

I tested with UXA on Tuesday and for me X crashes. I have an Intel i945.

Revision history for this message
Khashayar Naderehvandi (khashayar) wrote :

Timo, I read through that thread on dri-devel, and would like to add, just for the record, that for me the problem was never related to VT switching or suspend/resume cycles. The freezes start occuring after a few minutes of normal usage.

I don't know if this is relevant, but thought I'd mention it.

Revision history for this message
Till Kamppeter (till-kamppeter) wrote :

For me the problem usually appears only after a Suspend and Resume.

Revision history for this message
Erno Kuusela (erno-iki) wrote :

The DRI settings workaround eliminates the random stops.

But I have a feeling that it ran more smoothly in Intrepid, now it looks like ~2-4 fps with zoom taking about 2 seconds, if I have more than about 10 windows on a workspace. Or maybe I just have more windows open now, anyone else notice a slowdown?

Revision history for this message
Erno Kuusela (erno-iki) wrote :

Whoops, I was talking about the compiz window picker's zoom performance in my above comment.

Revision history for this message
Khashayar Naderehvandi (khashayar) wrote :

Yes, performance is really bad with the workaround here as well.

Revision history for this message
Timo Aaltonen (tjaalton) wrote :

Here is the final patch, and as you can see it's quite small.. This should hit upstream in the not-too-distant future.

Date: Fri, 06 Feb 2009 13:04:49 -0800
From: Jesse Barnes <email address hidden>
To: Dave Airlie <email address hidden>
Cc: DRI <email address hidden>, Timo Aaltonen <email address hidden>,
    Michel Dänzer <email address hidden>
Subject: [PATCH] capture last_vblank count at IRQ uninstall time too

In dc1336ff4fe08ae7cfe8301bfd7f0b2cfd31d20a (set vblank enable flag correctly
across IRQ uninstall), we made sure drivers that uninstall their interrupt
handler set the vblank enabled flag correctly, so that when interrupts are
re-enabled, vblank interrupts & counts work as expected. However I missed the
last_vblank field: it needs to be updated as well, otherwise, at the next
drm_update_vblank_count we'll end up comparing a current count to a stale
one (the last one captured by the disable function), which may trigger the
wraparound handling, leading to a jumpy counter and hangs in drm_wait_vblank.

The jumpy counter can prevent the DRM_WAIT_ON from returning success if the
difference between the current count and the requested count is greater than
2^23, leading to timeouts or hangs, if the ioctl is restarted in a loop (as
is the case in libdrm < 2.4.4).

Signed-off-by: Jesse Barnes <email address hidden>

diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c
index 69aa0ab..3795dbc 100644
--- a/drivers/gpu/drm/drm_irq.c
+++ b/drivers/gpu/drm/drm_irq.c
@@ -276,6 +276,7 @@ int drm_irq_uninstall(struct drm_device * dev)
        for (i = 0; i < dev->num_crtcs; i++) {
                DRM_WAKEUP(&dev->vbl_queue[i]);
                dev->vblank_enabled[i] = 0;
+ dev->last_vblank[i] = dev->driver->get_vblank_counter(dev, i);
        }
        spin_unlock_irqrestore(&dev->vbl_lock, irqflags);

Revision history for this message
Matteo Collina (matteo-collina) wrote :

I've applied that patch to the current ubuntu kernel but it doesn't solve the problem for me: there are still freezes after a suspend/resume cycle without the modified drirc.

Revision history for this message
Derek Dolney (nospam-dolney) wrote :

The patch worked for me: no more freezes after suspend/resume.

Revision history for this message
Derek Dolney (nospam-dolney) wrote :

Oops...uh, yeah. Let me just pull my foot out of my mouth for a sec...

I forgot I also had a user .drirc that disabled vblank. This patch *does not* solve the suspend/resume problem.

Revision history for this message
Timo Aaltonen (tjaalton) wrote :

Derek, Matteo: what graphics chip do you have? Attach your /var/log/Xorg.0.log to be sure.

Revision history for this message
Tim Gardner (timg-tpi) wrote :
Changed in linux:
status: Triaged → Fix Committed
Revision history for this message
Derek Dolney (nospam-dolney) wrote :

I have an Intel 965GM.

Revision history for this message
Martin Olsson (mnemo) wrote :

I definitely still have the >1sec freezes _after_ suspend/resume on a Gigabyte GA-EG45M-DS2H board (which has a G45-chipset) with the "capture last_vblank count at IRQ uninstall time too" patch applied.

Currently I've not seen freezes _before_ the first suspend/resume round trip but normally I have to run xorg for quiet some time before I see the non-suspend/resume-related freezes. Maybe the non-suspend/resume freezes are still there, maybe not.

Revision history for this message
Martin Olsson (mnemo) wrote :

Now I applied the "add get_vblank_counter function for GM45" patch as well (so that I had both this one and the "capture last_vblank count at IRQ uninstall time too" one). After one suspend/resume roundtrip I still get the >1sec freezes consistently. Note that I have a G45 (a desktop machine) and not the mobile GM45 chipset (maybe these patches removes the freezes from GM45 laptops?).

Revision history for this message
Matteo Collina (matteo-collina) wrote :

No Martin, I have a Dell laptop (Latitude E6400) with the GM45 and the problem is still there.

[0 sec: 401802 usec](II) intel(0): Integrated Graphics Chipset: Intel(R) Mobile Intel® GM45 Express Chipset
[0 sec: 401816 usec](--) intel(0): Chipset: "Mobile Intel® GM45 Express Chipset"

Do you need a 'normal' Xorg.0.log or one after suspend/resume?

Revision history for this message
Timo Aaltonen (tjaalton) wrote :

It's enough to see what chip you have, no need for the log otherwise. So there are still issues with G*45...

Derek, my 965GM works perfectly with the oneliner, so I suspect you've done something wrong..

Revision history for this message
Matteo Collina (matteo-collina) wrote :

I've just recompiled with the two fixes uploaded by Tim and those doesn't solve the problem.

Revision history for this message
Derek Dolney (nospam-dolney) wrote :

Timo:

Well I double checked for you to be sure I hadn't forgotten anything in the patch->rebuild->install chain. No, I did it right.

Are you sure you don't have neither /etc/drirc nor a ~/.drirc? I forgot the latter and spoke too soon because of it.

You didn't disable vblank in ccsm at any point in your testing?

Revision history for this message
Martin Olsson (mnemo) wrote :

Yesterday before I went to sleep I rebooted by G45 machine and when left it running over night with both of the drm patches applied. When I woke up again I the bug was happening, so that means that I get this freezes even without suspend/resume if I just let X.org run sufficiently long (I also had like 2-3 windows on each side of the cube when it was idling over night).

Another scary note is that I now currently see this on the G45 machine (I used to have around 60 FPS in glxgears before I applied the drm patches because of the slow down to screen Hz but now it's getting crazy... basically I can't even see the gears moving at all and the FPS is single digit):

mnemo@kingfish:~$ glxgears
49 frames in 5.1 seconds = 9.528 FPS
20 frames in 10.2 seconds = 1.957 FPS
20 frames in 10.2 seconds = 1.960 FPS
20 frames in 9.2 seconds = 2.170 FPS

(Note: that's 2 frames per second, and not 2000 FPS!!)

Revision history for this message
Timo Aaltonen (tjaalton) wrote :

Derek, you're right, the patches aren't enough. It's harder to trigger though..

Can you try the patch from this post on top of the two earlier commits? I've tried it before and it worked for me (during the brief testing period), and upstream would like to know if it helps in this case:

http://www.mail-archive.com/dri-devel%40lists.sourceforge.net/msg37945.html

Revision history for this message
Derek Dolney (nospam-dolney) wrote :

That patch worked for me. I can suspend/resume with vblank and it works fine.

Should I apply the oneliner also. (I did not).

Revision history for this message
Martin Olsson (mnemo) wrote :

The third patch does improve things on Gigabyte GA-EG45M-DS2H mobo (G45), I can suspend/resume and VT switch without getting into that annoying >1sec freeze mode. I have not yet tried running xorg for a _long_ time to see if that still triggers the bug. glxgears now also reports around 60 FPS as excepted with vblank (the gears move now but they still flicker in a very annoying way, I guess this is a separate bug though). I can play chromnium arcade with nice FPS etc.

With 3-4 windows on each cube side the overall graphics performance is still _horrible_ when spinning the cube though. It doesn't stop for >1sec but it's embarrassingly slow for a quad core 2.8ghz, 8GB machine. If I _hold_ the "spin cube to the right" button for about 10-15 seconds then audio from totem is more or less certain to skip (silence for about 1sec) which is really annoying because it happens also sometimes on single normal ALT-TAB (not every ALT-TAB though).

G45 definitely needs some more love before it's usable. I will go test UXA now.

Revision history for this message
Martin Olsson (mnemo) wrote :

I also found these nasty lines in my dmesg after testing with all three patches:

[ 759.736511] [drm:i915_get_vblank_counter] *ERROR* trying to get vblank count for disabled pipe 1

[ 779.816019] Corrupted low memory at ffff88000000d348 (d348 phys) = 400000000000
[ 779.816029] ------------[ cut here ]------------
[ 779.816032] WARNING: at /build/buildd/linux-2.6.28/arch/x86/kernel/setup.c:719 check_for_bios_corruption+0xdd/0xe0()
[ 779.816034] Memory corruption detected in low memory
[ 779.816035] Modules linked in: i915 drm binfmt_misc bnep ipt_MASQUERADE iptable_nat nf_nat nf_conntrack_ipv4 nf_defrag_ipv4 xt_state nf_conntrack ipt_REJECT xt_tcpudp iptable_filter ip_tables x_tables bridge stp kvm_intel kvm acpi_cpufreq input_polldev video output ppdev parport_pc lp parport joydev snd_hda_intel snd_pcm_oss snd_mixer_oss snd_pcm snd_seq_dummy snd_seq_oss snd_seq_midi snd_rawmidi snd_seq_midi_event snd_seq snd_timer snd_seq_device snd soundcore snd_page_alloc intel_agp usbhid psmouse iTCO_wdt pcspkr iTCO_vendor_support serio_raw pata_it8213 r8169 mii ehci_hcd uhci_hcd fbcon tileblit font bitblit softcursor fuse
[ 779.816078] Pid: 0, comm: swapper Not tainted 2.6.28-7-generic #20-Ubuntu
[ 779.816080] Call Trace:
[ 779.816081] <IRQ> [<ffffffff8024d857>] warn_slowpath+0xb7/0xf0
[ 779.816089] [<ffffffff8052217d>] ? usb_submit_urb+0xdd/0x270
[ 779.816093] [<ffffffff8067f320>] ? printk+0x67/0x6f
[ 779.816097] [<ffffffff8025980f>] ? __mod_timer+0xbf/0xe0
[ 779.816100] [<ffffffff802168dd>] check_for_bios_corruption+0xdd/0xe0
[ 779.816102] [<ffffffff802168e0>] ? periodic_check_for_corruption+0x0/0x40
[ 779.816105] [<ffffffff802168e9>] periodic_check_for_corruption+0x9/0x40
[ 779.816108] [<ffffffff80258db9>] run_timer_softirq+0x179/0x260
[ 779.816112] [<ffffffff8027066f>] ? clockevents_program_event+0x4f/0x90
[ 779.816114] [<ffffffff802539fc>] __do_softirq+0x9c/0x170
[ 779.816117] [<ffffffff80213d8c>] call_softirq+0x1c/0x30
[ 779.816120] [<ffffffff80214ffd>] do_softirq+0x5d/0xa0
[ 779.816123] [<ffffffff8025377d>] irq_exit+0x8d/0xa0
[ 779.816126] [<ffffffff80224828>] smp_apic_timer_interrupt+0x88/0xc0
[ 779.816129] [<ffffffff80213668>] apic_timer_interrupt+0x88/0x90
[ 779.816130] <EOI> [<ffffffff8022b866>] ? native_safe_halt+0x6/0x10
[ 779.816137] [<ffffffff804670ee>] ? acpi_safe_halt+0x3a/0x55
[ 779.816139] [<ffffffff80467c79>] ? acpi_idle_do_entry+0x1b/0x2b
[ 779.816142] [<ffffffff80467cf1>] ? acpi_idle_enter_c1+0x68/0x8d
[ 779.816145] [<ffffffff80571385>] ? cpuidle_idle_call+0xa5/0x100
[ 779.816148] [<ffffffff80210e85>] ? cpu_idle+0x65/0xc0
[ 779.816151] [<ffffffff8066dd7c>] ? rest_init+0x5c/0x70
[ 779.816153] ---[ end trace 8faa7fd8cd7a6ddd ]---
[ 906.658683] [drm:i915_get_vblank_counter] *ERROR* trying to get vblank count for disabled pipe 1
[ 912.087777] [drm:i915_get_vblank_counter] *ERROR* trying to get vblank count for disabled pipe 1
[ 938.758016] [drm:i915_get_vblank_counter] *ERROR* trying to get vblank count for disabled pipe 1

Revision history for this message
Launchpad Janitor (janitor) wrote :
Download full text (4.5 KiB)

This bug was fixed in the package linux - 2.6.28-8.21

---------------
linux (2.6.28-8.21) jaunty; urgency=low

  [ Andy Whitcroft ]

  * SAUCE: switch the Asus Pundit P1-AH2 to old acpi sleep ordering
    - LP: #327267

  [ Tim Gardner ]

  * Added LPIA arch support
  * Added libdrm-dev as a 'Replaces' to linux-libc-dev
  * SAUCE: LPIA support for 9202 HDA Sigmatel codec
  * SAUCE: Add an X86_LPIA Kconfig option
  * SAUCE: UHCI USB quirk for resume
  * SAUCE: LPIA Reboot fix for Intel Crownbeach development boards
  * SAUCE: LPIA Logical reset of USB port on resume
  * Set CONFIG_WIRELESS_OLD_REGULATORY=n, added wireless-crda
    as an install dependency.

  [ Upstream Kernel Changes ]

  * Revert "Revert "x86, early_ioremap: fix fencepost error""
    - LP: #312554
  * drm/i915: capture last_vblank count at IRQ uninstall time too
    - LP: #320813
  * drm/i915: add get_vblank_counter function for GM45
    - LP: #320813
  * Staging: comedi: fix Kbuild
  * Staging: meilhaus: fix Kbuild
  * Staging: android: binder: fix arm build errors
  * Staging: android: timed_gpio: Fix build to build on kernels after
    2.6.25.
  * Staging: android: fix build error on 64bit boxes
  * Staging: android: Add lowmemorykiller documentation.
  * Staging: android: task_get_unused_fd_flags: fix the wrong usage of
    tsk->signal
  * staging: agnx: drivers/staging/agnx/agnx.h needs <linux/io.h>
  * Staging: usbip: usbip_start_threads(): handle kernel_thread failure
  * Staging: poch: fix verification of memory area
  * Documentation: move DMA-mapping.txt to Doc/PCI/
  * sgi-xp: fix writing past the end of kzalloc()'d space
  * do_wp_page: fix regression with execute in place
  * wait: prevent exclusive waiter starvation
  * shm: fix shmctl(SHM_INFO) lockup with !CONFIG_SHMEM
  * revert "rlimit: permit setting RLIMIT_NOFILE to RLIM_INFINITY"
  * prevent kprobes from catching spurious page faults
  * sound: usb-audio: handle wMaxPacketSize for FIXED_ENDPOINT devices
  * md: Ensure an md array never has too many devices.
  * md: Fix a bug in linear.c causing which_dev() to return the wrong
    device.
  * ACPI: Enable bit 11 in _PDC to advertise hw coord
  * ACPI: dock: Don't eval _STA on every show_docked sysfs read
  * ieee1394: ohci1394: increase AT req. retries, fix ack_busy_X from
    Panasonic camcorders and others
  * firewire: ohci: increase AT req. retries, fix ack_busy_X from Panasonic
    camcorders and others
  * firewire: sbp2: fix DMA mapping leak on the failure path
  * firewire: sbp2: add workarounds for 2nd and 3rd generation iPods
  * ieee1394: sbp2: add workarounds for 2nd and 3rd generation iPods
  * module: remove over-zealous check in __module_get()
  * x86: APIC: enable workaround on AMD Fam10h CPUs
  * eeepc-laptop: fix oops when changing backlight brightness during
    eeepc-laptop init
  * eeepc-laptop: Add support for extended hotkeys
  * e1000: fix bug with shared interrupt during reset
  * e1000: Fix PCI enable to honor the need_ioport flag
  * agp/intel: Fix broken ® symbol in device name.
  * ALSA: hda - Add quirk for FSC Amilo Xi2550
  * ALSA: hda - Add missing COEF initialization for ALC887
  * ALSA: hda - Add missing initialization ...

Read more...

Changed in linux:
status: Fix Committed → Fix Released
Revision history for this message
Matteo Collina (matteo-collina) wrote :

This bug it's not fixed at all!

Revision history for this message
Timo Aaltonen (tjaalton) wrote :

right, let's wait for the last patch to go through upstream review.

Changed in linux:
status: Fix Released → In Progress
Steve Langasek (vorlon)
Changed in linux:
assignee: timg-tpi → tjaalton
Revision history for this message
Timo Aaltonen (tjaalton) wrote :

I've disabled vblank for intel again (in mesa), because it doesn't look likely that it'd get stable in time for jaunty. Leaving the bug open but dropping the milestone.

Changed in linux:
milestone: jaunty-alpha-6 → none
status: In Progress → Triaged
Revision history for this message
Matteo Collina (matteo-collina) wrote :

Timo, is related with the last update that I have really slow performance with OpenArena? Some days ago that game was running smoothly.

Revision history for this message
Launchpad Janitor (janitor) wrote :
Download full text (164.3 KiB)

This bug was fixed in the package linux - 2.6.28-9.30

---------------
linux (2.6.28-9.30) jaunty; urgency=low

  [ Amit Kucheria ]

  * ARM:mx51 Add SoC and board support for mx51 platforms
  * ARM:mx51 Add CONFIG_ARCH_MXC_CANONICAL to disable parts of Freescale's
    code
  * MMC: Add support for 8-bit cards
  * Add ARM:MX51 SoC support to the build system
  * ARM: Make ARM arch aware of ubuntu/ drivers
  * ARM: Add imx51 configuration
  * Disable d-i modules for imx51 and mv78xx0
  * Disable Apparmor on boot for ARM
  * Updating imx51 config

  [ Jason Liu ]

  * Do not use OOB with MLC NAND

  [ Richard Zhu ]

  * Support the eMMC4.3 card

  [ Rob Herring ]

  * ARM: Add more cache memory types macros

  [ Tim Gardner ]

  * Set CONFIG_CPU_FREQ_DEFAULT_GOV_PERFORMANCE=y for i386/amd64/lpia

  [ Manoj Iyer ]

  * Enable CONFIG_RTL8187SE=m

  [ Upstream Kernel Changes ]

  * USB: EHCI: slow down ITD reuse
    - LP: #329437

linux (2.6.28-9.29) jaunty; urgency=low

  [ Andy Whitcroft ]

  * link-headers -- only link directories which do not already exist
    - LP: #315252

  [ Daniel Marjamäki ]

  * SAUCE: (drop after 2.6.28) netxen: fix memory leak in
    drivers/net/netxen_nic_init.c
    - LP: #330813

  [ Dhananjay Phadke ]

  * SAUCE: (drop after 2.6.28) netxen: fix endianness in firmware commands
    - LP: #330813
  * SAUCE: (drop after 2.6.28) netxen: fix ipv6 offload and tx cleanup
    - LP: #330813
  * SAUCE: (drop after 2.6.28) netxen: fix link speed reporting for some
    boards
    - LP: #330813
  * SAUCE: (drop after 2.6.28) netxen: firmware init fix
    - LP: #330813
  * SAUCE: (drop after 2.6.28) netxen: cleanup mac list on driver unload
    - LP: #330813
  * SAUCE: (drop after 2.6.28) netxen: hold tx lock while sending firmware
    commands
    - LP: #330813
  * SAUCE: (drop after 2.6.28) netxen: handle dma mapping failures
    - LP: #330813
  * SAUCE: (drop after 2.6.28) netxen: avoid invalid iounmap
    - LP: #330813
  * SAUCE: (drop after 2.6.28) netxen: include ipv6.h (fixes build failure)
    - LP: #330813
  * SAUCE: (drop after 2.6.28) netxen: fix vlan tso/checksum offload
    - LP: #330813
  * SAUCE: (drop after 2.6.28) netxen: reduce memory footprint
    - LP: #330813
  * SAUCE: (drop after 2.6.28) netxen: revert jumbo ringsize
    - LP: #330813
  * SAUCE: (drop after 2.6.28) netxen: fix msi-x interrupt handling
    - LP: #330813
  * SAUCE: (drop after 2.6.28) netxen: remove pcie workaround
    - LP: #330813

  [ Hannes Eder ]

  * SAUCE: (drop after 2.6.28) drivers/net/netxen: fix sparse warnings: use
    NULL pointer instead of plain integer
    - LP: #330813

  [ Huaxu Wan ]

  * SAUCE: report rfkill changes event if interface is down
    - LP: #193970

  [ Tim Gardner ]

  * MV78XX0 must specify a target in the vars definition.

  [ Upstream Kernel Changes ]

  * Revert "ext4: wait on all pending commits in ext4_sync_fs()"
  * jbd2: Fix return value of jbd2_journal_start_commit()
  * jbd2: Avoid possible NULL dereference in
    jbd2_journal_begin_ordered_truncate()
  * ext4: Fix to read empty directory blocks correctly in 64k
  * ext4: Fix lockdep warning
  * ext4: Initialize preallocation list_head's properly
  *...

Changed in linux:
status: Triaged → Fix Released
Revision history for this message
Khashayar Naderehvandi (khashayar) wrote :

Timo, does the latest kernel update mean you're gonna enable vblank again?

Revision history for this message
Till Kamppeter (till-kamppeter) wrote :

It is indeed fixed now. After booting into the new kernel and suspending/restoring the problem disappeared.

Revision history for this message
In , Jesse Barnes (jbarnes-virtuousgeek) wrote :

Adjusting severity: crashes & hangs should be marked critical.

Revision history for this message
In , Eric Anholt (eric-anholt) wrote :

Closing it as fixed due to not being present in UXA.

Changed in xserver-xorg-video-intel:
status: Confirmed → Fix Released
Changed in xserver-xorg-video-intel:
importance: Unknown → Critical
Changed in xserver-xorg-video-intel:
importance: Critical → Unknown
Changed in xserver-xorg-video-intel:
importance: Unknown → Critical
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.