lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Mon, 11 Oct 2010 16:40:14 -0700 From: Jesse Barnes <jbarnes@...tuousgeek.org> To: Dave Airlie <airlied@...il.com> Cc: Thomas Gleixner <tglx@...utronix.de>, LKML <linux-kernel@...r.kernel.org>, Ingo Molnar <mingo@...e.hu>, Keith Packard <keithp@...thp.com>, "Rafael J. Wysocki" <rjw@...k.pl> Subject: Re: "do_IRQ: 0.89 No irq handler for vector (irq -1)" On Mon, 11 Oct 2010 15:48:26 -0700 Jesse Barnes <jbarnes@...tuousgeek.org> wrote: > On Fri, 8 Oct 2010 21:46:50 +1000 > Dave Airlie <airlied@...il.com> 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@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists