Created attachment 48755 [details]
dmesg output

Note that I am not using Compiz or other accelerated/fancy window managers, just an old-fashioned xmonad.

The issue is not a hard lockup of the entire machine, rather frequent multi-second lockups of video output in certain kind of 2d apps. I've noted this so far while trying to play videos with Adobe Flash Player in a browser, and the game Battle for Wesnoth.

Upon starting these programs, video rendering is normal and smooth for 1-2s, then video rendering freezes. The rest of the system works normally (audio, cpu work, disk I/O...), and video outside the windows of these apps continues to render normally. 3-10s, the frozen app resumes rendering, with the expected content, for another 1-2s, and the cycle repeats.

While investigating, I upgraded to the xorg-edgers Ubuntu PPA (those are the versions I'm reporting below). With those X drivers, the lockup bug does not seem to occur after a cold boot or reboot, but appears after the first C3 (ram) suspend-resume cycle, and persists until the next full reboot. With the stable Ubuntu drivers, this behavior starts even before the first suspend cycle.

Environment:
- Chipset: Intel(R) Sandybridge Mobile (GT2)
- Architecture: i686
- libdrm version: 2.4.26
- mesa version: 2.1 Mesa 7.10.2
- intel driver version: 2.15.0
- xorg version: X.Org X Server 1.10.2.901 (1.10.3 RC 1)
- kernel version: 2.6.38-8-generic
- Distribution: Ubuntu 11.04
- Machine: Lenovo Thinkpad X220 i5
- Display: LVDS

Reproduction:
- On the above hardware, install Ubuntu 11.04. Install the xorg-edgers PPA to get bleeding edge video drivers.
- Reboot.
- Run Battle for Wesnoth. Muck around in the UI for ~1min, notice rendering does not freeze.
- C3 suspend and resume.
- Run Battle for Wesnoth. Muck around in the UI, notice rendering is now choppy and freezy. Notice the surrounding stuff doesn't seem affected.
- Reboot the machine.
- Run Battle for Wesnoth. Notice rendering works again.

All logs attached per the guide