[Intel-gfx] [ANNOUNCE] xf86-video-intel 2.11.901

[Jesse Barnes]

On Thu, 1 Jul 2010 16:55:47 -0400
Andrew Lutomirski <luto at mit.edu> wrote:

> [Dave, cc-ing you because your vt panic patch is involved.]
> 
> On Wed, Jun 23, 2010 at 12:07 PM, Jesse Barnes <jbarnes at virtuousgeek.org> wrote:
> > On Mon, 21 Jun 2010 16:32:48 -0400
> > Andrew Lutomirski <luto at mit.edu> wrote:
> >
> >> On Sun, Jun 20, 2010 at 11:29 AM, Andrew Lutomirski <luto at mit.edu> wrote:
> >> > On Fri, Jun 18, 2010 at 4:04 PM, Jesse Barnes <jbarnes at virtuousgeek.org> wrote:
> >> >> On Thu, 17 Jun 2010 19:44:10 -0700
> >> >> Jesse Barnes <jbarnes at virtuousgeek.org> wrote:
> >> >>
> >> >>> On Fri, 18 Jun 2010 02:20:23 +0200
> >> >>> Marc Deop i Argemí <damnshock at gmail.com> wrote:
> >> >>>
> >> >>> > On Friday June 18 2010 02:17:53 Andrew Lutomirski wrote:
> >> >>> > > Neither patch applies for me.
> >> >>> >
> >> >>> > One of them do apply for me, the other one doesn't.
> >> >>> >
> >> >>> > Testing done on latest 2.6.35-rc3, the building fails.
> >> >>>
> >> >>> Arg, ok, I'll refresh them and post new ones tomorrow.
> >> >>
> >> >> Ok here are some updated ones.
> >> >
> >> > Running these patches on 2.6.35-rc3 (plus the brown-paper-bag TCP fix,
> >> > plus my hotplug_mask hack, plus my CRT regression fix) with
> >> > xf86-video-intel be55066c6481b4c5e2cd39ef1c0f3be88cae0c93 (which is
> >> > about a day old) seems stable and I don't have any visible corruption.
> >>
> >> Just froze again.  I moved my mouse and the screen turned black except
> >> for the mouse cursor and a little underscore in the top left that
> >> looked like the fbcon cursor.
> >>
> >> Again, magic sysrq didn't work, which I'd imagine would help narrow
> >> things down (presumably, no matter how hard the graphics hardware gets
> >> wedged, magic sysrq should still work).
> >
> > Yeah means the GMCH itself probably hung, possibly not responding to
> > memory requests from the CPU.
> >
> > The display was otherwise idle when it froze?  The behavior you
> > describe sounds like a panic; there's a patch available to get some
> > more info in that case: "vt/console: try harder to print output when
> > panicing" that Dave Airlie just posted (attached).  Can you apply it as
> > well and see if you can reproduce the problem?
> 
> Yes.  That patch sort of worked, but the main part of the OOPS
> scrolled off the screen (other subsequent oopsen displaced it) and
> shift-pgup didn't do anything.  (Neither did sysrq.)
> 
> Here's a blurry photo.

Ah great, so we're getting some info.  But the good stuff scrolled off
the screen.  Can you try setting up netconsole so you can capture all
of it in a terminal on a working machine?

You can also match the call trace info back to the source line.  The
call trace will look something like
  i915_gem_execbuffer 0x123/0x456
where the first number is the offset into the function and the second
is the size of the function.  Once you have that (just grab the first
one, usually up near the top of the register dump) you can use gdb to
find it:
  gdb /path/to/i915.ko
  ...
  (gdb) list *i915_gem_execbuffer+0x123
  ...
That should show you exactly where things went bad...

Thanks,
-- 
Jesse Barnes, Intel Open Source Technology Center