Usage of WoWLAN with iwlwifi driver (Device phy0 failed to suspend async: error -16)

Usage of WoWLAN with iwlwifi driver (Device phy0 failed to suspend async: error -16)

[Oliver Freyermuth]

Dear wireless experts, 

I have been trying to get basic WoWLAN to work with the following configuration:
- Intel Corporation Wireless 7260 (rev 73) with in-tree iwlwifi driver
- Kernel 4.10.0 (on Gentoo Linux)
- Very recent firmware version for the card and revision:
iwlwifi 0000:0a:00.0: loaded firmware version 17.459231.0 op_mode iwlmvm
iwlwifi 0000:0a:00.0: Detected Intel(R) Dual Band Wireless AC 7260, REV=0x144

I try to do:
$ iw phy phy0 wowlan enable magic-packet
$ iw phy phy0 wowlan show
WoWLAN is enabled:
 * wake up on magic packet

However, when trying to suspend to RAM ( echo mem > /sys/power/state ), I get:
[46656.403767] dpm_run_callback(): wiphy_suspend+0x0/0x97 [cfg80211] returns -16
[46656.403769] PM: Device phy0 failed to suspend async: error -16
[46656.967002] PM: Some devices failed to suspend, or early wake event detected

It also happens with more complex configurations (e.g. TCP connection WoWLAN mode). 

Only after:
$ iw phy phy0 wowlan disable
I can suspend normally again. 

I found an earlier report here:
https://bugzilla.kernel.org/show_bug.cgi?id=109591#c25
from somebody using kernel 4.6. 

Is this a known issue? Is WoWLAN supposed to work with this hardware (I guess it's quite wide-spread)? 

If possible, please ping me directly in replies, I am not subscribed to the list (but will try to check gmane regularly). 

Cheers and thanks for any support, 
	Oliver

Re: Usage of WoWLAN with iwlwifi driver (Device phy0 failed to suspend async: error -16)

[Johannes Berg]

> I have been trying to get basic WoWLAN to work with the following
> configuration:
> - Intel Corporation Wireless 7260 (rev 73) with in-tree iwlwifi
> driver

So I just tried on 4.9 with a 6205 NIC and it works there. The
difference must be somewhere in mvm/d3.c then, I guess. I got a lot of
warnings at resume time though, not sure why.

> However, when trying to suspend to RAM ( echo mem > /sys/power/state
> ), I get:
> [46656.403767] dpm_run_callback(): wiphy_suspend+0x0/0x97 [cfg80211]
> returns -16
> [46656.403769] PM: Device phy0 failed to suspend async: error -16
> 

However, I don't see EBUSY anywhere there in the driver.

Can you recompile the kernel and run a quick experiment?

Open drivers/net/wireless/intel/iwlwifi/mvm/mvm.h and put something
like this after the includes:

#undef EBUSY
#define EBUSY ({ WARN_ON(1); 16; })

that should trigger a warning at the place where the EBUSY came from,
assuming it did in fact come from the driver. You could repeat it for
net/mac80211/ieee80211_i.h if that doesn't trigger.

> https://bugzilla.kernel.org/show_bug.cgi?id=109591#c25

That device is like mine, afaict, so this seems to be a different bug.

johannes

Re: Usage of WoWLAN with iwlwifi driver (Device phy0 failed to suspend async: error -16)

[Oliver Freyermuth]

Am 24.02.2017 um 13:11 schrieb Johannes Berg:
>> However, when trying to suspend to RAM ( echo mem > /sys/power/state
>> ), I get:
>> [46656.403767] dpm_run_callback(): wiphy_suspend+0x0/0x97 [cfg80211]
>> returns -16
>> [46656.403769] PM: Device phy0 failed to suspend async: error -16
>>
> 
> However, I don't see EBUSY anywhere there in the driver.
> 
> Can you recompile the kernel and run a quick experiment?
> 
> Open drivers/net/wireless/intel/iwlwifi/mvm/mvm.h and put something
> like this after the includes:
> 
> #undef EBUSY
> #define EBUSY ({ WARN_ON(1); 16; })
> 
> that should trigger a warning at the place where the EBUSY came from,
> assuming it did in fact come from the driver. You could repeat it for
> net/mac80211/ieee80211_i.h if that doesn't trigger.

Thanks for your reply and the suggestion! I have put the two lines directly after the last #include
in both files, i.e. both drivers/net/wireless/intel/iwlwifi/mvm/mvm.h and net/mac80211/ieee80211_i.h . 
Sadly, none of them triggers when trying to enter suspend. 

I still get:
[   85.308756] dpm_run_callback(): wiphy_suspend+0x0/0x97 [cfg80211] returns -16
[   85.308757] PM: Device phy0 failed to suspend async: error -16
[   85.310518] sd 5:0:0:0: [sdb] Stopping disk
[   85.857976] PM: Some devices failed to suspend, or early wake event detected
with nothing in between. 

Just to make sure, I can confirm the change is effective, since I get many of:
[   57.819114] WARNING: CPU: 4 PID: 4092 at drivers/net/wireless/intel/iwlwifi/mvm/tx.c:1503 iwl_mvm_rx_tx_cmd+0x51e/0x579 [iwlmvm]
(with the tracebacks) for example when connecting to a different network. But none of these when trying to suspend...

Any other ideas on where I could look, or how I could trace the origin of this -16? 

> 
>> https://bugzilla.kernel.org/show_bug.cgi?id=109591#c25
> 
> That device is like mine, afaict, so this seems to be a different bug.
You are right about the bug report - I provided the wrong link, sorry. 
The report I meant is here:
https://bugzilla.redhat.com/show_bug.cgi?id=1362311
for a 7260 similar to mine. 

I believe that 
 https://bugzilla.kernel.org/show_bug.cgi?id=109591#c25
i.e. comment 25 was made by the same person who just hijacked that kernel
bug report even though it was indeed for a very different hardware. 

I'm open for any other suggestions, let me know if anything comes to mind. 

Cheers and thanks for your reply, 
	Oliver

Re: Usage of WoWLAN with iwlwifi driver (Device phy0 failed to suspend async: error -16)

[Johannes Berg]

On Fri, 2017-02-24 at 19:51 +0100, Oliver Freyermuth wrote:
> 
> Thanks for your reply and the suggestion! I have put the two lines
> directly after the last #include
> in both files, i.e. both drivers/net/wireless/intel/iwlwifi/mvm/mvm.h
> and net/mac80211/ieee80211_i.h . 
> Sadly, none of them triggers when trying to enter suspend. 
> 
> I still get:
> [   85.308756] dpm_run_callback(): wiphy_suspend+0x0/0x97 [cfg80211]
> returns -16
> [   85.308757] PM: Device phy0 failed to suspend async: error -16
> [   85.310518] sd 5:0:0:0: [sdb] Stopping disk
> [   85.857976] PM: Some devices failed to suspend, or early wake
> event detected
> with nothing in between. 

I'd have expected the message to show up *before* the first one
(dpm_run_callback) you quoted, because this one already has the -16
return value printed, and it must've been generated before that.

I just tried on one of my systems, but it's not exactly the same kernel
version (would be difficult to install right now), and it works just
fine for me. Perhaps there's something going on with your system.

> Just to make sure, I can confirm the change is effective, since I get
> many of:
> [   57.819114] WARNING: CPU: 4 PID: 4092 at
> drivers/net/wireless/intel/iwlwifi/mvm/tx.c:1503
> iwl_mvm_rx_tx_cmd+0x51e/0x579 [iwlmvm]
> (with the tracebacks) for example when connecting to a different
> network. But none of these when trying to suspend...

Oops. I didn't see this instance of EBUSY in the success path - it's
used for a comparison that probably never triggered. Anyway, no harm
done apart from logging lots of useless stack traces :)

> Any other ideas on where I could look, or how I could trace the
> origin of this -16? 

(see below)

> You are right about the bug report - I provided the wrong link,
> sorry. 
> The report I meant is here:
> https://bugzilla.redhat.com/show_bug.cgi?id=1362311
> for a 7260 similar to mine. 

Yes, that one looks like the same as yours.

> I believe that 
>  https://bugzilla.kernel.org/show_bug.cgi?id=109591#c25
> i.e. comment 25 was made by the same person who just hijacked that
> kernel
> bug report even though it was indeed for a very different hardware. 

Ok, that's possible.

So let's see. The error *isn't* generated by mac80211 or iwlwifi, but
it's still returned through wiphy_suspend(). That function just calls
mac80211 though, and never generates any error conditions by itself. As
a consequence, this must be generated in some callee of wiphy_suspend()
that *isn't* in mac80211/iwlwifi...

__ieee80211_suspend() also doesn't generate any error codes by itself,
let's take a look at iwlmvm's suspend (called through drv_suspend()),
that's iwl_mvm_suspend().

Oh. Can you see if you have CONFIG_IWLWIFI_PCIE_RTPM enabled in your
configuration? If you do, please turn it off and see if that fixes it.

This still looks fishy in the code though, but let's see if that's the
problem first.

johannes

Re: Usage of WoWLAN with iwlwifi driver (Device phy0 failed to suspend async: error -16)

[Oliver Freyermuth]

Am 24.02.2017 um 20:37 schrieb Johannes Berg:
> So let's see. The error *isn't* generated by mac80211 or iwlwifi, but
> it's still returned through wiphy_suspend(). That function just calls
> mac80211 though, and never generates any error conditions by itself. As
> a consequence, this must be generated in some callee of wiphy_suspend()
> that *isn't* in mac80211/iwlwifi...
> 
> __ieee80211_suspend() also doesn't generate any error codes by itself,
> let's take a look at iwlmvm's suspend (called through drv_suspend()),
> that's iwl_mvm_suspend().
> 
> Oh. Can you see if you have CONFIG_IWLWIFI_PCIE_RTPM enabled in your
> configuration? If you do, please turn it off and see if that fixes it.
Indeed, you got it! 
I had it on, and turning that off lets me suspend just fine after activating WoWLAN!

See here, the syslog is now clean (I removed the EBUSY-WARNONs for now):
[12383.757181] PM: Syncing filesystems ... done.
[12383.924701] PM: Preparing system for sleep (mem)
[12384.249363] ACPI Warning: \_SB.PCI0.PEG0.DGPU._DSM: Argument #4 type mismatch - Found [Buffer], ACPI requires [Package] (20160930/nsarguments-95)
[12385.323377] Freezing user space processes ... (elapsed 0.001 seconds) done.
[12385.325193] Freezing remaining freezable tasks ... (elapsed 0.001 seconds) done.
[12385.326602] PM: Suspending system (mem)
[12385.326619] Suspending console(s) (use no_console_suspend to debug)
[12385.326989] sd 5:0:0:0: [sdb] Synchronizing SCSI cache
[12385.327076] sd 0:0:0:0: [sda] Synchronizing SCSI cache
[12385.327199] sd 0:0:0:0: [sda] Stopping disk
[12385.329952] sd 5:0:0:0: [sdb] Stopping disk
[12385.335474] iwlwifi 0000:0a:00.0: L1 Enabled - LTR Enabled
[12385.335737] iwlwifi 0000:0a:00.0: L1 Enabled - LTR Enabled
[12385.426964] ACPI : EC: event blocked
[12385.637708] ACPI Warning: \_SB.PCI0.PEG0.DGPU._DSM: Argument #4 type mismatch - Found [Buffer], ACPI requires [Package] (20160930/nsarguments-95)
[12385.678281] nvidia-modeset: WARNING: GPU:0: Failed to determine which devices were hotplugged: 0x11

[12385.892099] PM: suspend of devices complete after 565.370 msecs
[12385.892586] PM: late suspend of devices complete after 0.484 msecs
[12385.892942] ACPI : EC: interrupt blocked
[12385.893495] ehci-pci 0000:00:1d.0: System wakeup enabled by ACPI
[12385.893568] iwlwifi 0000:0a:00.0: System wakeup enabled by ACPI
[12385.893685] ehci-pci 0000:00:1a.0: System wakeup enabled by ACPI
[12385.893754] xhci_hcd 0000:00:14.0: System wakeup enabled by ACPI
[12385.905567] PM: noirq suspend of devices complete after 12.970 msecs
[12385.905967] ACPI: Preparing to enter system sleep state S3
[12385.906505] ACPI : EC: EC stopped
[12385.906505] PM: Saving platform NVS memory
[12385.906511] Disabling non-boot CPUs ...
[12385.908459] smpboot: CPU 1 is now offline
[12385.919596] smpboot: CPU 2 is now offline
[12385.928100] smpboot: CPU 3 is now offline
[12385.939661] smpboot: CPU 4 is now offline
[12385.952240] smpboot: CPU 5 is now offline
[12385.965252] smpboot: CPU 6 is now offline
[12385.975465] smpboot: CPU 7 is now offline


The problem is that it seems I cannot actually wake the machine anymore afterwards... 
While in the suspend procedure, I see:
[12385.893568] iwlwifi 0000:0a:00.0: System wakeup enabled by ACPI
as expected, I could neither get it to make a tcp connection in tcp-connection mode,
nor could I wake the machine via magic packet in magic-packet mode. 

Could that be some hardware / system firmware limitation, e.g. if my UEFI does not support actually powering
the WiFi hardware if I am in S3? I have yet to (re)check the UEFI config, but since the options are
extremely limited on this Alienware laptop, I guess I will not find anything related to that. 

At least, the suspend problem seems to be clearly related to some path only used if CONFIG_IWLWIFI_PCIE_RTPM is on. 

> 
> This still looks fishy in the code though, but let's see if that's the
> problem first.
> 
> johannes
> 

Re: Usage of WoWLAN with iwlwifi driver (Device phy0 failed to suspend async: error -16)

[Johannes Berg]

> > Oh. Can you see if you have CONFIG_IWLWIFI_PCIE_RTPM enabled in
> > your configuration? If you do, please turn it off and see if that
> > fixes it.
> 
> Indeed, you got it! 
> I had it on, and turning that off lets me suspend just fine after
> activating WoWLAN!

[snip]

> The problem is that it seems I cannot actually wake the machine
> anymore afterwards... 
> While in the suspend procedure, I see:
> [12385.893568] iwlwifi 0000:0a:00.0: System wakeup enabled by ACPI
> as expected, I could neither get it to make a tcp connection in tcp-
> connection mode,
> nor could I wake the machine via magic packet in magic-packet mode. 
> 
> Could that be some hardware / system firmware limitation, e.g. if my
> UEFI does not support actually powering
> the WiFi hardware if I am in S3?

Yes. Does it print something to that effect at resume time? I think it
should.

> At least, the suspend problem seems to be clearly related to some
> path only used if CONFIG_IWLWIFI_PCIE_RTPM is on. 

Would you mind filing a bug on bugzilla.kernel.org (and adding linuxwif
i@intel.com as the assignee or at least in Cc)? I think we really ought
to sort out the issues with the RTPM stuff.

johannes

Re: Usage of WoWLAN with iwlwifi driver (Device phy0 failed to suspend async: error -16)

[Oliver Freyermuth]

Am 02.03.2017 um 09:55 schrieb Johannes Berg:
>> The problem is that it seems I cannot actually wake the machine
>> anymore afterwards... 
>> While in the suspend procedure, I see:
>> [12385.893568] iwlwifi 0000:0a:00.0: System wakeup enabled by ACPI
>> as expected, I could neither get it to make a tcp connection in tcp-
>> connection mode,
>> nor could I wake the machine via magic packet in magic-packet mode. 
>>
>> Could that be some hardware / system firmware limitation, e.g. if my
>> UEFI does not support actually powering
>> the WiFi hardware if I am in S3?
> 
> Yes. Does it print something to that effect at resume time? I think it
> should.
Oh yes - I totally missed that since it came quite late in the resume cycle:

[12386.085899] iwlwifi 0000:0a:00.0: System wakeup disabled by ACPI
[12386.088449] iwlwifi 0000:0a:00.0: Device was reset during suspend

I guess the "Device was reset during suspend" means my firmware did something uncool
like cutting the power to it (it's a laptop, but I suspended with power supply staying connected). 
UEFI options are very limited, so I guess I'm just out of luck with this hardware. 

I have another laptop with the same iwlwifi card (but newer HW revision), a comparable Gentoo 
installation but with an unlocked UEFI. 
I'll play with it on the weekend and report back in case I find anything different there. 

>> At least, the suspend problem seems to be clearly related to some
>> path only used if CONFIG_IWLWIFI_PCIE_RTPM is on. 
> 
> Would you mind filing a bug on bugzilla.kernel.org (and adding linuxwif
> i@intel.com as the assignee or at least in Cc)? I think we really ought
> to sort out the issues with the RTPM stuff.
Good idea, I'll do that over the weekend. 

Thanks a lot for the support! 
	Oliver

> 
> johannes
> 

Re: Usage of WoWLAN with iwlwifi driver (Device phy0 failed to suspend async: error -16)

[Johannes Berg]

> > Yes. Does it print something to that effect at resume time? I think
> > it should.
> 
> Oh yes - I totally missed that since it came quite late in the resume
> cycle:
> 
> [12386.085899] iwlwifi 0000:0a:00.0: System wakeup disabled by ACPI
> [12386.088449] iwlwifi 0000:0a:00.0: Device was reset during suspend
> 
> I guess the "Device was reset during suspend" means my firmware did
> something uncool like cutting the power to it (it's a laptop, but I
> suspended with power supply staying connected). 

Yes.

> UEFI options are very limited, so I guess I'm just out of luck with
> this hardware. 

Yeah, most likely.

> I have another laptop with the same iwlwifi card (but newer HW
> revision), a comparable Gentoo 
> installation but with an unlocked UEFI. 
> I'll play with it on the weekend and report back in case I find
> anything different there. 

Ok. I *have* gotten this to work on some (old) laptops, but not
generally.

johannes

Re: Usage of WoWLAN with iwlwifi driver (Device phy0 failed to suspend async: error -16)

[Oliver Freyermuth]

Am 02.03.2017 um 09:55 schrieb Johannes Berg:
> Would you mind filing a bug on bugzilla.kernel.org (and adding linuxwif
> i@intel.com as the assignee or at least in Cc)? I think we really ought
> to sort out the issues with the RTPM stuff.
Done: 
https://bugzilla.kernel.org/show_bug.cgi?id=194791

Am 02.03.2017 um 19:38 schrieb Johannes Berg:
>> I have another laptop with the same iwlwifi card (but newer HW
>> revision), a comparable Gentoo 
>> installation but with an unlocked UEFI. 
>> I'll play with it on the weekend and report back in case I find
>> anything different there. 
> 
> Ok. I *have* gotten this to work on some (old) laptops, but not
> generally.
> 
Well, at least with that other laptop I get *some* different result. 
Again, things only work with the RTPM stuff disabled (as expected). 
However, I do not get the dreaded:
"Device was reset during suspend"
on that machine!
Also, the machine stays connected to the AP if WoWLAN is activated and I enter suspend. 

However, it does not wake... To get any feedback, I tried something more complex. 

With tcp-mode, and using the small testing code I found from you somewhere on the web:
https://bugs.chromium.org/p/chromium/issues/detail?id=361435#c21
indeed I get:
"new client!"
after the machine has suspended. 
It even seems to receive the "WAKEUPNOW" when I close the server,
since it does not make further reconnection attempts after. 

So in general, it seems the Intel card stays powered and does what it should. 
The only issue is that the machine does not wake at all... 

My kernel log says:
[ 2751.003805] iwlwifi 0000:03:00.0: L1 Enabled - LTR Enabled
[ 2751.656632] ACPI : EC: event blocked
[ 2753.817464] PM: suspend of devices complete after 2822.876 msecs
[ 2753.829438] PM: late suspend of devices complete after 11.970 msecs
[ 2753.829818] ACPI : EC: interrupt blocked
[ 2753.830343] ehci-pci 0000:00:1d.0: System wakeup enabled by ACPI
[ 2753.830345] iwlwifi 0000:03:00.0: System wakeup enabled by ACPI
[ 2753.830348] pcieport 0000:00:1c.3: System wakeup enabled by ACPI
[ 2753.830484] ehci-pci 0000:00:1a.0: System wakeup enabled by ACPI
[ 2753.830502] xhci_hcd 0000:00:14.0: System wakeup enabled by ACPI
[ 2753.842577] PM: noirq suspend of devices complete after 13.136 msecs
[ 2753.842853] ACPI: Preparing to enter system sleep state S3
[ 2753.843922] ACPI : EC: EC stopped
[ 2753.843923] PM: Saving platform NVS memory
[ 2753.843928] Disabling non-boot CPUs ...

[snip]

[ 2753.982917] ACPI: Waking up from system sleep state S3
[ 2753.983883] acpi LNXPOWER:01: Turning OFF
[ 2753.984044] ACPI : EC: interrupt unblocked
[ 2753.985895] ehci-pci 0000:00:1a.0: System wakeup disabled by ACPI
[ 2753.985912] ehci-pci 0000:00:1d.0: System wakeup disabled by ACPI
[ 2753.985917] xhci_hcd 0000:00:14.0: System wakeup disabled by ACPI
[ 2753.996565] PM: noirq resume of devices complete after 12.652 msecs
[ 2753.997093] PM: early resume of devices complete after 0.507 msecs
[ 2753.997205] ACPI : EC: event unblocked
[ 2753.997355] iwlwifi 0000:03:00.0: System wakeup disabled by ACPI
[ 2753.997369] ACPI : button: The lid device is not compliant to SW_LID.
[ 2753.997733] pcieport 0000:00:1c.3: System wakeup disabled by ACPI
[ 2753.997753] sd 0:0:0:0: [sda] Starting disk
[ 2753.997754] sd 5:0:0:0: [sdb] Starting disk
[ 2753.997886] rtc_cmos 00:02: System wakeup disabled by ACPI
[ 2754.007327] iwlwifi 0000:03:00.0: L1 Enabled - LTR Enabled

So nothing which looks bad as far as I can see. 

Maybe this UEFI firmware is broken in a different, albeit "more stupid" way: 
Discarding ACPI wakeup from PCI devices, even though it leaves them powered? 

Cheers, 
Oliver

Re: Usage of WoWLAN with iwlwifi driver (Device phy0 failed to suspend async: error -16)

[Johannes Berg]

On Sun, 2017-03-05 at 16:12 +0100, Oliver Freyermuth wrote:

[snip]

> With tcp-mode, and using the small testing code I found from you
> somewhere on the web:
> https://bugs.chromium.org/p/chromium/issues/detail?id=361435#c21
> indeed I get:
> "new client!"
> after the machine has suspended. 
> It even seems to receive the "WAKEUPNOW" when I close the server,
> since it does not make further reconnection attempts after. 

Heh. I think you're quite possibly the first person (other than me) to
ever use this :)

[snip]

> So nothing which looks bad as far as I can see. 

Agree, nothing looks bad. Try running "iw event" while you suspend - if
the NIC thought it woke up the system there will be an event indicating
so.

> Maybe this UEFI firmware is broken in a different, albeit "more
> stupid" way: 
> Discarding ACPI wakeup from PCI devices, even though it leaves them
> powered? 

I guess it's possible. I guess there's also a chance that we're missing
some setup in the driver though. I vaguely remember a patch in ChromeOS
that somehow we never merged ... ah yes, must've been this one:
https://chromium-review.googlesource.com/311101
though that means it's not relevant in your system.

So basically I don't really see anything missing in the driver, hmm.

johannes

Re: Usage of WoWLAN with iwlwifi driver (Device phy0 failed to suspend async: error -16)

[Oliver Freyermuth]

Am 06.03.2017 um 09:11 schrieb Johannes Berg:
> On Sun, 2017-03-05 at 16:12 +0100, Oliver Freyermuth wrote:
> 
> [snip]
> 
>> With tcp-mode, and using the small testing code I found from you
>> somewhere on the web:
>> https://bugs.chromium.org/p/chromium/issues/detail?id=361435#c21
>> indeed I get:
>> "new client!"
>> after the machine has suspended. 
>> It even seems to receive the "WAKEUPNOW" when I close the server,
>> since it does not make further reconnection attempts after. 
> 
> Heh. I think you're quite possibly the first person (other than me) to
> ever use this :)
> 
It seems the script itself is really working as it should, see below ;-). 

> [snip]
> 
>> So nothing which looks bad as far as I can see. 
> 
> Agree, nothing looks bad. Try running "iw event" while you suspend - if
> the NIC thought it woke up the system there will be an event indicating
> so.
> 
Indeed, I get:
1488836432.153465: wlan0 (phy #0): WoWLAN wakeup
        * packet (might be truncated): ac:fd:ce:de:e1:58:b8:27:eb:f4:3b:4c:08:00:45:00:00:31:78:d1:40:00:3f:06:3d:55:c0:a8:02:23:c0:a8:02:2d:30:39:30:39:f2:04:6f:88:8b:74:4c:c2:50:18:72:10:00:00:00:00:57:41:4b:45:55:50:4e:4f:57
        * TCP connection wakeup received

Note the trailing "57:41:4b:45:55:50:4e:4f:57" which is your "WAKEUPNOW". 

Also magic packet "works" this way, i.e. shows up via "iw event". 

>> Maybe this UEFI firmware is broken in a different, albeit "more
>> stupid" way: 
>> Discarding ACPI wakeup from PCI devices, even though it leaves them
>> powered? 
> 
> I guess it's possible. I guess there's also a chance that we're missing
> some setup in the driver though. I vaguely remember a patch in ChromeOS
> that somehow we never merged ... ah yes, must've been this one:
> https://chromium-review.googlesource.com/311101
> though that means it's not relevant in your system.
> 
> So basically I don't really see anything missing in the driver, hmm.
I realized I also have a Win10 installation on that machine - and may as well try WoWLAN with it. 
Enabling (in the dreaded device manager) wake via the WiFi device, magic packet mode, I also cannot wake the machine. 
So if it was a driver bug, it would have to be present both in Windows and Linux drivers - but I guess it's just another case
of broken system firmware *sigh*. 

And that's even though it's a pretty recent Clevo W230SD-based machine (which I considered decently widespread)
with unlocked UEFI (so I see almost all options), but of course nothing related to ACPI wakeup. 
But I guess widespread alone does not help ;-). 

> 
> johannes
> 

Thanks for all!
Oliver

Re: Usage of WoWLAN with iwlwifi driver (Device phy0 failed to suspend async: error -16)

[Johannes Berg]

> > Agree, nothing looks bad. Try running "iw event" while you suspend
> > - if
> > the NIC thought it woke up the system there will be an event
> > indicating
> > so.
> > 
> 
> Indeed, I get:
> 1488836432.153465: wlan0 (phy #0): WoWLAN wakeup
>         * packet (might be truncated):
> ac:fd:ce:de:e1:58:b8:27:eb:f4:3b:4c:08:00:45:00:00:31:78:d1:40:00:3f:
> 06:3d:55:c0:a8:02:23:c0:a8:02:2d:30:39:30:39:f2:04:6f:88:8b:74:4c:c2:
> 50:18:72:10:00:00:00:00:57:41:4b:45:55:50:4e:4f:57
>         * TCP connection wakeup received
> 
> Note the trailing "57:41:4b:45:55:50:4e:4f:57" which is your
> "WAKEUPNOW". 
> 
> Also magic packet "works" this way, i.e. shows up via "iw event". 

Right. So that means the device did in fact stay powered all the way
through, otherwise we wouldn't have been able to retrieve this event
data.

> I realized I also have a Win10 installation on that machine - and may
> as well try WoWLAN with it. 
> Enabling (in the dreaded device manager) wake via the WiFi device,
> magic packet mode, I also cannot wake the machine. 

Ok. I didn't even know it was easy to actually get this configured on
Windows :)

> So if it was a driver bug, it would have to be present both in
> Windows and Linux drivers - but I guess it's just another case
> of broken system firmware *sigh*. 

Agree, that seems rather unlikely. Unless there's some kind of "magic"
setup that the UEFI wants, and the driver knows nothing about ... also
seems unlikely though.

> And that's even though it's a pretty recent Clevo W230SD-based
> machine (which I considered decently widespread)
> with unlocked UEFI (so I see almost all options), but of course
> nothing related to ACPI wakeup. 
> But I guess widespread alone does not help ;-). 

Yeah, too bad. Want to ask the manufacturer for help? ;-)

johannes

Re: Usage of WoWLAN with iwlwifi driver (Device phy0 failed to suspend async: error -16)

[Oliver Freyermuth]

Am 06.03.2017 um 22:51 schrieb Johannes Berg:
>> I realized I also have a Win10 installation on that machine - and may
>> as well try WoWLAN with it. 
>> Enabling (in the dreaded device manager) wake via the WiFi device,
>> magic packet mode, I also cannot wake the machine. 
> 
> Ok. I didn't even know it was easy to actually get this configured on
> Windows :)
At least I hope it's so easy in Windows (and that's what "the internet" told me). 
I'm also not sure whether that's fully sufficient, since I never got it to work
(at least not with WiFi ;-) ). 
Also, it seems extremely driver dependent
to configure more complex stuff than magic packet (i.e. anything else is not in the normal
device manager GUI, but in the driver-specific options for each device). 

>> So if it was a driver bug, it would have to be present both in
>> Windows and Linux drivers - but I guess it's just another case
>> of broken system firmware *sigh*. 
> 
> Agree, that seems rather unlikely. Unless there's some kind of "magic"
> setup that the UEFI wants, and the driver knows nothing about ... also
> seems unlikely though.
> 
>> And that's even though it's a pretty recent Clevo W230SD-based
>> machine (which I considered decently widespread)
>> with unlocked UEFI (so I see almost all options), but of course
>> nothing related to ACPI wakeup. 
>> But I guess widespread alone does not help ;-). 
> 
> Yeah, too bad. Want to ask the manufacturer for help? ;-)
I believe my Chinese is not good enough to contact the original manufacturer - and the W230SD is already not manufactured
anymore, I think (even though it still was current a year ago or so). 
I also doubt the German company which relabelled the Clevo barebone (Schenker) will care. 
The other laptop is >4 years old now, and an Alienware machine with dedicated GPU (only), so they probably did not care too much about any power saving / ACPI wakeup feature at all. 

But anyways, WoW-LAN for me would just have been a nice feature, but is not essential for survival. 

With cheap can-be-always-on-devices like a Raspberry Pi, I guess WoW-LAN in consumer-grade laptops is becoming less and less interesting. 
Also, I personally do not have a must-have usecase for it. 

Thanks anyways! :-)
	Oliver