On Tue, 25 Aug 2009 20:42:03 -0300 Henrique de Moraes Holschuh <hmh@xxxxxxxxxx> wrote: > On Mon, 24 Aug 2009, Jesse Barnes wrote: > > On Mon, 24 Aug 2009 20:39:07 +0200 > > "Rafael J. Wysocki" <rjw@xxxxxxx> wrote: > > > On Monday 24 August 2009, Matthew Garrett wrote: > > > > On Mon, Aug 24, 2009 at 01:12:39AM +0200, Rafael J. Wysocki > > > > wrote: > > > > > After some debugging it turned out that PCI0 is the PCI host > > > > > bridge (no-bus:pci0000:00), so apparently echoing PCI0 > > > > > to /proc/acpi/wakeup causes a wake-up GPE to be set up for the > > > > > host bridge which triggers wake-up once eth0 signals PME#. > > > > > > > > Mm. That sounds entirely plausible. If it were a built-in card > > > > then the DSDT would provide that GPE, but as an add-in... > > > > > > > > > First, I wonder if that's the case in general (anybody > > > > > knows?). Second, if that is the case, would it be a good idea > > > > > to set up the host bridge wake-up GPE by default? > > > > > > > > I'd expect this to be the case in general, yes. Systems that > > > > work without this probably have the BIOS enable it themselves on > > > > suspend. I suspect we'll have to set it to make sure. > > > > > > OK, Matthew, Alan, thanks for your opinions. > > > > > > I'll try to implement this, then. > > > > I think that's the best approach. The only risk that I can see > > immediately is that we'll expose ourselves to add-in cards with > > flakey PME# signals. We can worry about that when/if we see it > > though. > > I have seen it, an old atheros-based wifi card packaged by 3COM. My > Intel D875PBZ motherboard could not turn off (it would turn back on > due to #PME) with that crap installed. Probably the BIOS didn't > defend itself enough against PME on power _off_. I didn't even need > to have ANY driver at all for that card for it to be a hassle. > > I have sinced given that card away to someone who runs it under > Windows in a different motherboard (that probably masks #PME on > shutdown :p). > > May I humbly suggest a command-line switch to let the user disable > the new behaviour (or even selectively disable/enable it per host > bridge) since day one? The default can be enabled, let's priorize > good hardware and firmware over buggy crap! but let's make it easy > to work around any issues it could cause right from the beginning, > because they _will_ happen. Hopefully we can do even better than that with per-device quirks (i.e. only disable PME on a bridge if a child device is buggy). Rafael? -- Jesse Barnes, Intel Open Source Technology Center -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
