On Tue, May 27, 2014 at 10:09 AM, Andy Lutomirski <luto@xxxxxxxxxxxxxx> wrote: > On Mon, May 26, 2014 at 11:47 AM, Andy Lutomirski <luto@xxxxxxxxxxxxxx> wrote: >> On Mon, May 26, 2014 at 11:13 AM, Emmanuel Grumbach <egrumbach@xxxxxxxxx> wrote: >>>>>>> >>>>>>> diff --git a/drivers/net/wireless/iwlwifi/dvm/power.c >>>>>>> b/drivers/net/wireless/iwlwifi/dvm/power.c >>>>>>> index f2c1439..e5a6b70 100644 >>>>>>> --- a/drivers/net/wireless/iwlwifi/dvm/power.c >>>>>>> +++ b/drivers/net/wireless/iwlwifi/dvm/power.c >>>>>>> @@ -288,6 +288,9 @@ static void iwl_power_build_cmd(struct iwl_priv *priv, >>>>>>> bool enabled = priv->hw->conf.flags & IEEE80211_CONF_PS; >>>>>>> int dtimper; >>>>>>> >>>>>>> + iwl_power_sleep_cam_cmd(priv, cmd); >>>>>>> + return; >>>>>>> + >>>>>>> dtimper = priv->hw->conf.ps_dtim_period ?: 1; >>>>>>> >>>>>>> if (priv->wowlan) >>>>>> >>>>>> This patch has survived for about 15 minutes on 3.15-rc. It certainly >>>>>> has some effect: pinging from the AP to the STA now takes a consistent >>>>>> ~3.8ms instead of taking varying amounts of time between 5 and 200 ms >>>>>> or so. >>>>>> >>>>>> I wonder if this is something 802.11n/802.11ac-specific? I remember >>>>>> having all kinds of problems with 802.11n on this laptop that were >>>>>> resolved by turning off 11n or turning off power saving. >>>>>> >>>>> >>>>> well... my patch really turns off power saving. The hard way. >>>>> But since you are having issues - I guess I'll post it and disable >>>>> power save for these devices. Note that today most of the power save >>>>> features are disabled anyway. >>>> >>>> Would it make sense to do this only when connected to a VHT-supporting >>>> AP or whatever AP feature is probably triggering the problem? >>> >>> I am not sure it is related to some "VHT / whatever" feature. From >>> your logs, I'd say this bug could have happened with any AP. It is >>> down there in the PCI layer. >>> >>>> >>>> *sigh* I'd just plug in a new PCIe wireless card, except that I think >>>> that my evil BIOS will refuse to boot if I do that. >>>> >>> I can recommend 7260 :) >> >> http://www.thinkwiki.org/wiki/Problem_with_unauthorized_MiniPCI_network_card >> >> I'm not sure how I feel about flashing my BIOS with random things off >> the internet :( >> >>> Before you do that, can you check this one? >>> >>> diff --git a/drivers/net/wireless/iwlwifi/dvm/power.c >>> b/drivers/net/wireless/iwlwifi/dvm/power.c >>> index f2c1439..047112c 100644 >>> --- a/drivers/net/wireless/iwlwifi/dvm/power.c >>> +++ b/drivers/net/wireless/iwlwifi/dvm/power.c >>> @@ -292,6 +292,8 @@ static void iwl_power_build_cmd(struct iwl_priv *priv, >>> >>> if (priv->wowlan) >>> iwl_static_sleep_cmd(priv, cmd, IWL_POWER_INDEX_5, dtimper); >>> + if (!enabled) >>> + iwl_power_sleep_cam_cmd(priv, cmd); >>> else if (!priv->lib->no_idle_support && >>> priv->hw->conf.flags & IEEE80211_CONF_IDLE) >>> iwl_static_sleep_cmd(priv, cmd, IWL_POWER_INDEX_5, 20); >>> @@ -299,9 +301,7 @@ static void iwl_power_build_cmd(struct iwl_priv *priv, >>> /* in thermal throttling low power state */ >>> iwl_static_sleep_cmd(priv, cmd, >>> iwl_tt_current_power_mode(priv), dtimper); >>> - } else if (!enabled) >>> - iwl_power_sleep_cam_cmd(priv, cmd); >>> - else if (priv->power_data.debug_sleep_level_override >= 0) >>> + } else if (priv->power_data.debug_sleep_level_override >= 0) >>> iwl_static_sleep_cmd(priv, cmd, >>> >>> priv->power_data.debug_sleep_level_override, >>> dtimper); >>> >>> This is the final version I want to send. >> >> I'll test it tonight. I'm away from both the network and the laptop right now. > > No good :( I got the same issue again, but it still sames rarer than unpatched. > > It looks like your patch allows both: > > iwl_static_sleep_cmd(priv, cmd, IWL_POWER_INDEX_5, dtimper); > > and > > iwl_static_sleep_cmd(priv, cmd, IWL_POWER_INDEX_5, 20); > > I don't know whether that's a problem. > > Also, is this bad? > > iwlwifi 0000:03:00.0: can't disable ASPM; OS doesn't have ASPM control > > lspci seems to think that L1 is enabled (see attached logs). > This seems surprisingly consistent: on first boot, wireless is okay w/ this AP, but after suspend/resume, it's unreliable. I could be wrong (the unreliability isn't *that* consistent), but I've just seen this a couple more times. Using pcie_aspm=force to forcibly disable L1 makes no difference. Is there possibly a driver bug that causes some workaround to be applied on boot but not on resume? Or is BIOS doing something different? --Andy -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
