From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756895Ab0JHLqx (ORCPT ); Fri, 8 Oct 2010 07:46:53 -0400 Received: from mail-ww0-f44.google.com ([74.125.82.44]:39619 "EHLO mail-ww0-f44.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756514Ab0JHLqw convert rfc822-to-8bit (ORCPT ); Fri, 8 Oct 2010 07:46:52 -0400 DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=D9iPQG9gpWyV/DK9moC6OosFQ8MMLUT16hyKL/poGimPlpDEJrMCzk1Q1tRuzu6fgG 7LJNT5Dc+1GRiXYHbpZP992MsY/rO7GBqYPL3R3UwbzZtu0EG3ocpTLO7bfOgds3P6w4 rvxeOXBv/R7OWwUiOizFi0EGlnMV/fEmAVCaI= MIME-Version: 1.0 In-Reply-To: References: Date: Fri, 8 Oct 2010 21:46:50 +1000 Message-ID: Subject: Re: "do_IRQ: 0.89 No irq handler for vector (irq -1)" From: Dave Airlie To: Thomas Gleixner Cc: LKML , Ingo Molnar , Jesse Barnes , Keith Packard Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Oct 8, 2010 at 5:52 PM, Thomas Gleixner wrote: > On Thu, 7 Oct 2010, Thomas Gleixner wrote: >  Oct  7 23:21:24 ionos kernel: Console: switching to colour VGA+ 80x25 >> Oct  7 23:21:31 ionos kernel: drm: unregistered panic notifier >> Oct  7 23:21:31 ionos kernel: vga_switcheroo: disabled >> Oct  7 23:21:31 ionos kernel: [drm:drm_mm_takedown] *ERROR* Memory manager not clean. Delaying takedown >> >> That one scares me :) >> >> Oct  7 23:21:32 ionos kernel: BUG: unable to handle kernel paging request at 00000037362e313a >> >> We are again dereferencing a user space address. > > Further debugging shows that the interrupt is torn down and the > vectors are cleared. On modprobe the irq is set up again and a > different vector is assigned. > > The interrupt which comes in is going to the old vector. So something > is stale in the card. Okay I've traced it with the hints Thomas gave me, What happens is we have never called pci_disable_device on video devices for various reasons, like shutting down VGA devices could be hostile, however on rmmod of the driver the PCI layer sets the device power state to PCI_UNKNOWN, when we next load the driver we call pci_enable_device which sees the enable cnt is 1, so never calls pci_set_power_state(PCI_D0), the MSI code won't actually write MSI msgs unless it knows we are in D0. Not sure how best to fix, I can workaround by calling pci_set_power_state(PCI_D0) in the drm drivers, but I sorta thing the PCI layer should take care of this. Dave.