All of lore.kernel.org
 help / color / mirror / Atom feed
From: Thomas Hellstrom <thellstrom@vmware.com>
To: Dave Airlie <airlied@gmail.com>
Cc: linux-graphics-maintainer@vmware.com,
	"dri-devel@lists.freedesktop.org"
	<dri-devel@lists.freedesktop.org>
Subject: Re: Device loses its IRQ number on driver unload?
Date: Tue, 10 Mar 2015 13:55:25 +0100	[thread overview]
Message-ID: <54FEE9BD.4060308@vmware.com> (raw)
In-Reply-To: <CAPM=9twZCpTK2khD3UGg82MNCPoVy6Q63erSRMvN6YQtQwR3Hg@mail.gmail.com>

On 03/09/2015 09:25 PM, Dave Airlie wrote:
> On 10 March 2015 at 02:02, Thomas Hellstrom <thellstrom@vmware.com> wrote:
>> On 03/09/2015 04:22 PM, Daniel Vetter wrote:
>>> On Mon, Mar 09, 2015 at 11:04:01AM +0100, Thomas Hellstrom wrote:
>>>> Hi,
>>>>
>>>> I'm not sure this started with 4.0 but when I rmmod the device driver
>>>> like so
>>>> rmmod vmwgfx
>>>>
>>>> The device loses its IRQ line as shown in lscpi:
>>>>    Flags: bus master, medium devsel, latency 64 <irq missing here>
>>>>
>>>> and a subsequent modprobe will fail since pdev->irq is 0.
>>>>
>>>> Is anyone else seeing this with other drivers?
>>> I seen occasionally (over the past couple of kernels) random zeros in pdev
>>> but dismissed it as broken machines or bugs in i915 (we have them ...).
>>> Usually the box died chasing a NULL pointer from pdev. Otherwise no.
>>> -Daniel
>> OK. Thanks for the info. Since in my case this is 100% reproducible I
>> guess I have an excellent opportunity to bisect the problem :-/
>>
> does lspci -H1, or some option like to direct access hw show it?
>
> just whether this is the kernel copy or the hw register getting messed up.
>
> Dave.
Hi, Dave,

lspci -H1 indeed shows the IRQ number. It turns out that the commit
introduced in 4.0 breaking this is

b4b55cda587442477a3a9f0669e26bba4b7800c0 is the first bad commit
commit b4b55cda587442477a3a9f0669e26bba4b7800c0
Author: Jiang Liu <jiang.liu@linux.intel.com>
Date:   Thu Feb 5 13:44:47 2015 +0800

    x86/PCI: Refine the way to release PCI IRQ resources


It's obvious from the commit message that unloading the driver *should*
drop the irq resource but its not
obvious what's reallocating that resource on driver load...

Anyway, it turns out that adding a
pci_disable_device(pdev) in the pci driver's remove() method
(vmw_remove() in my case) appears to fix the problem:
The device irq is removed on driver unload and enabled again on driver
load There appears to be no pci_disable_device() on driver exit in core drm.

However it still beats me why other drm drivers aren't seeing this, and
IMHO that commit should probably add a warning message if the pci device
isn't disabled on pci driver unload......

/Thomas

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

  reply	other threads:[~2015-03-10 12:55 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-03-09 10:04 Device loses its IRQ number on driver unload? Thomas Hellstrom
2015-03-09 15:22 ` Daniel Vetter
2015-03-09 16:02   ` Thomas Hellstrom
2015-03-09 20:25     ` Dave Airlie
2015-03-10 12:55       ` Thomas Hellstrom [this message]
2015-03-10 14:01         ` Alex Deucher
2015-03-10 21:05         ` Dave Airlie
2015-03-11  6:40           ` Thomas Hellstrom
2015-03-11  7:22             ` Dave Airlie
2015-03-11  9:28               ` Thomas Hellstrom

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=54FEE9BD.4060308@vmware.com \
    --to=thellstrom@vmware.com \
    --cc=airlied@gmail.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=linux-graphics-maintainer@vmware.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.