Re: "do_IRQ: 0.89 No irq handler for vector (irq -1)"

[Jesse Barnes]

On Mon, 11 Oct 2010 15:48:26 -0700
Jesse Barnes <jbarnes@xxxxxxxxxxxxxxxx> wrote:

> On Fri, 8 Oct 2010 21:46:50 +1000
> Dave Airlie <airlied@xxxxxxxxx> wrote:
> > 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.
> 
> So I think we *should* be able to call pci_disable_device at remove
> time.  But as you say, some platforms may not correctly re-route VGA
> space to an existing device or disable it properly when we do that.
> AFAICT x86 will be ok here though (seems to work ok locally too).

Just tested this some more, and I think it's the right thing to do in
the KMS case at least.  When we load a KMS driver it takes over the gfx
device and nothing can assume anything about VGA state unless using the
VGA arbiter.  So calling pci_disable_device() in the shutdown path of a
KMS driver shouldn't make things any worse, and will work around this
issue.

Doing so in the non-KMS case violates some PC assumptions though, in
that things like vgacon and the BIOS will assume VGA memory is still
around, which on some platforms pci_disable_device() may affect (I only
checked the x86 implementation).

> That said, it seems like we should update the current device state at
> load time as well, once we've matched the driver it seems like there
> should be no harm.
> 
> Rafael, what do you think?  Would having the correct power state at
> load time cause any trouble with other PM code?  I know we've had
> issues with setting it explicitly in the past...

So we should probably make pci_enable_device pick up the current state
as well, instead of assuming it's unknown just because the enable count
was non-zero (which as Dave points out, can be affected by sysfs writes
too).

The only downside I can think of there is that if the device is already
enabled, we generally have to assume another driver owns it, and who
knows if the device is actually alive enough to read the current state
from.  But I think we handle those errors ok too, so pulling it out
should be safe.

-- 
Jesse Barnes, Intel Open Source Technology Center
--
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/