From patchwork Thu Aug 14 16:34:56 2014 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Emmanuel Grumbach X-Patchwork-Id: 379962 X-Patchwork-Delegate: davem@davemloft.net Return-Path: X-Original-To: patchwork-incoming@ozlabs.org Delivered-To: patchwork-incoming@ozlabs.org Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by ozlabs.org (Postfix) with ESMTP id 4EBE0140086 for ; Fri, 15 Aug 2014 02:35:04 +1000 (EST) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751814AbaHNQe7 (ORCPT ); Thu, 14 Aug 2014 12:34:59 -0400 Received: from mail-lb0-f170.google.com ([209.85.217.170]:55449 "EHLO mail-lb0-f170.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751054AbaHNQe6 convert rfc822-to-8bit (ORCPT ); Thu, 14 Aug 2014 12:34:58 -0400 Received: by mail-lb0-f170.google.com with SMTP id l4so1066105lbv.15 for ; Thu, 14 Aug 2014 09:34:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=Ic3iBZiqh14ZLMfzQiiloNExmoXrvwNISzUtyhSWdf0=; b=tspv4Ra8MVgBYVcYf4cUWsXTwn77mgAV8qQJZnXw5OV7qcQW4USaOmHAQswek/A7qZ tnE4EiaNuSwdTkn0ic6GIk1QJJXIGVoZtv2jGET0e0kboXkyZ7BAndoBFe0IRjmlIHX/ FLkhM3blFI/A1lSsRSyXBZkPtr85I3BmK4I8Qs8IVA912+kZGakUvlRW+dhvxKx4rx2o uxjPHt34yQNQcUX5xuOntIHRBn0OHJIxydeHiAo4SYxb3Cw7aMUN5IkFGB3ITNSOkYoh DTyM3LVg8Zvq/wHc/zjBam4LSpOysF2awCSapnfmRwwYpxxauIEzk1Nol1iBYX7+BMe0 0v2Q== MIME-Version: 1.0 X-Received: by 10.112.48.103 with SMTP id k7mr6251184lbn.32.1408034096070; Thu, 14 Aug 2014 09:34:56 -0700 (PDT) Received: by 10.114.3.77 with HTTP; Thu, 14 Aug 2014 09:34:56 -0700 (PDT) In-Reply-To: <0BA3FCBA62E2DC44AF3030971E174FB31B266E67@hasmsx107.ger.corp.intel.com> References: <53ECD8D0.4050709@lwfinger.net> <0BA3FCBA62E2DC44AF3030971E174FB31B266E67@hasmsx107.ger.corp.intel.com> Date: Thu, 14 Aug 2014 09:34:56 -0700 Message-ID: Subject: Re: Intel wireless microcode problem.. From: Emmanuel Grumbach To: "Grumbach, Emmanuel" Cc: Linus Torvalds , Larry Finger , "Berg, Johannes" , Intel Linux Wireless , "John W. Linville" , Linux Wireless List , Network Development Sender: netdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org >> > >> > There is a new firmware that seems to help the problem. You can get it >> > from Emmanuel's git clone. As he wrote earlier >> >> So quite frankly, this is *not* acceptable. We have regression policies for the >> kernel, and this seems to be a kernel regression with the currently released >> firmware. And I'm not downloading experimental firmware while traveling >> with this laptop being my only way to work. >> >> The warnings cause *so* much message log spam that the machine is >> occasionally spending 5% of CPU time on systemd journaling, and >> presumably filling up disk space too. >> >> And the same way we don't tell people "update your buggy user space" >> when we introduce kernel regressions, we don't tell people "try a new >> firmware". >> >> People who have old systems (old distributions, old firmware, old hardware, >> old *anything*) that works with their previous kernel, are supposed to be >> able to upgrade their kernel with no regressions. >> That's the rules for the kernel, and that's what the rules have been for a long >> time. Kernel developers - including wireless driver writers >> - had better understand that rule. It's the absolute #1 rule when it comes to >> kernel development. This is not something new and surprosing. >> >> The insane amount of logging needs to be fixed. The wireless *works*, but >> the logging is too verbose. >> >> Now, maybe this isn't actually a kernel regression at all - maybe triggered by >> the horrid internet I have while traveling - but I tried twice, and when I >> booted into the regular Fedora kernel for testing (oh, just noticed that it's >> 3.15.8, not 3.16-based), I didn't see this kind of log spamming. So it looks like >> a regression to me, and we have rules about regressions. And they are just >> about the ONLY hard rules we have. But that regression rule really is very >> very important indeed. >> >> The wireless *works* with the current firmware, so all that is required is to >> make sure that the kernel stops spamming the logs so heavily. It would >> obviously be better to try to figure out *why* the microcode error happens, >> and what changed in the kernel to trigger it, but the "don't make the >> machine have trouble with the insane amount of logs" is at least an >> acceptable workaround. >> >> Ok? >> > As I said, I am tyring to repro right now - you are 100% right we are fully committed to make the current firmware work. The "experimental" firmware is just a firmware with a version problem - this is why I didn't release it formally. You can safely use it until we fix the problem. > And we will fix it. > And no - it is not related to the internet - this is surely a bug in our driver / firmware interface. I am currently trying to see how I can fix it - but I am also travelling... Ok - I think I have a fix. I could reproduce your problem and I verified my fix. pull request on the way... --- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html diff --git a/drivers/net/wireless/iwlwifi/mvm/mac80211.c b/drivers/net/wireless/iwlwifi/mvm/mac80211.c index 0d6a8b7..66ef6a8 100644 --- a/drivers/net/wireless/iwlwifi/mvm/mac80211.c +++ b/drivers/net/wireless/iwlwifi/mvm/mac80211.c @@ -396,7 +396,8 @@ int iwl_mvm_mac_setup_register(struct iwl_mvm *mvm) else hw->wiphy->flags &= ~WIPHY_FLAG_PS_ON_BY_DEFAULT; - hw->wiphy->flags |= WIPHY_FLAG_SUPPORTS_SCHED_SCAN; + /* TODO: enable that for firmwares that don't crash only... */ + /* hw->wiphy->flags |= WIPHY_FLAG_SUPPORTS_SCHED_SCAN; */ hw->wiphy->max_sched_scan_ssids = PROBE_OPTION_MAX; hw->wiphy->max_match_sets = IWL_SCAN_MAX_PROFILES; /* we create the 802.11 header and zero length SSID IE. */