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

[Andrew Lutomirski]

On Thu, Jul 1, 2010 at 5:21 PM, Jesse Barnes <jbarnes at virtuousgeek.org> wrote:
> 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?

Um, maybe.  I've yet to trigger this when I'm near another computer.

But it just happened again and the attached (terrible) picture might
be interesting.   But given the fbcon_switch lines, I bet we're seeing
the wrong thing.  I just set pause_on_oops=120 and I'll let you know
if I see it again.

--Andy

>
> 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
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0701101723.jpg
Type: image/jpeg
Size: 399181 bytes
Desc: not available
URL: <http://lists.freedesktop.org/archives/intel-gfx/attachments/20100701/a200ab74/attachment.jpg>