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
