Bug 22771 - [i855] X freezing running compiz unless DRI disabled
Summary: [i855] X freezing running compiz unless DRI disabled
Status: RESOLVED DUPLICATE of bug 26345
Alias: None
Product: xorg
Classification: Unclassified
Component: Driver/intel (show other bugs)
Version: 7.4 (2008.09)
Hardware: x86 (IA32) Linux (All)
: medium major
Assignee: Eric Anholt
QA Contact: Xorg Project Team
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2009-07-14 15:59 UTC by Bryce Harrington
Modified: 2010-03-02 08:15 UTC (History)
1 user (show)

See Also:
i915 platform:
i915 features:


Attachments
dri_debug.tgz (297.72 KB, application/x-compressed-tar)
2009-07-14 15:59 UTC, Bryce Harrington
no flags Details

Description Bryce Harrington 2009-07-14 15:59:36 UTC
Created attachment 27695 [details]
dri_debug.tgz

Forwarding this bug from Ubuntu reporter Mike Rose:
https://bugs.edge.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/370292

[Problem]
X freeze on 855gm.  dri_debug.tgz attached.

[Original Report]
X (running compiz) will completely freeze seemingly randomly (fairly often though - easily 5 times a day), necessitating a hardware restart (or REISUB) although the mouse pointer is still responsive and disk activity is still continuing. Another generic intel driver freeze it would seem.

I've tried the usual suspects with no avail:
happens on both UXA and EXA
with and without "MigrationHeuristics" "greedy"

Turning DRI off seems to fix the issue though.

Have been running Karmic alpha 2 for approx 5 hours now.

Good news is that the MTRR errors are gone.
Bad news is the freezes are still happening.

Two lockups. One occurred when I had firefox open, lots of tabs open,
'Normal' visual effects enabled. REISUB'ed.

Decided to try turning off visual effects, but got another lockup, this
time in terminal looking through kernel logs from the last lockup
looking for clues :)

I did notice that for approx a minute before the lockup, everything in
the terminal went real slow. Like, scrolling via mouse wheel would take
2 seconds before it would start scrolling. Very laggy. It's quite
probable that this has happened with past freezes without me noticing
however, as I've found some websites slow my computer down to a crawl
anyway (probably due to flash).

Nothing in the logs showing anything. For what it's worth, I also got
the lockup on the livecd too and I noticed before it happened I had a
slight font corruption (every instance of 'e' had a line through it).
Funnily enough, I also noticed this in terminal before it locked up
(this time 'r' was missing a bit) so I don't know if it's related or not.

Note that my framebuffer is larger than default because I have two monitors (internal LCD + external CRT), though this issue occurs on LCD only too. Both running at 1024x768

Enjoy your batchbuffer dump driver-gods :)
Comment 1 Eric Anholt 2009-07-15 15:44:23 UTC
The batchbuffer dump doesn't conclusively point to the bug I just fixed (though I think the bug might have occurred a few batchbuffers back), but it would certainly explain hanging several times a day with compiz.  Please re-open if the bug persists.

commit a1e6abb5ca89d699144d10fdc4309b3b78f2f7a9
Author: Eric Anholt <eric@anholt.net>
Date:   Wed Jul 15 14:15:10 2009 -0700

    Use batch_start_atomic to fix batchbuffer wrapping problems with 8xx render.
    
    Bug #22483.
Comment 2 Tony White 2009-10-06 18:52:32 UTC
No mention that anyone here :
https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/370292
finds this bug resolved. Because it is not.
It happens on all the major distributions available and has been progressively getting worse.
I have fedora rawhide updated right now and with kernel 2.6.31.2 the x server freezes the kernel within 10 seconds of x having being loaded.

Could you please either get hold of one of these machines with an intel 855gm card in it and actually test your latest driver with it or just regress the driver all the way back to when the drivers worked. 2.6.27.0 IIRC. It's getting ridiculous.
Comment 3 Chris Wilson 2010-03-02 08:15:38 UTC
As the last parsed instruction (IPEHR) does not match any of the preceding instructions, this looks like evidence of CPU/GPU incoherence. This may have been fixed by:

commit e517a5e97080bbe52857bd0d7df9b66602d53c4d
Author: Eric Anholt <eric@anholt.net>
Date:   Thu Sep 10 17:48:48 2009 -0700

    agp/intel: Fix the pre-9xx chipset flush.

In any case we can mark it as a dup of the current tracking bug for 8xx incoherency, bug 26345.

*** This bug has been marked as a duplicate of bug 26345 ***


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.