On Thu, 1 Jul 2010 16:55:47 -0400 Andrew Lutomirski <l...@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 <jbar...@virtuousgeek.org> > wrote: > > On Mon, 21 Jun 2010 16:32:48 -0400 > > Andrew Lutomirski <l...@mit.edu> wrote: > > > >> On Sun, Jun 20, 2010 at 11:29 AM, Andrew Lutomirski <l...@mit.edu> wrote: > >> > On Fri, Jun 18, 2010 at 4:04 PM, Jesse Barnes <jbar...@virtuousgeek.org> > >> > wrote: > >> >> On Thu, 17 Jun 2010 19:44:10 -0700 > >> >> Jesse Barnes <jbar...@virtuousgeek.org> wrote: > >> >> > >> >>> On Fri, 18 Jun 2010 02:20:23 +0200 > >> >>> Marc Deop i Argemí <damnsh...@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 _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
