PME# for add-on cards

PME# for add-on cards

[Rafael J. Wysocki]

Hi,

Recently we've had a bug report indicating that WoL doesn't work with e100,
although the driver does everything needed to support it.  Apparently, the user
had to echo PCI0 to /proc/acpi/wakeup to make it work.

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#.

So, it looks like we need to set up wake-up GPE for a host bridge for PME#
from add-on cards to work, at least on this particular box.

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?

Rafael
 

Re: [linux-pm] PME# for add-on cards

[Alan Stern]

On Mon, 24 Aug 2009, Rafael J. Wysocki wrote:

> Hi,
> 
> Recently we've had a bug report indicating that WoL doesn't work with e100,
> although the driver does everything needed to support it.  Apparently, the user
> had to echo PCI0 to /proc/acpi/wakeup to make it work.
> 
> 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#.
> 
> So, it looks like we need to set up wake-up GPE for a host bridge for PME#
> from add-on cards to work, at least on this particular box.
> 
> 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?

Regarding the last question: Yes, of course.  Why wouldn't it be a good 
idea?

Alan Stern

Re: PME# for add-on cards

[Rafael J. Wysocki]

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.

Best,
Rafael

Re: PME# for add-on cards

[Jesse Barnes]

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.

Thanks,
-- 
Jesse Barnes, Intel Open Source Technology Center

Re: PME# for add-on cards

[Henrique de Moraes Holschuh]

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.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh

Re: PME# for add-on cards

[Maxim Levitsky]

On Mon, 2009-08-24 at 01:12 +0200, Rafael J. Wysocki wrote:
> Hi,
> 
> Recently we've had a bug report indicating that WoL doesn't work with e100,
> although the driver does everything needed to support it.  Apparently, the user
> had to echo PCI0 to /proc/acpi/wakeup to make it work.
> 
> 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#.
> 
> So, it looks like we need to set up wake-up GPE for a host bridge for PME#
> from add-on cards to work, at least on this particular box.
> 
> 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?
> 
> Rafael
>  

This is very known problem (at least for me)

On my desktop, /proc/acpi/wakeup controls all the wakeup sources, and if
disabled, nether addon cards (ethernet) nor internal devices
(usb,ethernet) will wake up the system.

I think that proc/acpi/wakeup should be synced with power/wakeup
attribute.

Also, I would be really happy to see bogus (empty) power/wakeup
attributes be gone.

Also, something is broken in regards to PME from addon cards:
http://www.spinics.net/lists/netdev/msg104460.html


Best regards,
	Maxim Levitsky

Re: PME# for add-on cards

[Rafael J. Wysocki]

On Wednesday 26 August 2009, Maxim Levitsky wrote:
> On Mon, 2009-08-24 at 01:12 +0200, Rafael J. Wysocki wrote:
> > Hi,
> > 
> > Recently we've had a bug report indicating that WoL doesn't work with e100,
> > although the driver does everything needed to support it.  Apparently, the user
> > had to echo PCI0 to /proc/acpi/wakeup to make it work.
> > 
> > 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#.
> > 
> > So, it looks like we need to set up wake-up GPE for a host bridge for PME#
> > from add-on cards to work, at least on this particular box.
> > 
> > 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?
> > 
> > Rafael
> >  
> 
> This is very known problem (at least for me)
> 
> On my desktop, /proc/acpi/wakeup controls all the wakeup sources, and if
> disabled, nether addon cards (ethernet) nor internal devices
> (usb,ethernet) will wake up the system.

Can you please open a Bugzilla entry for that and add my address to the CC list
in there?

> I think that proc/acpi/wakeup should be synced with power/wakeup
> attribute.

In fact proc/acpi/wakeup is going to be removed at one point in future, so
we're moving the functionality to power/wakeup.

> Also, I would be really happy to see bogus (empty) power/wakeup
> attributes be gone.

They are not bogus.  Empty power/wakeup means that the device is not capable
of waking up the system.

> Also, something is broken in regards to PME from addon cards:
> http://www.spinics.net/lists/netdev/msg104460.html

I'll have a look.

Thanks,
Rafael

Re: PME# for add-on cards

[Jesse Barnes]

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

Re: PME# for add-on cards

[Rafael J. Wysocki]

On Thursday 27 August 2009, Jesse Barnes wrote:
> 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?

First off, this is about enabling the host bridge's GPE to wake up the
system rather than PME and I'm not yet sure we can generally do that for all
host bridges (investigation in progress).

The particular system I was talking about in the first message in this thread
had a specific entry for the host bridge in /proc/acpi/wakeup while the other
systems I looked at didn't appear to have anything like this.

At the moment I think it should be safe to set wakeup.state.enabled for the
host bridge provided that it has wakeup.flags.valid set (otherwise it wouldn't
work anyway).  The systems where this is known unsafe should be regarded as
buggy and handled through quirks IMO.

Thanks,
Rafael