Re: PME# for add-on cards

Jesse Barnes
2009-08-27T16:13:07Z

On Tue, 25 Aug 2009 20:42:03 -0300
Henrique de Moraes Holschuh <hmh@hmh.eng.br> wrote:

> On Mon, 24 Aug 2009, Jesse Barnes wrote:
> > On Mon, 24 Aug 2009 20:39:07 +0200
> > "Rafael J. Wysocki" <rjw@sisk.pl> 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