On Fri, 2008-11-07 at 22:00 +0000, Steven J Newbury wrote:
> 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   [EMAIL 
> > PROTECTED]: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

Unless keithp's most recent patch moving BREADCRUMB_INDEX prevents some
internal brain damage, messing with IER often seems to be a bad idea, at
least on 965gm.  I've spent most of the week fighting this issue on
FreeBSD.  Last night, I flipped the logic back to setting up IER during
interrupt handler install and flipping bits in IMR to enable / disable
irqs and everything is working correctly again.  I have made some other
code changes in the handler, but none of them resolved the issue.
Inverting the logic got everything working again, for both INTx and MSI.
I know that it is published that MSI should not be used on the 965gm,
but I've not seen any issues on my hardware.

robert.

> 
> 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   [EMAIL PROTECTED]: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
> > [EMAIL PROTECTED]
> > http://lists.freedesktop.org/mailman/listinfo/intel-gfx
> 
> 
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> --
> _______________________________________________
> Dri-devel mailing list
> Dri-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/dri-devel

Attachment: signature.asc
Description: This is a digitally signed message part

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
--
_______________________________________________
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel

Reply via email to