Re: Usage of WoWLAN with iwlwifi driver (Device phy0 failed to suspend async: error -16)
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
Re: Usage of WoWLAN with iwlwifi driver (Device phy0 failed to suspend async: error -16)
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)
> > 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)
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)
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 :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 :00:1d.0: System wakeup enabled by ACPI [ 2753.830345] iwlwifi :03:00.0: System wakeup enabled by ACPI [ 2753.830348] pcieport :00:1c.3: System wakeup enabled by ACPI [ 2753.830484] ehci-pci :00:1a.0: System wakeup enabled by ACPI [ 2753.830502] xhci_hcd :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 :00:1a.0: System wakeup disabled by ACPI [ 2753.985912] ehci-pci :00:1d.0: System wakeup disabled by ACPI [ 2753.985917] xhci_hcd :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 :03:00.0: System wakeup disabled by ACPI [ 2753.997369] ACPI : button: The lid device is not compliant to SW_LID. [ 2753.997733] pcieport :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 :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)
> > 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 :0a:00.0: System wakeup disabled by ACPI > [12386.088449] iwlwifi :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)
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 :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 :0a:00.0: System wakeup disabled by ACPI [12386.088449] iwlwifi :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)
> > 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 :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)
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 :0a:00.0: L1 Enabled - LTR Enabled [12385.335737] iwlwifi :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 :00:1d.0: System wakeup enabled by ACPI [12385.893568] iwlwifi :0a:00.0: System wakeup enabled by ACPI [12385.893685] ehci-pci :00:1a.0: System wakeup enabled by ACPI [12385.893754] xhci_hcd :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 :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)
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)
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)
> 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
