Return-path: Received: from mail-qg0-f42.google.com ([209.85.192.42]:52215 "EHLO mail-qg0-f42.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751479AbbARQxZ (ORCPT ); Sun, 18 Jan 2015 11:53:25 -0500 MIME-Version: 1.0 In-Reply-To: References: Date: Mon, 19 Jan 2015 04:53:24 +1200 Message-ID: (sfid-20150118_175334_553365_51A8BF5B) Subject: Re: Wireless scanning while turning off the radio problem.. From: Linus Torvalds To: Emmanuel Grumbach , Arend van Spriel Cc: Johannes Berg , David Miller , Linux Wireless List , Network Development Content-Type: text/plain; charset=UTF-8 Sender: linux-wireless-owner@vger.kernel.org List-ID: On Sun, Jan 18, 2015 at 11:24 PM, Emmanuel Grumbach wrote: > > we have different scan flows based on the firmware version you have, > so it would help if you could tell me what firmware you have. Sure. It's the larest one I could find iwlwifi 0000:01:00.0: loaded firmware version 23.11.10.0 op_mode iwlmvm with the actual firmware file being 'iwlwifi-7260-10.ucode' from the current linux-firmware tree. Iin a different email Arend van Spriel wrote: > > The function iwl_trans_pcie_stop_device() put device in low-power and > resets the cpu on the device. So iwl_op_mode_hw_rf_kill ends up in > iwl_mvm_set_hw_rfkill_state which schedules cfg80211_rfkill_sync_work > and returns true if firmware is running. The patch below might work. Any suggestions for how to best try to trigger this for testing? Looking at my logs, it turns out that I actually got this three times, but they were all on the same boot, and I think the first case might just have triggered the later ones. The trigger was turning off wifi from the wifi settings app due to being in an airplane when they were closing the doors. I don't *think* there was actually any wifi around at the time, which may or may not have made the scanning take longer and made it easier to trigger. But I've done it before (although this machine has been upgraded to F21 reasonably recently, and I did update the ucode file before the trip). And I did it afterwards to test. And it happened that one time (and then apparently kept happening during suspend/resume/shutdown, but as mentioned, I blame that on some sticky problem from the first time, and those events in turn happened because I couldn't get wireless to work afterwards). IOW, I'm not at all sure I can recreate it, so your "analyzing the source code for how this could happen" may be the only good way.. Linus