Hi Chris, On Sunday 23 January 2011, Chris Wilson wrote: > On Sun, 23 Jan 2011 15:38:41 +0000, Chris Clayton <chris2553@xxxxxxxxxxxxxx> wrote: <snip> > > I guess we may be working with slightly different versions of the source. > > > > 2. The kernel log now contains the following: > > > > r8169 0000:02:00.0: eth0: link up > > [drm] Initialized drm 1.1.0 20060810 > > irq 16: nobody cared (try booting with the "irqpoll" option) > > Pid: 0, comm: kworker/0:1 Not tainted 2.6.38-rc2+ #502 > > Call Trace: > > [<c1070a54>] ? __report_bad_irq.clone.2+0x24/0x90 > > [<c1070c17>] ? note_interrupt+0x157/0x190 > > [<c101b1cd>] ? ack_apic_level+0x5d/0x1e0 > > [<c107175b>] ? handle_fasteoi_irq+0xab/0xd0 > > [<c10716b0>] ? handle_fasteoi_irq+0x0/0xd0 > > <IRQ> [<c1004ddd>] ? do_IRQ+0x3d/0xc0 > > [<c1037f27>] ? irq_exit+0x57/0x70 > > [<c1019173>] ? smp_apic_timer_interrupt+0x53/0x90 > > [<c1003229>] ? common_interrupt+0x29/0x30 > > [<c119fbe9>] ? acpi_safe_halt+0x19/0x26 > > [<c119fc50>] ? acpi_idle_enter_c1+0x5a/0xa9 > > [<c1244d98>] ? cpuidle_idle_call+0x68/0xf0 > > [<c1001726>] ? cpu_idle+0x46/0x80 > > handlers: > > [<c129dd60>] (azx_interrupt+0x0/0x180) > > [<c12210d0>] (usb_hcd_irq+0x0/0x60) > > Disabling IRQ #16 > > pci 0000:00:02.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16 > > pci 0000:00:02.0: setting latency timer to 64 > > ioremap error for 0xbdce0000-0xbdce3000, requested 0x10, got 0x0 > > [drm] Supports vblank timestamp caching Rev 1 (10.10.2010). > > [drm] No driver support for vblank timestamp query. > > [drm] Initialized i915 1.6.0 20080730 for 0000:00:02.0 on minor 0 > > > > Is this likely to be related the the irq issues your patch addressed or > > is it a separate thing that I should report separately? > > It's the i915 IRQ alright, but I'm not sure what the cause is. An > unexpected interrupt arrived, although you don't use any paths in the > driver that use interrupts, nor should one be generated when all we are > doing is initialising the device structs. Should just be a minor nuisance > fortunately. > OK, I haven't raised the bug report yet, but I now know how to create it - reboot via kexec which is what I must have done when I built and installed the kernel to test your patches. I guess not having booted via the bios is leaving the card in an odd state. Do you care any more, please? If you do, I'll open the bug report. > If you can open a bug report to track it and attach > /sys/kernel/debug/dri/0/i915_gem_interrupts maybe we can work out from > the interrupt that arrived, why it was triggered. > -Chris Chris -- The more I see, the more I know. The more I know, the less I understand. Changing Man - Paul Weller _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel