RE: linux-next: build warning after merge of the mac80211-next tree
Hi, > > Hi all, > > After merging the mac80211-next tree, today's linux-next build (htmldocs) > produced this warning: > > include/net/cfg80211.h:6643: warning: expecting prototype for > wiphy_rfkill_set_hw_state(). Prototype was for > wiphy_rfkill_set_hw_state_reason() instead > include/net/cfg80211.h:6643: warning: expecting prototype for Ouch Johannes, this is the fix: diff --git a/include/net/cfg80211.h b/include/net/cfg80211.h index 3b296f2b7a2c..c6134220dd8f 100644 --- a/include/net/cfg80211.h +++ b/include/net/cfg80211.h @@ -6634,7 +6634,7 @@ void cfg80211_notify_new_peer_candidate(struct net_device *dev, */ /** - * wiphy_rfkill_set_hw_state - notify cfg80211 about hw block state + * wiphy_rfkill_set_hw_state_reason - notify cfg80211 about hw block state * @wiphy: the wiphy * @blocked: block status * @reason: one of reasons in &enum rfkill_hard_block_reasons Do you want a patch or you amend the original commit? It is not in net-next yet.
RE: [char-misc-next 6/6] mei: bus: add client dma interface
Hi Greg,
> On Sun, Feb 07, 2021 at 02:03:11PM +, Winkler, Tomas wrote:
> > >
> > > On Sat, Feb 06, 2021 at 03:04:34PM +, Winkler, Tomas wrote:
> > > > > On Sat, Feb 06, 2021 at 04:43:25PM +0200, Tomas Winkler wrote:
> > > > > > From: Alexander Usyskin
> > > > > >
> > > > > > Expose the client dma mapping via mei client bus interface.
> > > > > >
> > > > > > Signed-off-by: Alexander Usyskin
> > > > > > Signed-off-by: Tomas Winkler
> > > > > > ---
> > > > > > drivers/misc/mei/bus.c | 46
> > > > > ++
> > > > > > drivers/misc/mei/hw.h | 5 +
> > > > > > include/linux/mei_cl_bus.h | 3 +++
> > > > > > 3 files changed, 54 insertions(+)
> > > > > >
> > > > > > diff --git a/drivers/misc/mei/bus.c b/drivers/misc/mei/bus.c
> > > > > > index
> > > > > > 34fb5e541fe5..d430710a5fe5 100644
> > > > > > --- a/drivers/misc/mei/bus.c
> > > > > > +++ b/drivers/misc/mei/bus.c
> > > > > > @@ -636,6 +636,52 @@ static void mei_cl_bus_vtag_free(struct
> > > > > mei_cl_device *cldev)
> > > > > > kfree(cl_vtag);
> > > > > > }
> > > > > >
> > > > > > +void *mei_cldev_dma_map(struct mei_cl_device *cldev, u8
> > > > > > +buffer_id, size_t size) {
> > > > > > + struct mei_device *bus;
> > > > > > + struct mei_cl *cl;
> > > > > > + int ret;
> > > > > > +
> > > > > > + if (!cldev || !buffer_id || !size)
> > > > > > + return ERR_PTR(-EINVAL);
> > > > > > +
> > > > > > + if (!IS_ALIGNED(size, MEI_FW_PAGE_SIZE)) {
> > > > > > + dev_err(&cldev->dev, "Map size should be aligned to
> %lu\n",
> > > > > > + MEI_FW_PAGE_SIZE);
> > > > > > + return ERR_PTR(-EINVAL);
> > > > > > + }
> > > > > > +
> > > > > > + cl = cldev->cl;
> > > > > > + bus = cldev->bus;
> > > > > > +
> > > > > > + mutex_lock(&bus->device_lock);
> > > > > > + ret = mei_cl_dma_alloc_and_map(cl, NULL, buffer_id, size);
> > > > > > + mutex_unlock(&bus->device_lock);
> > > > > > + if (ret)
> > > > > > + return ERR_PTR(ret);
> > > > > > + return cl->dma.vaddr;
> > > > > > +}
> > > > > > +EXPORT_SYMBOL_GPL(mei_cldev_dma_map);
> > > > >
> > > > > Why are you exporting symbols without a user of them?
> > > > >
> > > > > That's a sure way to get them removed by someone right after
> > > > > this lands in the tree :)
> > > > >
> > > > > Please only add infrastructure for when you have a real user.
> > > > You are right, the user is coming from wifi tree. We need merge
> > > > before
> > > they do.
> > > > If you prefer we can merge that all from the wifi tree.
> > >
> > > That wasn't documented well at all in your changelog comment :(
> > Note taken.
> > > It can go through whatever tree needs it.
> > If possible please merge our changes already here, and let the wifi guys to
> finish their task in their tree, in their own time.
>
> I took some of these already, patches 1 and 6 I can't take as-is, sorry.
As Tomas said, 6 is needed by iwlwifi. I understand you want it to be routed
through iwlwifi-next.git. I added Kalle so that he gets a heads up.
1 is not related to iwlwifi.
PCI LTR - ASPM handling upon suspend / resume cycle. Regression since 4.18
Hi, Lately we (Intel) have got a few bugs on suspend / resume. The complaint is that our device becomes unavailable after suspend / resume cycle. The bug on which we have most data is [1]. The original submitter reported a regression since commit 9ab105deb60fa76d66cae5548819b4e8703d2056: PCI/ASPM: Disable ASPM L1.2 Substate if we don't have LTR When in the ASPM L1.0 state (but not the PCI-PM L1.0 state), the most recent LTR value and the LTR_L1.2_THRESHOLD determines whether the link enters the L1.2 substate. If we don't have LTR enabled, prevent the use of ASPM L1.2. PCI-PM L1.2 may still be used because it doesn't depend on LTR_L1.2_THRESHOLD (see PCIe r4.0, sec 5.5.1). After this commit, L1.2 is disabled upon resume: L1SubCtl1: PCI-PM_L1.2+ PCI-PM_L1.1+ ASPM_L1.2- ASPM_L1.1+ T_CommonMode=0us LTR1.2_Threshold=163840ns Whereas it wasn't before this commit: L1SubCtl1: PCI-PM_L1.2+ PCI-PM_L1.1+ ASPM_L1.2+ ASPM_L1.1+ T_CommonMode=0us LTR1.2_Threshold=163840ns I am copying here an initial analysis by Bjorn (from [2]): 1) Linux has no support for saving/restoring the Max Latency values in the LTR Capability. This results in the latencies being zero after you resume, as you see in the lspci output. The device still *works* after resume, but power consumption should increase because the device is effectively requesting the best possible service, so we probably don't use the L1.2 state at all. 2) Linux has no support for programming the Max Latency values for hot- added devices. When using ACPI hotplug, firmware may do this, but for native PCIe hotplug (pciehp), the new device should again be requesting the best possible service, resulting in more power consumption than necessary. The platform is supposed to supply a _DSM method with information required to program these values Another user found another commit impacting his device after suspend / resume: commit 6f9db69ad93cd6ab77d5571cf748ff7cdcfb0285 ACPI / PM: Default to s2idle in all machines supporting LP S0 The Dell Venue Pro 7140 supports the Low Power S0 Idle state, but does not support any of the _DSM functions that the current heuristic checks for. Since suspend-to-mem can not be safely performed on this machine, and since the bitfield check can't cover this case, it is safer to enable s2idle by default by checking for the presence of the _DSM alone and removing the bitfield check. This user confirmed that using suspend-to-mem instead of suspend-to- idle works for him. A user contacted my privately to let me know that he has issues with devices from other vendors although I can't tell if the problem is the same or not. Note that this problem started from kernel 4.18. Thank you. [1] - https://bugzilla.kernel.org/show_bug.cgi?id=201469 [2] - https://bugzilla.kernel.org/show_bug.cgi?id=201469#c26
RE: linux-next: build warnings after merge of the wireless-drivers-next tree
>
> Stephen Rothwell writes:
>
> > On Fri, 30 Nov 2018 12:05:55 +1100 Stephen Rothwell
> wrote:
> >>
> >> After merging the wireless-drivers-next tree, today's linux-next
> >> build
> >> (x86_64 allmodconfig) produced these warnings:
> >>
> >> drivers/net/wireless/intel/iwlwifi/iwl-drv.c: In function
> 'iwl_parse_tlv_firmware':
> >> drivers/net/wireless/intel/iwlwifi/iwl-drv.c:1098:7: warning: this
> statement may fall through [-Wimplicit-fallthrough=]
> >> if (iwlwifi_mod_params.enable_ini)
> >>^
> >> drivers/net/wireless/intel/iwlwifi/iwl-drv.c:1100:3: note: here
> >>default:
> >>^~~
> >> drivers/net/wireless/intel/iwlwifi/iwl-dbg-tlv.c: In function
> 'iwl_parse_fw_dbg_tlv':
> >> drivers/net/wireless/intel/iwlwifi/iwl-dbg-tlv.c:203:4: warning: this
> statement may fall through [-Wimplicit-fallthrough=]
> >> iwl_fw_dbg_copy_tlv(trans, tlv, true);
> >> ^
> >> drivers/net/wireless/intel/iwlwifi/iwl-dbg-tlv.c:204:3: note: here
> >>default:
> >>^~~
> >>
> >> Introduced by commit
> >>
> >> f14cda6f3b31 ("iwlwifi: trans: parse and store debug ini TLVs")
> >>
> >> These are noted because I use -Wimplict-fallthrough
> >>
> >> The warnings can be suppressed by adding a comment like
> >>/* fall through */
> >> at the appropriate place to indicate that the fallthough is intended.
> >
> > I am still seeing these warnings (but in the net-next tree now) and I
> > do not see a fix patch in the wireless-drivers-next tree.
>
> Luca did submit a patch[1] for cfg80211 to fix those but I don't see any
> patches for iwlwifi (even in the one pending pull request he sent), not sure
> what happened. I know that Luca is already on holidays but adding
> Emmanuel, maybe he can help here?
>
Just sent a patch.
RE: Fwd: [Bug 201647] New: Intel Wireless card 3165 does not get detected but bluetooth works
> > On Tue, Dec 11, 2018 at 06:31:47PM +, Grumbach, Emmanuel wrote: > > > On Tue, Dec 11, 2018 at 04:32:25PM +0000, Grumbach, Emmanuel wrote: > > > > > On Tue, Dec 11, 2018 at 06:35:20AM +, Grumbach, Emmanuel > wrote: > > > > > > > > > > https://bugzilla.kernel.org/show_bug.cgi?id=201647 > > > > > > > > > > > FWIW: I saw another problem like this with a 9650 device. > > > > > > > > > > Do you have a pointer to any info about this 9650 issue? Maybe > > > > > that would have a clue. > > > > > > > > I added him here so that you can ask whatever you like :) The > > > > story is the same. I am attaching a picture I got from the reporter. > > > > I can confirm that this device ID / subdevice ID is supported by > > > > the linux > > > driver. > > > > > > Was there a resolution, i.e., if somebody figured out how to make > > > the > > > 9650 wifi work, maybe a similar solution would work for the 3165? > > > > Unfortunately not, I am stuck there at the exact same point. > > No Wifi device shows up in lspci... > > Is there a public spec? My patience for reverse engineering things that are > documented somewhere that I'm not allowed to see is pretty limited. > Presumably *you* should be able to see the spec, since this is an Intel device > and you have an @intel.com address? Ok, I start to understand. So no, no public spec. I am an Intel employee, I used to maintain the WiFi driver (iwlwifi). I don't know much about PCI though. I am definitely not asking you to reverse engineer our device :) I can try to ask internally what could be going on. The reason I haven't done so so far and reached out to you is because I am not aware about switches that we need to toggle to make the device magically show up. So I thought it'd be related to the PCI core, which take me to the next point... > > From what we can tell so far, I don't *think* this is a PCI issue. If the > device > doesn't respond to a PCI config access, the PCI core can't really be expected > to do anything about it. Ok, thanks. So I understand from you that you didn't see any weird log from the PCI core saying: "I can see this device, but I can't enumerate it because XYZ". I tried to look for such a thing but couldn't. >From this point, I guess I can't do much either. I'll try to get info >internally.
RE: Fwd: [Bug 201647] New: Intel Wireless card 3165 does not get detected but bluetooth works
> > On Tue, Dec 11, 2018 at 04:32:25PM +, Grumbach, Emmanuel wrote: > > > On Tue, Dec 11, 2018 at 06:35:20AM +0000, Grumbach, Emmanuel wrote: > > > > > > > > https://bugzilla.kernel.org/show_bug.cgi?id=201647 > > > > > > > FWIW: I saw another problem like this with a 9650 device. > > > > > > Do you have a pointer to any info about this 9650 issue? Maybe that > > > would have a clue. > > > > I added him here so that you can ask whatever you like :) The story is > > the same. I am attaching a picture I got from the reporter. > > I can confirm that this device ID / subdevice ID is supported by the linux > driver. > > Was there a resolution, i.e., if somebody figured out how to make the > 9650 wifi work, maybe a similar solution would work for the 3165? Unfortunately not, I am stuck there at the exact same point. No Wifi device shows up in lspci...
RE: Fwd: [Bug 201647] New: Intel Wireless card 3165 does not get detected but bluetooth works
> > > > > > > > https://bugzilla.kernel.org/show_bug.cgi?id=201647 > > > > > > > > Bug ID: 201647 > > > >Summary: Intel Wireless card 3165 does not get detected but > > > > bluetooth works > > > >Product: Drivers > > > >Version: 2.5 > > > > Kernel Version: 4.19.1 > > > > Hardware: Intel > > > > OS: Linux > > > > Tree: Mainline > > > > Status: NEW > > > > Severity: high > > > > Priority: P1 > > > > Component: PCI > > > > Assignee: drivers_...@kernel-bugs.osdl.org > > > > Reporter: mertar...@gmail.com > > > > Regression: No > > > > > > > > This bug affects most of the devices with a Celeron N4000 and an > > > > Intel wifi 3165 Ac adapter. > > > > > > > > When using Linux wifi is not working however, Bluetooth is working > > > > fine. Also, Bluetooth part of this chip is connected via btusb > > > > and the wifi part of this chip is connected via PCIe. > > > > > > Can you attach a screenshot of the Windows 10 device manager info > > > for the wifi adapter to the bugzilla? If you can get a raw hex dump > > > of its config space, that would be awesome. > > > > > > Also attach a copy of your kernel .config file (typically in /boot/). > > > > > > My only guess is that maybe the system keeps wifi completely powered > > > down and uses hotplug to add it when needed. [1] mentions wifi > > > being on pcibus 1 under Windows. Your lspci does show bridge > > > 00:13.0 leading to bus 01, but Linux doesn't find any devices on bus 01. > > > > > > Hotplug could be done via either acpiphp (ACPI mediated hotplug) or > > > pciehp (native PCIe hotplug). Your dmesg shows you do have acpiphp. > > > > > > I can't tell about pciehp (your .config will show that), but I think > > > pciehp will only claim bridges where SltCap contains HotPlug+, and > > > yours shows HotPlug- , so I don't think pciehp will do anything on your > system. > > > > > > Even if the system does use hotplug, I don't know what mechanism the > > > OS would use to wake up the device, since we don't know it even > > > exists. I guess there could be some magic switch accessible via USB. > > > But if that were the case, I'm sure Emmanuel would know about it. > > > > Hm... Don't be so sure... :) > > I don't think we have anything as fancy as this. > > I guess you can try to dig into the BIOS settings? > > I have heard of such a switch that would make the device disappear. > > It's worth looking, but I don't understand how a BIOS switch would solve this > problem. I assume that with the same BIOS settings, Windows works and > Linux fails. I guess I had a typo there... I have *not* heard of such a switch. > > Maybe there would be a clue in an acpidump from affected machines, e.g., > maybe we'd see some kind of ACPI hotplug notification. That seems like a > long shot because we do have acpiphp in the kernel, and it *should* be > handling such notifications, but it could always be broken. > > The Windows device manager info (requested above) would be interesting. > Indeed. FWIW: I saw another problem like this with a 9650 device. PS: PCI folks don't use bugzilla's anymore? It's all over the mailing list?
RE: Fwd: [Bug 201647] New: Intel Wireless card 3165 does not get detected but bluetooth works
> > [+cc Emmanuel, LKML] > > On Fri, Nov 09, 2018 at 03:43:06PM -0600, Bjorn Helgaas wrote: > > -- Forwarded message - > > From: > > Date: Fri, Nov 9, 2018 at 4:10 AM > > Subject: [Bug 201647] New: Intel Wireless card 3165 does not get > > detected but bluetooth works > > > > https://bugzilla.kernel.org/show_bug.cgi?id=201647 > > > > Bug ID: 201647 > >Summary: Intel Wireless card 3165 does not get detected but > > bluetooth works > >Product: Drivers > >Version: 2.5 > > Kernel Version: 4.19.1 > > Hardware: Intel > > OS: Linux > > Tree: Mainline > > Status: NEW > > Severity: high > > Priority: P1 > > Component: PCI > > Assignee: drivers_...@kernel-bugs.osdl.org > > Reporter: mertar...@gmail.com > > Regression: No > > > > This bug affects most of the devices with a Celeron N4000 and an Intel > > wifi 3165 Ac adapter. > > > > When using Linux wifi is not working however, Bluetooth is working > > fine. Also, Bluetooth part of this chip is connected via btusb and > > the wifi part of this chip is connected via PCIe. > > Can you attach a screenshot of the Windows 10 device manager info for the > wifi adapter to the bugzilla? If you can get a raw hex dump of its config > space, that would be awesome. > > Also attach a copy of your kernel .config file (typically in /boot/). > > My only guess is that maybe the system keeps wifi completely powered > down and uses hotplug to add it when needed. [1] mentions wifi being on > pcibus 1 under Windows. Your lspci does show bridge 00:13.0 leading to bus > 01, but Linux doesn't find any devices on bus 01. > > Hotplug could be done via either acpiphp (ACPI mediated hotplug) or pciehp > (native PCIe hotplug). Your dmesg shows you do have acpiphp. > > I can't tell about pciehp (your .config will show that), but I think pciehp > will > only claim bridges where SltCap contains HotPlug+, and yours shows HotPlug- > , so I don't think pciehp will do anything on your system. > > Even if the system does use hotplug, I don't know what mechanism the OS > would use to wake up the device, since we don't know it even exists. I guess > there could be some magic switch accessible via USB. > But if that were the case, I'm sure Emmanuel would know about it. > Hm... Don't be so sure... :) I don't think we have anything as fancy as this. I guess you can try to dig into the BIOS settings? I have heard of such a switch that would make the device disappear.
RE: [linuxwifi] [PATCH] fix iwlwifi on old cards in v4.19 was Re: 4.19-rc[23] iwlwifi: BUG in swiotlb
> > > .max_tfd_queue_size was ommited for old cards, leading to oops in swiotlb. > > Signed-off-by: Pavel Machek > I picked it up in our tree with minor commit message fixes. I also added the Fixes tag for stable. Thanks!
RE: [linuxwifi] [PATCH] net: wireless: intel: iwlwifi: dvm: fix tid mask
> > On Thu, Jun 08, 2017 at 06:31:01AM +, Grumbach, Emmanuel wrote: > > Hi, > > Hi, > > > True, OTOH we need tid to be 8 sometimes. We *just* need to make sure > > that we don't index tid_data with this. Hence I think the proper fix is: > > > > diff --git a/drivers/net/wireless/intel/iwlwifi/dvm/tx.c > > b/drivers/net/wireless/intel/iwlwifi/dvm/tx.c > > index 06ac3f1..16a8646 100644 > > --- a/drivers/net/wireless/intel/iwlwifi/dvm/tx.c > > +++ b/drivers/net/wireless/intel/iwlwifi/dvm/tx.c > > @@ -1190,11 +1190,11 @@ void iwlagn_rx_reply_tx(struct iwl_priv *priv, > struct iwl_rx_cmd_buffer *rxb) > > next_reclaimed; > > IWL_DEBUG_TX_REPLY(priv, "Next reclaimed > > packet:%d\n", > > next_reclaimed); > > + iwlagn_check_ratid_empty(priv, sta_id, tid); > > } > > > > iwl_trans_reclaim(priv->trans, txq_id, ssn, &skbs); > > > > - iwlagn_check_ratid_empty(priv, sta_id, tid); > > freed = 0; > > > > /* process frames */ > > I can confirm it works. You can add my Tested-By. Patch in review in our internal tree. It'll be upstreamed through the regular process. Thanks for your report and debug work.
RE: [linuxwifi] [PATCH] net: wireless: intel: iwlwifi: dvm: fix tid mask
Hi,
> Subject: [linuxwifi] [PATCH] net: wireless: intel: iwlwifi: dvm: fix tid mask
>
> Currently the tid mask covers the first 4 bits of iwlagn_tx_resp::ra_tid,
> which gives 16 possible values for tid.
> This is problematic because IWL_MAX_TID_COUNT is 8, so indexing
> iwl_priv::tid_data can go very wrong.
True, OTOH we need tid to be 8 sometimes. We *just* need to make sure
that we don't index tid_data with this. Hence I think the proper fix is:
diff --git a/drivers/net/wireless/intel/iwlwifi/dvm/tx.c
b/drivers/net/wireless/intel/iwlwifi/dvm/tx.c
index 06ac3f1..16a8646 100644
--- a/drivers/net/wireless/intel/iwlwifi/dvm/tx.c
+++ b/drivers/net/wireless/intel/iwlwifi/dvm/tx.c
@@ -1190,11 +1190,11 @@ void iwlagn_rx_reply_tx(struct iwl_priv *priv, struct
iwl_rx_cmd_buffer *rxb)
next_reclaimed;
IWL_DEBUG_TX_REPLY(priv, "Next reclaimed packet:%d\n",
next_reclaimed);
+ iwlagn_check_ratid_empty(priv, sta_id, tid);
}
iwl_trans_reclaim(priv->trans, txq_id, ssn, &skbs);
- iwlagn_check_ratid_empty(priv, sta_id, tid);
freed = 0;
/* process frames */
Clearly calling iwlagn_check_ratid_empty with tid = IWL_TID_NON_QOS is a bad
idea.
>
> With UBSAN I can it happening while establishing the first connection
> after module load.
>
> [ 272.143440] UBSAN: Undefined behaviour in
> drivers/net/wireless/intel/iwlwifi/dvm/tx.c:777:32
> [ 272.143447] index 8 is out of range for type 'iwl_tid_data [8]'
> [ 272.143457] CPU: 0 PID: 4605 Comm: irq/32-iwlwifi Not tainted 4.12.0-dirty
> #2
> [ 272.143460] Hardware name: Hewlett-Packard HP EliteBook 2560p/162B,
> BIOS 68SSU Ver. F.02 07/26/2011
> [ 272.143462] Call Trace:
> [ 272.143472] dump_stack+0x9c/0x10b
> [ 272.143477] ? _atomic_dec_and_lock+0x285/0x285
> [ 272.143486] ubsan_epilogue+0xd/0x4e
> [ 272.143493] __ubsan_handle_out_of_bounds+0xef/0x118
> [ 272.143498] ? __ubsan_handle_shift_out_of_bounds+0x221/0x221
> [ 272.143519] ? iwl_trans_pcie_reclaim+0x153/0xc90 [iwlwifi]
> [ 272.143539] iwlagn_check_ratid_empty+0x337/0x410 [iwldvm]
> [ 272.143556] ? iwl_hcmd_names_cmp+0x2f/0x60 [iwlwifi]
> [ 272.143571] iwlagn_rx_reply_tx+0x8a4/0x1820 [iwldvm]
>
> Signed-off-by: Seraphime Kirkovski
> ---
>I'm currently running this patch on my machines and I have wifi.
>The patch presumes а cleanup patch, I sent yesterday:
> https://www.spinics.net/lists/kernel/msg2526314.html
>
> drivers/net/wireless/intel/iwlwifi/dvm/commands.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/net/wireless/intel/iwlwifi/dvm/commands.h
> b/drivers/net/wireless/intel/iwlwifi/dvm/commands.h
> index 37d2ba5ae852..e5994df9ea4c 100644
> --- a/drivers/net/wireless/intel/iwlwifi/dvm/commands.h
> +++ b/drivers/net/wireless/intel/iwlwifi/dvm/commands.h
> @@ -1448,7 +1448,7 @@ struct agg_tx_status {
> */
> /* refer to ra_tid */
> #define IWLAGN_TX_RES_TID_POS0
> -#define IWLAGN_TX_RES_TID_MSK0x0f
> +#define IWLAGN_TX_RES_TID_MSK0x07
> #define IWLAGN_TX_RES_RA_POS 4
> #define IWLAGN_TX_RES_RA_MSK 0xf0
>
> --
> 2.11.0
>
> -
> linuxw...@eclists.intel.com
> https://eclists.intel.com/sympa/info/linuxwifi
> Unsubscribe by sending email to sy...@eclists.intel.com with subject
> "Unsubscribe linuxwifi"
RE: [RFC 2/5] iwlwifi: fix request_module() use
>
> On Sun, Feb 19, 2017 at 09:47:59AM +, Grumbach, Emmanuel wrote:
> > >
> > > The return value of request_module() being 0 does not mean that the
> > > driver which was requested has loaded. To properly check that the
> > > driver was loaded each driver can use internal mechanisms to vet the
> > > driver is now present. The helper try_then_request_module() was
> > > added to help with this, allowing drivers to specify their own validation
> > > as
> the first argument.
> > >
> > > On iwlwifi the use case is a bit more complicated given that the
> > > value we need to check for is protected with a mutex later used on
> > > the
> > > module_init() of the module we are asking for. If we were to lock
> > > and
> > > request_module() we'd deadlock. iwlwifi needs its own wrapper then
> > > so it can handle its special locking requirements.
> > >
> > > Signed-off-by: Luis R. Rodriguez
> >
> > I don't see the problem with the current code. We don't assume that
> > everything has been loaded immediately after request_module returns.
> > We just free the intermediate firmware structures that won't be using
> > anymore. What happens here is that after request_module returns, we
> > patiently wait until it is loaded, and when that happens, iwl{d,m}vm's init
> function will be called.
>
> Right I get that.
>
> The code today complains if its respective opmode module was not loaded if
> request_module() did not return 0. As the commit log explains, relying on a
> return code of 0 to ensure a module loads is not sufficient. So the current
> print is almost pointless, so best we either:
>
> a) just remove the print and use instead request_module_nowait() (this is
> more
>in alignment of what your code actually does today; or
>
> b) fix the request_module() use so that the error print matches the
> expected
>and proper recommended use of request_module() (what this patch does)
>
> I prefer a) actually but I had to show what b) looked like first :)
>
Me too. Let's do the simple thing. After all, it's been working for 5 years now
(maybe more?)
and I don't see a huge need to verify that the opmode module has been loaded.
It is very unlikely to fail anyway, and in the case it did fail, it's not that
we can do much
from iwlwifi point of view. iwlwifi will stay loaded and sit idle since no
opmode will
be there to start using the hardware. We will keep having the device claimed,
and will
keep the interrupt registered and all that. No WiFi for you, but no harm caused
either.
RE: [RFC 2/5] iwlwifi: fix request_module() use
>
> The return value of request_module() being 0 does not mean that the driver
> which was requested has loaded. To properly check that the driver was
> loaded each driver can use internal mechanisms to vet the driver is now
> present. The helper try_then_request_module() was added to help with
> this, allowing drivers to specify their own validation as the first argument.
>
> On iwlwifi the use case is a bit more complicated given that the value we
> need to check for is protected with a mutex later used on the
> module_init() of the module we are asking for. If we were to lock and
> request_module() we'd deadlock. iwlwifi needs its own wrapper then so it
> can handle its special locking requirements.
>
> Signed-off-by: Luis R. Rodriguez
I don't see the problem with the current code. We don't assume that everything
has been
loaded immediately after request_module returns. We just free the intermediate
firmware
structures that won't be using anymore. What happens here is that after
request_module
returns, we patiently wait until it is loaded, and when that happens,
iwl{d,m}vm's init function
will be called. That one is the one that continues the flow by calling:
ret = iwl_opmode_register("iwlmvm", &iwl_mvm_ops);
(for the iwlmvm case).
Where am I wrong here?
> ---
> drivers/net/wireless/intel/iwlwifi/iwl-drv.c | 34 ---
> -
> 1 file changed, 25 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/net/wireless/intel/iwlwifi/iwl-drv.c
> b/drivers/net/wireless/intel/iwlwifi/iwl-drv.c
> index e198d6f5fcea..6beb92d19ea7 100644
> --- a/drivers/net/wireless/intel/iwlwifi/iwl-drv.c
> +++ b/drivers/net/wireless/intel/iwlwifi/iwl-drv.c
> @@ -1231,6 +1231,29 @@ static void _iwl_op_mode_stop(struct iwl_drv
> *drv)
> }
> }
>
> +static void iwlwifi_try_load_op(struct iwlwifi_opmode_table *op,
> + struct iwl_drv *drv)
> +{
> + int ret = 0;
> +
> + ret = request_module("%s", op->name);
> + if (ret)
> + goto out;
> +
> + mutex_lock(&iwlwifi_opmode_table_mtx);
> + if (!op->ops)
> + ret = -ENOENT;
> + mutex_unlock(&iwlwifi_opmode_table_mtx);
> +
> +out:
> +#ifdef CONFIG_IWLWIFI_OPMODE_MODULAR
> + if (ret)
> + IWL_ERR(drv,
> + "failed to load module %s (error %d), is dynamic
> loading enabled?\n",
> + op->name, ret);
> +#endif
> +}
> +
> /**
> * iwl_req_fw_callback - callback when firmware was loaded
> *
> @@ -1471,15 +1494,8 @@ static void iwl_req_fw_callback(const struct
> firmware *ucode_raw, void *context)
>* else from proceeding if the module fails to load
>* or hangs loading.
>*/
> - if (load_module) {
> - err = request_module("%s", op->name);
> -#ifdef CONFIG_IWLWIFI_OPMODE_MODULAR
> - if (err)
> - IWL_ERR(drv,
> - "failed to load module %s (error %d), is
> dynamic loading enabled?\n",
> - op->name, err);
> -#endif
> - }
> + if (load_module)
> + iwlwifi_try_load_op(op, drv);
> goto free;
>
> try_again:
> --
> 2.11.0
RE: [RFC 1/5] iwlwifi: fix drv cleanup on opmode registration failure
Hi Luis,
>
> The firmware async callback handles the device's opmode start call, but
> optionally also allows opmode registration to take care of its opmode start.
> If
> the firmware callback handles it its error path in case of opmode start
> failure
> has a few pieces of code missing from the opmode registration. The opmode
> registration hanlder has no cleanup at all. Sync both error paths.
>
> This should in theory fix a detangled drv from the drv list should either of
> the
> opmode modules loaded and handled registration for the drv.
>
> The path of having the opmode registration deal with the drv opmode start is
> actually the more common path. The other path, from the async callback is
> rathe rare (1/8 or so times for me) -- it happens when the the opmode
> driver's init routine completed prior to the driver's async callback opmode
> start call.
I'd claim it should never happen unless you have several devices on the system
using the same
opmode, or unless you do:
modprobe iwlwifi #which will load iwl{d,m}vm
rmmod iwl{d,m}vm #and do _not_ remove iwlwifi
modprobe iwlwifi
>
> Signed-off-by: Luis R. Rodriguez
> ---
Luca is OOO, but this looks fine to me.
> drivers/net/wireless/intel/iwlwifi/iwl-drv.c | 7 ++-
> 1 file changed, 6 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/net/wireless/intel/iwlwifi/iwl-drv.c
> b/drivers/net/wireless/intel/iwlwifi/iwl-drv.c
> index be466a074c1d..e198d6f5fcea 100644
> --- a/drivers/net/wireless/intel/iwlwifi/iwl-drv.c
> +++ b/drivers/net/wireless/intel/iwlwifi/iwl-drv.c
> @@ -1611,8 +1611,13 @@ int iwl_opmode_register(const char *name, const
> struct iwl_op_mode_ops *ops)
> continue;
> op->ops = ops;
> /* TODO: need to handle exceptional case */
> - list_for_each_entry(drv, &op->drv, list)
> + list_for_each_entry(drv, &op->drv, list) {
> drv->op_mode = _iwl_op_mode_start(drv, op);
> + if (!drv->op_mode) {
> + complete(&drv-
> >request_firmware_complete);
> + device_release_driver(drv->trans->dev);
> + }
> + }
>
> mutex_unlock(&iwlwifi_opmode_table_mtx);
> return 0;
> --
> 2.11.0
RE: [PATCH RESEND] iwlwifi, Do not implement thermal zone unless ucode is loaded
> On 07/15/2016 07:25 AM, Stanislaw Gruszka wrote: > > On Thu, Jul 14, 2016 at 09:44:22AM +, Grumbach, Emmanuel wrote: > >>> If I understad correctly this error happen 100% of the time, not > >>> only during init. Hence seems there is an issue here, i.e. cur_ucode > >>> is not marked correctly as IWL_UCODE_REGULAR or > iwl_mvm_get_temp() > >>> fail 100% of the time (iwl_mvm_is_tt_in_fw() incorrecly return true on > Prarit device ? ). > >> > >> Cur_ucode will not be IWL_UCODE_REGULAR until you load the firmware > >> which will happen upon ifup. > > > > Then creating thermal_device on ifup looks more reasonable to me. > > Otherwise we can create device that can be non-functional virtually > > forever, i.e. when soft RFKILL is enabled. However I admit that > > creating thermal_device when HW is detected has some advantages too. > > That's my plan right now. Unfortunately something else in the kernel seems > recently broken and is preventing me from testing. I will get back to this > early next week. > But we already said that this won't work since you may have the device enabled upon boot and then disabled. So unless you unregister the thermal zone subsystem upon wifi disable, you won't solve the problem. Kalle and Luca already refused that solution. I glanced (again) at the thermal zone API and since it allows to return an int, the subsystem itself should handle the failures and / or the userspace problems. The API itself is awful, it has no documentation whatsoever, even not variable names, but only types... You can't really blame the subsystem users to assume that a method that can return an int can't fail where the out values is passed by a pointer. Of course, you have to guess that this is the expected behavior, since you don't have any hint about the meaning of the parameters. I think that the right place to "fix" this problem is to fix the subsystem. This way, you will fix it for iwlwifi and for any (future) other users that may fall into the trap opened by the API itself.
RE: [PATCH RESEND] iwlwifi, Do not implement thermal zone unless ucode is loaded
> > On Mon, Jul 11, 2016 at 06:27:30PM +, Grumbach, Emmanuel wrote: > > I guess that works, but it seems wrong to me. Usually, registration > > should happen only upon INIT, and yes, at that time the firmware is > > not ready to provide the information yet. > > > > > > > As can be seen in the current code base, iwl_mvm_tzone_get_temp() > > > will return -EIO 100% of the time when the firmware doesn't support > > > reading the > > If I understad correctly this error happen 100% of the time, not only during > init. Hence seems there is an issue here, i.e. cur_ucode is not marked > correctly as IWL_UCODE_REGULAR or iwl_mvm_get_temp() fail 100% of the > time (iwl_mvm_is_tt_in_fw() incorrecly return true on Prarit device ? ). Cur_ucode will not be IWL_UCODE_REGULAR until you load the firmware which will happen upon ifup. > > BTW, you implement thermal_zone device, but do you also need hwmon > device? Perhaps using theramal_zone_params no_hwmon option would be > proper here? That's an interesting direction. I'd have to check, but TBH, I am not familiar with that code. Luca was very involved during the development but he is not available right now. I will be back more the less when the merge window will close :) > > Stanislaw
RE: [PATCH RESEND] iwlwifi, Do not implement thermal zone unless ucode is loaded
>
> Prarit Bhargava writes:
>
> > On 07/13/2016 03:24 AM, Luca Coelho wrote:
> >
> >> I totally agree with Emmanuel and Kalle. We should not change this.
> >> It is a design decision to return an error when the interface is
> >> down, this is very common with other subsystems as well.
> >
> > Please show me another subsystem or driver that does this. I've
> > looked around the kernel but cannot find one that updates the firmware
> > and implements new features on the fly like this. I have come across
> > several drivers that allow for an update, but they do not implement
> > new features based on the firmware.
> >
> > Additionally, what happens when someone back revs firmware versions
> > (which happens far more than you and I would expect)? Does that mean
> > I now go from a functional system to a non-functional system wrt to
> userspace?
>
> I'm not following, what do you mean exactly? Why are you talking updating
> the firmware?
>
> So when we talk about "loading firmware" we mean that the driver pushes
> the firmware image to to the chipset. And then the interface is down the
> chipset is powered down and the RAM on it will be erased. That's the general
> idea anyway, I haven't checked how iwlwifi exactly works in this case but
> Luca or Emmanuel can correct me.
This is correct.
>
> >> The userspace should be able to handle errors and report something
> >> like "unavailable" when this kind of error is returned.
> >
> > I myself have made the same arguments wrt to cpufreq code & bad
> > userspace choices. I just went through this a few months back with
> > what went from a simple patch and turned out to be a hideous patch in
> > cpufreq. You cannot break userspace like this.
>
> Don't get me wrong, I'm a strong supporter of stable user space interfaces
> and I always try to adher to that. But there's a limit for everything. If I'm
> understanding correctly, what you mean is that the kernel should never
> return an error because an application doesn't handle errors gracefully.
> Sorry, but that doesn't make sense to me.
>
> > See commit 51443fbf3d2c ("cpufreq: intel_pstate: Fix intel_pstate
> > powersave min_perf_pct value"). What should have been a trivial
> > change resulted in a massive change because of broken userspace.
>
> In that cpufreq case I understand, it was about a combination of
> configuration values which broke the user space. But here we are just
> dealing with a simple error value, nothing fancy.
>
> >> I'm not sure EIO is the best we can have, but for me that's exactly
> >> what it is. The thermal zone *is* there, but cannot be accessed
> >> because the firmware is not available. I'm okay to change it to
> >> EBUSY, if that would help userspace, but I think that's a bit
> >> misleading. The device is not busy, on the contrary, it's not even running
> at all.
> >>
> >
> > I understand that, but by returning -EIO we end up with an error.
> >
> >> Furthermore, I don't think this is "breaking userspace" in the sense
> >> of being a regression.
> >
> > I run (let's say 4.5 kernel). sensors works. I update to 4.7.
> > sensors doesn't work. How is that not a regression? That's _exactly_
> > what it should be reported as.
>
> Sure, it's a regression in a way. But that's how the user space app you are
> using is implemented, the same problem would happen with any driver
> returning errors.
>
> >> The userspace API has always been implemented with the possibility of
> >> returning errors. It's not a good design if a single device
> >> returning an error causes all the other devices to also fail.
> >>
> >
> > If that were the case we would never have to worry about "breaking
> userspace"?
> > For any kernel change I could just say that the userspace design was
> > bad and be done with it. Why fix anything then?
>
> Because we are talking about a simple error value.
>
> > I don't see any harm in waiting to register the sysfs files for hwmon
> > until the firmware has been validated.
>
> I'm against of that because it's bad software design. It's standard practise
> in
> Linux that drivers register their capabilities during driver probe time so
> that
> user space can query them whenever needed. I assume a properly behaving
> user space app would want to know about all the available sensors once the
> driver is initialised and your suggestion would break that.
>
> > IIUC, the up/down'ing of the device doesn't happen that often (during
> > initial boot, and suspend/resume, switching wifi connections,
> > shutdown?).
>
> Basically it can happen anytime, this is fully controlled by user space.
> There's no point of trying to make any assumptions as they won't hold
> anyway.
>
> > This would make the iwlwifi community happy (IMO) and sensors would
> > still work. At the same time I could write a patch for lm-sensors to
> > fix this issue if it comes up in future versions.
> > [Aside: I'm going to have the reproducing system available today and
> > will test this out
Re: [PATCH RESEND] iwlwifi, Do not implement thermal zone unless ucode is loaded
On Mon, 2016-07-11 at 14:19 -0400, Prarit Bhargava wrote:
>
> On 07/11/2016 02:00 PM, Emmanuel Grumbach wrote:
> > On Mon, Jul 11, 2016 at 6:18 PM, Prarit Bhargava > > wrote:
> > >
> > > Didn't get any feedback or review comments on this patch.
> > > Resending ...
> > >
> > > P.
> >
> > This change is obviously completely broken. It simply disables the
> > registration to thermal zone core.
>
> No it is not broken, and yes, that is exactly what should happen IMO.
>
> The problem is that the iwlwifi driver implements the thermal zone
> even when the
> device doesn't support it.
We implement thermal zone because we do support it, but the problem is
that we need the firmware to be loaded for that. So you can argue that
we should register *later* when the firmware is loaded. But this is
really not helping all that much because the firmware can also be
stopped at any time. So you'd want us to register / unregister the
thermal zone anytime the firmware is loaded / unloaded?
I guess that works, but it seems wrong to me. Usually, registration
should happen only upon INIT, and yes, at that time the firmware is not
ready to provide the information yet.
Maybe returning -EBUSY would help lm-sensors not to get confused?
>
> As can be seen in the current code base, iwl_mvm_tzone_get_temp()
> will return
> -EIO 100% of the time when the firmware doesn't support reading the
> temperature[1]. In this case a read of sysfs will result in a return
> of -EIO,
> and this breaks existing userspace programs such as lm-sensors (which
> by all
> accounts is bad to do).
Right, but I don't understand why the userspace is broken because of
that? Unless we register / unregister anytime the firmware is loaded, I
don't see any proper way to fix this. And yes, I'd expect the userspace
to handle gracefully failures in its requests.
>
> Note that in my patch I have removed the -EIO return in favor of not
> registering
> the non-existent thermal zone. I'm not removing any functionality by
> changing
> this, nor am I adding functionality. In both cases the thermal zone
> is not
> functional, and with my patch userspace continues to work.
You are removing the thermal zone functionality since even when the
firmware will be loaded (which typically happens fairly quickly),
thermal zone won't work.
>
> P.
>
> [1] iwl_mvm_tzone_set_trip_temp() also returns -EIO, so setting and
> getting of
> the temperature is non-functional.
>
>
> >
> > >
> > > ---8<---
> > >
> > > The iwlwifi driver implements a thermal zone and hwmon device,
> > > but
> > > returns -EIO on temperature reads if the firmware isn't loaded.
> > > This
> > > results in the error
> > >
> > > iwlwifi-virtual-0
> > > Adapter: Virtual device
> > > ERROR: Can't get value of subfeature temp1_input: I/O error
> > > temp1:N/A
> > >
> > > being output when using sensors from the lm-sensors package.
> > > Since
> > > the temperature cannot be read unless the ucode is loaded there
> > > is no
> > > reason to add the interface only to have it return an error 100%
> > > of
> > > the time.
> > >
> > > This patch moves the firmware check to
> > > iwl_mvm_thermal_zone_register() and
> > > stops the thermal zone from being created if the ucode hasn't
> > > been loaded.
> > >
> > > Signed-off-by: Prarit Bhargava
> > > Cc: Johannes Berg
> > > Cc: Emmanuel Grumbach
> > > Cc: Luca Coelho
> > > Cc: Intel Linux Wireless
> > > Cc: Kalle Valo
> > > Cc: Chaya Rachel Ivgi
> > > Cc: Sara Sharon
> > > Cc: linux-wirel...@vger.kernel.org
> > > Cc: net...@vger.kernel.org
> > > ---
> > > drivers/net/wireless/intel/iwlwifi/mvm/tt.c | 13 +++--
> > > 1 file changed, 3 insertions(+), 10 deletions(-)
> > >
> > > diff --git a/drivers/net/wireless/intel/iwlwifi/mvm/tt.c
> > > b/drivers/net/wireless/intel/iwlwifi/mvm/tt.c
> > > index 58fc7b3c711c..64802659711f 100644
> > > --- a/drivers/net/wireless/intel/iwlwifi/mvm/tt.c
> > > +++ b/drivers/net/wireless/intel/iwlwifi/mvm/tt.c
> > > @@ -634,11 +634,6 @@ static int iwl_mvm_tzone_get_temp(struct
> > > thermal_zone_device *device,
> > >
> > > mutex_lock(&mvm->mutex);
> > >
> > > - if (!mvm->ucode_loaded || !(mvm->cur_ucode ==
> > > IWL_UCODE_REGULAR)) {
> > > - ret = -EIO;
> > > - goto out;
> > > - }
> > > -
> > > ret = iwl_mvm_get_temp(mvm, &temp);
> > > if (ret)
> > > goto out;
> > > @@ -684,11 +679,6 @@ static int
> > > iwl_mvm_tzone_set_trip_temp(struct thermal_zone_device *device,
> > >
> > > mutex_lock(&mvm->mutex);
> > >
> > > - if (!mvm->ucode_loaded || !(mvm->cur_ucode ==
> > > IWL_UCODE_REGULAR)) {
> > > - ret = -EIO;
> > > - goto out;
> > > - }
> > > -
> > > if (trip < 0 || trip >= IWL_MAX_DTS_TRIPS) {
> > > ret = -EINVAL;
> > > goto out;
> > > @@ -750,6 +740,9 @@ static void
> > > iwl_mvm_thermal_zone_register(struct iwl_mvm *mvm
Re: WARNING: CPU: 1 PID: 2485 at drivers/net/wireless/intel/iwlwifi/pcie/trans.c:1752 iwl_trans_pcie_grab_nic_access+0x110/0x120 [iwlwifi]
On Sat, 2016-04-16 at 17:43 +0200, Borislav Petkov wrote: > On Fri, Apr 15, 2016 at 04:16:02AM +0000, Grumbach, Emmanuel wrote: > > [1] > > https://git.kernel.org/cgit/linux/kernel/git/iwlwifi/backport-iwlwi > > fi.git/ > > It is very strange to pull from this repo, git fetch is doing > something > for a while now without any forward progress. This is not surprising at all. This tree is not a kernel tree, but rather a backport tree. It doesn't contain anything besides the Wifi stack and the backport code. It has no common commit with the Linux kernel. I understand that you fetched this tree from a kernel tree but that's not a good idea. Git will try to find a common ancestor but that will fail... after a huge number of tentatives. You'd better clone it. > In any case, 4.5 is bad too, testing 4.4 now. Here you go. > I 'm travelling currently > so the whole bisection deal will take a whole but I'll get to it > eventually. I'll be glad to see something coming out of this, but I can't say I am very optimistic. > > Thanks for taking a look. >
Re: WARNING: CPU: 1 PID: 2485 at drivers/net/wireless/intel/iwlwifi/pcie/trans.c:1752 iwl_trans_pcie_grab_nic_access+0x110/0x120 [iwlwifi]
On Fri, 2016-04-15 at 02:07 +, Borislav Petkov wrote: > Hi, > > so I'm seeing this when wlan0 tries to associate. On 4.6-rc2 + tip. > After that, wifi is dead in the water. Anyone have a clue? > > And 4.5 seems fine, I'm typing from it as we speak. > ... > [ 661.142657] [ cut here ] > [ 661.142816] WARNING: CPU: 1 PID: 2485 at > drivers/net/wireless/intel/iwlwifi/pcie/trans.c:1752 > iwl_trans_pcie_grab_nic_access+0x110/0x120 [iwlwifi] > [ 661.143231] Timeout waiting for hardware access (CSR_GP_CNTRL > 0x) > This means that we have an electrical issue that prevents us from accessing the device over the PCI bus. BAR has been garbaged or alike. Every time I tried to debug that from the driver side it has ... failed. Because the "good" in the end did exhibit the problem. So, unless you are ready to embark for a bisection journey (and hope that this time when you type 'git bisect good' it is really 'good'), I can't do much. What I can suggest is to install our latest backport based tree on 4.5. This will allow you to have an easily bisectable tree. But it might very well be that 4.5 + latest driver (equivalent to 4.6 as far as iwlwifi is concerned) will be fine. The backport tree is here [1]. Unfortunately, that's the only thing I can suggest for now. [1] https://git.kernel.org/cgit/linux/kernel/git/iwlwifi/backport-iwlwi fi.git/ > -- > Regards/Gruss, > Boris. > > ECO tip #101: Trim your mails when you reply. Srsly.
Re: [PATCH] iwlwifi: pcie: remove duplicate assignment of variable isr_stats
On Mon, 2016-03-28 at 12:33 +0100, Colin King wrote: > From: Colin Ian King > > isr_stats is written twice with the same value, remove one of the > redundant assignments to isr_stats. > > Signed-off-by: Colin Ian King > --- Applied - thanks. > drivers/net/wireless/intel/iwlwifi/pcie/rx.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/net/wireless/intel/iwlwifi/pcie/rx.c > b/drivers/net/wireless/intel/iwlwifi/pcie/rx.c > index 4be3c35..253e4f0 100644 > --- a/drivers/net/wireless/intel/iwlwifi/pcie/rx.c > +++ b/drivers/net/wireless/intel/iwlwifi/pcie/rx.c > @@ -1805,7 +1805,7 @@ irqreturn_t iwl_pcie_irq_msix_handler(int irq, > void *dev_id) > struct msix_entry *entry = dev_id; > struct iwl_trans_pcie *trans_pcie = > iwl_pcie_get_trans_pcie(entry); > struct iwl_trans *trans = trans_pcie->trans; > - struct isr_statistics *isr_stats = isr_stats = &trans_pcie > ->isr_stats; > + struct isr_statistics *isr_stats = &trans_pcie->isr_stats; > u32 inta_fh, inta_hw; > > lock_map_acquire(&trans->sync_cmd_lockdep_map);
Re: [PATCH v3] iwlwifi: dvm: use alloc_ordered_workqueue()
On 03/19/2016 07:15 AM, Eva Rachel Retuya wrote: > Use alloc_ordered_workqueue() to allocate the workqueue instead of > create_singlethread_workqueue() since the latter is deprecated and is > scheduled > for removal. > > There are work items doing related operations that shouldn't be swapped when > queued in a certain order hence preserve the strict execution ordering of a > single threaded (ST) workqueue by switching to alloc_ordered_workqueue(). > > WQ_MEM_RECLAIM flag is not needed since the worker is not depended > during memory reclaim. > > Signed-off-by: Eva Rachel Retuya > Acked-by: Tejun Heo > --- Applied - thanks.
RE: [PATCH] iwlwifi: dvm: convert create_singlethread_workqueue() to alloc_workqueue()
> Hello,
>
> On Thu, Mar 17, 2016 at 01:43:22PM +0100, Johannes Berg wrote:
> > On Thu, 2016-03-17 at 20:37 +0800, Eva Rachel Retuya wrote:
> > > Use alloc_workqueue() to allocate the workqueue instead of
> > > create_singlethread_workqueue() since the latter is deprecated and
> > > is scheduled for removal.
> >
> > Scheduled where?
>
> They've been deprecated for years now. I should note that in the header.
>
> > > static void iwl_setup_deferred_work(struct iwl_priv *priv)
> > > {
> > > - priv->workqueue = create_singlethread_workqueue(DRV_NAME);
> > > + priv->workqueue = alloc_workqueue(DRV_NAME, WQ_HIGHPRI |
> > > WQ_UNBOUND |
> > > + WQ_MEM_RECLAIM, 1);
> >
> > Seems like you should use alloc_ordered_workqueue() though? That also
> > gets you UNBOUND immediately, and the "1".
>
> Right, this one should have been alloc_ordered_workqueue().
>
> > I'm not really sure HIGHPRI is needed either.
>
> So, no WQ_MEM_RECLAIM either then, I suppose? What are the latency
> requirements here - what happens if a thermal management work gets
> delayed?
>
This worker is not supposed to free memory, so no WQ_MEM_RECLAIM needed. The
latency is not critical.
RE: [PATCH] iwlwifi: dvm: convert create_singlethread_workqueue() to alloc_workqueue()
>
> Use alloc_workqueue() to allocate the workqueue instead of
> create_singlethread_workqueue() since the latter is deprecated and is
> scheduled
> for removal.
I can't see any indication of that in the code of workqueue.
Can you share details about that?
>
> There are work items doing related operations that shouldn't be swapped
> when
> queued in a certain order hence preserve the strict execution ordering of a
> single threaded (ST) workqueue by setting max_active to 1 and adding the
> WQ_UNBOUND flag.
>
> In addition, there are work items dealing with temperature throttling
> (tt_work,
> ct_enter, ct_exit). Adding the WQ_HIGHPRI flag would place the work items
> in a
> high priority workqueue.
>
> Lastly, guarantee forward progress for work items depended upon during
> memory
> reclaim by the addition of the WQ_MEM_RECLAIM flag.
>
> Signed-off-by: Eva Rachel Retuya
> ---
> To the maintainers:
> Just to confirm, are work items depended upon during memory reclaim? If
> not, the WQ_MEM_RECLAIM flag will be dropped. I added it just in case since
> create_singlethread_workqueue() also sets this flag.
>
> drivers/net/wireless/intel/iwlwifi/dvm/main.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/net/wireless/intel/iwlwifi/dvm/main.c
> b/drivers/net/wireless/intel/iwlwifi/dvm/main.c
> index f62c2d7..37fa11c 100644
> --- a/drivers/net/wireless/intel/iwlwifi/dvm/main.c
> +++ b/drivers/net/wireless/intel/iwlwifi/dvm/main.c
> @@ -1071,7 +1071,8 @@ static void iwl_bg_restart(struct work_struct *data)
>
> static void iwl_setup_deferred_work(struct iwl_priv *priv)
> {
> - priv->workqueue = create_singlethread_workqueue(DRV_NAME);
> + priv->workqueue = alloc_workqueue(DRV_NAME, WQ_HIGHPRI |
> WQ_UNBOUND |
> + WQ_MEM_RECLAIM, 1);
>
> INIT_WORK(&priv->restart, iwl_bg_restart);
> INIT_WORK(&priv->beacon_update, iwl_bg_beacon_update);
> --
> 1.9.1
Re: [PATCH] iwlwifi: fix erroneous return value
On 02/10/2016 07:10 PM, Anton Protopopov wrote:
> The iwl_trans_pcie_start_fw() function may return the positive value EIO
> instead of -EIO in case of error.
>
> Signed-off-by: Anton Protopopov
> ---
> drivers/net/wireless/intel/iwlwifi/pcie/trans.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/net/wireless/intel/iwlwifi/pcie/trans.c
> b/drivers/net/wireless/intel/iwlwifi/pcie/trans.c
> index d60a467..920ea9d 100644
> --- a/drivers/net/wireless/intel/iwlwifi/pcie/trans.c
> +++ b/drivers/net/wireless/intel/iwlwifi/pcie/trans.c
> @@ -1034,7 +1034,7 @@ static int iwl_trans_pcie_start_fw(struct iwl_trans
> *trans,
> if (trans_pcie->is_down) {
> IWL_WARN(trans,
>"Can't start_fw since the HW hasn't been started\n");
> - ret = EIO;
> + ret = -EIO;
> goto out;
> }
>
applied - thanks.
Re: [PATCH] iwlwifi: Document missing module options
Hi,
On 01/07/2016 12:24 AM, Rodrigo Freire wrote:
> This patch documents two missing module options in the internal
> code comment block.
>
> Signed-off-by: Rodrigo Freire
> ---
> drivers/net/wireless/iwlwifi/iwl-modparams.h |2 ++
> 1 files changed, 2 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/net/wireless/iwlwifi/iwl-modparams.h
> b/drivers/net/wireless/iwlwifi/iwl-modparams.h
> index ac2b90d..1477277 100644
> --- a/drivers/net/wireless/iwlwifi/iwl-modparams.h
> +++ b/drivers/net/wireless/iwlwifi/iwl-modparams.h
> @@ -102,6 +102,8 @@ enum iwl_disable_11n {
> * @power_level: power level, default = 1
> * @debug_level: levels are IWL_DL_*
> * @ant_coupling: antenna coupling in dB, default = 0
> + * @nvm_file: specifies a external NVM file
> + * @uapsd_disable: disable U-APSD, default = 1
> * @d0i3_disable: disable d0i3, default = 1,
> * @lar_disable: disable LAR (regulatory), default = 0
> * @fw_monitor: allow to use firmware monitor
Applied in our internal tree. Thanks.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH RESEND] iwlwifi:Fix error handling in the function iwl_pcie_enqueue_hcmd
Hi,
On 12/30/2015 07:15 PM, Nicholas Krause wrote:
> This fixes error handling in the function iwl_pcie_enqueue_hcmd
> by checking if all calls to the function wl_pcie_txq_build_tfd
> have failed by returning a error code and if so jump to the goto
> label out from the cleaning up of acquired resources before
For sure you haven't ran your code otherwise you would have noticed it
break pretty much everything.
Moreover this patch is not based on my -next tree.
Simple rebasing won't fix the obvious issues in your patch though.
> Signed-off-by: Nicholas Krause
> ---
> drivers/net/wireless/iwlwifi/pcie/tx.c | 27 +--
> 1 file changed, 17 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/net/wireless/iwlwifi/pcie/tx.c
> b/drivers/net/wireless/iwlwifi/pcie/tx.c
> index 2b86c21..49c8c77 100644
> --- a/drivers/net/wireless/iwlwifi/pcie/tx.c
> +++ b/drivers/net/wireless/iwlwifi/pcie/tx.c
> @@ -1472,9 +1472,11 @@ static int iwl_pcie_enqueue_hcmd(struct iwl_trans
> *trans,
> /* start the TFD with the scratchbuf */
> scratch_size = min_t(int, copy_size, IWL_HCMD_SCRATCHBUF_SIZE);
> memcpy(&txq->scratchbufs[q->write_ptr], &out_cmd->hdr, scratch_size);
> - iwl_pcie_txq_build_tfd(trans, txq,
> -iwl_pcie_get_scratchbuf_dma(txq, q->write_ptr),
> -scratch_size, true);
> + idx = iwl_pcie_txq_build_tfd(trans, txq,
> + iwl_pcie_get_scratchbuf_dma(txq,
> q->write_ptr),
> + scratch_size, true);
> + if (idx)
> + goto out;
>
> /* map first command fragment, if any remains */
> if (copy_size > scratch_size) {
> @@ -1489,8 +1491,9 @@ static int iwl_pcie_enqueue_hcmd(struct iwl_trans
> *trans,
> goto out;
> }
>
> - iwl_pcie_txq_build_tfd(trans, txq, phys_addr,
> -copy_size - scratch_size, false);
> + idx = iwl_pcie_txq_build_tfd(trans, txq, phys_addr, copy_size -
> scratch_size, false);
> + if (idx)
> + goto out;
> }
>
> /* map the remaining (adjusted) nocopy/dup fragments */
> @@ -1513,7 +1516,9 @@ static int iwl_pcie_enqueue_hcmd(struct iwl_trans
> *trans,
> goto out;
> }
>
> - iwl_pcie_txq_build_tfd(trans, txq, phys_addr, cmdlen[i], false);
> + idx = iwl_pcie_txq_build_tfd(trans, txq, phys_addr, cmdlen[i],
> false);
> + if (idx)
> + goto out;
> }
>
> out_meta->flags = cmd->flags;
> @@ -1830,8 +1835,8 @@ int iwl_trans_pcie_tx(struct iwl_trans *trans, struct
> sk_buff *skb,
> /* The first TB points to the scratchbuf data - min_copy bytes */
> memcpy(&txq->scratchbufs[q->write_ptr], &dev_cmd->hdr,
> IWL_HCMD_SCRATCHBUF_SIZE);
> - iwl_pcie_txq_build_tfd(trans, txq, tb0_phys,
> -IWL_HCMD_SCRATCHBUF_SIZE, true);
> + if (iwl_pcie_txq_build_tfd(trans, txq, tb0_phys,
> IWL_HCMD_SCRATCHBUF_SIZE, true))
> + goto out_err;
>
> /* there must be data left over for TB1 or this code must be changed */
> BUILD_BUG_ON(sizeof(struct iwl_tx_cmd) < IWL_HCMD_SCRATCHBUF_SIZE);
> @@ -1841,7 +1846,8 @@ int iwl_trans_pcie_tx(struct iwl_trans *trans, struct
> sk_buff *skb,
> tb1_phys = dma_map_single(trans->dev, tb1_addr, tb1_len, DMA_TO_DEVICE);
> if (unlikely(dma_mapping_error(trans->dev, tb1_phys)))
> goto out_err;
> - iwl_pcie_txq_build_tfd(trans, txq, tb1_phys, tb1_len, false);
> + if (iwl_pcie_txq_build_tfd(trans, txq, tb1_phys, tb1_len, false))
> + goto out_err;
>
> /*
>* Set up TFD's third entry to point directly to remainder
> @@ -1857,7 +1863,8 @@ int iwl_trans_pcie_tx(struct iwl_trans *trans, struct
> sk_buff *skb,
> &txq->tfds[q->write_ptr]);
> goto out_err;
> }
> - iwl_pcie_txq_build_tfd(trans, txq, tb2_phys, tb2_len, false);
> + if (iwl_pcie_txq_build_tfd(trans, txq, tb2_phys, tb2_len,
> false))
> + goto out_err;
> }
>
> /* Set up entry for this TFD in Tx byte-count array */
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] iwlwifi: fix compare_const_fl.cocci warnings
Hi Julia,
On 11/27/2015 06:11 PM, Julia Lawall wrote:
> Move constants to the right of binary operators.
>
> Generated by: scripts/coccinelle/misc/compare_const_fl.cocci
>
> Signed-off-by: Fengguang Wu
> Signed-off-by: Julia Lawall
> ---
>
> This looks a bit nicer around the other way, in my opinion.
Thanks, I picked it up. I agree with your taste although having
constants on the left side can avoid the typo = instead of == since they
can't be an l-value. Obviously we never do that and prefer to have the
constant on the right side. More readable for sure.
>
> calib.c |2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> --- a/drivers/net/wireless/intel/iwlwifi/dvm/calib.c
> +++ b/drivers/net/wireless/intel/iwlwifi/dvm/calib.c
> @@ -311,7 +311,7 @@ static int iwl_sens_energy_cck(struct iw
> /* If previous beacon had too many false alarms,
>* give it some extra margin by reducing sensitivity again
>* (but don't go below measured energy of desired Rx) */
> - if (IWL_FA_TOO_MANY == data->nrg_prev_state) {
> + if (data->nrg_prev_state == IWL_FA_TOO_MANY) {
> IWL_DEBUG_CALIB(priv, "... increasing margin\n");
> if (data->nrg_th_cck > (max_nrg_cck + NRG_MARGIN))
> data->nrg_th_cck -= NRG_MARGIN;
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH 4/7] iwlwifi: fix a problematic usage of WARN_ON_ONCE()
>
> WARN_ON_ONCE() takes a condition rather than a format string. This patch
> converted WARN_ON_ONCE() to WARN_ONCE() instead.
>
> Signed-off-by: Geliang Tang
> ---
> drivers/net/wireless/intel/iwlwifi/mvm/rs.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
Already fixed. Thanks.
>
> diff --git a/drivers/net/wireless/intel/iwlwifi/mvm/rs.c
> b/drivers/net/wireless/intel/iwlwifi/mvm/rs.c
> index d1ad103..58d7bee 100644
> --- a/drivers/net/wireless/intel/iwlwifi/mvm/rs.c
> +++ b/drivers/net/wireless/intel/iwlwifi/mvm/rs.c
> @@ -1827,7 +1827,7 @@ static int rs_switch_to_column(struct iwl_mvm
> *mvm,
> rate->type = lq_sta->is_vht ? LQ_VHT_MIMO2 :
> LQ_HT_MIMO2;
> rate_mask = lq_sta->active_mimo2_rate;
> } else {
> - WARN_ON_ONCE("Bad column mode");
> + WARN_ONCE(1, "Bad column mode");
> }
>
> if (column->mode != RS_LEGACY) {
> --
> 2.5.0
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [linuxwifi] [-next] WARNING at iwl_mvm_time_event_send_add+0x72/0x1b6
On 10/26/2015 10:30 AM, Sergey Senozhatsky wrote: > On (10/26/15 07:51), Grumbach, Emmanuel wrote: >>> On 10/26/2015 08:41 AM, Sergey Senozhatsky wrote: >>>> Hi, >>>> >>>> linux-next 20151022 >>>> >>>> >>> >>> Can be reproduced reliably? >>> Seems like a bad race between the end of session protection for the >>> authentication and the start of the session protection for the deauth. >>> I think I found the hole in the locks in there, but it is going to be >>> tricky to solve. >> >> Not sure if I found the race. Can you please send the complete log? >> If you have timestamps, it'd greatly helps... >> dmesg output should do. >> > > Hi, > > not really sure if I can reproduce this one easily. seen once. > I see... This log seems to teach me you have 2 entities trying to control the wlan interface: as soon as we are associated, someone kicks us out. What I *think* is happening here is that the session protection for the authentication is launched (command sent to the firmware), but not started yet (at least the driver hasn't received the notification from the firmware) until someone (who?) wants to deauth. At that stage, te_data->running is false, and te_data->id is valid. To send the deauth frame (why are we even sending it since we are not authenticated?), another session protection is started, and here you hit the warning. This scenario is highly improbable and besides the WARNING (which is an issue, I admit), there is no undesirable behavior. I lean towards leaving the code as is for now instead of playing with locks and get the code nasty. I think I do want to leave the WARNING in place despite the fact that we see it *can* happen. But this is *so* rare, that I prefer to have it so that it can catch other (real?) issues. The interesting point here is why mac80211 tries to deauth when we are not authenticated yet. I think I've seen a patch for that, but I'd need to check. > --- > > Oct 26 15:20:51 dhclient[399]: DHCPDISCOVER on wlp2s0 to 255.255.255.255 > port 67 interval 7 > Oct 26 15:20:58 dhclient[399]: DHCPDISCOVER on wlp2s0 to 255.255.255.255 > port 67 interval 17 > Oct 26 15:21:09 dhclient[539]: DHCPDISCOVER on wlp2s0 to 255.255.255.255 > port 67 interval 7 > Oct 26 15:21:09 kernel: wlp2s0: authenticate with 00:04:96:69:0d:80 > Oct 26 15:21:09 kernel: wlp2s0: send auth to 00:04:96:69:0d:80 (try 1/3) > Oct 26 15:21:09 kernel: wlp2s0: authenticated > Oct 26 15:21:09 kernel: wlp2s0: associate with 00:04:96:69:0d:80 (try 1/3) > Oct 26 15:21:09 kernel: wlp2s0: RX AssocResp from 00:04:96:69:0d:80 > (capab=0x11 status=0 aid=24) > Oct 26 15:21:09 kernel: wlp2s0: associated > Oct 26 15:21:09 kernel: IPv6: ADDRCONF(NETDEV_CHANGE): wlp2s0: link becomes > ready > Oct 26 15:21:09 kernel: wlp2s0: deauthenticating from 00:04:96:69:0d:80 by > local choice (Reason: 3=DEAUTH_LEAVING) > Oct 26 15:21:12 kernel: wlp2s0: authenticate with 00:04:96:61:e9:f0 > Oct 26 15:21:12 kernel: wlp2s0: send auth to 00:04:96:61:e9:f0 (try 1/3) > Oct 26 15:21:12 kernel: wlp2s0: authenticated > Oct 26 15:21:12 kernel: wlp2s0: associate with 00:04:96:61:e9:f0 (try 1/3) > Oct 26 15:21:12 kernel: wlp2s0: RX AssocResp from 00:04:96:61:e9:f0 > (capab=0x11 status=0 aid=16) > Oct 26 15:21:12 kernel: wlp2s0: associated > Oct 26 15:21:12 kernel: wlp2s0: deauthenticating from 00:04:96:61:e9:f0 by > local choice (Reason: 3=DEAUTH_LEAVING) > Oct 26 15:21:16 dhclient[539]: DHCPDISCOVER on wlp2s0 to 255.255.255.255 > port 67 interval 10 > Oct 26 15:21:22 kernel: wlp2s0: authenticate with 00:04:96:69:0d:80 > Oct 26 15:21:22 kernel: wlp2s0: send auth to 00:04:96:69:0d:80 (try 1/3) > Oct 26 15:21:22 kernel: wlp2s0: authenticated > Oct 26 15:21:22 kernel: wlp2s0: associate with 00:04:96:69:0d:80 (try 1/3) > Oct 26 15:21:22 kernel: wlp2s0: RX AssocResp from 00:04:96:69:0d:80 > (capab=0x11 status=0 aid=25) > Oct 26 15:21:22 kernel: wlp2s0: associated > Oct 26 15:21:22 kernel: wlp2s0: deauthenticating from 00:04:96:69:0d:80 by > local choice (Reason: 3=DEAUTH_LEAVING) > Oct 26 15:21:26 dhclient[539]: DHCPDISCOVER on wlp2s0 to 255.255.255.255 > port 67 interval 9 > Oct 26 15:21:35 dhclient[539]: DHCPDISCOVER on wlp2s0 to 255.255.255.255 > port 67 interval 12 > Oct 26 15:21:47 kernel: wlp2s0: authenticate with 00:04:96:69:0d:80 > Oct 26 15:21:47 kernel: wlp2s0: send auth to 00:04:96:69:0d:80 (try 1/3) > Oct 26 15:21:47 kernel: wlp2s0: authenticated > Oct 26 15:21:47 kernel: wlp2s0: associate with 00:04:96:69:0d:80 (try 1/3) > Oct 26 15:21:47 kernel: wlp2s0: RX AssocResp from 00:04:96:69:0d:80 > (capab=0x11 status=0 aid=25) > Oct 26 15:21:47 kernel: wlp2s0:
Re: [linuxwifi] [-next] WARNING at iwl_mvm_time_event_send_add+0x72/0x1b6
On 10/26/2015 09:23 AM, Grumbach, Emmanuel wrote: > Hi, > > On 10/26/2015 08:41 AM, Sergey Senozhatsky wrote: >> Hi, >> >> linux-next 20151022 >> >> > > Can be reproduced reliably? > Seems like a bad race between the end of session protection for the > authentication and the start of the session protection for the deauth. > I think I found the hole in the locks in there, but it is going to be > tricky to solve. Not sure if I found the race. Can you please send the complete log? If you have timestamps, it'd greatly helps... dmesg output should do. > >> wlp2s0: aborting authentication with 00:04:96:61:cd:e0 by local choice >> (Reason: 3=DEAUTH_LEAVING) >> [ cut here ] >> WARNING: CPU: 0 PID: 1006 at >> drivers/net/wireless/iwlwifi/mvm/time-event.c:513 >> iwl_mvm_time_event_send_add+0x72/0x1b6 [iwlmvm]() >> Modules linked in: mousedev arc4 nls_iso8859_1 nls_cp437 vfat fat serio_raw >> psmouse atkbd coretemp hwmon i915 libps2 iwlmvm i2c_algo_bit mac80211 >> drm_kms_helper cfbfillrect intel_powerclamp syscopyarea cfbimgblt >> sysfillrect sysimgblt crc32c_intel fb_sys_fops cfbcopyarea iwlwifi drm r8 >> CPU: 0 PID: 1006 Comm: iwconfig Not tainted >> 4.3.0-rc6-next-20151022-dbg-2-g4041783-dirty #260 >> 8800c69479c8 811dd4ad >> 8800c6947a00 8103db4e a04fd261 88041c7cdfc8 >> 88041cc87a20 88041c7ceb28 8800c6947aac 8800c6947a10 >> Call Trace: >> [] dump_stack+0x4b/0x63 >> [] warn_slowpath_common+0x99/0xb2 >> [] ? iwl_mvm_time_event_send_add+0x72/0x1b6 [iwlmvm] >> [] warn_slowpath_null+0x1a/0x1c >> [] iwl_mvm_time_event_send_add+0x72/0x1b6 [iwlmvm] >> [] ? __lock_is_held+0x3c/0x57 >> [] iwl_mvm_protect_session+0x150/0x219 [iwlmvm] >> [] ? iwl_mvm_protect_session+0x150/0x219 [iwlmvm] >> [] ? iwl_mvm_ref_sync+0x37/0x10c [iwlmvm] >> [] iwl_mvm_mac_mgd_prepare_tx+0xa4/0xc2 [iwlmvm] >> [] ? iwl_mvm_mac_mgd_prepare_tx+0xa4/0xc2 [iwlmvm] >> [] ieee80211_mgd_deauth+0x14f/0x3b0 [mac80211] >> [] ? __lock_is_held+0x3c/0x57 >> [] ieee80211_deauth+0x18/0x1a [mac80211] >> [] cfg80211_mlme_deauth+0x13c/0x28e [cfg80211] >> [] cfg80211_disconnect+0xb5/0x2f7 [cfg80211] >> [] cfg80211_mgd_wext_siwfreq+0xed/0x160 [cfg80211] >> [] ? cfg80211_wext_freq+0x5f/0x5f [cfg80211] >> [] cfg80211_wext_siwfreq+0x76/0xf6 [cfg80211] >> [] ioctl_standard_call+0x66/0x376 >> [] wext_handle_ioctl+0x102/0x16d >> [] dev_ioctl+0x6bb/0x6de >> [] ? handle_mm_fault+0xefc/0x13f9 >> [] sock_ioctl+0x230/0x23c >> [] ? sock_ioctl+0x230/0x23c >> [] do_vfs_ioctl+0x458/0x4dc >> [] ? retint_user+0x18/0x20 >> [] ? __fget_light+0x4d/0x71 >> [] SyS_ioctl+0x43/0x61 >> [] entry_SYSCALL_64_fastpath+0x12/0x6f >> ---[ end trace 6a44e7f1588bdae7 ]--- >> >> >> -ss >> - >> linuxw...@eclists.intel.com >> https://eclists.intel.com/sympa/info/linuxwifi >> Unsubscribe by sending email to sy...@eclists.intel.com with subject >> "Unsubscribe linuxwifi" >> > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [linuxwifi] [-next] WARNING at iwl_mvm_time_event_send_add+0x72/0x1b6
Hi, On 10/26/2015 08:41 AM, Sergey Senozhatsky wrote: > Hi, > > linux-next 20151022 > > Can be reproduced reliably? Seems like a bad race between the end of session protection for the authentication and the start of the session protection for the deauth. I think I found the hole in the locks in there, but it is going to be tricky to solve. > wlp2s0: aborting authentication with 00:04:96:61:cd:e0 by local choice > (Reason: 3=DEAUTH_LEAVING) > [ cut here ] > WARNING: CPU: 0 PID: 1006 at > drivers/net/wireless/iwlwifi/mvm/time-event.c:513 > iwl_mvm_time_event_send_add+0x72/0x1b6 [iwlmvm]() > Modules linked in: mousedev arc4 nls_iso8859_1 nls_cp437 vfat fat serio_raw > psmouse atkbd coretemp hwmon i915 libps2 iwlmvm i2c_algo_bit mac80211 > drm_kms_helper cfbfillrect intel_powerclamp syscopyarea cfbimgblt sysfillrect > sysimgblt crc32c_intel fb_sys_fops cfbcopyarea iwlwifi drm r8 > CPU: 0 PID: 1006 Comm: iwconfig Not tainted > 4.3.0-rc6-next-20151022-dbg-2-g4041783-dirty #260 > 8800c69479c8 811dd4ad > 8800c6947a00 8103db4e a04fd261 88041c7cdfc8 > 88041cc87a20 88041c7ceb28 8800c6947aac 8800c6947a10 > Call Trace: > [] dump_stack+0x4b/0x63 > [] warn_slowpath_common+0x99/0xb2 > [] ? iwl_mvm_time_event_send_add+0x72/0x1b6 [iwlmvm] > [] warn_slowpath_null+0x1a/0x1c > [] iwl_mvm_time_event_send_add+0x72/0x1b6 [iwlmvm] > [] ? __lock_is_held+0x3c/0x57 > [] iwl_mvm_protect_session+0x150/0x219 [iwlmvm] > [] ? iwl_mvm_protect_session+0x150/0x219 [iwlmvm] > [] ? iwl_mvm_ref_sync+0x37/0x10c [iwlmvm] > [] iwl_mvm_mac_mgd_prepare_tx+0xa4/0xc2 [iwlmvm] > [] ? iwl_mvm_mac_mgd_prepare_tx+0xa4/0xc2 [iwlmvm] > [] ieee80211_mgd_deauth+0x14f/0x3b0 [mac80211] > [] ? __lock_is_held+0x3c/0x57 > [] ieee80211_deauth+0x18/0x1a [mac80211] > [] cfg80211_mlme_deauth+0x13c/0x28e [cfg80211] > [] cfg80211_disconnect+0xb5/0x2f7 [cfg80211] > [] cfg80211_mgd_wext_siwfreq+0xed/0x160 [cfg80211] > [] ? cfg80211_wext_freq+0x5f/0x5f [cfg80211] > [] cfg80211_wext_siwfreq+0x76/0xf6 [cfg80211] > [] ioctl_standard_call+0x66/0x376 > [] wext_handle_ioctl+0x102/0x16d > [] dev_ioctl+0x6bb/0x6de > [] ? handle_mm_fault+0xefc/0x13f9 > [] sock_ioctl+0x230/0x23c > [] ? sock_ioctl+0x230/0x23c > [] do_vfs_ioctl+0x458/0x4dc > [] ? retint_user+0x18/0x20 > [] ? __fget_light+0x4d/0x71 > [] SyS_ioctl+0x43/0x61 > [] entry_SYSCALL_64_fastpath+0x12/0x6f > ---[ end trace 6a44e7f1588bdae7 ]--- > > > -ss > - > linuxw...@eclists.intel.com > https://eclists.intel.com/sympa/info/linuxwifi > Unsubscribe by sending email to sy...@eclists.intel.com with subject > "Unsubscribe linuxwifi" > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] iwlwifi: out-of-bounds access in iwl_init_sband_channels
Hi,
On 08/14/2015 03:36 AM, Adrien Schildknecht wrote:
> Both loops of this function compare data from the 'chan' array and then
> check if the index is valid.
>
> The 2 conditions should be inverted to avoid an out-of-bounds access.
>
Was that found by a static analyzer or any other automated tool, or was
that the result of your very careful review?
> Signed-off-by: Adrien Schildknecht
> ---
> drivers/net/wireless/iwlwifi/iwl-eeprom-parse.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/net/wireless/iwlwifi/iwl-eeprom-parse.c
> b/drivers/net/wireless/iwlwifi/iwl-eeprom-parse.c
> index 21302b6..acc3d18 100644
> --- a/drivers/net/wireless/iwlwifi/iwl-eeprom-parse.c
> +++ b/drivers/net/wireless/iwlwifi/iwl-eeprom-parse.c
> @@ -713,12 +713,12 @@ int iwl_init_sband_channels(struct iwl_nvm_data *data,
> struct ieee80211_channel *chan = &data->channels[0];
> int n = 0, idx = 0;
>
> - while (chan->band != band && idx < n_channels)
> + while (idx < n_channels && chan->band != band)
> chan = &data->channels[++idx];
>
> sband->channels = &data->channels[idx];
>
> - while (chan->band == band && idx < n_channels) {
> + while (idx < n_channels && chan->band == band) {
> chan = &data->channels[++idx];
> n++;
> }
>
Looks fine - I'll pick it up.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [linuxwifi] [PATCH] iwlwifi:Fix error handling in the function iwl_pcie_enqueue_hcmd
On 07/22/2015 08:30 PM, nick wrote: > > > On 2015-07-22 01:28 PM, Grumbach, Emmanuel wrote: >> >> >> On 07/22/2015 07:39 PM, Nicholas Krause wrote: >>> This fixes error handling in the function iwl_pcie_enqueue_hcmd >>> by checking if all calls to the function wl_pcie_txq_build_tfd >>> have failed by returning a error code and if so jump to the goto >>> label out from the cleaning up of acquired resources before >> >> What tests did you run on your patch? >> > None did I miss something? I can't really accept a patch if you don't even test it, right? Your patch doesn't look problematic at first glance, but hitting these paths isn't easy and I am not very happy to change the behavior without direct testing. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] iwlwifi:Fix error handling in the function iwl_pcie_enqueue_hcmd
On 07/22/2015 07:39 PM, Nicholas Krause wrote: > This fixes error handling in the function iwl_pcie_enqueue_hcmd > by checking if all calls to the function wl_pcie_txq_build_tfd > have failed by returning a error code and if so jump to the goto > label out from the cleaning up of acquired resources before What tests did you run on your patch? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] iwlwifi:dvm:Return false if resume command data is not same size as received packet for the function iwl_resume_status_fn
On Wed, 2015-06-10 at 12:58 -0400, Nicholas Krause wrote:
>
> On June 10, 2015 12:50:45 PM EDT, "Grumbach, Emmanuel"
> wrote:
> >On Wed, 2015-06-10 at 12:33 -0400, Nicholas Krause wrote:
> >> This makes the function iwl_resume_status_fn return false now if
> >> the received packet of type iwl_rx_packet is not the same size
> >> as the structure pointer, iwl_resume_data's cmd element in order
> >> to signal callers about this error and allow them to handle it
> >> occurrently.
> >>
> >
> >Hm... Did you actually hit this if?
> >I am not sure I really want to wait here (which is what will happen if
> >you return false) when we get an unexpected length? I do not expect
> >anything besides the response I am waiting for since the firmware is
> >handling the GET_STATUS *only* - it just came back from WoWLAN. Bottom
> >line, this is really an error path and I prefer to exit and not wait
> >for
> >the timeout in that case.
> >But I might be missing something?
> >
> Why not wait for the time out? Seems there is no reason not to and in that
> case
> if the firmware handles this
I doubt it will. This goes back to my original question: did you really
hit this path? Does the patch solves a real bug you faced?
> why is the if statement still here.
To get a debug print? :)
> Nick
> >> Signed-off-by: Nicholas Krause
> >> ---
> >> drivers/net/wireless/iwlwifi/dvm/mac80211.c | 2 +-
> >> 1 file changed, 1 insertion(+), 1 deletion(-)
> >>
> >> diff --git a/drivers/net/wireless/iwlwifi/dvm/mac80211.c
> >b/drivers/net/wireless/iwlwifi/dvm/mac80211.c
> >> index 5abd62e..21e808c 100644
> >> --- a/drivers/net/wireless/iwlwifi/dvm/mac80211.c
> >> +++ b/drivers/net/wireless/iwlwifi/dvm/mac80211.c
> >> @@ -409,7 +409,7 @@ static bool iwl_resume_status_fn(struct
> >iwl_notif_wait_data *notif_wait,
> >>
> >>if (iwl_rx_packet_payload_len(pkt) != sizeof(*resume_data->cmd)) {
> >>IWL_ERR(priv, "rx wrong size data\n");
> >> - return true;
> >> + return false;
> >>}
> >>memcpy(resume_data->cmd, pkt->data, sizeof(*resume_data->cmd));
> >>resume_data->valid = true;
>
N�r��yb�X��ǧv�^�){.n�+{zX����ܨ}���Ơz�&j:+v���zZ+��+zf���h���~i���z� �w���?�&�)ߢf��^jǫy�m��@A�a���
0��h���i
Re: [PATCH] iwlwifi:dvm:Return false if resume command data is not same size as received packet for the function iwl_resume_status_fn
On Wed, 2015-06-10 at 12:33 -0400, Nicholas Krause wrote:
> This makes the function iwl_resume_status_fn return false now if
> the received packet of type iwl_rx_packet is not the same size
> as the structure pointer, iwl_resume_data's cmd element in order
> to signal callers about this error and allow them to handle it
> occurrently.
>
Hm... Did you actually hit this if?
I am not sure I really want to wait here (which is what will happen if
you return false) when we get an unexpected length? I do not expect
anything besides the response I am waiting for since the firmware is
handling the GET_STATUS *only* - it just came back from WoWLAN. Bottom
line, this is really an error path and I prefer to exit and not wait for
the timeout in that case.
But I might be missing something?
> Signed-off-by: Nicholas Krause
> ---
> drivers/net/wireless/iwlwifi/dvm/mac80211.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/net/wireless/iwlwifi/dvm/mac80211.c
> b/drivers/net/wireless/iwlwifi/dvm/mac80211.c
> index 5abd62e..21e808c 100644
> --- a/drivers/net/wireless/iwlwifi/dvm/mac80211.c
> +++ b/drivers/net/wireless/iwlwifi/dvm/mac80211.c
> @@ -409,7 +409,7 @@ static bool iwl_resume_status_fn(struct
> iwl_notif_wait_data *notif_wait,
>
> if (iwl_rx_packet_payload_len(pkt) != sizeof(*resume_data->cmd)) {
> IWL_ERR(priv, "rx wrong size data\n");
> - return true;
> + return false;
> }
> memcpy(resume_data->cmd, pkt->data, sizeof(*resume_data->cmd));
> resume_data->valid = true;
Re: [BUG 4.1.0-rc6] iwlwifi: "Error sending REPLY_TXFIFO_FLUSH: time out after 2000ms"
On Thu, 2015-06-04 at 22:32 +0300, Kirill A. Shutemov wrote: > On Thu, Jun 04, 2015 at 06:13:22PM +0000, Grumbach, Emmanuel wrote: > > On Thu, 2015-06-04 at 20:37 +0300, Kirill A. Shutemov wrote: > > > Hi, > > > > > > I've trigered the bug few times after several suspend/resume cycles. > > > Hardware is Thinkpad X1 2013 with Intel Corporation Centrino Advanced-N > > > 6205 (8086:0085) (rev 96). > > > > > > > This really looks like the platform problem people have been hitting. > > The device is no longer accessible. > > Unfortunately, I really don't know what we can do in that case. > > Is there anything I can do to provide info you need? > Thing is that I have already talked to the relevant people internally. The problem here is that the PCI bus is not doing its work anymore. This can happen when one of the sides does a violation that the other side isn't ready to cope with. The proper way to cope with this is to take the machine and to plug it in a PCI analyzer. This is an equipment that monitors all the PCI transactions on the bus. You are not the first to complain, I have had a lot of complaints about this recently. Someone even tried to bisect because he thought this was a regression. This didn't bring any conclusion since the commit that served as the 'good' baseline wasn't working anymore after he finished the bisection. In short, unless you are ready to send the actual system that is giving you trouble, there isn't much I can do. You can try the step in https://bugzilla.kernel.org/show_bug.cgi?id=91171#c42 to see if it can help recovering.
Re: pull request: iwlmvm firmware -13.ucode
Signed this time. On Thu, 2015-05-28 at 20:53 +0300, Emmanuel Grumbach wrote: > Hello, > > This is a pull request to include -13.ucode into mainline. > This firmware can run on 7260, 3160, 7265, 7265D and 3165 which are all > the devices driven by iwlmvm. > This firmware is supported starting from kernel 4.1 > > Thanks you. > > The following changes since commit 8e181320b11de501046cf75c8c30915cd09a1e39: > > linux-firmware: Add Realtek Bluetooth HCD firmware (2015-05-08 13:12:23 > -0400) > > are available in the git repository at: > > git://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/linux-firmware.git > > for you to fetch changes up to 841b151cfd49e03e6531891e8cef0a5f3de83d40: > > iwlwifi: add new -13 firmware for 3160 / 7260 / 7265 / 7265D (2015-05-28 > 19:54:40 +0300) > > > Emmanuel Grumbach (1): > iwlwifi: add new -13 firmware for 3160 / 7260 / 7265 / 7265D > > WHENCE | 12 > iwlwifi-3160-13.ucode | Bin 0 -> 688616 bytes > iwlwifi-7260-13.ucode | Bin 0 -> 786920 bytes > iwlwifi-7265-13.ucode | Bin 0 -> 885224 bytes > iwlwifi-7265D-13.ucode | Bin 0 -> 1008668 bytes > 5 files changed, 12 insertions(+) > create mode 100644 iwlwifi-3160-13.ucode > create mode 100644 iwlwifi-7260-13.ucode > create mode 100644 iwlwifi-7265-13.ucode > create mode 100644 iwlwifi-7265D-13.ucode > > diff --git a/WHENCE b/WHENCE > index e544914..06da22a 100644 > --- a/WHENCE > +++ b/WHENCE > @@ -834,6 +834,9 @@ Version: 23.15.10.0 > File: iwlwifi-7260-12.ucode > Version: 25.17.12.0 > > +File: iwlwifi-7260-13.ucode > +Version: 25.27.13.0 > + > File: iwlwifi-3160-7.ucode > Version: 22.1.7.0 > > @@ -849,6 +852,9 @@ Version: 23.15.10.0 > File: iwlwifi-3160-12.ucode > Version: 25.17.12.0 > > +File: iwlwifi-3160-13.ucode > +Version: 25.27.13.0 > + > File: iwlwifi-7265-8.ucode > Version: 22.24.8.0 > > @@ -861,12 +867,18 @@ Version: 23.15.10.0 > File: iwlwifi-7265-12.ucode > Version: 25.17.12.0 > > +File: iwlwifi-7265-13.ucode > +Version: 25.27.13.0 > + > File: iwlwifi-7265D-10.ucode > Version: 23.15.10.0 > > File: iwlwifi-7265D-12.ucode > Version: 25.17.12.0 > > +File: iwlwifi-7265D-13.ucode > +Version: 25.27.13.0 > + > Licence: Redistributable. See LICENCE.iwlwifi_firmware for details > > Also available from > http://wireless.kernel.org/en/users/Drivers/iwlwifi#Firmware > diff --git a/iwlwifi-3160-13.ucode b/iwlwifi-3160-13.ucode > new file mode 100644 > index 000..a5fb7b7 > Binary files /dev/null and b/iwlwifi-3160-13.ucode differ > diff --git a/iwlwifi-7260-13.ucode b/iwlwifi-7260-13.ucode > new file mode 100644 > index 000..a12dd50 > Binary files /dev/null and b/iwlwifi-7260-13.ucode differ > diff --git a/iwlwifi-7265-13.ucode b/iwlwifi-7265-13.ucode > new file mode 100644 > index 000..53f5134 > Binary files /dev/null and b/iwlwifi-7265-13.ucode differ > diff --git a/iwlwifi-7265D-13.ucode b/iwlwifi-7265D-13.ucode > new file mode 100644 > index 000..df4307e > Binary files /dev/null and b/iwlwifi-7265D-13.ucode differ signature.asc Description: This is a digitally signed message part
pull request: iwlmvm firmware -13.ucode
Hello, This is a pull request to include -13.ucode into mainline. This firmware can run on 7260, 3160, 7265, 7265D and 3165 which are all the devices driven by iwlmvm. This firmware is supported starting from kernel 4.1 Thanks you. The following changes since commit 8e181320b11de501046cf75c8c30915cd09a1e39: linux-firmware: Add Realtek Bluetooth HCD firmware (2015-05-08 13:12:23 -0400) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/linux-firmware.git for you to fetch changes up to 841b151cfd49e03e6531891e8cef0a5f3de83d40: iwlwifi: add new -13 firmware for 3160 / 7260 / 7265 / 7265D (2015-05-28 19:54:40 +0300) Emmanuel Grumbach (1): iwlwifi: add new -13 firmware for 3160 / 7260 / 7265 / 7265D WHENCE | 12 iwlwifi-3160-13.ucode | Bin 0 -> 688616 bytes iwlwifi-7260-13.ucode | Bin 0 -> 786920 bytes iwlwifi-7265-13.ucode | Bin 0 -> 885224 bytes iwlwifi-7265D-13.ucode | Bin 0 -> 1008668 bytes 5 files changed, 12 insertions(+) create mode 100644 iwlwifi-3160-13.ucode create mode 100644 iwlwifi-7260-13.ucode create mode 100644 iwlwifi-7265-13.ucode create mode 100644 iwlwifi-7265D-13.ucode diff --git a/WHENCE b/WHENCE index e544914..06da22a 100644 --- a/WHENCE +++ b/WHENCE @@ -834,6 +834,9 @@ Version: 23.15.10.0 File: iwlwifi-7260-12.ucode Version: 25.17.12.0 +File: iwlwifi-7260-13.ucode +Version: 25.27.13.0 + File: iwlwifi-3160-7.ucode Version: 22.1.7.0 @@ -849,6 +852,9 @@ Version: 23.15.10.0 File: iwlwifi-3160-12.ucode Version: 25.17.12.0 +File: iwlwifi-3160-13.ucode +Version: 25.27.13.0 + File: iwlwifi-7265-8.ucode Version: 22.24.8.0 @@ -861,12 +867,18 @@ Version: 23.15.10.0 File: iwlwifi-7265-12.ucode Version: 25.17.12.0 +File: iwlwifi-7265-13.ucode +Version: 25.27.13.0 + File: iwlwifi-7265D-10.ucode Version: 23.15.10.0 File: iwlwifi-7265D-12.ucode Version: 25.17.12.0 +File: iwlwifi-7265D-13.ucode +Version: 25.27.13.0 + Licence: Redistributable. See LICENCE.iwlwifi_firmware for details Also available from http://wireless.kernel.org/en/users/Drivers/iwlwifi#Firmware diff --git a/iwlwifi-3160-13.ucode b/iwlwifi-3160-13.ucode new file mode 100644 index 000..a5fb7b7 Binary files /dev/null and b/iwlwifi-3160-13.ucode differ diff --git a/iwlwifi-7260-13.ucode b/iwlwifi-7260-13.ucode new file mode 100644 index 000..a12dd50 Binary files /dev/null and b/iwlwifi-7260-13.ucode differ diff --git a/iwlwifi-7265-13.ucode b/iwlwifi-7265-13.ucode new file mode 100644 index 000..53f5134 Binary files /dev/null and b/iwlwifi-7265-13.ucode differ diff --git a/iwlwifi-7265D-13.ucode b/iwlwifi-7265D-13.ucode new file mode 100644 index 000..df4307e Binary files /dev/null and b/iwlwifi-7265D-13.ucode differ signature.asc Description: This is a digitally signed message part
Re: iwlwifi getting stuck with current Linus' tree (646da63172)
On Mon, 2015-05-04 at 08:55 +0200, Jiri Kosina wrote: > On Mon, 4 May 2015, Grumbach, Emmanuel wrote: > > > > so over a past few days, I tried to perform a bisect, but failed as > > > expected. The issue is not reliably enough reproducible for me, so I > > > ended > > > up with a completely bogus commit. > > > > > > *However*, now that I have been following the causes and symptoms more > > > closely (due to the bisect attempt), I have to confirm that the issue > > > happens much more often when the machine is question is physically being > > > moved when associated. > > > > > > > I am doing this all the time and I don't hit your problem. Without any > > logs I don't see how I can help here. Please try to catch logs of the > > crash. Thanks. > > I have provided them in the very first e-mail to this thread; see > > https://lkml.org/lkml/2015/4/22/601 > > If there is any way how to obtain more verbose / useful logs, please let > me know, I'll be happy to do that. > Sorry, my bad. I lost context here... So I really don't know what to say. I can't see any iwlwifi commit that could be causing this, OTOH, bisection didn't bring any results. You can try to unregister the device from PCI and then to rescan. It worked for some people. Other than that, I can't do much. Did you update your BIOS before you started to see this failure?
Re: iwlwifi getting stuck with current Linus' tree (646da63172)
On Sun, 2015-05-03 at 23:42 +0200, Jiri Kosina wrote:
> Hi,
>
> so over a past few days, I tried to perform a bisect, but failed as
> expected. The issue is not reliably enough reproducible for me, so I ended
> up with a completely bogus commit.
>
> *However*, now that I have been following the causes and symptoms more
> closely (due to the bisect attempt), I have to confirm that the issue
> happens much more often when the machine is question is physically being
> moved when associated.
>
I am doing this all the time and I don't hit your problem. Without any
logs I don't see how I can help here. Please try to catch logs of the
crash. Thanks.
N�r��yb�X��ǧv�^�){.n�+{zX����ܨ}���Ơz�&j:+v���zZ+��+zf���h���~i���z� �w���?�&�)ߢf��^jǫy�m��@A�a���
0��h���i
Re: iwlwifi getting stuck with current Linus' tree (646da63172)
On Thu, 2015-04-23 at 14:48 +0200, Piotr Karbowski wrote:
> Hello,
>
> On Thu, Apr 23, 2015 at 11:15 AM, Jiri Kosina wrote:
> > On Thu, 23 Apr 2015, Grumbach, Emmanuel wrote:
> >
> >> > I will try it, but I expect the result to be bogus because of this,
> >> > unfortunately.
> >>
> >> I can understand. A few users reported that this bug occurred more
> >> reliably when moving their system, although it seems very weird to me.
> >
> > My "feeling" was that it sometimes was related to start of audio playback,
> > but not 100% relieble either.
> >
> >> > > First question is: Are you sure that 4.0-rc6 was good?
> >> >
> >> > Pretty much, yes. I've been running it for quite some time on this
> >> > machine without any issues. But after updating to current HEAD two days
> >> > ago, the issue triggered like 6 or 7 times already.
> >>
> >> Ok - I will try to look at the PCI commits there although I am not sure
> >> I'll be able to make much sense of them...
> >
> > Thanks,
>
> i've also started noticing hard system lockups with iwlwifi. What's
> worth noticing is that I've started to see this on 3.19 and I also
> have it on 4.0 kernel thus allow me to report it in this very thread.
> I had over month uptime, untill I've updated iwl ucode, maybe this was
> introduced not by kernel but firmware?. The lockups are random and
> result in hard system lockup, frozen Xorg, screen artifacts/glitches,
> audio playback keeps repeating last second or so of music, sysrq
> cannot handle it as well as auto-reboot after kernel panic does not
> kicks in.
>
I don't see how the ucode can cause crashes, but a new ucode can make
the driver behave differently (new APIs being available) and that can
cause crashes. Please share any logs you may have.
> The hardware I see this problem on is iwl 7260. The only workaround
> I've found so far was to disable power save via `iw dev wlan0 set
> power_save off` and not a single lockup since. What's rather
> disturbing is that by 'modinfo iwlwifi' it does say that power_save is
> default off, but it is not. I am sure that nothing else enables
> power_save on my system because I don't even have udev, and for the
> test I've also disabled wicd, then simple `modprobe iwlwifi` and `iw
> dev wlan0 get power_save` reports 'on'.
Yeah - I know. This is confusing. This module parameter doesn't affect
7260: it uses iwlmvm module which its own setting. iwlwifi's power_save
parameter serves older devices such as 6205 which you seem to have as
well.
In 6205's case, power save is disabled by default. But all this seems
very far away from the original thread.
>
> I also have another system iwl 6205 and no single lockup was noted,
> but it indeed have power_save disabled, so that may be the case.
>
> -- Piotr.
N�r��yb�X��ǧv�^�){.n�+{zX����ܨ}���Ơz�&j:+v���zZ+��+zf���h���~i���z� �w���?�&�)ߢf��^jǫy�m��@A�a���
0��h���i
Re: iwlwifi getting stuck with current Linus' tree (646da63172)
On Thu, 2015-04-23 at 10:15 +0200, Jiri Kosina wrote:
> On Thu, 23 Apr 2015, Grumbach, Emmanuel wrote:
>
> > > I've been running current Linus' tree and have been getting system
> > > lockups
> > > frequently. After a few "silent" lockups, I was able to obtain a dmesg
> > > before the machine turned dead again (wifi stopped working shortly before
> > > that).
> > >
> > > Before starting to debug / bisect (last known good on this machine is
> > > 4.0-rc6), I am attaching the dmesg in case someone already knows what the
> > > issue is.
> > >
> >
> > I briefly went over the iwlwifi commits between 4.0-rc6 and linux/master
> > and couldn't find anything obvious.
> > Note that for the device you have, the commits that touch
> > drivers/net/wireless/iwlwifi/mvm are not relevant.
> >
> > What you are seeing is that the PCI host is disconnecting the WiFi NIC
> > for some weird reason. It is not the first time I see that, but
> > unfortunately, I have never been able to debug this. I am personally not
> > a HW PCI expert and I couldn't reproduce either...
> >
> > I am afraid I won't save you the time of the bisection, but I am not
> > entirely sure that bisecting the iwlwifi driver is enough to find the
> > commit that broke it. You may want to bisect the pci bus driver as well.
>
> The problem is that I can't really reliably reproduce it; it happens
> rather often, but not so often that I could be certainly sure that my
> distinction of good and bad kernels would be accurate.
>
> I will try it, but I expect the result to be bogus because of this,
> unfortunately.
>
I can understand. A few users reported that this bug occurred more
reliably when moving their system, although it seems very weird to me.
> > First question is: Are you sure that 4.0-rc6 was good?
>
> Pretty much, yes. I've been running it for quite some time on this
> machine without any issues. But after updating to current HEAD two days
> ago, the issue triggered like 6 or 7 times already.
>
Ok - I will try to look at the PCI commits there although I am not sure
I'll be able to make much sense of them...
> Thanks,
>
N�r��yb�X��ǧv�^�){.n�+{zX����ܨ}���Ơz�&j:+v���zZ+��+zf���h���~i���z� �w���?�&�)ߢf��^jǫy�m��@A�a���
0��h���i
Re: iwlwifi getting stuck with current Linus' tree (646da63172)
Hi, On Wed, 2015-04-22 at 22:42 +0200, Jiri Kosina wrote: > Hi, > > I've been running current Linus' tree and have been getting system lockups > frequently. After a few "silent" lockups, I was able to obtain a dmesg > before the machine turned dead again (wifi stopped working shortly before > that). > > Before starting to debug / bisect (last known good on this machine is > 4.0-rc6), I am attaching the dmesg in case someone already knows what the > issue is. > I briefly went over the iwlwifi commits between 4.0-rc6 and linux/master and couldn't find anything obvious. Note that for the device you have, the commits that touch drivers/net/wireless/iwlwifi/mvm are not relevant. What you are seeing is that the PCI host is disconnecting the WiFi NIC for some weird reason. It is not the first time I see that, but unfortunately, I have never been able to debug this. I am personally not a HW PCI expert and I couldn't reproduce either... I am afraid I won't save you the time of the bisection, but I am not entirely sure that bisecting the iwlwifi driver is enough to find the commit that broke it. You may want to bisect the pci bus driver as well. First question is: Are you sure that 4.0-rc6 was good? Let me know if you find something. > iwlwifi :03:00.0: Error sending REPLY_ADD_STA: time out after 2000ms. > iwlwifi :03:00.0: Current CMD queue read_ptr 235 write_ptr 237 > iwlwifi :03:00.0: Loaded firmware version: 8.83.5.1 build 33692 > iwlwifi :03:00.0: Start IWL Error Log Dump: > iwlwifi :03:00.0: Status: 0x004C, count: -1 > iwlwifi :03:00.0: 0x | ADVANCED_SYSASSERT > iwlwifi :03:00.0: 0x | uPc > iwlwifi :03:00.0: 0x | branchlink1 > iwlwifi :03:00.0: 0x | branchlink2 > iwlwifi :03:00.0: 0x | interruptlink1 > iwlwifi :03:00.0: 0x | interruptlink2 > iwlwifi :03:00.0: 0x | data1 > iwlwifi :03:00.0: 0x | data2 > iwlwifi :03:00.0: 0x | line > iwlwifi :03:00.0: 0x | beacon time > iwlwifi :03:00.0: 0x | tsf low > iwlwifi :03:00.0: 0x | tsf hi > iwlwifi :03:00.0: 0x | time gp1 > iwlwifi :03:00.0: 0x | time gp2 > iwlwifi :03:00.0: 0x | time gp3 > iwlwifi :03:00.0: 0x | uCode version > iwlwifi :03:00.0: 0x | hw version > iwlwifi :03:00.0: 0x | board version > iwlwifi :03:00.0: 0x | hcmd > iwlwifi :03:00.0: 0x | isr0 > iwlwifi :03:00.0: 0x | isr1 > iwlwifi :03:00.0: 0x | isr2 > iwlwifi :03:00.0: 0x | isr3 > iwlwifi :03:00.0: 0x | isr4 > iwlwifi :03:00.0: 0x | isr_pref > iwlwifi :03:00.0: 0x | wait_event > iwlwifi :03:00.0: 0x | l2p_control > iwlwifi :03:00.0: 0x | l2p_duration > iwlwifi :03:00.0: 0x | l2p_mhvalid > iwlwifi :03:00.0: 0x | l2p_addr_match > iwlwifi :03:00.0: 0x | lmpm_pmg_sel > iwlwifi :03:00.0: 0x | timestamp > iwlwifi :03:00.0: 0x | flow_handler > iwlwifi :03:00.0: Log capacity -1 is bogus, limit to 256 entries > iwlwifi :03:00.0: Log write index -1 is bogus, limit to 256 > iwlwifi :03:00.0: Start IWL Event Log Dump: display last 20 entries > iwlwifi :03:00.0: EVT_LOGT:4294967295:0x:4294967295 > iwlwifi :03:00.0: EVT_LOGT:4294967295:0x:4294967295 > iwlwifi :03:00.0: EVT_LOGT:4294967295:0x:4294967295 > iwlwifi :03:00.0: EVT_LOGT:4294967295:0x:4294967295 > iwlwifi :03:00.0: EVT_LOGT:4294967295:0x:4294967295 > iwlwifi :03:00.0: EVT_LOGT:4294967295:0x:4294967295 > iwlwifi :03:00.0: EVT_LOGT:4294967295:0x:4294967295 > iwlwifi :03:00.0: EVT_LOGT:4294967295:0x:4294967295 > iwlwifi :03:00.0: EVT_LOGT:4294967295:0x:4294967295 > iwlwifi :03:00.0: EVT_LOGT:4294967295:0x:4294967295 > iwlwifi :03:00.0: EVT_LOGT:4294967295:0x:4294967295 > iwlwifi :03:00.0: EVT_LOGT:4294967295:0x:4294967295 > iwlwifi :03:00.0: EVT_LOGT:4294967295:0x:4294967295 > iwlwifi :03:00.0: EVT_LOGT:4294967295:0x:4294967295 > iwlwifi :03:00.0: EVT_LOGT:4294967295:0x:4294967295 > iwlwifi :03:00.0: EVT_LOGT:4294967295:0x:4294967295 > iwlwifi :03:00.0: EVT_LOGT:4294967295:0x:4294967295 > iwlwifi :03:00.0: EVT_LOGT:4294967295:0x:4294967295 > iwlwifi :03:00.0: EVT_LOGT:4294967295:0x:4294967295 > iwlwifi :03:00.0: EVT_LOGT:4294967295:0x:4294967295 > wlan0: HW problem - can not stop rx aggregation for 00:b0:0c:4e:a5:28 tid 0 > ieee80211 phy0: Hardware restart was requested > iwlwifi :03:00.0: iwl_trans_wait_tx_queue_empty bad state = 0 > iwlwifi :03:00.0: L1 Disabled - LTR Disabled > iwlwifi :03:00.0
RE: linux-next: manual merge of the ftrace tree with the net-next tree
>
> Hi Steven,
>
> Today's linux-next merge of the ftrace tree got a conflict in
> drivers/net/wireless/iwlwifi/iwl-devtrace.h between commit 7e1223b50089
> ("iwlwifi: mvm: new Alive / error table API") from the net-next tree and
> commit c5ef935d01a2 ("iwlwifi: Move each system tracepoints to their own
> header") from the ftrace tree.
>
> I fixed it up (see patch below, since this code was moved to a new file) and
> can carry the fix as necessary (no action is required).
Yes - So I was discussing that with Steven and you fixed it properly. Thank
your for that.
>
> From: Stephen Rothwell
> Date: Mon, 13 Apr 2015 17:21:30 +1000
> Subject: [PATCH] iwlwifi: mvm: fix up for tracing split
>
> Signed-off-by: Stephen Rothwell
> ---
> drivers/net/wireless/iwlwifi/iwl-devtrace-iwlwifi.h | 18 ++
> 1 file changed, 10 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/net/wireless/iwlwifi/iwl-devtrace-iwlwifi.h
> b/drivers/net/wireless/iwlwifi/iwl-devtrace-iwlwifi.h
> index 6cb66a988271..223b8752f924 100644
> --- a/drivers/net/wireless/iwlwifi/iwl-devtrace-iwlwifi.h
> +++ b/drivers/net/wireless/iwlwifi/iwl-devtrace-iwlwifi.h
> @@ -116,11 +116,11 @@ TRACE_EVENT(iwlwifi_dev_ucode_error,
> TP_PROTO(const struct device *dev, u32 desc, u32 tsf_low,
>u32 data1, u32 data2, u32 line, u32 blink1,
>u32 blink2, u32 ilink1, u32 ilink2, u32 bcon_time,
> - u32 gp1, u32 gp2, u32 gp3, u32 ucode_ver, u32 hw_ver,
> + u32 gp1, u32 gp2, u32 gp3, u32 major, u32 minor, u32
> hw_ver,
>u32 brd_ver),
> TP_ARGS(dev, desc, tsf_low, data1, data2, line,
> blink1, blink2, ilink1, ilink2, bcon_time, gp1, gp2,
> - gp3, ucode_ver, hw_ver, brd_ver),
> + gp3, major, minor, hw_ver, brd_ver),
> TP_STRUCT__entry(
> DEV_ENTRY
> __field(u32, desc)
> @@ -136,7 +136,8 @@ TRACE_EVENT(iwlwifi_dev_ucode_error,
> __field(u32, gp1)
> __field(u32, gp2)
> __field(u32, gp3)
> - __field(u32, ucode_ver)
> + __field(u32, major)
> + __field(u32, minor)
> __field(u32, hw_ver)
> __field(u32, brd_ver)
> ),
> @@ -155,21 +156,22 @@ TRACE_EVENT(iwlwifi_dev_ucode_error,
> __entry->gp1 = gp1;
> __entry->gp2 = gp2;
> __entry->gp3 = gp3;
> - __entry->ucode_ver = ucode_ver;
> + __entry->major = major;
> + __entry->minor = minor;
> __entry->hw_ver = hw_ver;
> __entry->brd_ver = brd_ver;
> ),
> TP_printk("[%s] #%02d %010u data 0x%08X 0x%08X line %u, "
> "blink 0x%05X 0x%05X ilink 0x%05X 0x%05X "
> - "bcon_tm %010u gp 0x%08X 0x%08X 0x%08X uCode 0x%08X
> "
> - "hw 0x%08X brd 0x%08X",
> + "bcon_tm %010u gp 0x%08X 0x%08X 0x%08X major 0x%08X
> "
> + "minor 0x%08X hw 0x%08X brd 0x%08X",
> __get_str(dev), __entry->desc, __entry->tsf_low,
> __entry->data1,
> __entry->data2, __entry->line, __entry->blink1,
> __entry->blink2, __entry->ilink1, __entry->ilink2,
> __entry->bcon_time, __entry->gp1, __entry->gp2,
> - __entry->gp3, __entry->ucode_ver, __entry->hw_ver,
> - __entry->brd_ver)
> + __entry->gp3, __entry->major, __entry->minor,
> + __entry->hw_ver, __entry->brd_ver)
> );
>
> TRACE_EVENT(iwlwifi_dev_ucode_event,
> --
> 2.1.4
>
> --
> Cheers,
> Stephen Rothwells...@canb.auug.org.au
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] iwlwifi: mvm: fix usage of debug specific variables
Hi,
On Wed, 2015-03-04 at 18:59 +0100, Alban Gruin wrote:
> Some variables in structs "iwl_mvm" and "iwl_mvm_vif" are used for debug
> purpose, and are declared only if CONFIG_IWLWIFI_DEBUGFS is
> set. However, some of these variables are used even if
> CONFIG_IWLWIFI_DEBUGFS is not set, resulting in a compilation error.
> This patch aims to fix this issue by adding a preprocessor condition
> where these variables are used.
>
oh well... thanks for the heads up.
Your patch is not perfect, but I'll fix the problems in our internal
tree and the fix will be pushed out soon.
Thanks!
> Signed-off-by: Alban Gruin
> ---
> drivers/net/wireless/iwlwifi/mvm/mac-ctxt.c | 4
> drivers/net/wireless/iwlwifi/mvm/phy-ctxt.c | 3 +++
> 2 files changed, 7 insertions(+)
> diff --git a/drivers/net/wireless/iwlwifi/mvm/mac-ctxt.c
> b/drivers/net/wireless/iwlwifi/mvm/mac-ctxt.c
> index 581b3b8..42bd545 100644
> --- a/drivers/net/wireless/iwlwifi/mvm/mac-ctxt.c
> +++ b/drivers/net/wireless/iwlwifi/mvm/mac-ctxt.c
> @@ -1375,10 +1375,12 @@ static void iwl_mvm_beacon_loss_iterator(void *_data,
> u8 *mac,
> {
> struct iwl_missed_beacons_notif *missed_beacons = _data;
> struct iwl_mvm_vif *mvmvif = iwl_mvm_vif_from_mac80211(vif);
> +#ifdef CONFIG_IWLWIFI_DEBUGFS
> struct iwl_mvm *mvm = mvmvif->mvm;
> struct iwl_fw_dbg_trigger_missed_bcon *bcon_trig;
> struct iwl_fw_dbg_trigger_tlv *trigger;
> u32 stop_trig_missed_bcon, stop_trig_missed_bcon_since_rx;
> +#endif
> u32 rx_missed_bcon, rx_missed_bcon_since_rx;
>
> if (mvmvif->id != (u16)le32_to_cpu(missed_beacons->mac_id))
> @@ -1395,6 +1397,7 @@ static void iwl_mvm_beacon_loss_iterator(void *_data,
> u8 *mac,
>IWL_MVM_MISSED_BEACONS_THRESHOLD)
> ieee80211_beacon_loss(vif);
>
> +#ifdef CONFIG_IWLWIFI_DEBUGFS
> if (!iwl_fw_dbg_trigger_enabled(mvm->fw,
> FW_DBG_TRIGGER_MISSED_BEACONS))
> return;
> @@ -1414,6 +1417,7 @@ static void iwl_mvm_beacon_loss_iterator(void *_data,
> u8 *mac,
> if (rx_missed_bcon_since_rx >= stop_trig_missed_bcon_since_rx ||
> rx_missed_bcon >= stop_trig_missed_bcon)
> iwl_mvm_fw_dbg_collect_trig(mvm, trigger, NULL, 0);
> +#endif
> }
>
> int iwl_mvm_rx_missed_beacons_notif(struct iwl_mvm *mvm,
> diff --git a/drivers/net/wireless/iwlwifi/mvm/phy-ctxt.c
> b/drivers/net/wireless/iwlwifi/mvm/phy-ctxt.c
> index 1bd10ed..850c72c 100644
> --- a/drivers/net/wireless/iwlwifi/mvm/phy-ctxt.c
> +++ b/drivers/net/wireless/iwlwifi/mvm/phy-ctxt.c
> @@ -175,8 +175,11 @@ static void iwl_mvm_phy_ctxt_cmd_data(struct iwl_mvm
> *mvm,
> cmd->rxchain_info |= cpu_to_le32(idle_cnt << PHY_RX_CHAIN_CNT_POS);
> cmd->rxchain_info |= cpu_to_le32(active_cnt <<
>PHY_RX_CHAIN_MIMO_CNT_POS);
> +
> +#ifdef CONFIG_IWLWIFI_DEBUGFS
> if (unlikely(mvm->dbgfs_rx_phyinfo))
> cmd->rxchain_info = cpu_to_le32(mvm->dbgfs_rx_phyinfo);
> +#endif
>
> cmd->txchain_info = cpu_to_le32(iwl_mvm_get_valid_tx_ant(mvm));
> }
N�r��yb�X��ǧv�^�){.n�+{zX����ܨ}���Ơz�&j:+v���zZ+��+zf���h���~i���z� �w���?�&�)ߢf��^jǫy�m��@A�a���
0��h���i
RE: [PATCH] Revert "cfg80211: make WEXT compatibility unselectable"
> > On Wed, 31 Dec 2014, Arend van Spriel wrote: > > > You mentioned in the discussion and I quote: "*If* wireless > > maintainers think otherwise, I'll send a revert request to Linus for > > consideration.". However, you did not wait for any response from the > > wireless maintainers nor from the author of the patch you are reverting. > > Seems like an overreaction to me though personally I do not disgree > > with the revert itself. > > My understanding from the whole thread was that Emmanuel disagrees with > the revert, and I consider Emmanuel to definitely belong to the "wireless > maintainers" group. If my understanding was wrong on this, sorry for that. You understanding is wrong. This patch has an author and you could I didn't sign-off the patch which is an obvious indication I am not a "wireless maintainer". You didn't even make the minimal effort to check how this patch should be properly routed. Regardless of all this, I didn't say I disagree, I said that we need to find a way to signal the userland developers that an API will be deprecated at some point. I haven't seen any response / suggestion from you on that. > > One way or another, the revert really is a-must-have, as it causes visible > userspace regressions. I am really surprised that it's causing so lively > discussion and doubts. > > -- > Jiri Kosina > SUSE Labs -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH] Revert "cfg80211: make WEXT compatibility unselectable"
> On 12/30/14 23:52, Jiri Kosina wrote: > > This reverts commit 24a0aa212ee2dbe44360288684478d76a8e20a0a. > > > > It's causing severe userspace breakage. Namely, all the utilities from > > wireless-utils which are relying on CONFIG_WEXT (which means tools > > like 'iwconfig', 'iwlist', etc) are not working anymore. There is a > > 'iw' utility in newer wireless-tools, which is supposed to be a > > replacement for all the "deprecated" binaries, but it's far away from > > being massively adopted. > > > > Please see [1] for example of the userspace breakage this is causing. > > > > In addition to that, Larry Finger reports [2] that this patch is also > > causing ipw2200 driver being impossible to build. > > > > To me this clearly shows that CONFIG_WEXT is far, far away from being > > "deprecated enough" to be removed. > > Hi Jiri, > > You mentioned in the discussion and I quote: "*If* wireless maintainers think > otherwise, I'll send a revert request to Linus for consideration.". However, > you did not wait for any response from the wireless maintainers nor from the > author of the patch you are reverting. > Seems like an overreaction to me though personally I do not disgree with the > revert itself. Not to mention the patch has already been applied on Linus's tree... > > Regards, > Arend > > > [1] http://thread.gmane.org/gmane.linux.kernel/1857010 > > [2] http://thread.gmane.org/gmane.linux.network/343688 > > > > Signed-off-by: Jiri Kosina > > --- > > net/wireless/Kconfig | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git a/net/wireless/Kconfig b/net/wireless/Kconfig index > > 22ba971..29c8675 100644 > > --- a/net/wireless/Kconfig > > +++ b/net/wireless/Kconfig > > @@ -175,7 +175,7 @@ config CFG80211_INTERNAL_REGDB > > Most distributions have a CRDA package. So if unsure, say N. > > > > config CFG80211_WEXT > > - bool > > + bool "cfg80211 wireless extensions compatibility" > > depends on CFG80211 > > select WEXT_CORE > > help -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: iwlwifi-driver card doesn't work with 3.19-rc2+
>
> On Tue, 30 Dec 2014, Larry Finger wrote:
>
> > > > If wireless maintainers think otherwise, I'll send a revert
> > > > request to Linus for consideration.
> > >
> > > I wonder if the reaction would be like this one:
> > >
> > > https://lkml.org/lkml/2012/12/23/75
> > >
> > > :-)
> >
> > It would be a little like that.
> >
> > One thread of interest is https://lkml.org/lkml/2014/12/22/348. Commit
> > 24a0aa212ee2 ("cfg80211: make WEXT compatibility unselectable") made
> > it impossible to select the IPW2200. The patch to allow selecting the
> > IPW2200, which automatically selects CFG80211_WEXT has been added to
> > wireless-drivers, but it has not yet made it to mainline. Once it
> > does, then choosing to build the IPW2200 will provide a workaround.
> >
> > In my opinion, the need for the IPW2200 to have CFG80211_WEXT means
> > that the original commit will likely be reverted, but your voice will help.
>
> Ok, thanks a lot for another datapoint. I am sending revert patch to Linus
> tonight.
>
I don't see this as another datapoint. All it means is that there are ancient
drivers
that won't work at all with newer tools and that are taken into consideration
while
trying to deprecate an API.
Now - basically all your argument is on Johannes's comment: "deprecated enough".
I think we have a chicken and egg problem here. We can't break things towards
userland.
Good. But we do want to deprecate this API because lots of valid purely
technical reasons.
Unfortunately, I don't see what we could do to send a strong signal to
userspace tools developers
to have them work / plan a move to a modern API.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH] Revert "cfg80211: make WEXT compatibility unselectable"
> Subject: [PATCH] Revert "cfg80211: make WEXT compatibility unselectable" > > This reverts commit 24a0aa212ee2dbe44360288684478d76a8e20a0a. > > It's causing severe userspace breakage. Namely, all the utilities from > wireless-utils which are relying on CONFIG_WEXT (which means tools like > 'iwconfig', 'iwlist', etc) are not working anymore. There is a 'iw' utility in > newer wireless-tools, which is supposed to be a replacement for all the > "deprecated" binaries, but it's far away from being massively adopted. > > Please see [1] for example of the userspace breakage this is causing. > > In addition to that, Larry Finger reports [2] that this patch is also causing > ipw2200 driver being impossible to build. > > To me this clearly shows that CONFIG_WEXT is far, far away from being > "deprecated enough" to be removed. > > [1] http://thread.gmane.org/gmane.linux.kernel/1857010 > [2] http://thread.gmane.org/gmane.linux.network/343688 > > Signed-off-by: Jiri Kosina Wait. I don't want to discuss the userspace API deprecation here but I do think that this patch should be applied to the proper tree if at all. The proper tree is mac80211.git. Now you are unhappy with what happens there and want to escalate - fine. But then, please do so following the natural hierarchy of the trees: net.git. Then mac80211.git's maintainer (Johannes) will be able to sync with your change more easily. Johannes doesn't need me as an advocate, but I feel that reverting a mac80211 patch in linux.git while we are only in -rc2 while everybody is on holiday leave is a bit unfair. > --- > net/wireless/Kconfig | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/net/wireless/Kconfig b/net/wireless/Kconfig index > 22ba971..29c8675 100644 > --- a/net/wireless/Kconfig > +++ b/net/wireless/Kconfig > @@ -175,7 +175,7 @@ config CFG80211_INTERNAL_REGDB > Most distributions have a CRDA package. So if unsure, say N. > > config CFG80211_WEXT > - bool > + bool "cfg80211 wireless extensions compatibility" > depends on CFG80211 > select WEXT_CORE > help > -- > Jiri Kosina > SUSE Labs -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: iwlwifi-driver card doesn't work with 3.19-rc2+
On Tue, 2014-12-30 at 16:21 +0100, Jiri Kosina wrote: > On Tue, 30 Dec 2014, Grumbach, Emmanuel wrote: > > > > > So why do you used them? > > > > They have been deprecated for a couple of years now. You should be > > > > using nl80211 based tools such as iw. > > > > > > A couple of years is not very long where userspace is concerned. > > > > > Well - the decently new wireless tools do talk nl80211. > > With 3.18-rc5, I get this: > > # iwconfig --version > iwconfig Wireless-Tools version 30 > Compatible with Wireless Extension v11 to v22. > > KernelCurrently compiled with Wireless Extension v22. > > wlan0 Recommend Wireless Extension v21 or later, > Currently compiled with Wireless Extension v22. > > > With 3.19-rc, I get (with the same userspace) this: > > # iwconfig --version > iwconfig Wireless-Tools version 30 > Compatible with Wireless Extension v11 to v22. > > Cannot read /proc/net/wireless > > And nothing else (iwlist, etc) works either. This is with > > # rpm -qi wireless-tools | grep Ver > Version : 30.pre9 > > from openSUSE 13.2. That's not decently new enough? > You should also have the iw tool which will provide all you need using the nl80211 interface which is now the preferred interface. > > You can still enable it (CFG80211_WEXT). > > It has been disabled by: > > > > commit 24a0aa212ee2dbe44360288684478d76a8e20a0a > > Author: Johannes Berg > > Date: Fri Nov 28 12:14:06 2014 +0100 > > > >cfg80211: make WEXT compatibility unselectable > > I think this needs to be reverted. >
RE: iwlwifi-driver card doesn't work with 3.19-rc2+
>
> On 12/30/2014 09:23 AM, Emmanuel Grumbach wrote:
> > On Tue, Dec 30, 2014 at 3:33 PM, Jiri Kosina wrote:
> >>
> >> Hi,
> >>
> >> I just booted current Linus' tree (5faa0154fe33) on my x200s
> >> thinkpad, and wifi doesn't work. iwconfig is telling me that wlan0
> >> interface has no wireless extensions.
> >>
> >
> > So why do you used them?
> > They have been deprecated for a couple of years now. You should be
> > using nl80211 based tools such as iw.
>
> A couple of years is not very long where userspace is concerned.
>
Well - the decently new wireless tools do talk nl80211.
You can still enable it (CFG80211_WEXT).
It has been disabled by:
commit 24a0aa212ee2dbe44360288684478d76a8e20a0a
Author: Johannes Berg
Date: Fri Nov 28 12:14:06 2014 +0100
cfg80211: make WEXT compatibility unselectable
N�r��yb�X��ǧv�^�){.n�+{zX����ܨ}���Ơz�&j:+v���zZ+��+zf���h���~i���z� �w���?�&�)ߢf��^jǫy�m��@A�a���
0��h���i
Re: [PATCH 12/27] iwlwifi: dvm: main: Use setup_timer
On Fri, 2014-12-26 at 15:35 +0100, Julia Lawall wrote: > Convert a call to init_timer and accompanying intializations of > the timer's data and function fields to a call to setup_timer. > > A simplified version of the semantic match that fixes this problem is as > follows: (http://coccinelle.lip6.fr/) > > // > @@ > expression t,f,d; > @@ > > -init_timer(&t); > +setup_timer(&t,f,d); > -t.data = d; > -t.function = f; > // > > Signed-off-by: Julia Lawall > Both applied - thanks.
Re: [iwlwifi] BUG: unable to handle kernel
On Thu, 2014-12-18 at 13:07 -0800, Fengguang Wu wrote:
> On Fri, Dec 19, 2014 at 03:42:17AM +0800, Grumbach, Emmanuel wrote:
> > On Thu, 2014-12-18 at 09:13 -0800, Fengguang Wu wrote:
> > > Hi All,
> > >
> > > I don't see any relationship between the BUG and this bisected commit.
> > > Anyway, it's better to report it to the lists than to ignore.
> >
> > Right - but I have to say that I have no clue how this comment can cause
> > the bug you are seeing...
>
> s?comment?commit?
>
Yes :)
> > Do you even have an Intel Wireless device the VM could access?
>
> Nope. It's simple QEMU virtual machine boot test.
>
In that case - this just can't be right... Don't know what to say...
> Thanks,
> Fengguang
>
> > >
> > > git://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/iwlwifi-fixes.git
> > > master
> > >
> > > commit 03d6c3b0fa4f5f0379cede079ec828a6c999fe43
> > > Author: Emmanuel Grumbach
> > > AuthorDate: Wed Dec 3 10:39:07 2014 +0200
> > > Commit: Emmanuel Grumbach
> > > CommitDate: Sun Dec 14 10:20:29 2014 +0200
> > >
> > > iwlwifi: pcie: re-ACK all interrupts after device reset
> > >
> > > When we reset the device, the CSR_INT gets cleared as well
> > > as CSR_INT_MASK. Meaning that we shouldn't get any interrupt
> > > but, due to a hardware bug, recent devices will keep sending
> > > interrupts. This leads to an interrupt storm while stopping
> > > the device.
> > > The way to fix this is to ACK all the interrupts after the
> > > device is reset so that the value of CSR_INT will stay
> > > 0x.
> > >
> > > Fixes: 522713c81e4e ("iwlwifi: pcie: properly reset the device")
> > > Signed-off-by: Emmanuel Grumbach
> > >
> > > +--++++
> > > | | 0a79a0c011 | 03d6c3b0fa |
> > > iwlwifi-fi |
> > > +--++++
> > > | boot_successes | 60 | 19 | 3
> > > |
> > > | boot_failures| 0 | 1 | 9
> > > |
> > > | BUG:unable_to_handle_kernel | 0 | 1 | 9
> > > |
> > > | Oops | 0 | 1 | 9
> > > |
> > > | RIP:strcmp | 0 | 1 | 9
> > > |
> > > | Kernel_panic-not_syncing:Fatal_exception | 0 | 1 | 9
> > > |
> > > | backtrace:led_trigger_register_simple| 0 | 1 | 9
> > > |
> > > | backtrace:ledtrig_usb_init | 0 | 1 | 9
> > > |
> > > | backtrace:kernel_init_freeable | 0 | 1 | 9
> > > |
> > > +--++++
> > >
> > > [5.345018] g_serial gadget: Gadget Serial v2.4
> > > [5.345927] g_serial gadget: g_serial ready
> > > [5.345927] g_serial gadget: g_serial ready
> > > [5.346777] BUG: unable to handle kernel
> > > [5.346777] BUG: unable to handle kernel paging requestpaging request
> > > at 8804e5f0
> > > at 8804e5f0
> > > [5.348183] IP:
> > > [5.348183] IP: [] strcmp+0x6/0x20
> > > [] strcmp+0x6/0x20
> > > [5.349183] PGD 37f1067
> > > [5.349183] PGD 37f1067 PUD 37f2067 PUD 37f2067 PMD 37f3067 PMD
> > > 37f3067 PTE 8004e060PTE 8004e060
> > >
> > > [5.350498] Oops: [#1]
> > > [5.350498] Oops: [#1] DEBUG_PAGEALLOCDEBUG_PAGEALLOC
> > >
> > > [5.351360] CPU: 0 PID: 1 Comm: swapper Not tainted 3.18.0-g03d6c3b #1
> > > [5.351360] CPU: 0 PID: 1 Comm: swapper Not tainted 3.18.0-g03d6c3b #1
> > > [5.352660] task: 88001206 ti: 88001204c000 task.ti:
> > > 88001204c000
> > > [5.352660] task: 88001206 ti: 88001204c000 task.ti:
> > > 88001204c000
> > > [5.354143] RIP: 0010:[]
> > > [5.354143] RIP: 0010:[] []
> > > strcmp+0x6/0x20
> > > [] strcmp+0x6/0x20
>
Re: [iwlwifi] BUG: unable to handle kernel
On Thu, 2014-12-18 at 09:13 -0800, Fengguang Wu wrote:
> Hi All,
>
> I don't see any relationship between the BUG and this bisected commit.
> Anyway, it's better to report it to the lists than to ignore.
Right - but I have to say that I have no clue how this comment can cause
the bug you are seeing...
Do you even have an Intel Wireless device the VM could access?
>
> git://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/iwlwifi-fixes.git master
>
> commit 03d6c3b0fa4f5f0379cede079ec828a6c999fe43
> Author: Emmanuel Grumbach
> AuthorDate: Wed Dec 3 10:39:07 2014 +0200
> Commit: Emmanuel Grumbach
> CommitDate: Sun Dec 14 10:20:29 2014 +0200
>
> iwlwifi: pcie: re-ACK all interrupts after device reset
>
> When we reset the device, the CSR_INT gets cleared as well
> as CSR_INT_MASK. Meaning that we shouldn't get any interrupt
> but, due to a hardware bug, recent devices will keep sending
> interrupts. This leads to an interrupt storm while stopping
> the device.
> The way to fix this is to ACK all the interrupts after the
> device is reset so that the value of CSR_INT will stay
> 0x.
>
> Fixes: 522713c81e4e ("iwlwifi: pcie: properly reset the device")
> Signed-off-by: Emmanuel Grumbach
>
> +--++++
> | | 0a79a0c011 | 03d6c3b0fa |
> iwlwifi-fi |
> +--++++
> | boot_successes | 60 | 19 | 3
> |
> | boot_failures| 0 | 1 | 9
> |
> | BUG:unable_to_handle_kernel | 0 | 1 | 9
> |
> | Oops | 0 | 1 | 9
> |
> | RIP:strcmp | 0 | 1 | 9
> |
> | Kernel_panic-not_syncing:Fatal_exception | 0 | 1 | 9
> |
> | backtrace:led_trigger_register_simple| 0 | 1 | 9
> |
> | backtrace:ledtrig_usb_init | 0 | 1 | 9
> |
> | backtrace:kernel_init_freeable | 0 | 1 | 9
> |
> +--++++
>
> [5.345018] g_serial gadget: Gadget Serial v2.4
> [5.345927] g_serial gadget: g_serial ready
> [5.345927] g_serial gadget: g_serial ready
> [5.346777] BUG: unable to handle kernel
> [5.346777] BUG: unable to handle kernel paging requestpaging request at
> 8804e5f0
> at 8804e5f0
> [5.348183] IP:
> [5.348183] IP: [] strcmp+0x6/0x20
> [] strcmp+0x6/0x20
> [5.349183] PGD 37f1067
> [5.349183] PGD 37f1067 PUD 37f2067 PUD 37f2067 PMD 37f3067 PMD 37f3067
> PTE 8004e060PTE 8004e060
>
> [5.350498] Oops: [#1]
> [5.350498] Oops: [#1] DEBUG_PAGEALLOCDEBUG_PAGEALLOC
>
> [5.351360] CPU: 0 PID: 1 Comm: swapper Not tainted 3.18.0-g03d6c3b #1
> [5.351360] CPU: 0 PID: 1 Comm: swapper Not tainted 3.18.0-g03d6c3b #1
> [5.352660] task: 88001206 ti: 88001204c000 task.ti:
> 88001204c000
> [5.352660] task: 88001206 ti: 88001204c000 task.ti:
> 88001204c000
> [5.354143] RIP: 0010:[]
> [5.354143] RIP: 0010:[] []
> strcmp+0x6/0x20
> [] strcmp+0x6/0x20
> [5.354451] RSP: :88001204fe28 EFLAGS: 00010246
> [5.354451] RSP: :88001204fe28 EFLAGS: 00010246
> [5.354451] RAX: RBX: 88000c08fe00 RCX:
> 81d35310
> [5.354451] RAX: RBX: 88000c08fe00 RCX:
> 81d35310
> [5.354451] RDX: 88000c08fe68 RSI: 826d05be RDI:
> 8804e5f0
> [5.354451] RDX: 88000c08fe68 RSI: 826d05be RDI:
> 8804e5f0
> [5.354451] RBP: 88001204fe28 R08: 0001 R09:
> 033a
> [5.354451] RBP: 88001204fe28 R08: 0001 R09:
> 033a
> [5.354451] R10: R11: 82531cd1 R12:
> 88000c19fa00
> [5.354451] R10: R11: 82531cd1 R12:
> 88000c19fa00
> [5.354451] R13: R14: 837958b8 R15:
>
> [5.354451] R13: R14: 837958b8 R15:
>
> [5.354451] FS: () GS:82789000()
> knlGS:
> [5.354451] FS: () GS:82789000()
> knlGS:
> [5.354451] CS: 0010 DS: ES: CR0: 8005003b
> [5.354451] CS: 0010 DS: ES: CR0: 8005003b
> [5.354451] CR2: 8804e5f0 CR3: 02776000 CR4:
> 06b0
> [5.354451] CR2: 8804e5f0 CR3: 02776000 CR4:
> 0
RE: [PATCH 07/11] iwlwifi: dvm: Fix probable mask then right shift defect
> > Precedence of & and >> is not the same and is not left to right. > shift has higher precedence and should be done after the mask. > > Add parentheses around the mask. > > Signed-off-by: Joe Perches > --- Applied - thanks. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [Ilw] WARNING: drivers/net/wireless/iwlwifi/mvm/tx.c:197 iwl_mvm_set_tx_params+0x5f4/0x630 [iwlmvm]()
> Hi,
>
> on recent Linus git, I regulary get the following backtrace (since 3.17 around
> or so).
> HW is Intel Corporation Wireless 7260 (rev 83)
>
> [ 1774.340980] [ cut here ]
> [ 1774.341003] WARNING: CPU: 2 PID: 2402 at
> /home/arnd/Projekte/kernel/linux-
> 2.6/drivers/net/wireless/iwlwifi/mvm/tx.c:197
> iwl_mvm_set_tx_params+0x5f4/0x630 [iwlmvm]()
Yep - fix is in my tree already.
> [ 1774.341004] Got an HT rate for a non data frame 0x8
> [ 1774.341005] Modules linked in: ccm xt_CHECKSUM iptable_mangle
> xt_tcpudp bridge stp llc ip6table_filter ip6_tables iptable_filter ip_tables
> ebtable_nat ebtables x_tables dm_crypt cdc_ncm uvcvideo usbnet
> videobuf2_vmalloc videobuf2_memops mii videobuf2_core cdc_wdm
> cdc_acm v4l2_common videodev media btusb deflate ctr twofish_generic
> twofish_x86_64_3way twofish_x86_64 twofish_common camellia_generic
> camellia_x86_64 serpent_sse2_x86_64 serpent_generic xts blowfish_generic
> blowfish_x86_64 blowfish_common cast5_generic cast_common
> des3_ede_x86_64 des_generic cmac xcbc rmd160 sha512_generic
> crypto_null af_key xfrm_algo rfcomm bnep bluetooth arc4 binfmt_misc
> snd_hda_codec_realtek snd_hda_codec_generic snd_hda_codec_hdmi
> x86_pkg_temp_thermal coretemp kvm_intel dm_multipath kvm
> ghash_clmulni_intel aesni_intel aes_x86_64 ablk_helper cryptd lrw gf128mul
> glue_helper snd_hda_intel microcode snd_hda_controller joydev serio_raw
> iwlmvm snd_hda_codec lpc_ich mac80211 snd_hwdep wmi thinkpad_
> acpi nvra
> m tpm_tis snd_pcm iwlwifi cfg80211 snd_seq_midi snd_seq_midi_event
> snd_rawmidi snd_seq snd_seq_device snd_timer snd xhci_pci xhci_hcd
> soundcore btrfs xor raid6_pq rtsx_pci_sdmmc rtsx_pci psmouse i915
> i2c_algo_bit drm_kms_helper ahci libahci e1000e ptp drm pps_core video
> [ 1774.341060] CPU: 2 PID: 2402 Comm: wpa_supplicant Tainted: P
> 3.18.0-rc1aha+ #1
> [ 1774.341061] Hardware name: LENOVO 20AQCTO1WW/20AQCTO1WW,
> BIOS GJET79WW (2.29 ) 09/03/2014
> [ 1774.341063] 0009 880302b93728 8168e85a
>
> [ 1774.341065] 880302b93778 880302b93768 8104c5d1
> 880302b937d8
> [ 1774.341067] 8802e4a82480 8800a520b026
> 88030d7f9a88
> [ 1774.341069] Call Trace:
> [ 1774.341074] [] dump_stack+0x46/0x58
> [ 1774.341078] [] warn_slowpath_common+0x81/0xa0
> [ 1774.341080] [] warn_slowpath_fmt+0x46/0x50
> [ 1774.341089] [] iwl_mvm_set_tx_params+0x5f4/0x630
> [iwlmvm]
> [ 1774.341095] [] iwl_mvm_tx_skb+0x54/0x350 [iwlmvm]
> [ 1774.341101] [] iwl_mvm_mac_tx+0xaf/0x1b0 [iwlmvm]
> [ 1774.341104] [] ? put_online_cpus+0x56/0x80
> [ 1774.341120] [] __ieee80211_tx+0x271/0x380 [mac80211]
> [ 1774.341133] [] ieee80211_tx+0xca/0x100 [mac80211]
> [ 1774.341144] [] ieee80211_xmit+0xa1/0x100 [mac80211]
> [ 1774.341155] []
> ieee80211_subif_start_xmit+0x66a/0xd10 [mac80211]
> [ 1774.341160] [] dev_hard_start_xmit+0x169/0x3d0
> [ 1774.341163] [] sch_direct_xmit+0xe2/0x1e0
> [ 1774.341166] [] __dev_queue_xmit+0x247/0x560
> [ 1774.341168] [] dev_queue_xmit+0x10/0x20
> [ 1774.341171] [] packet_sendmsg+0xe8d/0x1130
> [ 1774.341174] [] ? sock_recvmsg+0xa2/0xd0
> [ 1774.341176] [] sock_sendmsg+0x93/0xd0
> [ 1774.341179] [] ? evict+0x110/0x180
> [ 1774.341182] [] ? __d_free+0x2b/0x50
> [ 1774.341185] [] ? __fdget+0x13/0x20
> [ 1774.341187] [] SYSC_sendto+0x121/0x1c0
> [ 1774.341189] [] ? __sys_recvmsg+0x42/0x80
> [ 1774.341192] [] SyS_sendto+0xe/0x10
> [ 1774.341194] [] system_call_fastpath+0x12/0x17
> [ 1774.341195] ---[ end trace f25bbefa3f5a7aa1 ]---
>
N�r��yb�X��ǧv�^�){.n�+{zX����ܨ}���Ơz�&j:+v���zZ+��+zf���h���~i���z� �w���?�&�)ߢf��^jǫy�m��@A�a���
0��h���i
RE: 3.18-rc0: iwlegacy failed after a while
[Changed subject] This is really iwlegacy and not iwlwifi. > > Hi! > > Full dmesg is in the attachment, I guess the troubles started with: > > iwl3945 :03:00.0: Queue 4 stuck for 2004 ms. > iwl3945 :03:00.0: On demand firmware reload > iwl3945 :03:00.0: Master Disable Timed Out, 100 usec > ieee80211 phy0: Hardware restart was requested > iwl3945 :03:00.0: BSM uCode verification failed at addr > 0x3800+0 (of 900), is 0xa5\ > a5a5a2, s/b 0xf802020 > iwl3945 :03:00.0: Unable to set up bootstrap uCode: -5 > > Best regards, > Pavel > > -- Huh - I don't remember any change there, but you should ask the right person - iwlegacy maintainer :) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH 3.11 005/137] iwlwifi: dvm: don't enable CTS to self
> > On Sun, Aug 31, 2014 at 12:04:19PM +, Grumbach, Emmanuel wrote: > > > -Original Message- > > > From: Luis Henriques [mailto:luis.henriq...@canonical.com] > > > Sent: Monday, August 18, 2014 12:31 PM > > > To: linux-kernel@vger.kernel.org; sta...@vger.kernel.org; kernel- > > > t...@lists.ubuntu.com > > > Cc: Grumbach, Emmanuel; Luis Henriques > > > Subject: [PATCH 3.11 005/137] iwlwifi: dvm: don't enable CTS to self > > > > > > 3.11.10.15 -stable review patch. If anyone has any objections, > > > please let me know. > > > > Just came back from a long travel - please drop this one. It has caused > trouble to people. > > I need to revert it. > > > > Thank you for your feedback, Emmanuel. > > Unfortunately, this kernel has been released already and no more updates > are foreseen to the 3.11 extended kernel -- this was its last release. > Ok - I just pushed the revert to my tree and sent a pull request. > Cheers, > -- > Luís > > > > > > > -- > > > > > > From: Emmanuel Grumbach > > > > > > commit 43d826ca5979927131685cc2092c7ce862cb91cd upstream. > > > > > > We should always prefer to use full RTS protection. Using CTS to > > > self gives a meaningless improvement, but this flow is much harder > > > for the firmware which is likely to have issues with it. > > > > > > Signed-off-by: Emmanuel Grumbach > > > Signed-off-by: Luis Henriques > > > --- > > > drivers/net/wireless/iwlwifi/dvm/rxon.c | 12 > > > 1 file changed, 12 deletions(-) > > > > > > diff --git a/drivers/net/wireless/iwlwifi/dvm/rxon.c > > > b/drivers/net/wireless/iwlwifi/dvm/rxon.c > > > index cd1ad0019185..ca17e4c9eca2 100644 > > > --- a/drivers/net/wireless/iwlwifi/dvm/rxon.c > > > +++ b/drivers/net/wireless/iwlwifi/dvm/rxon.c > > > @@ -1072,13 +1072,6 @@ int iwlagn_commit_rxon(struct iwl_priv *priv, > > > struct iwl_rxon_context *ctx) > > > /* recalculate basic rates */ > > > iwl_calc_basic_rates(priv, ctx); > > > > > > - /* > > > - * force CTS-to-self frames protection if RTS-CTS is not preferred > > > - * one aggregation protection method > > > - */ > > > - if (!priv->hw_params.use_rts_for_aggregation) > > > - ctx->staging.flags |= RXON_FLG_SELF_CTS_EN; > > > - > > > if ((ctx->vif && ctx->vif->bss_conf.use_short_slot) || > > > !(ctx->staging.flags & RXON_FLG_BAND_24G_MSK)) > > > ctx->staging.flags |= RXON_FLG_SHORT_SLOT_MSK; @@ - > > > 1484,11 +1477,6 @@ void iwlagn_bss_info_changed(struct ieee80211_hw > > > *hw, > > > else > > > ctx->staging.flags &= ~RXON_FLG_TGG_PROTECT_MSK; > > > > > > - if (bss_conf->use_cts_prot) > > > - ctx->staging.flags |= RXON_FLG_SELF_CTS_EN; > > > - else > > > - ctx->staging.flags &= ~RXON_FLG_SELF_CTS_EN; > > > - > > > memcpy(ctx->staging.bssid_addr, bss_conf->bssid, ETH_ALEN); > > > > > > if (vif->type == NL80211_IFTYPE_AP || > > > -- > > > 1.9.1 > > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH 3.11 005/137] iwlwifi: dvm: don't enable CTS to self
> -Original Message- > From: Luis Henriques [mailto:luis.henriq...@canonical.com] > Sent: Monday, August 18, 2014 12:31 PM > To: linux-kernel@vger.kernel.org; sta...@vger.kernel.org; kernel- > t...@lists.ubuntu.com > Cc: Grumbach, Emmanuel; Luis Henriques > Subject: [PATCH 3.11 005/137] iwlwifi: dvm: don't enable CTS to self > > 3.11.10.15 -stable review patch. If anyone has any objections, please let me > know. Just came back from a long travel - please drop this one. It has caused trouble to people. I need to revert it. > > -- > > From: Emmanuel Grumbach > > commit 43d826ca5979927131685cc2092c7ce862cb91cd upstream. > > We should always prefer to use full RTS protection. Using CTS to self gives a > meaningless improvement, but this flow is much harder for the firmware > which is likely to have issues with it. > > Signed-off-by: Emmanuel Grumbach > Signed-off-by: Luis Henriques > --- > drivers/net/wireless/iwlwifi/dvm/rxon.c | 12 > 1 file changed, 12 deletions(-) > > diff --git a/drivers/net/wireless/iwlwifi/dvm/rxon.c > b/drivers/net/wireless/iwlwifi/dvm/rxon.c > index cd1ad0019185..ca17e4c9eca2 100644 > --- a/drivers/net/wireless/iwlwifi/dvm/rxon.c > +++ b/drivers/net/wireless/iwlwifi/dvm/rxon.c > @@ -1072,13 +1072,6 @@ int iwlagn_commit_rxon(struct iwl_priv *priv, > struct iwl_rxon_context *ctx) > /* recalculate basic rates */ > iwl_calc_basic_rates(priv, ctx); > > - /* > - * force CTS-to-self frames protection if RTS-CTS is not preferred > - * one aggregation protection method > - */ > - if (!priv->hw_params.use_rts_for_aggregation) > - ctx->staging.flags |= RXON_FLG_SELF_CTS_EN; > - > if ((ctx->vif && ctx->vif->bss_conf.use_short_slot) || > !(ctx->staging.flags & RXON_FLG_BAND_24G_MSK)) > ctx->staging.flags |= RXON_FLG_SHORT_SLOT_MSK; @@ - > 1484,11 +1477,6 @@ void iwlagn_bss_info_changed(struct ieee80211_hw > *hw, > else > ctx->staging.flags &= ~RXON_FLG_TGG_PROTECT_MSK; > > - if (bss_conf->use_cts_prot) > - ctx->staging.flags |= RXON_FLG_SELF_CTS_EN; > - else > - ctx->staging.flags &= ~RXON_FLG_SELF_CTS_EN; > - > memcpy(ctx->staging.bssid_addr, bss_conf->bssid, ETH_ALEN); > > if (vif->type == NL80211_IFTYPE_AP || > -- > 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [patch] iwlwifi: fix Kconfig option continuity
> > On 07/06/2014 10:11 AM, Larry Finger wrote: > > A problem with configuration of IWLWIFI has been bisected to commit > 48e2934, where a new section was added to > drivers/net/wireless/iwlwifi/Kconfig with the following code: > > > > # don't call it _MODULE -- will confuse Kconfig/fixdep/... > > config IWLWIFI_OPMODE_MODULAR > > bool > > default y if IWLDVM=m > > default y if IWLMVM=m > > > > When the above section is present, 'make xconfig' fails to show a > "Debugging options" menu' even though 'make menuconfig' displays > correctly. despite the incorrect on-screen display, xconfig does not delete > the affected info in .config after it was set by menuconfig, thus the bug only > seems to affect the display in xconfig. > > > > Is there anything wrong with that section in iwlwifi's Kconfig, or is it a > > bug in > xconfig? > > in menuconfig or nconfig: > Notice that 'Debugging options' is not indented under iwlwifi, but listed at > the same indent level. That is a huge clue. > > > in xconfig: > The 'Debugging options' menu is displayed, but it's not where you expect or > want it to be found. Look under 'Wireless LAN' and immediately under > 'Atheros Wireless Cards' > and it says 'Debugging options' (on the left panel). Then the debugging > options are displayed in the right hand panel. > > This is a common problem. I have made Kconfig patches for it several times. > Here is another one. Works for me. > > --- > Fix iwlwifi options so that they all depend on IWLWIFI and are displayed > under the iwlwifi driver instead of in other unexpected places. > > Signed-off-by: Randy Dunlap > Reported-by: Larry Finger > --- Thanks for the patch. I'll add a commit message and submit it. > drivers/net/wireless/iwlwifi/Kconfig | 17 - > 1 file changed, 8 insertions(+), 9 deletions(-) > > Index: lnx-316-rc3/drivers/net/wireless/iwlwifi/Kconfig > == > = > --- lnx-316-rc3.orig/drivers/net/wireless/iwlwifi/Kconfig > +++ lnx-316-rc3/drivers/net/wireless/iwlwifi/Kconfig > @@ -39,9 +39,10 @@ config IWLWIFI > say M here and read . > The > module will be called iwlwifi. > > +if IWLWIFI > + > config IWLWIFI_LEDS > bool > - depends on IWLWIFI > depends on LEDS_CLASS=y || LEDS_CLASS=IWLWIFI > select LEDS_TRIGGERS > select MAC80211_LEDS > @@ -49,7 +50,6 @@ config IWLWIFI_LEDS > > config IWLDVM > tristate "Intel Wireless WiFi DVM Firmware support" > - depends on IWLWIFI > default IWLWIFI > help > This is the driver that supports the DVM firmware which is @@ -58,7 > +58,6 @@ config IWLDVM > > config IWLMVM > tristate "Intel Wireless WiFi MVM Firmware support" > - depends on IWLWIFI > help > This is the driver that supports the MVM firmware which is > currently only available for 7260 and 3160 devices. > @@ -70,7 +69,7 @@ config IWLWIFI_OPMODE_MODULAR > default y if IWLMVM=m > > comment "WARNING: iwlwifi is useless without IWLDVM or IWLMVM" > - depends on IWLWIFI && IWLDVM=n && IWLMVM=n > + depends on IWLDVM=n && IWLMVM=n > > config IWLWIFI_BCAST_FILTERING > bool "Enable broadcast filtering" > @@ -86,11 +85,9 @@ config IWLWIFI_BCAST_FILTERING > expect incoming broadcasts for their normal operations. > > menu "Debugging Options" > - depends on IWLWIFI > > config IWLWIFI_DEBUG > bool "Enable full debugging output in the iwlwifi driver" > - depends on IWLWIFI > ---help--- > This option will enable debug tracing output for the iwlwifi drivers > > @@ -115,7 +112,7 @@ config IWLWIFI_DEBUG > > config IWLWIFI_DEBUGFS > bool "iwlwifi debugfs support" > -depends on IWLWIFI && MAC80211_DEBUGFS > +depends on MAC80211_DEBUGFS > ---help--- > Enable creation of debugfs files for the iwlwifi drivers. This > is a low-impact option that allows getting insight into the @@ - > 123,13 +120,12 @@ config IWLWIFI_DEBUGFS > > config IWLWIFI_DEBUG_EXPERIMENTAL_UCODE > bool "Experimental uCode support" > -depends on IWLWIFI && IWLWIFI_DEBUG > +depends on IWLWIFI_DEBUG > ---help--- > Enable use of experimental ucode for testing and debugging. > > config IWLWIFI_DEVICE_TRACING > bool "iwlwifi device access tracing" > - depends on IWLWIFI > depends on EVENT_TRACING > help > Say Y here to trace all commands, including TX frames and IO @@ - > 144,4 +140,7 @@ config IWLWIFI_DEVICE_TRACING > > If unsure, say Y so we can help you better when problems > occur. > + > endmenu > + > +endif -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH] drivers/net/wireless: Use RCU_INIT_POINTER(x, NULL) in iwlwifi/mvm/sta.c
> > This patch replaces rcu_assign_pointer(x, NULL) with RCU_INIT_POINTER(x, > NULL) > > The rcu_assign_pointer() ensures that the initialization of a structure > is carried out before storing a pointer to that structure. > And in the case of the NULL pointer, there is no structure to initialize. > So, rcu_assign_pointer(p, NULL) can be safely converted to > RCU_INIT_POINTER(p, NULL) > > Signed-off-by: Monam Agarwal > --- > drivers/net/wireless/iwlwifi/mvm/sta.c |8 > 1 file changed, 4 insertions(+), 4 deletions(-) > Applied - with small change in commit log. Thank you for your contribution. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: Re: [PATCH 3.4 93/99] iwlwifi: always copy first 16 bytes of commands
> On Sat, 2014-03-22 at 09:51 -0700, Greg Kroah-Hartman wrote: > > On Sat, Mar 22, 2014 at 05:28:02PM +0100, Andreas Sturmlechner wrote: > > > Original Message from: Greg Kroah-Hartman > > > > > > > > > > > Does Linus's tree also have this problem for you? Or does it work > > > > there? If it works there, perhaps we just missed backporting > > > > something to 3.4? > > > > > > > > > > Other trouble aside, iwlwifi works fine - writing this from today's > > > build of 3.14.0-rc7+. > > > > Hm. Any linux-wifi developers have an idea? I can always just revert > > this patch, but finding out the root cause would be nice... Reverting the patch is obviously the first thing to do. Finding the root would be nice but I am afraid the time won't allow it... In any case, this patch is meant to avoid a few DMAR fault and possibly some calibration mismatch upon suspend resume. Nothing critical in my eyes. > > Andreas, could you test whether this regression is also present in 3.2.55? > This patch is based on my backport for 3.2.y. > > Ben. > > -- > Ben Hutchings > I'm not a reverse psychological virus. Please don't copy me into your sig.
RE: linux-next: build failure after merge of the final tree (wireless-next tree related)
>
> Hi all,
>
> After merging the final tree, today's linux-next build (powerpc allyesconfig)
> failed like this:
>
> drivers/net/wireless/iwlwifi/mvm/debugfs.c: In function
> 'iwl_dbgfs_fw_error_dump_release':
> drivers/net/wireless/iwlwifi/mvm/debugfs.c:161:2: error: implicit declaration
> of function 'vfree' [-Werror=implicit-function-declaration]
> vfree(file->private_data);
> ^
Sorry for that - patch on the way.
>
> Caused by commit 1bd3cbc1a0e9 ("iwlwifi: mvm: send udev event upon
> firmware error to dump logs") from the wireless-next tree. See Rule 1
> from Documentation/SubmitChecklist.
>
> I have reverted that commit (and commit cdb00563fe2c ("iwlwifi: mvm: BT
> Coex - add debugfs hook to set BT Tx priority") that may depend on it)
> for today.
> --
> Cheers,
> Stephen Rothwells...@canb.auug.org.au
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: wlwifi - Microcode SW error detected.
> > Hi, > I am not sure who to report this issue so please let me know if this is > not a proper channel. > > My dmesg claims the following: > [14921.841475] iwlwifi :02:00.0: RF_KILL bit toggled to enable radio. > [14922.178602] usb 1-1.4: new full-speed USB device number 5 using ehci-pci > [14922.275384] usb 1-1.4: New USB device found, idVendor=413c, > idProduct=8187 > [14922.275408] usb 1-1.4: New USB device strings: Mfr=1, Product=2, > SerialNumber=3 > [14922.275410] usb 1-1.4: Product: DW375 Bluetooth Module > [14922.275412] usb 1-1.4: Manufacturer: Dell Computer Corp > [14922.275413] usb 1-1.4: SerialNumber: 446D57C904C4 > [14922.913064] atkbd serio0: Unknown key pressed (translated set 2, code > 0x88 on isa0060/serio0). > [14922.913069] atkbd serio0: Use 'setkeycodes e008 ' to make it > known. > [14922.913116] iwlwifi :02:00.0: RF_KILL bit toggled to disable radio. > [14923.002924] usb 1-1.4: USB disconnect, device number 5 > [14923.112880] iwlwifi :02:00.0: Microcode SW error detected. > Restarting 0x200. > [14923.112887] iwlwifi :02:00.0: CSR values: > [14923.112888] iwlwifi :02:00.0: (2nd byte of CSR_INT_COALESCING is > CSR_INT_PERIODIC_REG) > [14923.112918] iwlwifi :02:00.0:CSR_HW_IF_CONFIG_REG: > 0X0048d304 > [14923.112944] iwlwifi :02:00.0: CSR_INT_COALESCING: 0X0040 > [14923.112969] iwlwifi :02:00.0: CSR_INT: 0X > [14923.112995] iwlwifi :02:00.0:CSR_INT_MASK: 0X > [14923.113020] iwlwifi :02:00.0: CSR_FH_INT_STATUS: 0X > [14923.113046] iwlwifi :02:00.0: CSR_GPIO_IN: 0X000f > [14923.113071] iwlwifi :02:00.0: CSR_RESET: 0X > [14923.113097] iwlwifi :02:00.0:CSR_GP_CNTRL: 0X000403c5 > [14923.113123] iwlwifi :02:00.0: CSR_HW_REV: 0X0074 > [14923.113149] iwlwifi :02:00.0: CSR_EEPROM_REG: 0Xf5130ffd > [14923.113174] iwlwifi :02:00.0: CSR_EEPROM_GP: 0X9001 > [14923.113200] iwlwifi :02:00.0: CSR_OTP_GP_REG: 0X00030001 > [14923.113226] iwlwifi :02:00.0: CSR_GIO_REG: 0X00080042 > [14923.113251] iwlwifi :02:00.0:CSR_GP_UCODE_REG: 0X001f > [14923.113277] iwlwifi :02:00.0: CSR_GP_DRIVER_REG: 0X > [14923.113303] iwlwifi :02:00.0: CSR_UCODE_DRV_GP1: 0X0005 > [14923.113328] iwlwifi :02:00.0: CSR_UCODE_DRV_GP2: 0X > [14923.113354] iwlwifi :02:00.0: CSR_LED_REG: 0X0038 > [14923.113379] iwlwifi :02:00.0:CSR_DRAM_INT_TBL_REG: > 0X880c4272 > [14923.113405] iwlwifi :02:00.0:CSR_GIO_CHICKEN_BITS: 0X27800200 > [14923.113431] iwlwifi :02:00.0: CSR_ANA_PLL_CFG: 0X > [14923.113457] iwlwifi :02:00.0: CSR_HW_REV_WA_REG: > 0X0001001a > [14923.113482] iwlwifi :02:00.0:CSR_DBG_HPET_MEM_REG: > 0X > [14923.113484] iwlwifi :02:00.0: FH register values: > [14923.113520] iwlwifi :02:00.0: FH_RSCSR_CHNL0_STTS_WPTR_REG: > 0X0a231600 > [14923.113536] iwlwifi :02:00.0: > FH_RSCSR_CHNL0_RBDCB_BASE_REG: 0X00a23ed0 > [14923.113551] iwlwifi :02:00.0: FH_RSCSR_CHNL0_WPTR: > 0X0018 > [14923.113566] iwlwifi :02:00.0: > FH_MEM_RCSR_CHNL0_CONFIG_REG: 0X80801114 > [14923.113580] iwlwifi :02:00.0: > FH_MEM_RSSR_SHARED_CTRL_REG: 0X00fc > [14923.113595] iwlwifi :02:00.0:FH_MEM_RSSR_RX_STATUS_REG: > 0X0703 > [14923.113611] iwlwifi :02:00.0: > FH_MEM_RSSR_RX_ENABLE_ERR_IRQ2DRV: 0X > [14923.113626] iwlwifi :02:00.0:FH_TSSR_TX_STATUS_REG: > 0X07ff0001 > [14923.113641] iwlwifi :02:00.0: FH_TSSR_TX_ERROR_REG: > 0X > [14923.113644] iwlwifi :02:00.0: Loaded firmware version: 9.221.4.1 build > 25532 > [14923.113800] iwlwifi :02:00.0: Start IWL Error Log Dump: > [14923.113802] iwlwifi :02:00.0: Status: 0x204D, count: 5 > [14923.113804] iwlwifi :02:00.0: 0x0005 | SYSASSERT > [14923.113805] iwlwifi :02:00.0: 0x0001EFD8 | uPc > [14923.113807] iwlwifi :02:00.0: 0x0001EEE4 | branchlink1 > [14923.113808] iwlwifi :02:00.0: 0x0001EEE4 | branchlink2 > [14923.113809] iwlwifi :02:00.0: 0x1532 | interruptlink1 > [14923.113811] iwlwifi :02:00.0: 0x | interruptlink2 > [14923.113812] iwlwifi :02:00.0: 0x | data1 > [14923.113813] iwlwifi :02:00.0: 0x | data2 > [14923.113815] iwlwifi :02:00.0: 0x012E | line > [14923.113816] iwlwifi :02:00.0: 0x00400529 | beacon time > [14923.113818] iwlwifi :02:00.0: 0x00031AD7 | tsf low > [14923.113819] iwlwifi :02:00.0: 0x | tsf hi > [14923.113820] iwlwifi :02:00.0: 0x | time gp1 > [14923.113822] iwlwifi :02:00.0: 0x0004B850 | time gp2 > [14923.113823] iwlwifi :02:00.0: 0x | time
RE: [cfg80211 / iwlwifi] setting wireless regulatory domain doesn't work.
> > On 12/17/2013 11:06 PM, Linus Torvalds wrote: > > We have literally had this *exact* same issue with firmware loading. > > Network drivers shouldn't try to load firmware at module load time. > > Same deal. > > It is kind of a chicken and egg problem for (wireless) networking drivers. To > get IFF_UP from the network layer you have to register a netdevice. For > wireless drivers this means you have to register a wiphy device with cfg80211 > which flags capabilities and optionally are custom regulatory domain. That > information depends on the device and firmware used. And there we have a > full circle. > To solve this - iwlwifi uses request_firmware_nowait. Its doc reads: "Asynchronous variant of request_firmware for user contexts: - sleep for as small periods as possible since it may increase kernel boot time of built-in device drivers requesting firmware in their ->probe methods, if gfp is GFP_KERNEL."
RE: [PATCH] iwlwifi: remove duplicate includes
> Subject: [PATCH] iwlwifi: remove duplicate includes > > Reported by "make includecheck" > > Tested that the corresponding sources still compile well on x86 > > Signed-off-by: Michael Opdenacker electrons.com> > --- Picked up. Thanks. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH 08/11] iwlwifi: Remove extern from function prototypes
> Subject: [PATCH 08/11] iwlwifi: Remove extern from function prototypes > > There are a mix of function prototypes with and without extern in the kernel > sources. Standardize on not using extern for function prototypes. > > Function prototypes don't need to be written with extern. > extern is assumed by the compiler. Its use is as unnecessary as using auto to > declare automatic/local variables in a block. > > Signed-off-by: Joe Perches > --- > drivers/net/wireless/iwlwifi/dvm/agn.h | 2 +- > drivers/net/wireless/iwlwifi/dvm/dev.h | 2 +- > drivers/net/wireless/iwlwifi/dvm/rs.h | 8 > drivers/net/wireless/iwlwifi/mvm/rs.h | 9 - > 4 files changed, 10 insertions(+), 11 deletions(-) > ACK -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [Ilw] 3.10.10-rt7: inconsistent lock state (iwlwifi)
>
> lockdep complains about this:
>
> [ 92.094870]CPU0
> [ 92.094871]
> [ 92.094872] lock(&trans_pcie->irq_lock);
> [ 92.094873]
> [ 92.094875] lock(&trans_pcie->irq_lock);
> [ 92.094875]
> *** DEADLOCK ***
Sorry by I am not aware of all the details of RT kernels.
What I see here is that we always disable interrupts when we take
trans_pcie->irq_lock so I don't see how this flow is possible - at least not in
the world I know. Can you please elaborate on why this is possible in the RT
world?
Thanks.
>
> [ 92.094877] 1 lock held by systemd-journal/1002:
> [ 92.094882] #0: (&mm->mmap_sem){+.}, at: []
> __do_page_fault+0x1cc/0x5a0
> [ 92.094883]
> stack backtrace:
> [ 92.094885] CPU: 0 PID: 1002 Comm: systemd-journal Not tainted 3.10.10-
> rt7 #5
> [ 92.094887] Hardware name: Acer Aspire 1810T/JM11-MS, BIOS v1.3310
> 03/25/2010
> [ 92.094890] 81fd95f0 81a21cf0 81525783
> 81a21d40
> [ 92.094893] 81522347 8801
> 0001
> [ 92.094895] 0002 88013734d050 8107d420
>
> [ 92.094896] Call Trace:
> [ 92.094902][] dump_stack+0x19/0x1b
> [ 92.094905] [] print_usage_bug+0x1fb/0x20c
> [ 92.094909] [] ? check_usage_backwards+0x140/0x140
> [ 92.094912] [] mark_lock+0x23a/0x2c0
> [ 92.094914] [] __lock_acquire+0x7ff/0x1a60
> [ 92.094918] [] ? __do_page_fault+0x1cc/0x5a0
> [ 92.094920] [] lock_acquire+0x62/0x80
> [ 92.094927] [] ? iwl_pcie_isr_ict+0x2c/0x2d0 [iwlwifi]
> [ 92.094930] [] rt_spin_lock+0x40/0x50
> [ 92.094936] [] ? iwl_pcie_isr_ict+0x2c/0x2d0 [iwlwifi]
> [ 92.094943] [] iwl_pcie_isr_ict+0x2c/0x2d0 [iwlwifi]
> [ 92.094948] [] handle_irq_event_percpu+0x55/0x180
> [ 92.094951] [] handle_irq_event+0x38/0x60
> [ 92.094954] [] handle_edge_irq+0x6f/0x140
> [ 92.094956] [] handle_irq+0x19/0x30
> [ 92.094959] [] do_IRQ+0x45/0xb0
> [ 92.094962] [] common_interrupt+0x6d/0x6d
> [ 92.094966][] ? __do_page_fault+0x1cc/0x5a0
> [ 92.094969] [] ? lock_release_non_nested+0xa0/0x300
> [ 92.094973] [] ? get_parent_ip+0xd/0x50
> [ 92.094976] [] ? retint_swapgs+0xe/0x13
> [ 92.094980] [] ? trace_hardirqs_off_thunk+0x3a/0x3c
> [ 92.094983] [] do_page_fault+0x9/0x10
> [ 92.094985] [] page_fault+0x22/0x30
> [ 92.288725] iwlwifi :02:00.0: L1 Enabled; Disabling L0S
> [ 92.291849] iwlwifi :02:00.0: Radio type=0x1-0x2-0x0
> [ 92.422236] IPv6: ADDRCONF(NETDEV_UP): wlan0: link is not ready
>
>
> ___
> ilw mailing list
> i...@linux.intel.com
> http://linux.intel.com/mailman/listinfo/ilw
RE: iwlwifi: regression in 3.8-rc4 and 3.7.3
> > > > On Sun, Jan 20, 2013 at 6:56 AM, Hugh Dickins > wrote: > > > > > After sending the first 2MB, scp over wireless becomes > > > > > unbearably slow, with frequent stalls: on this ThinkPad T420s running > 3.8-rc4 or 3.7.3. > > > > > Not always, but often. > > > > > > > > > > > > > There is one pending iwlwifi-fixes, dunno if it will fix your issue. > > > > [1] http://git.kernel.org/?p=linux/kernel/git/iwlwifi/iwlwifi- > > > > fixes.git;a=commitdiff;h=c3e5d7181afb66657393066bccce0956fab09ab3 > > > > > > Right - so the 2 patches are unrelated, and the one Sedat is pointing at > > > is > relevant for 3.8 only. It fixes a bug that has been introduced in 3.8. > > > > Yes, I have now given that one a try, but it does not affect my issue. > > > > > Regarding the issue Hugh is suffering from, I have to say that I am a > > > little > confused since I am pretty sure the patch is right. Now, it might uncover > other > pre-existing bugs. All I can say is that I don't think that reverting the > patch is > *so* problematic since the patch really wants to solve a rare case. If it > causes > issues, we can simply revert it. It only means that when I will get a little > bit of > time, I might need to ask you a few logs. Thanks for the report (and the > bisection). > > > > Sure, let me know what to do, once you have time to investigate. > > > > So far as I know, I'm the first to notice: so we can probably leave it > > in 3.8-rc for now, until/unless it gives wider trouble. > > > > But reverting from 3.7-stable soon would be a good idea, regressions > > there being more tiresome. > > I'm seeing iwlwifi performance problems in 3.8 as well, and have heard from > several other saying the same thing. Testing with iperf shows very little data > getting through most of the time. > > Reverting f590dcec944552f9a4a61155810f3abd17d6465d on top of 3.8-rc6 > seems to have eliminated the problems for me, so far at least. I'll request > some > testing from others as well. > > Seth So the revert patch is on its way: http://git.kernel.org/?p=linux/kernel/git/davem/net.git;a=commit;h=ae023b2795d36f0f077e157428eb7eafa29ee412 - A member of the Intel Corporation group of companies This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [Ilw] iwlwifi/iwldvm soft lockup with 3.8.0-rc5 (was: almost unusable on 3.8.0-rc5)
> > Hello all, > > Oh the irony, I was just starting an email saying wifi is almost unusable for > me > with 3.8 and my machine (a thinkpad t530) completely froze while typing it... > > I was going to say I'm getting a lot of: > iwlwifi :03:00.0: fail to flush all tx fifo queues > Please try this one: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commit;h=c3e5d7181afb66657393066bccce0956fab09ab3 as you can see, it is in mainline already. - A member of the Intel Corporation group of companies This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: linux-next: manual merge of the wireless-next tree with Linus' tree
> Today's linux-next merge of the wireless-next tree got a conflict in
> drivers/net/wireless/iwlwifi/dvm/tx.c between commit f590dcec9445
> ("iwlwifi: fix the reclaimed packet tracking upon flush queue") from Linus'
> tree
> and commit 1c3fea82d6eb ("iwlwifi: improve the reports in TX
> path") from the wireless-next tree.
>
> diff --cc drivers/net/wireless/iwlwifi/dvm/tx.c
> index 31534f7,b0aad71..000
> --- a/drivers/net/wireless/iwlwifi/dvm/tx.c
> +++ b/drivers/net/wireless/iwlwifi/dvm/tx.c
> @@@ -1218,14 -1205,8 +1210,15 @@@ int iwlagn_rx_reply_tx(struct iwl_priv
> freed++;
> }
>
> +if (tid != IWL_TID_NON_QOS) {
> +priv->tid_data[sta_id][tid].next_reclaimed =
> +next_reclaimed;
> +IWL_DEBUG_TX_REPLY(priv, "Next reclaimed
> packet:%d\n",
> + next_reclaimed);
> +}
> +
> - WARN_ON(!is_agg && freed != 1);
> + if (!is_agg && freed != 1)
> + IWL_ERR(priv, "Q: %d, freed %d\n", txq_id, freed);
>
This looks fine - thanks!
-
A member of the Intel Corporation group of companies
This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: iwlwifi: regression in 3.8-rc4 and 3.7.3
>
> On Sun, Jan 20, 2013 at 6:56 AM, Hugh Dickins wrote:
> > After sending the first 2MB, scp over wireless becomes unbearably
> > slow, with frequent stalls: on this ThinkPad T420s running 3.8-rc4 or 3.7.3.
> > Not always, but often.
> >
>
> There is one pending iwlwifi-fixes, dunno if it will fix your issue.
> [1] http://git.kernel.org/?p=linux/kernel/git/iwlwifi/iwlwifi-
> fixes.git;a=commitdiff;h=c3e5d7181afb66657393066bccce0956fab09ab3
Right - so the 2 patches are unrelated, and the one Sedat is pointing at is
relevant for 3.8 only. It fixes a bug that has been introduced in 3.8.
Regarding the issue Hugh is suffering from, I have to say that I am a little
confused since I am pretty sure the patch is right. Now, it might uncover other
pre-existing bugs. All I can say is that I don't think that reverting the patch
is *so* problematic since the patch really wants to solve a rare case. If it
causes issues, we can simply revert it. It only means that when I will get a
little bit of time, I might need to ask you a few logs. Thanks for the report
(and the bisection).
-
A member of the Intel Corporation group of companies
This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.
N�r��yb�X��ǧv�^�){.n�+{zX����ܨ}���Ơz�&j:+v���zZ+��+zf���h���~i���z� �w���?�&�)ߢf��^jǫy�m��@A�a���
0��h���i
RE: linux-next: manual merge of the net-next tree with the pci tree
> Today's linux-next merge of the net-next tree got a conflict in
> drivers/net/wireless/iwlwifi/pcie/trans.c between commit b9d146e30a2d
> ("iwlwifi: collapse wrapper for pcie_capability_read_word()") from the pci
> tree and commit 7afe3705cd4e ("iwlwifi: continue clean up -
> pcie/trans.c") from the net-next tree.
>
> I fixed it up (see below) and can carry the fix as necessary (no action is
> required).
>
Looks right - thanks Stephen!
-
Intel Israel (74) Limited
This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
