From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S965181Ab1GOIWX (ORCPT ); Fri, 15 Jul 2011 04:22:23 -0400 Received: from mail-qy0-f181.google.com ([209.85.216.181]:51019 "EHLO mail-qy0-f181.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S964935Ab1GOIWU (ORCPT ); Fri, 15 Jul 2011 04:22:20 -0400 Subject: Dropped IRQ disables Radeon 3D Date: Fri, 15 Jul 2011 08:20:02 -0000 From: Michael Witten To: linux-kernel@vger.kernel.org Cc: Arnuschky , Benjamin Herrenschmidt Message-ID: <0fe54f4a77b64475b9e6041d9ef5772b-mfwitten@gmail.com> In-Reply-To: References: Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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] [] ? __report_bad_irq.isra.6+0x37/0x83 > [357580.931283] [] ? snd_intel8x0_interrupt+0x4e/0x1c0 > [357580.931289] [] ? note_interrupt+0x110/0x175 > [357580.931296] [] ? tg3_interrupt_tagged+0x29/0x70 > [357580.931301] [] ? handle_irq_event_percpu+0x105/0x117 > [357580.931306] [] ? unmask_irq+0x1a/0x1a > [357580.931310] [] ? handle_irq_event+0x19/0x24 > [357580.931314] [] ? handle_level_irq+0x40/0x56 > [357580.931318] [] ? do_IRQ+0x2e/0x81 > [357580.931327] [] ? irq_exit+0x44/0x67 > [357580.931334] [] ? common_interrupt+0x29/0x30 > [357580.931339] [] ? __do_softirq+0x30/0xe5 > [357580.931343] [] ? local_bh_enable+0x2/0x2 > [357580.931346] [] ? irq_exit+0x31/0x67 > [357580.931353] [] ? do_IRQ+0x6e/0x81 > [357580.931360] [] ? acpi_hw_write_port+0x22/0x83 > [357580.931365] [] ? common_interrupt+0x29/0x30 > [357580.931371] [] ? acpi_idle_enter_bm+0x1d5/0x20a > [357580.931378] [] ? cpuidle_idle_call+0x65/0x95 > [357580.931382] [] ? cpu_idle+0x23/0x3d > [357580.931387] [] ? start_kernel+0x263/0x268 > [357580.931392] [] ? loglevel+0x14/0x14 > [357580.931395] handlers: > [357580.931397] [] (radeon_driver_irq_handler_kms+0x0/0x10) > [357580.931405] [] (usb_hcd_irq+0x0/0x5e) > [357580.931411] [] (usb_hcd_irq+0x0/0x5e) > [357580.931415] [] (tg3_interrupt_tagged+0x0/0x70) > [357580.931420] [] (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