[Intel-gfx] [PATCH] Manage PIPESTAT pending interrupt values to unblock vblank interrupts
Steven J Newbury
steve at snewbury.org.uk
Fri Nov 7 23:00:35 CET 2008
On Fri, 2008-11-07 at 21:44 +0000, Steven J Newbury wrote:
> On Fri, 2008-11-07 at 20:45 +0000, Steven J Newbury wrote:
> > On Fri, 2008-11-07 at 11:11 -0800, Eric Anholt wrote:
> > > On Fri, 2008-11-07 at 14:01 +0000, Steven J Newbury wrote:
>
> > > > I'm on 965GM and I'm having a serious interrupt problem since this patch
> > > > went into for-review:
> > > >
> > > > Nov 7 04:20:22 infinity irq 16: nobody cared (try booting with the
> > > > "irqpoll" option)
> > > > Nov 7 04:20:22 infinity Pid: 0, comm: swapper Not tainted
> > > > 2.6.28-rc3-00236-g1d7eff8 #23
> > > > Nov 7 04:20:22 infinity Call Trace:
> > > > Nov 7 04:20:22 infinity <IRQ> [<ffffffff80491a25>] ?
> > > > i915_driver_irq_handler+0x53/0x186
> > > > Nov 7 04:20:22 infinity [<ffffffff80270b55>] __report_bad_irq+0x3d/0x8c
> > > > Nov 7 04:20:22 infinity [<ffffffff80270cb7>] note_interrupt+0x113/0x178
> > > > Nov 7 04:20:22 infinity [<ffffffff802713db>] handle_fasteoi_irq
> > > > +0x99/0xc3
> > > > Nov 7 04:20:22 infinity [<ffffffff8020ee5f>] do_IRQ+0x9c/0x11d
> > > > Nov 7 04:20:22 infinity [<ffffffff8020c826>] ret_from_intr+0x0/0xa
> > > > Nov 7 04:20:22 infinity <EOI> [<ffffffff804572c0>] ?
> > > > acpi_idle_enter_simple+0x175/0x1a8
> > > > Nov 7 04:20:22 infinity [<ffffffff804572b6>] ? acpi_idle_enter_simple
> > > > +0x16b/0x1a8
> > > > Nov 7 04:20:22 infinity [<ffffffff8052af56>] ? cpuidle_idle_call
> > > > +0xa6/0xe0
> > > > Nov 7 04:20:22 infinity [<ffffffff8020b47a>] ? cpu_idle+0x4c/0xb0
> > > > Nov 7 04:20:22 infinity [<ffffffff80614551>] ? rest_init+0x75/0x77
> > > > Nov 7 04:20:22 infinity handlers:
> > > > Nov 7 04:20:22 infinity [<ffffffff804919d2>] (i915_driver_irq_handler
> > > > +0x0/0x186)
> > > > Nov 7 04:20:22 infinity Disabling IRQ #16
> > > >
> > > > This happens after a random amount of time in X, athough never very
> > > > long. From this point on there are no interrupts generated unless I
> > > > switch vts away from X and back again.
> I'm wrong here. Switching vts only "fixes" the second problem below.
>
> > This gets interrupts working
> > > > again for a short while.
> > >
> > > Can you get /proc/dri/0/i915_gem_interrupt from before and just after
> > > the problem occurs?
> > >
> > I'll fire up a for-review kernel and see what it says.
>
> Before X:
>
> Interrupt enable: 00000000
> Interrupt identity: 00000000
> Interrupt mask: fffedfff
> Pipe A stat: 00000203
> Pipe B stat: 80000206
> Interrupts received: 0
> Current sequence: 0
> Waiter sequence: 0
> IRQ sequence: 0
>
> After X has started:
>
> Interrupt enable: 00000051
> Interrupt identity: 00000002
> Interrupt mask: fffedfac
> Pipe A stat: 00020204
> Pipe B stat: 00000206
> Interrupts received: 1327
> Current sequence: 1742
> Waiter sequence: 0
> IRQ sequence: 1738
>
> Interrupt enable: 00000051
> Interrupt identity: 00000002
> Interrupt mask: fffedfac
> Pipe A stat: 00020204
> Pipe B stat: 00000206
> Interrupts received: 33424
> Current sequence: 43154
> Waiter sequence: 0
> IRQ sequence: 43132
>
> Interrupt enable: 00000051
> Interrupt identity: 00000002
> Interrupt mask: fffedfac
> Pipe A stat: 00020204
> Pipe B stat: 00020000
> Interrupts received: 42250
> Current sequence: 58442
> Waiter sequence: 0
> IRQ sequence: 58434
> ____
>
> After interrupt failure:
>
> Interrupt enable: 00000051
> Interrupt identity: 00000000
> Interrupt mask: fffedfac
> Pipe A stat: 00020204
> Pipe B stat: 00000206
> Interrupts received: 200097
> Current sequence: 96282
> Waiter sequence: 0
> IRQ sequence: 96282
>
> Output of 'cat /proc/interrupts' :
> CPU0 CPU1
> 0: 309831 301848 IO-APIC-edge timer
> 1: 964 1747 IO-APIC-edge i8042
> 4: 1 1 IO-APIC-edge
> 8: 1 0 IO-APIC-edge rtc0
> 9: 0 1 IO-APIC-fasteoi acpi
> 12: 11555 16280 IO-APIC-edge i8042
> 14: 0 0 IO-APIC-edge ata_piix
> 15: 0 0 IO-APIC-edge ata_piix
> 16: 99522 100479 IO-APIC-fasteoi i915 at pci:0000:00:02.0
> 19: 6 9 IO-APIC-fasteoi yenta, firewire_ohci
> 20: 75 63 IO-APIC-fasteoi uhci_hcd:usb1,
> uhci_hcd:usb3, ehci_hcd:usb7
> 21: 204 216 IO-APIC-fasteoi uhci_hcd:usb2,
> uhci_hcd:usb4, HDA Intel
> 22: 352 644 IO-APIC-fasteoi uhci_hcd:usb5,
> ehci_hcd:usb6
> 43: 4898 5996 PCI-MSI-edge ahci
> NMI: 0 0 Non-maskable interrupts
> LOC: 116278 86951 Local timer interrupts
> RES: 27385 27476 Rescheduling interrupts
> CAL: 91 32 Function call interrupts
> TLB: 32 96 TLB shootdowns
> TRM: 0 0 Thermal event interrupts
> THR: 0 0 Threshold APIC interrupts
> SPU: 0 0 Spurious interrupts
> ERR: 0
> MIS: 0
Curiously, the i915_gem_interrupt count continues to rise despite no
more interrupts being recorded in /proc/interrupts. Clearly interrupts
are not working, X is very slow, and glxgears reports interrupts are not
working correctly.
Currently:
cat /proc/dri/0/i915_gem_interrupt
Interrupt enable: 00000051
Interrupt identity: 00000002
Interrupt mask: fffedfac
Pipe A stat: 00000000
Pipe B stat: 00000206
Interrupts received: 615479
Current sequence: 308340
Waiter sequence: 0
IRQ sequence: 308338
Interrupts have since restarted a couple of times, it *may* be due to VT
switching after all (repeated VT switching apparently can cause the
system to lock up when interrupts aren't working correctly), but they
stopped again at *very* suspiciously round numbers:
For example:
16: 299110 300893 IO-APIC-fasteoi i915 at pci:0000:00:02.0
They also previously stopped around ~150000 ~150000
> >
> > > > This is possibly also related to the massive slowdown I get X uses 20%+
> > > > CPU constantly and continually probes DDC, when I switch to battery,
> > > > this I had expected to be fixed by the recent patch removing ACPI event
> > > > handling, but strangely it still occurs.
> > >
> > > You're the only person I've heard of with this problem. You'll need to
> > > figure out what's causing it. We still handle ACPI events, it was just
> > > an internal timer potentially firing off DDC that was removed.
> > >
> > I wonder if it's the VBIOS triggering continuous events? It may have
> > started happening when I updated to revision A13 (the latest) of the
> > Dell D830 BIOS. Perhaps I'm the only tester with a D830?
> >
> > Any idea how I could track this down?
> >
>
>
> _______________________________________________
> Intel-gfx mailing list
> Intel-gfx at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
More information about the Intel-gfx
mailing list