Dropped IRQ disables Radeon 3D

From: Michael Witten
Date: Fri Jul 15 2011 - 04:22:26 EST


This is kind of a status update.

On Mon, 02 May 2011 20:19:35 +0000, Michael Witten wrote:

> I've been randomly getting the following backtrace in dmesg for a
> while now (I thought I built my kernel with debugging support and
> symbols, but I guess not, so sorry if it's not that helpful); at
> the time, I was running:
>
> v2.6.39-rc4-183-g0f1d9f7 (0f1d9f78ce41a8874d30271ef8480e6f8f7f1fce)
>
> It only seems like my 3D acceleration is disabled as a result
> of disabling the IRQ (and the IRQ number is not always the
> same).
>
> I can fix my 3D acceleration by suspending to ram and then
> waking my system up again.
>
> [357580.931252] irq 11: nobody cared (try booting with the "irqpoll" option)
> [357580.931260] Pid: 0, comm: swapper Not tainted 2.6.39-rc4-0f1d9f78ce41a8874d30271ef8480e6f8f7f1fce-THOR-205+ #4
> [357580.931264] Call Trace:
> [357580.931276] [<c1329df1>] ? __report_bad_irq.isra.6+0x37/0x83
> [357580.931283] [<c12900cb>] ? snd_intel8x0_interrupt+0x4e/0x1c0
> [357580.931289] [<c104d6a3>] ? note_interrupt+0x110/0x175
> [357580.931296] [<c121be98>] ? tg3_interrupt_tagged+0x29/0x70
> [357580.931301] [<c104c832>] ? handle_irq_event_percpu+0x105/0x117
> [357580.931306] [<c104da68>] ? unmask_irq+0x1a/0x1a
> [357580.931310] [<c104c85d>] ? handle_irq_event+0x19/0x24
> [357580.931314] [<c104daa8>] ? handle_level_irq+0x40/0x56
> [357580.931318] <IRQ> [<c100358a>] ? do_IRQ+0x2e/0x81
> [357580.931327] [<c1024510>] ? irq_exit+0x44/0x67
> [357580.931334] [<c132e2a9>] ? common_interrupt+0x29/0x30
> [357580.931339] [<c1024345>] ? __do_softirq+0x30/0xe5
> [357580.931343] [<c1024315>] ? local_bh_enable+0x2/0x2
> [357580.931346] <IRQ> [<c10244fd>] ? irq_exit+0x31/0x67
> [357580.931353] [<c10035ca>] ? do_IRQ+0x6e/0x81
> [357580.931360] [<c1147dd7>] ? acpi_hw_write_port+0x22/0x83
> [357580.931365] [<c132e2a9>] ? common_interrupt+0x29/0x30
> [357580.931371] [<c1154f11>] ? acpi_idle_enter_bm+0x1d5/0x20a
> [357580.931378] [<c1261150>] ? cpuidle_idle_call+0x65/0x95
> [357580.931382] [<c1001577>] ? cpu_idle+0x23/0x3d
> [357580.931387] [<c14dd60b>] ? start_kernel+0x263/0x268
> [357580.931392] [<c14dd151>] ? loglevel+0x14/0x14
> [357580.931395] handlers:
> [357580.931397] [<c11bdcb4>] (radeon_driver_irq_handler_kms+0x0/0x10)
> [357580.931405] [<c122cca3>] (usb_hcd_irq+0x0/0x5e)
> [357580.931411] [<c122cca3>] (usb_hcd_irq+0x0/0x5e)
> [357580.931415] [<c121be6f>] (tg3_interrupt_tagged+0x0/0x70)
> [357580.931420] [<c129007d>] (snd_intel8x0_interrupt+0x0/0x1c0)
> [357580.931426] Disabling IRQ #11

Arnuschky wrote to me about this related Debian bug report:

Fri, 2010-06-18 10:21:05 +0000
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=586312

I popped over to #radeon on freenode where user agd5f told me to
try the following on the kernel command line:

pci=nomsi

After reading about MSIs and the requisite CONFIG_* settings, I
realized that I didn't even have MSI support in the kernel anyway.
Then agd5f suggested the following patches by Benjamin Herrenschmidt
might be of help:

http://lists.freedesktop.org/archives/dri-devel/2011-July/012980.html
http://lists.freedesktop.org/archives/dri-devel/2011-July/012981.html

the latter of which fixes a syncronization bug on systems that use
non-MSI IRQs (presumably pin-based IRQs) for the radeon device/driver.

For my system, I decided to enable MSI/MSI-X support by building
Linux with the following configuration variables set:

CONFIG_PCI=y
CONFIG_X86_LOCAL_APIC=y
CONFIG_X86_IO_APIC=y
CONFIG_PCI_MSI=y

and making sure I get the following:

$ dmesg | grep MSI | grep radeon
radeon 0000:01:00.0: irq 42 for MSI/MSI-X
radeon 0000:01:00.0: radeon: using MSI.

I'm not sure if this will avoid the problem, but it sure seems like
a good bet.

Sincerely,
Michael Witten
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/