On Tue, 8 Sep 2009, Linus Torvalds wrote:
>
> The code here is
>
> 16: 48 8b 80 00 01 00 00 mov 0x100(%rax),%rax
> 1d: 48 8b 50 08 mov 0x8(%rax),%rdx
> 21: 48 85 d2 test %rdx,%rdx
> 24: 74 11 je 0x37
> 26: 49 8b 44 24 78 mov 0x78(%r12),%rax
> 2b:* 8b 80 84 00 00 00 mov 0x84(%rax),%eax <-- trapping instruction
> 31: 89 82 08 08 00 00 mov %eax,0x808(%rdx)
> 37: f6 45 a0 02 testb $0x2,-0x60(%rbp)
>
> and that "testb $0x2, -0x60(%rbp)" seems to be the
>
> if (iir & I915_USER_INTERRUPT) {
Yeah, that seems to be the right thing.
So the actual faulting instruction is from this:
if (dev->primary->master) {
master_priv = dev->primary->master->driver_priv;
if (master_priv->sarea_priv)
master_priv->sarea_priv->last_dispatch =
READ_BREADCRUMB(dev_priv);
and it looks like %rax starts out being 'dev', then the
mov 0x100(%rax),%rax
means that %rax is now 'dev->primary', and then
mov 0x8(%rax),%rdx
moves 'dev->primary->master' into %rdx. It's not zero, so we then do that
READ_BREADCRUMB(dev_priv), which expands to
READ_HWSP(dev_priv, I915_BREADCRUMB_INDEX)
which in turn is
(((volatile u32*)(dev_priv->hw_status_page))[reg])
and it looks like dev_priv->hw_status_page is NULL.
You can verify this by looking at teh exception address:
BUG: unable to handle kernel NULL pointer dereference at 0000000000000084
and that '84' is I915_BREADCRUMB_INDEX*4 (0x21*4).
And the problem seems to be that we've cleared the hw_status_page pointer
in i915_gem_cleanup_hws():
dev_priv->hw_status_page = NULL;
and we did that in
i915_gem_idle() ->
i915_gem_cleanup_ringbuffer() ->
i915_gem_cleanup_hws()
so now since interrupts are still enabled, you'll get a NULL pointer
dereference.
I think my patch is correct.
Linus
--
To unsubscribe from this list: send the line "unsubscribe kernel-testers" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
