| Summary: | Compiz blur plugin hangs X | ||
|---|---|---|---|
| Product: | Mesa | Reporter: | Sven Arvidsson <sa> |
| Component: | Drivers/DRI/i965 | Assignee: | Eric Anholt <eric> |
| Status: | RESOLVED FIXED | QA Contact: | |
| Severity: | critical | ||
| Priority: | medium | CC: | mmoneta |
| Version: | git | ||
| Hardware: | Other | ||
| OS: | All | ||
| Whiteboard: | |||
| i915 platform: | i915 features: | ||
| Bug Depends on: | |||
| Bug Blocks: | 18841, 20277 | ||
| Attachments: |
Xorg log
Xorg config Full compiz configuration before blur plugin is added dmesg after hang Backtrace from compiz after hang Backtrace from Xorg after hang |
||
Created attachment 20916 [details]
Xorg config
Created attachment 20917 [details]
Full compiz configuration before blur plugin is added
Created attachment 20918 [details]
dmesg after hang
Created attachment 20919 [details]
Backtrace from compiz after hang
Created attachment 20920 [details]
Backtrace from Xorg after hang
Is it a hang, or just absurdly slow? Also, are you sure that the X Server is loading your new mesa? We shouldn't be hitting software fallbacks for that path since 3e0164aabb48a99fce58964cad99fd3978ee84f6. INTEL_DEBUG=fall output (which goes to the console, I think, not the server log) would be useful if you're sure it's the new code being run. Does the gearbox demo work? I think it's a real hang, and not merely being unusably slow. I left it sitting for several minutes, and nothing on the screen (such as the clock) was redrawn. CPU usage remained low. Using focus_blur in compiz works fine, and is quite fast. I do think the new Mesa is being used, I build and install it using debian packages, so there should be a very slim chance of anything old hanging around. The gearbox demo works well, but outputs this if run with INTEL_DEBUG=fall: do_copy_texsubimage fail 0x9f2d698 (nil) do_copy_texsubimage fail 0xa031308 (nil) etc... I get no debug messages when compiz is run with INTEL_DEBUG=fall. Also, something seems to go bad when I try to reboot after the hang, it never works and I must hit the reset switch, so I guess the kernel is involved too. Needed to run the X Server (which is actually executing the driver code), not compiz, with that env var. Other than being spectacularly slow, the only thing I can think of is that compiz was hanging the chip and it was only showing up as being stuck waiting on the object now. The hang doesn't happen immediately, only when a transparent window appears. I guess I didn't notice this before as I usually have a transparent terminal visible. As soon as a transparent window appear, X hangs with these errors logged: do_copy_texsubimage fail 0x9944d48 (nil) do_copy_texsubimage fail 0xa147688 (nil) [mi] EQ overflowing. The server is probably stuck in an infinite loop. [mi] mieqEnequeue: out-of-order valuator event; dropping. Even if it is spectacularly slow, I left it sitting for half an hour, and the screen is never updated, so it's unusable in any case. Using mesa commit 2305642b2e8edcebdc727f1181f7dbfcc78e8028 the blur plugin no longer hangs X. Mass version move, cvs -> git |
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.
Created attachment 20915 [details] Xorg log Activating the blur plugin in Compiz results in an immediate X hang if /apps/compiz/plugins/blur/screen0/options/alpha_blur_match is set to "normal". Terminating the compiz process does not help, and after Xorg is killed I get a message about the hardware being wedged. System environment: -- chipset: G45 / ICH10R -- system architecture: 32-bit -- xf86-video-intel: bea98cdfd93fc1181a06c51e57fcab227ff4827e -- xserver: 1.5.2 -- mesa: a0d5c3cfe6582f8294154f6877319193458158a2 -- drm: c99566fb810c9d8cae5e9cd39d1772b55e2f514c -- kernel: for-airlied 66647dc60d16fae9f6963fd98b6d9baa1a8dac69 -- Linux distribution: Debian unstable -- Machine or mobo model: Asus P5Q-EM -- Display connector: DVI