[ubuntu-x] X Freezes with EXA and -intel on Jaunty

[Bryce Harrington]

On Mon, Apr 13, 2009 at 03:02:04PM -0700, Carl Worth wrote:
> On Fri, 2009-04-10 at 18:19 -0700, Bryce Harrington wrote:
> > To get a better overview of all the freezes I've compiled a table
> > listing the bugs, along with triggers and workarounds where known:
> > 
> >   https://wiki.ubuntu.com/X/Bugs/IntelDriver
> > 
> > I hope this data is of some use to you in testing efforts.
> 
> Hey, that looks like a great list. Thanks!

Sure, fwiw, I *think* I narrowed the current i965 freezes at the bottom
of the list to a mesa 7.3->7.4 update.  Reverting back to 7.3 seems to
at least make the freeze occur less often (several people report that
they still get freezes though.)

> > In addition, I've drafted a troubleshooting guide specifically for
> > freeze bugs:
> > 
> >   https://wiki.ubuntu.com/X/Troubleshooting/Freeze
> > 
> > Any ideas on other tricks for gathering data that may be of use to you
> > in debugging these problems would be welcomed for adding to this page.
> 
> That looks like it has some useful things on it.
> 
> For several of us now, we are stuck unable to fix some important
> GPU-hanging bugs because we can't succesfully reproduce them. So getting
> the batchbuffer dump is going to be essential for some of these.
> 
> If you've got some clueful, motivated users that you could walk through
> the process of following my instructions for getting a dump, that would
> be fantastic.

To be honest, once we get to "now patch the kernel..." I think we lose
most people at that point.  Reverting mesa (or ideally the patch that
caused the regression) may be a more doable option.
 
> > Carl has informed me about the new tools being developed for gathering
> > data on freezes.  I'm looking forward to deploying these tools in
> > Karmic, so hopefully we can work together towards getting the above list
> > cleared out.
> 
> It's looking like the 2.6.30 kernel will have all the kernel patches in
> mainstream Linux. (And it wouldn't be hard to backport these to
> something earlier, I don't think.)

If someone does backport this to the Ubuntu kernel, let me know.  I
might be able to get the kernel team to build a test kernel with this if
they're not too swamped.
 
> As for the tool to parse the hex dump, it's intel_gpu_dump and it lives
> here:
> 
> git://anongit.freedesktop.org/git/xorg/app/intel-gpu-tools
> 
> It's already fairly useful, (if you have the kernel patches installed,
> you just run "sudo intel_gpu_dump" and you get a human-readable dump for
> sending to us). And we've already used this to fix a couple of bugs.
> Eric and I are hacking on this tool regularly to add more and more
> information to it, (like, right now it doesn't print the PCI IDs nor the
> mapping from those to GPU chipset---that's what I'll add next---then
> we'll think about adding info on whether the GPU is idle/running/hung?
> if we can make a sensible, automatic determination of that kind of
> thing).

Cool, I'll look into making sure this gets packaged.  Will this be
living as a separate tool permanently, or will it get rolled into the
driver package, as intel_reg_dumper did?  (The latter lets us skip a lot
of paperwork in getting it available for users by default, but the
former is doable, just takes more effort.)

Bryce