* Re: NetworkManager not listing access points
From: Dan Williams @ 2013-09-23 16:13 UTC (permalink / raw)
To: Detlev Casanova; +Cc: Johannes Berg, linux-wireless, laurent.pinchart
In-Reply-To: <3006906.Q9n0kfrGGo@naboo>
On Sun, 2013-09-22 at 16:20 +0200, Detlev Casanova wrote:
> Le samedi 21 septembre 2013 22:51:59 Johannes Berg a écrit :
> > On Thu, 2013-09-19 at 07:58 +0200, Detlev Casanova wrote:
> > > Here is the output (attached file for formatting)
> >
> > Was that from the good case? The bad case would have been
> more
> > interesting.
>
> This is both cases. I made another one and here, I can give more
> details:
>
> Network manager is trying to list APs and fails until time
> 1379858724.386569
Ok, the logs indicate that the driver simply doesn't see any scan
results:
1379858724.381522: Received scan results (0 BSSes)
Then 20 seconds later (after the explicit iwlist), it finds some scan
results:
1379858746.953924: Received scan results (3 BSSes)
So I'm not sure what's going on here, but I don't think NetworkManager
is the issue; it's likely in the supplicant's scanning code or in the
driver itself. NetworkManager asks the supplicant to scan with both the
wildcard SSID and any hidden-tagged SSID, and the wildcard SSID should
ensure that all available APs are found.
Johannes, does anything else jump out at you in the logs?
Dan
> The The first "iwlist wlan0 scan" is done juste after the log line
> (1379858738.682054). It lists the APs in range in the console but
> not in the Network Manager ui.
>
> The second "iwlist wlan0 scan" is done at time 1379858739.802067
> and APs are being listed in the console and in the Network Manager
> UI.
>
> After that, NM will connect to the acces point with SSID "Maison".
>
> It also looks like the listing in Network Manager comes between the
> moment "iwlist wlan0 scan" is run for the second time and the
> moment is shows its output on the console.
>
> Detlev.
^ permalink raw reply
* Re: [PATCH 3.12] Revert "rt2x00pci: Use PCI MSIs whenever possible"
From: Gertjan van Wingerde @ 2013-09-23 16:55 UTC (permalink / raw)
To: Stanislaw Gruszka, linux-wireless; +Cc: users, Jakub Kicinski, moorray
In-Reply-To: <20130923020812.GA1577@redhat.com>
On 09/23/13 04:08, Stanislaw Gruszka wrote:
> This reverts commit 9483f40d8d01918b399b4e24d0c1111db0afffeb.
>
> Some devices stop to connect with above commit, see:
> https://bugzilla.kernel.org/show_bug.cgi?id=61621
>
> Since there is no clear benefit of having MSI enabled, just revert
> change to fix the problem.
>
> Cc: stable@vger.kernel.org # 3.11+
> Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
Acked-by: Gertjan van Wingerde <gwingerde@gmail.com>
> ---
> drivers/net/wireless/rt2x00/rt2x00pci.c | 9 +--------
> 1 file changed, 1 insertion(+), 8 deletions(-)
>
> diff --git a/drivers/net/wireless/rt2x00/rt2x00pci.c b/drivers/net/wireless/rt2x00/rt2x00pci.c
> index 76d95de..dc49e52 100644
> --- a/drivers/net/wireless/rt2x00/rt2x00pci.c
> +++ b/drivers/net/wireless/rt2x00/rt2x00pci.c
> @@ -105,13 +105,11 @@ int rt2x00pci_probe(struct pci_dev *pci_dev, const struct rt2x00_ops *ops)
> goto exit_release_regions;
> }
>
> - pci_enable_msi(pci_dev);
> -
> hw = ieee80211_alloc_hw(sizeof(struct rt2x00_dev), ops->hw);
> if (!hw) {
> rt2x00_probe_err("Failed to allocate hardware\n");
> retval = -ENOMEM;
> - goto exit_disable_msi;
> + goto exit_release_regions;
> }
>
> pci_set_drvdata(pci_dev, hw);
> @@ -152,9 +150,6 @@ exit_free_reg:
> exit_free_device:
> ieee80211_free_hw(hw);
>
> -exit_disable_msi:
> - pci_disable_msi(pci_dev);
> -
> exit_release_regions:
> pci_release_regions(pci_dev);
>
> @@ -179,8 +174,6 @@ void rt2x00pci_remove(struct pci_dev *pci_dev)
> rt2x00pci_free_reg(rt2x00dev);
> ieee80211_free_hw(hw);
>
> - pci_disable_msi(pci_dev);
> -
> /*
> * Free the PCI device data.
> */
>
--
---
Gertjan
^ permalink raw reply
* Re: [Ilw] Intel 6300 crashes hard (3.11 regression?)
From: Andrew Lutomirski @ 2013-09-23 18:21 UTC (permalink / raw)
To: Grumbach, Emmanuel; +Cc: ilw@linux.intel.com, linux-wireless@vger.kernel.org
In-Reply-To: <0BA3FCBA62E2DC44AF3030971E174FB301DB3584@HASMSX103.ger.corp.intel.com>
On Mon, Sep 23, 2013 at 5:01 PM, Grumbach, Emmanuel
<emmanuel.grumbach@intel.com> wrote:
>>
>> I've had a failure twice on 3.11.1-200.fc19.x86_64. I've never seen it on
>> earlier Fedora kernels or on 3.11-rc3. The computer hangs for a minute or so.
>> When it comes back, wireless doesn't work. rmmoding and modprobing
>> iwldvm doesn't help (it's at the bottom of the attachment).
>>
>> Even rebooting doesn't fix it unless I pull the battery. Otherwise iwlwifi loads
>> but wlan0 doesn't appear and the only log line is the one saying that iwlwifi
>> loaded.
>>
>> The messages on startup are:
>>
>> [ 11.440725] iwlwifi 0000:03:00.0: can't disable ASPM; OS doesn't
>> have ASPM control
>> [ 11.440788] iwlwifi 0000:03:00.0: irq 51 for MSI/MSI-X
>> [ 11.455653] iwlwifi 0000:03:00.0: loaded firmware version 9.221.4.1
>> build 25532 op_mode iwldvm
>> [ 11.517924] iwlwifi 0000:03:00.0: CONFIG_IWLWIFI_DEBUG enabled
>> [ 11.517930] iwlwifi 0000:03:00.0: CONFIG_IWLWIFI_DEBUGFS enabled
>> [ 11.517932] iwlwifi 0000:03:00.0: CONFIG_IWLWIFI_DEVICE_TRACING
>> disabled
>> [ 11.517934] iwlwifi 0000:03:00.0: CONFIG_IWLWIFI_P2P disabled
>> [ 11.517936] iwlwifi 0000:03:00.0: Detected Intel(R) Centrino(R)
>> Ultimate-N 6300 AGN, REV=0x74
>> [ 11.519626] iwlwifi 0000:03:00.0: L1 Enabled; Disabling L0S
>>
>> (Both failures happened with pcie_aspm=force, but this is without it.
>> I want to see if disabling that option fixes it.)
>
> Please do and report back - what I can see here is that we kinda can't access the NIC - so I would be curious if pcie_aspm=force changes the game here.
>
It happened again. This time I got some stuff in the middle of the
dump that I didn't notice last time:
[ 1125.076283] iwlwifi 0000:03:00.0: Q 19 is active and mapped to fifo
2 ra_tid 0xa5a5 [90,1515870810]
[ 1127.073531] iwlwifi 0000:03:00.0: Error sending REPLY_TXFIFO_FLUSH:
time out after 2000ms.
[ 1127.073544] iwlwifi 0000:03:00.0: Current CMD queue read_ptr 135
write_ptr 143
[ 1127.073550] iwlwifi 0000:03:00.0: Couldn't flush the AGG queue
[ 1129.110029] iwlwifi 0000:03:00.0: Error sending REPLY_ADD_STA: time
out after 2000ms.
[ 1129.110037] iwlwifi 0000:03:00.0: Current CMD queue read_ptr 135
write_ptr 146
[ 1129.110044] wlan0: HW problem - can not stop rx aggregation for
50:a7:33:27:30:78 tid 0
[ 1131.107391] iwlwifi 0000:03:00.0: Error sending REPLY_ADD_STA: time
out after 2000ms.
[ 1131.107399] iwlwifi 0000:03:00.0: Current CMD queue read_ptr 135
write_ptr 149
[ 1131.107405] wlan0: HW problem - can not stop rx aggregation for
50:a7:33:27:30:78 tid 1
[ 1133.104739] iwlwifi 0000:03:00.0: Error sending REPLY_ADD_STA: time
out after 2000ms.
[ 1133.104745] iwlwifi 0000:03:00.0: Current CMD queue read_ptr 135
write_ptr 152
[ 1133.104750] wlan0: HW problem - can not stop rx aggregation for
50:a7:33:27:30:78 tid 5
[ 1135.102155] iwlwifi 0000:03:00.0: Error sending REPLY_ADD_STA: time
out after 2000ms.
[ 1135.102160] iwlwifi 0000:03:00.0: Current CMD queue read_ptr 135
write_ptr 155
[ 1135.102163] wlan0: HW problem - can not stop rx aggregation for
50:a7:33:27:30:78 tid 6
[ 1137.099675] iwlwifi 0000:03:00.0: Error sending REPLY_QOS_PARAM:
time out after 2000ms.
[ 1137.099682] iwlwifi 0000:03:00.0: Current CMD queue read_ptr 135
write_ptr 158
[ 1137.099686] iwlwifi 0000:03:00.0: Failed to update QoS
[ 1139.097113] iwlwifi 0000:03:00.0: Error sending REPLY_RXON: time
out after 2000ms.
[ 1139.097120] iwlwifi 0000:03:00.0: Current CMD queue read_ptr 135
write_ptr 161
[ 1139.097124] iwlwifi 0000:03:00.0: Error clearing ASSOC_MSK on BSS (-110)
[ 1141.094533] iwlwifi 0000:03:00.0: Error sending REPLY_RXON: time
out after 2000ms.
[ 1141.094589] iwlwifi 0000:03:00.0: Current CMD queue read_ptr 135
write_ptr 164
[ 1141.094633] iwlwifi 0000:03:00.0: Error clearing ASSOC_MSK on BSS (-110)
[ 1141.314184] iwlwifi 0000:03:00.0: No space in command queue
[ 1141.314259] iwlwifi 0000:03:00.0: Restarting adapter queue is full
[ 1141.314305] iwlwifi 0000:03:00.0: Error sending REPLY_LEDS_CMD:
enqueue_hcmd failed: -28
[ 1143.091961] iwlwifi 0000:03:00.0: Error sending REPLY_RXON: time
out after 2000ms.
[ 1143.092016] iwlwifi 0000:03:00.0: Current CMD queue read_ptr 135
write_ptr 165
[ 1143.092060] iwlwifi 0000:03:00.0: Error clearing ASSOC_MSK on BSS (-110)
[ 1145.090373] iwlwifi 0000:03:00.0: fail to flush all tx fifo queues Q 0
[ 1145.090450] iwlwifi 0000:03:00.0: Current SW read_ptr 142 write_ptr 143
[ 1145.110262] iwl data: 00000000: 90 3b 0d a2 00 88 ff ff 50 3b 0d a2
00 88 ff ff .;......P;......
[ 1145.130280] iwlwifi 0000:03:00.0: FH TRBs(0) = 0x5a5a5a5a
[ 1145.149994] iwlwifi 0000:03:00.0: FH TRBs(1) = 0x5a5a5a5a
[ 1145.169813] iwlwifi 0000:03:00.0: FH TRBs(2) = 0x5a5a5a5a
[ 1145.189419] iwlwifi 0000:03:00.0: FH TRBs(3) = 0x5a5a5a5a
[ 1145.208993] iwlwifi 0000:03:00.0: FH TRBs(4) = 0x5a5a5a5a
[ 1145.228552] iwlwifi 0000:03:00.0: FH TRBs(5) = 0x5a5a5a5a
[ 1145.248097] iwlwifi 0000:03:00.0: FH TRBs(6) = 0x5a5a5a5a
[ 1145.267558] iwlwifi 0000:03:00.0: FH TRBs(7) = 0x5a5a5a5a
3.10 seems stable.
--Andy
^ permalink raw reply
* RE: [Ilw] Intel 6300 crashes hard (3.11 regression?)
From: Grumbach, Emmanuel @ 2013-09-23 18:24 UTC (permalink / raw)
To: Andrew Lutomirski; +Cc: ilw@linux.intel.com, linux-wireless@vger.kernel.org
In-Reply-To: <CAObL_7GA-SD5bK7Hnwyp_vnoLxSbcGGtnzgyD-GBHAwaxF1JxQ@mail.gmail.com>
> >>
> >> I've had a failure twice on 3.11.1-200.fc19.x86_64. I've never seen
> >> it on earlier Fedora kernels or on 3.11-rc3. The computer hangs for a
> minute or so.
> >> When it comes back, wireless doesn't work. rmmoding and modprobing
> >> iwldvm doesn't help (it's at the bottom of the attachment).
> >>
> >> Even rebooting doesn't fix it unless I pull the battery. Otherwise
> >> iwlwifi loads but wlan0 doesn't appear and the only log line is the
> >> one saying that iwlwifi loaded.
> >>
> >> The messages on startup are:
> >>
> >> [ 11.440725] iwlwifi 0000:03:00.0: can't disable ASPM; OS doesn't
> >> have ASPM control
> >> [ 11.440788] iwlwifi 0000:03:00.0: irq 51 for MSI/MSI-X
> >> [ 11.455653] iwlwifi 0000:03:00.0: loaded firmware version 9.221.4.1
> >> build 25532 op_mode iwldvm
> >> [ 11.517924] iwlwifi 0000:03:00.0: CONFIG_IWLWIFI_DEBUG enabled
> >> [ 11.517930] iwlwifi 0000:03:00.0: CONFIG_IWLWIFI_DEBUGFS enabled
> >> [ 11.517932] iwlwifi 0000:03:00.0: CONFIG_IWLWIFI_DEVICE_TRACING
> >> disabled
> >> [ 11.517934] iwlwifi 0000:03:00.0: CONFIG_IWLWIFI_P2P disabled
> >> [ 11.517936] iwlwifi 0000:03:00.0: Detected Intel(R) Centrino(R)
> >> Ultimate-N 6300 AGN, REV=0x74
> >> [ 11.519626] iwlwifi 0000:03:00.0: L1 Enabled; Disabling L0S
> >>
> >> (Both failures happened with pcie_aspm=force, but this is without it.
> >> I want to see if disabling that option fixes it.)
> >
> > Please do and report back - what I can see here is that we kinda can't
> access the NIC - so I would be curious if pcie_aspm=force changes the game
> here.
> >
>
> It happened again. This time I got some stuff in the middle of the dump that
> I didn't notice last time:
>
> [ 1125.076283] iwlwifi 0000:03:00.0: Q 19 is active and mapped to fifo
> 2 ra_tid 0xa5a5 [90,1515870810]
> [ 1127.073531] iwlwifi 0000:03:00.0: Error sending REPLY_TXFIFO_FLUSH:
> time out after 2000ms.
> [ 1127.073544] iwlwifi 0000:03:00.0: Current CMD queue read_ptr 135
> write_ptr 143 [ 1127.073550] iwlwifi 0000:03:00.0: Couldn't flush the AGG
> queue [ 1129.110029] iwlwifi 0000:03:00.0: Error sending REPLY_ADD_STA:
> time out after 2000ms.
> [ 1129.110037] iwlwifi 0000:03:00.0: Current CMD queue read_ptr 135
> write_ptr 146 [ 1129.110044] wlan0: HW problem - can not stop rx
> aggregation for
> 50:a7:33:27:30:78 tid 0
> [ 1131.107391] iwlwifi 0000:03:00.0: Error sending REPLY_ADD_STA: time out
> after 2000ms.
> [ 1131.107399] iwlwifi 0000:03:00.0: Current CMD queue read_ptr 135
> write_ptr 149 [ 1131.107405] wlan0: HW problem - can not stop rx
> aggregation for
> 50:a7:33:27:30:78 tid 1
> [ 1133.104739] iwlwifi 0000:03:00.0: Error sending REPLY_ADD_STA: time out
> after 2000ms.
> [ 1133.104745] iwlwifi 0000:03:00.0: Current CMD queue read_ptr 135
> write_ptr 152 [ 1133.104750] wlan0: HW problem - can not stop rx
> aggregation for
> 50:a7:33:27:30:78 tid 5
> [ 1135.102155] iwlwifi 0000:03:00.0: Error sending REPLY_ADD_STA: time out
> after 2000ms.
> [ 1135.102160] iwlwifi 0000:03:00.0: Current CMD queue read_ptr 135
> write_ptr 155 [ 1135.102163] wlan0: HW problem - can not stop rx
> aggregation for
> 50:a7:33:27:30:78 tid 6
> [ 1137.099675] iwlwifi 0000:03:00.0: Error sending REPLY_QOS_PARAM:
> time out after 2000ms.
> [ 1137.099682] iwlwifi 0000:03:00.0: Current CMD queue read_ptr 135
> write_ptr 158 [ 1137.099686] iwlwifi 0000:03:00.0: Failed to update QoS [
> 1139.097113] iwlwifi 0000:03:00.0: Error sending REPLY_RXON: time out after
> 2000ms.
> [ 1139.097120] iwlwifi 0000:03:00.0: Current CMD queue read_ptr 135
> write_ptr 161 [ 1139.097124] iwlwifi 0000:03:00.0: Error clearing ASSOC_MSK
> on BSS (-110) [ 1141.094533] iwlwifi 0000:03:00.0: Error sending REPLY_RXON:
> time out after 2000ms.
> [ 1141.094589] iwlwifi 0000:03:00.0: Current CMD queue read_ptr 135
> write_ptr 164 [ 1141.094633] iwlwifi 0000:03:00.0: Error clearing ASSOC_MSK
> on BSS (-110) [ 1141.314184] iwlwifi 0000:03:00.0: No space in command
> queue [ 1141.314259] iwlwifi 0000:03:00.0: Restarting adapter queue is full [
> 1141.314305] iwlwifi 0000:03:00.0: Error sending REPLY_LEDS_CMD:
> enqueue_hcmd failed: -28
> [ 1143.091961] iwlwifi 0000:03:00.0: Error sending REPLY_RXON: time out after
> 2000ms.
> [ 1143.092016] iwlwifi 0000:03:00.0: Current CMD queue read_ptr 135
> write_ptr 165 [ 1143.092060] iwlwifi 0000:03:00.0: Error clearing ASSOC_MSK
> on BSS (-110) [ 1145.090373] iwlwifi 0000:03:00.0: fail to flush all tx fifo queues
> Q 0 [ 1145.090450] iwlwifi 0000:03:00.0: Current SW read_ptr 142 write_ptr
> 143 [ 1145.110262] iwl data: 00000000: 90 3b 0d a2 00 88 ff ff 50 3b 0d a2
> 00 88 ff ff .;......P;......
> [ 1145.130280] iwlwifi 0000:03:00.0: FH TRBs(0) = 0x5a5a5a5a [ 1145.149994]
> iwlwifi 0000:03:00.0: FH TRBs(1) = 0x5a5a5a5a [ 1145.169813] iwlwifi
> 0000:03:00.0: FH TRBs(2) = 0x5a5a5a5a [ 1145.189419] iwlwifi 0000:03:00.0: FH
> TRBs(3) = 0x5a5a5a5a [ 1145.208993] iwlwifi 0000:03:00.0: FH TRBs(4) =
> 0x5a5a5a5a [ 1145.228552] iwlwifi 0000:03:00.0: FH TRBs(5) = 0x5a5a5a5a [
> 1145.248097] iwlwifi 0000:03:00.0: FH TRBs(6) = 0x5a5a5a5a [ 1145.267558]
> iwlwifi 0000:03:00.0: FH TRBs(7) = 0x5a5a5a5a
>
>
> 3.10 seems stable.
>
Hmm.... Is bisection an option?
I don't really see any change in our driver that could cause that, but I'll need to check a bit more.
^ permalink raw reply
* Re: [PATCH 36/51] DMA-API: usb: use dma_set_coherent_mask()
From: Russell King - ARM Linux @ 2013-09-23 18:42 UTC (permalink / raw)
To: Alan Stern
Cc: alsa-devel, linux-doc, Alexander Shishkin, linux-mmc, linux-fbdev,
linux-nvme, linux-ide, devel, linux-samsung-soc, linux-scsi,
e1000-devel, b43-dev, linux-media, devicetree, Stephen Warren,
Kukjin Kim, dri-devel, linux-tegra, linux-omap, linux-arm-kernel,
Solarflare linux maintainers, netdev, linux-usb, linux-wireless,
Felipe Balbi, linux-crypto, Greg Kroah-Hartman,
uclinux-dist-devel, linuxppc-dev
In-Reply-To: <Pine.LNX.4.44L0.1309231418030.1348-100000@iolanthe.rowland.org>
On Mon, Sep 23, 2013 at 02:27:39PM -0400, Alan Stern wrote:
> On Thu, 19 Sep 2013, Russell King wrote:
>
> > The correct way for a driver to specify the coherent DMA mask is
> > not to directly access the field in the struct device, but to use
> > dma_set_coherent_mask(). Only arch and bus code should access this
> > member directly.
> >
> > Convert all direct write accesses to using the correct API.
> >
> > Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
>
> > diff --git a/drivers/usb/host/ehci-platform.c b/drivers/usb/host/ehci-platform.c
> > index f6b790c..5b0cd2d 100644
> > --- a/drivers/usb/host/ehci-platform.c
> > +++ b/drivers/usb/host/ehci-platform.c
>
> > @@ -91,8 +91,9 @@ static int ehci_platform_probe(struct platform_device *dev)
> > dev->dev.platform_data = &ehci_platform_defaults;
> > if (!dev->dev.dma_mask)
> > dev->dev.dma_mask = &dev->dev.coherent_dma_mask;
> > - if (!dev->dev.coherent_dma_mask)
> > - dev->dev.coherent_dma_mask = DMA_BIT_MASK(32);
> > + err = dma_set_coherent_mask(&dev->dev, DMA_BIT_MASK(32));
> > + if (err)
> > + return err;
> >
> > pdata = dev_get_platdata(&dev->dev);
>
> ehci-platform.c is a generic file, intended for use by multiple
> platforms. Is it not possible that on some platforms, the arch or bus
> code may already have initialized the DMA masks? Isn't something like
> this (i.e., DMA bindings) planned for Device Tree?
>
> By eliminating the tests above and calling dma_set_coherent_mask or
> dma_coerce_mask_and_coherent unconditionally, this patch (and the next)
> would overwrite those initial settings.
>
> I don't know to what extent the same may be true for the other,
> platform-specific, drivers changed by this patch. But it's something
> to be aware of.
Please check the DMA API documentation:
=====
For correct operation, you must interrogate the kernel in your device
probe routine to see if the DMA controller on the machine can properly
support the DMA addressing limitation your device has. It is good
style to do this even if your device holds the default setting,
because this shows that you did think about these issues wrt. your
device.
The query is performed via a call to dma_set_mask():
int dma_set_mask(struct device *dev, u64 mask);
The query for consistent allocations is performed via a call to
dma_set_coherent_mask():
int dma_set_coherent_mask(struct device *dev, u64 mask);
=====
So, All drivers which use DMA are supposed to issue the appropriate
calls to check the DMA masks before they perform DMA, even if the
"default" is correct.
And yes, this is all part of sorting out the DT mess - we should
start not from the current mess (which is really totally haphazard)
but from the well established position of how the DMA API _should_
be used. What that means is that all drivers should be issuing
these calls as appropriate today.
The default mask setup when the device is created is just that -
it's a default mask, and it should not be used to decide anything
about the device. That's something which the driver should compute
on its own accord and then inform the various other layers via the
appropriate call.
Remember, on PCI, even when we have 64-bit, we do not declare PCI
devices with a 64-bit DMA mask: that's up to PCI device drivers to
_try_ to set a 64-bit DMA mask, which when successful _allows_ them
to use 64-bit DMA. If it fails, they have to only use 32-bit. If
they want a smaller mask, the _driver_ has to set the smaller mask,
not the device creating code.
The reason we're into this (particularly on ARM) is that we got lazy
because we could get by with declaring a DMA mask at device creation
time, since all devices were statically declared. Now it's time to
get rid of those old lazy ways and start doing things correctly and
to the requirements of the APIs.
^ permalink raw reply
* RE: [PATCH v5 1/2] Bluetooth: btmrvl: add setup handler
From: Bing Zhao @ 2013-09-23 19:18 UTC (permalink / raw)
To: Marcel Holtmann
Cc: linux-bluetooth@vger.kernel.org, Gustavo Padovan, Johan Hedberg,
linux-wireless@vger.kernel.org, Mike Frysinger, Hyuckjoo Lee,
Amitkumar Karwar
In-Reply-To: <18678858-E711-43E5-AFE6-E637D1CECFFB@holtmann.org>
Hi Marcel,
> > - btmrvl_send_module_cfg_cmd(priv, MODULE_BRINGUP_REQ);
> > + hdev->setup = btmrvl_setup;
>
> just to make sure you guys understand how ->setup() works. It is only called once. Bringing the
> adapter down and up again does not call ->setup() a second time. So do you guys need this setup_done
> variable and if so, then you need to be a bit more verbose and help me understand why.
It's observed that sometimes the setup handler is called twice when Bluetooth daemon is running in background. We will rebase to latest commit on bluetooth-next tree and test again. If the issue is gone with the latest code in -next tree we will remove the setup_done flag.
Thanks,
Bing
^ permalink raw reply
* [PATCH] staging: vt6656: [BUG] iwctl_siwencodeext return if device not open
From: Malcolm Priestley @ 2013-09-23 19:30 UTC (permalink / raw)
To: gregkh; +Cc: linux-wireless
Don't allow entry to iwctl_siwencodeext if device not open.
This fixes a race condition where wpa supplicant/network manager
enters the function when the device is already closed.
Signed-off-by: Malcolm Priestley <tvboxspy@gmail.com>
Cc: stable@vger.kernel.org # 3.8+
---
drivers/staging/vt6656/iwctl.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/staging/vt6656/iwctl.c b/drivers/staging/vt6656/iwctl.c
index 033cb50..5968888 100644
--- a/drivers/staging/vt6656/iwctl.c
+++ b/drivers/staging/vt6656/iwctl.c
@@ -1634,6 +1634,9 @@ int iwctl_siwencodeext(struct net_device *dev, struct iw_request_info *info,
if (pMgmt == NULL)
return -EFAULT;
+ if (!(pDevice->flags & DEVICE_FLAGS_OPENED))
+ return -ENODEV;
+
buf = kzalloc(sizeof(struct viawget_wpa_param), GFP_KERNEL);
if (buf == NULL)
return -ENOMEM;
--
1.8.3.2
^ permalink raw reply related
* RE: [PATCH v5 2/2] Bluetooth: btmrvl: add calibration data download support
From: Bing Zhao @ 2013-09-23 19:35 UTC (permalink / raw)
To: Marcel Holtmann
Cc: linux-bluetooth@vger.kernel.org, Gustavo Padovan, Johan Hedberg,
linux-wireless@vger.kernel.org, Mike Frysinger, Hyuckjoo Lee,
Amitkumar Karwar
In-Reply-To: <05172D80-CE30-4B7D-A64E-11B8E320EF7F@holtmann.org>
Hi Marcel,
> > + cmd = (struct btmrvl_cmd *)skb->data;
> > + cmd->ocf_ogf =
> > + cpu_to_le16(hci_opcode_pack(OGF, BT_CMD_LOAD_CONFIG_DATA));
> > + cmd->length = BT_CMD_DATA_SIZE;
> > + cmd->data[0] = 0x00;
> > + cmd->data[1] = 0x00;
> > + cmd->data[2] = 0x00;
> > + cmd->data[3] = BT_CMD_DATA_SIZE - 4;
>
> why not use __hci_cmd_sync() here. It is designed to be used from ->setup() where it is guaranteed
> that the HCI request lock is held. And it is guaranteed that ->setup() is executed in a workqueue.
The reason of not using __hci_cmd_sync() is that we are sending vendor specific command here (MRVL_VENDOR_PKT). The __hci_cmd_sync seems handle HCI_COMMAND_PKT only.
Please let us know if you have any suggestion to solve this problem.
Thanks,
Bing
^ permalink raw reply
* RE: [PATCH 11/19] wireless: Change variable type to bool
From: Bing Zhao @ 2013-09-23 19:40 UTC (permalink / raw)
To: Peter Senna Tschudin
Cc: linville@tuxdriver.com, linux-wireless@vger.kernel.org,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
kernel-janitors@vger.kernel.org
In-Reply-To: <1379802471-30252-11-git-send-email-peter.senna@gmail.com>
Hi Peter,
Thanks for your patch.
> The variables cancel_scan_cmd, enable_data, hs_activate and valid are
> only assigned the values true and false. Change its type to bool.
>
> The simplified semantic patch that find this problem is as
> follows (http://coccinelle.lip6.fr/):
>
> @exists@
> type T;
> identifier b;
> @@
> - T
> + bool
> b = ...;
> ... when any
> b = \(true\|false\)
>
> Signed-off-by: Peter Senna Tschudin <peter.senna@gmail.com>
Acked-by: Bing Zhao <bzhao@marvell.com>
Thanks,
Bing
> ---
> drivers/net/wireless/mwifiex/cmdevt.c | 2 +-
> drivers/net/wireless/mwifiex/join.c | 2 +-
> drivers/net/wireless/mwifiex/sta_cmd.c | 2 +-
> drivers/net/wireless/mwifiex/wmm.c | 2 +-
> 4 files changed, 4 insertions(+), 4 deletions(-)
^ permalink raw reply
* Re: [Ilw] Intel 6300 crashes hard (3.11 regression?)
From: Emmanuel Grumbach @ 2013-09-23 19:47 UTC (permalink / raw)
To: Andrew Lutomirski
Cc: Grumbach, Emmanuel, ilw@linux.intel.com,
linux-wireless@vger.kernel.org
In-Reply-To: <CAObL_7GA-SD5bK7Hnwyp_vnoLxSbcGGtnzgyD-GBHAwaxF1JxQ@mail.gmail.com>
>>> I've had a failure twice on 3.11.1-200.fc19.x86_64. I've never seen it on
>>> earlier Fedora kernels or on 3.11-rc3. The computer hangs for a minute or so.
>>> When it comes back, wireless doesn't work. rmmoding and modprobing
>>> iwldvm doesn't help (it's at the bottom of the attachment).
>>>
>>> Even rebooting doesn't fix it unless I pull the battery. Otherwise iwlwifi loads
>>> but wlan0 doesn't appear and the only log line is the one saying that iwlwifi
>>> loaded.
>>>
>>> The messages on startup are:
>>>
>>> [ 11.440725] iwlwifi 0000:03:00.0: can't disable ASPM; OS doesn't
>>> have ASPM control
>>> [ 11.440788] iwlwifi 0000:03:00.0: irq 51 for MSI/MSI-X
>>> [ 11.455653] iwlwifi 0000:03:00.0: loaded firmware version 9.221.4.1
>>> build 25532 op_mode iwldvm
>>> [ 11.517924] iwlwifi 0000:03:00.0: CONFIG_IWLWIFI_DEBUG enabled
>>> [ 11.517930] iwlwifi 0000:03:00.0: CONFIG_IWLWIFI_DEBUGFS enabled
>>> [ 11.517932] iwlwifi 0000:03:00.0: CONFIG_IWLWIFI_DEVICE_TRACING
>>> disabled
>>> [ 11.517934] iwlwifi 0000:03:00.0: CONFIG_IWLWIFI_P2P disabled
>>> [ 11.517936] iwlwifi 0000:03:00.0: Detected Intel(R) Centrino(R)
>>> Ultimate-N 6300 AGN, REV=0x74
>>> [ 11.519626] iwlwifi 0000:03:00.0: L1 Enabled; Disabling L0S
>>>
>>> (Both failures happened with pcie_aspm=force, but this is without it.
>>> I want to see if disabling that option fixes it.)
>>
>> Please do and report back - what I can see here is that we kinda can't access the NIC - so I would be curious if pcie_aspm=force changes the game here.
>>
>
> It happened again. This time I got some stuff in the middle of the
> dump that I didn't notice last time:
>
> [ 1125.076283] iwlwifi 0000:03:00.0: Q 19 is active and mapped to fifo
> 2 ra_tid 0xa5a5 [90,1515870810]
> [ 1127.073531] iwlwifi 0000:03:00.0: Error sending REPLY_TXFIFO_FLUSH:
> time out after 2000ms.
> [ 1127.073544] iwlwifi 0000:03:00.0: Current CMD queue read_ptr 135
> write_ptr 143
> [ 1127.073550] iwlwifi 0000:03:00.0: Couldn't flush the AGG queue
> [ 1129.110029] iwlwifi 0000:03:00.0: Error sending REPLY_ADD_STA: time
> out after 2000ms.
> [ 1129.110037] iwlwifi 0000:03:00.0: Current CMD queue read_ptr 135
> write_ptr 146
> [ 1129.110044] wlan0: HW problem - can not stop rx aggregation for
> 50:a7:33:27:30:78 tid 0
> [ 1131.107391] iwlwifi 0000:03:00.0: Error sending REPLY_ADD_STA: time
> out after 2000ms.
> [ 1131.107399] iwlwifi 0000:03:00.0: Current CMD queue read_ptr 135
> write_ptr 149
> [ 1131.107405] wlan0: HW problem - can not stop rx aggregation for
> 50:a7:33:27:30:78 tid 1
> [ 1133.104739] iwlwifi 0000:03:00.0: Error sending REPLY_ADD_STA: time
> out after 2000ms.
> [ 1133.104745] iwlwifi 0000:03:00.0: Current CMD queue read_ptr 135
> write_ptr 152
> [ 1133.104750] wlan0: HW problem - can not stop rx aggregation for
> 50:a7:33:27:30:78 tid 5
> [ 1135.102155] iwlwifi 0000:03:00.0: Error sending REPLY_ADD_STA: time
> out after 2000ms.
> [ 1135.102160] iwlwifi 0000:03:00.0: Current CMD queue read_ptr 135
> write_ptr 155
> [ 1135.102163] wlan0: HW problem - can not stop rx aggregation for
> 50:a7:33:27:30:78 tid 6
> [ 1137.099675] iwlwifi 0000:03:00.0: Error sending REPLY_QOS_PARAM:
> time out after 2000ms.
> [ 1137.099682] iwlwifi 0000:03:00.0: Current CMD queue read_ptr 135
> write_ptr 158
> [ 1137.099686] iwlwifi 0000:03:00.0: Failed to update QoS
> [ 1139.097113] iwlwifi 0000:03:00.0: Error sending REPLY_RXON: time
> out after 2000ms.
> [ 1139.097120] iwlwifi 0000:03:00.0: Current CMD queue read_ptr 135
> write_ptr 161
> [ 1139.097124] iwlwifi 0000:03:00.0: Error clearing ASSOC_MSK on BSS (-110)
> [ 1141.094533] iwlwifi 0000:03:00.0: Error sending REPLY_RXON: time
> out after 2000ms.
> [ 1141.094589] iwlwifi 0000:03:00.0: Current CMD queue read_ptr 135
> write_ptr 164
> [ 1141.094633] iwlwifi 0000:03:00.0: Error clearing ASSOC_MSK on BSS (-110)
> [ 1141.314184] iwlwifi 0000:03:00.0: No space in command queue
> [ 1141.314259] iwlwifi 0000:03:00.0: Restarting adapter queue is full
> [ 1141.314305] iwlwifi 0000:03:00.0: Error sending REPLY_LEDS_CMD:
> enqueue_hcmd failed: -28
> [ 1143.091961] iwlwifi 0000:03:00.0: Error sending REPLY_RXON: time
> out after 2000ms.
> [ 1143.092016] iwlwifi 0000:03:00.0: Current CMD queue read_ptr 135
> write_ptr 165
> [ 1143.092060] iwlwifi 0000:03:00.0: Error clearing ASSOC_MSK on BSS (-110)
> [ 1145.090373] iwlwifi 0000:03:00.0: fail to flush all tx fifo queues Q 0
> [ 1145.090450] iwlwifi 0000:03:00.0: Current SW read_ptr 142 write_ptr 143
> [ 1145.110262] iwl data: 00000000: 90 3b 0d a2 00 88 ff ff 50 3b 0d a2
> 00 88 ff ff .;......P;......
> [ 1145.130280] iwlwifi 0000:03:00.0: FH TRBs(0) = 0x5a5a5a5a
> [ 1145.149994] iwlwifi 0000:03:00.0: FH TRBs(1) = 0x5a5a5a5a
> [ 1145.169813] iwlwifi 0000:03:00.0: FH TRBs(2) = 0x5a5a5a5a
> [ 1145.189419] iwlwifi 0000:03:00.0: FH TRBs(3) = 0x5a5a5a5a
> [ 1145.208993] iwlwifi 0000:03:00.0: FH TRBs(4) = 0x5a5a5a5a
> [ 1145.228552] iwlwifi 0000:03:00.0: FH TRBs(5) = 0x5a5a5a5a
> [ 1145.248097] iwlwifi 0000:03:00.0: FH TRBs(6) = 0x5a5a5a5a
> [ 1145.267558] iwlwifi 0000:03:00.0: FH TRBs(7) = 0x5a5a5a5a
>
Just saw this:
[ 3030.922014] pci_pm_runtime_suspend():
hcd_pci_runtime_suspend+0x0/0x50 returns -16
[ 3116.219553] pci_pm_runtime_suspend():
hcd_pci_runtime_suspend+0x0/0x50 returns -16
[ 3208.606354] iwlwifi 0000:03:00.0: Error sending POWER_TABLE_CMD:
time out after 2000ms.
can it be that the PCI subsystem gets confused after suspend resume?
^ permalink raw reply
* [PATCH 3.12 0/2] Fix cw1200_spi interrupt delivery
From: Solomon Peachy @ 2013-09-23 20:00 UTC (permalink / raw)
To: linux-wireless
The earlier fix for cw1200_spi driver's interrupt handling woes solved
the oops, but it had the side effect of making interrupt delivery
unreliable nearly to the point of uselessness.
Rather than try to fix the fix, just revert entirely and convert it to
using Linux's threaded oneshot irq handling. Far simpler, and it
actually seems to work.
^ permalink raw reply
* [PATCH 3.12 1/2] Revert "cw1200: Don't perform SPI transfers in interrupt context"
From: Solomon Peachy @ 2013-09-23 20:00 UTC (permalink / raw)
To: linux-wireless; +Cc: Solomon Peachy
In-Reply-To: <1379966404-7047-1-git-send-email-pizza@shaftnet.org>
This reverts commit aec8e88c947b7017e2b4bbcb68a4bfc4a1f8ad35.
This solution turned out to cause interrupt delivery problems, and
rather than trying to fix this approach, it has been scrapped in favor
of an alternative (and far simpler) implementation.
Signed-off-by: Solomon Peachy <pizza@shaftnet.org>
---
drivers/net/wireless/cw1200/cw1200_spi.c | 19 +++----------------
drivers/net/wireless/cw1200/fwio.c | 2 +-
drivers/net/wireless/cw1200/hwbus.h | 1 -
drivers/net/wireless/cw1200/hwio.c | 15 ---------------
4 files changed, 4 insertions(+), 33 deletions(-)
diff --git a/drivers/net/wireless/cw1200/cw1200_spi.c b/drivers/net/wireless/cw1200/cw1200_spi.c
index f5e6b48..5a64ac9 100644
--- a/drivers/net/wireless/cw1200/cw1200_spi.c
+++ b/drivers/net/wireless/cw1200/cw1200_spi.c
@@ -42,7 +42,6 @@ struct hwbus_priv {
spinlock_t lock; /* Serialize all bus operations */
wait_queue_head_t wq;
int claimed;
- int irq_disabled;
};
#define SDIO_TO_SPI_ADDR(addr) ((addr & 0x1f)>>2)
@@ -238,8 +237,6 @@ static irqreturn_t cw1200_spi_irq_handler(int irq, void *dev_id)
struct hwbus_priv *self = dev_id;
if (self->core) {
- disable_irq_nosync(self->func->irq);
- self->irq_disabled = 1;
cw1200_irq_handler(self->core);
return IRQ_HANDLED;
} else {
@@ -273,22 +270,13 @@ exit:
static int cw1200_spi_irq_unsubscribe(struct hwbus_priv *self)
{
+ int ret = 0;
+
pr_debug("SW IRQ unsubscribe\n");
disable_irq_wake(self->func->irq);
free_irq(self->func->irq, self);
- return 0;
-}
-
-static int cw1200_spi_irq_enable(struct hwbus_priv *self, int enable)
-{
- /* Disables are handled by the interrupt handler */
- if (enable && self->irq_disabled) {
- enable_irq(self->func->irq);
- self->irq_disabled = 0;
- }
-
- return 0;
+ return ret;
}
static int cw1200_spi_off(const struct cw1200_platform_data_spi *pdata)
@@ -368,7 +356,6 @@ static struct hwbus_ops cw1200_spi_hwbus_ops = {
.unlock = cw1200_spi_unlock,
.align_size = cw1200_spi_align_size,
.power_mgmt = cw1200_spi_pm,
- .irq_enable = cw1200_spi_irq_enable,
};
/* Probe Function to be called by SPI stack when device is discovered */
diff --git a/drivers/net/wireless/cw1200/fwio.c b/drivers/net/wireless/cw1200/fwio.c
index 0b2061b..acdff0f 100644
--- a/drivers/net/wireless/cw1200/fwio.c
+++ b/drivers/net/wireless/cw1200/fwio.c
@@ -485,7 +485,7 @@ int cw1200_load_firmware(struct cw1200_common *priv)
/* Enable interrupt signalling */
priv->hwbus_ops->lock(priv->hwbus_priv);
- ret = __cw1200_irq_enable(priv, 2);
+ ret = __cw1200_irq_enable(priv, 1);
priv->hwbus_ops->unlock(priv->hwbus_priv);
if (ret < 0)
goto unsubscribe;
diff --git a/drivers/net/wireless/cw1200/hwbus.h b/drivers/net/wireless/cw1200/hwbus.h
index 51dfb3a..8b2fc83 100644
--- a/drivers/net/wireless/cw1200/hwbus.h
+++ b/drivers/net/wireless/cw1200/hwbus.h
@@ -28,7 +28,6 @@ struct hwbus_ops {
void (*unlock)(struct hwbus_priv *self);
size_t (*align_size)(struct hwbus_priv *self, size_t size);
int (*power_mgmt)(struct hwbus_priv *self, bool suspend);
- int (*irq_enable)(struct hwbus_priv *self, int enable);
};
#endif /* CW1200_HWBUS_H */
diff --git a/drivers/net/wireless/cw1200/hwio.c b/drivers/net/wireless/cw1200/hwio.c
index 41bd761..ff230b7 100644
--- a/drivers/net/wireless/cw1200/hwio.c
+++ b/drivers/net/wireless/cw1200/hwio.c
@@ -273,21 +273,6 @@ int __cw1200_irq_enable(struct cw1200_common *priv, int enable)
u16 val16;
int ret;
- /* We need to do this hack because the SPI layer can sleep on I/O
- and the general path involves I/O to the device in interrupt
- context.
-
- However, the initial enable call needs to go to the hardware.
-
- We don't worry about shutdown because we do a full reset which
- clears the interrupt enabled bits.
- */
- if (priv->hwbus_ops->irq_enable) {
- ret = priv->hwbus_ops->irq_enable(priv->hwbus_priv, enable);
- if (ret || enable < 2)
- return ret;
- }
-
if (HIF_8601_SILICON == priv->hw_type) {
ret = __cw1200_reg_read_32(priv, ST90TDS_CONFIG_REG_ID, &val32);
if (ret < 0) {
--
1.8.3.1
^ permalink raw reply related
* [PATCH 3.12 2/2] cw1200: Use a threaded oneshot irq handler for cw1200_spi
From: Solomon Peachy @ 2013-09-23 20:00 UTC (permalink / raw)
To: linux-wireless; +Cc: Solomon Peachy
In-Reply-To: <1379966404-7047-1-git-send-email-pizza@shaftnet.org>
This supercedes the older patch ("cw1200: Don't perform SPI transfers in
interrupt context") that badly attempted to fix this problem.
This is a far simpler solution, which has the added benefit of
actually working.
Signed-off-by: Solomon Peachy <pizza@shaftnet.org>
---
drivers/net/wireless/cw1200/cw1200_spi.c | 7 ++++---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/net/wireless/cw1200/cw1200_spi.c b/drivers/net/wireless/cw1200/cw1200_spi.c
index 5a64ac9..899cad3 100644
--- a/drivers/net/wireless/cw1200/cw1200_spi.c
+++ b/drivers/net/wireless/cw1200/cw1200_spi.c
@@ -250,9 +250,10 @@ static int cw1200_spi_irq_subscribe(struct hwbus_priv *self)
pr_debug("SW IRQ subscribe\n");
- ret = request_any_context_irq(self->func->irq, cw1200_spi_irq_handler,
- IRQF_TRIGGER_HIGH,
- "cw1200_wlan_irq", self);
+ ret = request_threaded_irq(self->func->irq, NULL,
+ cw1200_spi_irq_handler,
+ IRQF_TRIGGER_HIGH | IRQF_ONESHOT,
+ "cw1200_wlan_irq", self);
if (WARN_ON(ret < 0))
goto exit;
--
1.8.3.1
^ permalink raw reply related
* Re: [brcmfmac] BUG: unable to handle kernel paging request at ffffffff82196446
From: Arend van Spriel @ 2013-09-23 20:07 UTC (permalink / raw)
To: Fengguang Wu
Cc: Hante Meuleman, John W. Linville, linux-kernel, linux-wireless,
brcm80211-dev-list
In-Reply-To: <20130923121402.GA12626@localhost>
On 09/23/2013 02:14 PM, Fengguang Wu wrote:
> On Mon, Sep 16, 2013 at 11:15:53AM +0200, Arend van Spriel wrote:
>> On 09/02/2013 12:23 PM, Fengguang Wu wrote:
>>> Greetings,
>>>
>>> I got the below dmesg and the first bad commit is
>>
>> Hi Fengguang,
>>
>> I could not reproduce this issue. Could you retest with the attached
>> patch file applied and let me know if that fixes the problem?
>
> Yeah it fixed the problem: no more oops in 1000 kernel boot tests. Thank you!
Whoa, 1000 boots. Thank you for being so thorough :-)
Regards,
Arend
^ permalink raw reply
* pull request: bluetooth 2013-09-23
From: Gustavo Padovan @ 2013-09-23 21:00 UTC (permalink / raw)
To: linville; +Cc: linux-wireless, linux-bluetooth, linux-kernel
[-- Attachment #1: Type: text/plain, Size: 2208 bytes --]
Hi John,
First Bluetooth fixes to 3.12, it includes:
* 3 patches to add device id for 3 new hardwares.
* 2 patches from Johan to fix the rfkill behaviour during setup stage
* a small clean up in the rfcomm TTY code that fixes a potential racy
condition (by Gianluca Anzolin)
* 2 fixes to proper set encryption key size and security level in the
peripheral role of Bluetooth LE devices. (by Andre Guedes)
* a fix for dealing devices where pairing is not necessary, we were keeping
the Bluetooth ACL connection alive for too much time. (by Syam Sidhardhan)
Please pull or let me know of any problems! Thanks!
Gustavo
---
The following changes since commit f4e1a4d3ecbb9e42bdf8e7869ee8a4ebfa27fb20:
rt2800: change initialization sequence to fix system freeze (2013-09-09 14:44:34 -0400)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth master
for you to fetch changes up to 5bcecf325378218a8e248bb6bcae96ec7362f8ef:
Bluetooth: btusb: Add support for Belkin F8065bf (2013-09-23 17:44:25 -0300)
----------------------------------------------------------------
Andre Guedes (2):
Bluetooth: Fix security level for peripheral role
Bluetooth: Fix encryption key size for peripheral role
Gianluca Anzolin (1):
Bluetooth: don't release the port in rfcomm_dev_state_change()
Johan Hedberg (2):
Bluetooth: Introduce a new HCI_RFKILLED flag
Bluetooth: Fix rfkill functionality during the HCI setup stage
Ken O'Brien (1):
Bluetooth: btusb: Add support for Belkin F8065bf
Peng Chen (1):
Bluetooth: Add a new PID/VID 0cf3/e005 for AR3012.
Raphael Kubo da Costa (1):
Bluetooth: Add support for BCM20702A0 [0b05, 17cb]
Syam Sidhardhan (1):
Bluetooth: Fix ACL alive for long in case of non pariable devices
drivers/bluetooth/ath3k.c | 2 ++
drivers/bluetooth/btusb.c | 5 +++++
include/net/bluetooth/hci.h | 1 +
net/bluetooth/hci_core.c | 26 ++++++++++++++++++++------
net/bluetooth/hci_event.c | 6 +++++-
net/bluetooth/l2cap_core.c | 7 +++++++
net/bluetooth/rfcomm/tty.c | 35 ++---------------------------------
7 files changed, 42 insertions(+), 40 deletions(-)
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: brcmsmac causes soft lockup in 3.12-rc1
From: Michael Stolovitzsky @ 2013-09-24 0:52 UTC (permalink / raw)
To: linux-wireless
In-Reply-To: <523FF83D.8030103@broadcom.com>
On Mon, Sep 23, 2013 at 10:13:49AM +0200, Arend van Spriel wrote:
> On 09/22/2013 12:34 AM, Michael Stolovitzsky wrote:
> >Hi,
> >
> >On 3.12-rc1, modprobe brcmsmac causes a soft lockup (trace #1), effectively killing the box. This is a Lenovo S206
> >with BCM4313 (14e4:4727), which I believe is a bluetooth combo board. After a while,
> >RCU scheduler code detects a lockup (trace #2).
> >
> >This did not happen in 3.11.1, although brcmsmac hasn't worked on this machine
> >as far as I remember. In the previous kernels (~3.2.0+), it loads, but the
> >reception is extremely weak - you must be within few meters to the AP, and the card would
> >die after several minutes. The proprietary wl.ko driver works fine.
> >
> >I've attached the dmesg output, the kernel configuration and the output of lspci -vnn.
> >I'm comfortable with experimenting; please let me know how I can help here.
>
> A fix for this problem has been submitted to John. I think it is in
> transit to mainline so probably will be in 3.12-rc2.
>
> Here the URL of the patch:
>
> https://git.kernel.org/cgit/linux/kernel/git/linville/wireless.git/patch/?id=aaa2ced15ad8dca8048666c9f70736424d696a6b
>
Arend, much thanks and an apology for not checking the patches. I will try this out ASAP.
Is the (presumedly) low RX gain also a known problem with brcmsmac on BCM4313?
^ permalink raw reply
* [PATCH] mac80211: use exact-size allocation for authentication frame
From: Fred Zhou @ 2013-09-24 2:33 UTC (permalink / raw)
To: johannes; +Cc: linux-wireless, Fred Zhou
The authentication frame has a fixied size of 30 bytes
(including header, algo num, trans seq num, and status)
followed by a variable challenge text.
Allocate using exact size, instead of over-allocation
by sizeof(ieee80211_mgmt).
Signed-off-by: Fred Zhou <fred.zy@gmail.com>
---
net/mac80211/util.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/net/mac80211/util.c b/net/mac80211/util.c
index e1b34a1..674ab12 100644
--- a/net/mac80211/util.c
+++ b/net/mac80211/util.c
@@ -1083,9 +1083,10 @@ void ieee80211_send_auth(struct ieee80211_sub_if_data *sdata,
struct sk_buff *skb;
struct ieee80211_mgmt *mgmt;
int err;
-
+
+ /* 30 = header + auth_algo + auth_transaction + status_code */
skb = dev_alloc_skb(local->hw.extra_tx_headroom +
- sizeof(*mgmt) + 6 + extra_len);
+ 30 + extra_len);
if (!skb)
return;
--
1.7.9.5
^ permalink raw reply related
* Re: [PATCH v5 2/2] Bluetooth: btmrvl: add calibration data download support
From: Marcel Holtmann @ 2013-09-24 4:21 UTC (permalink / raw)
To: Bing Zhao
Cc: linux-bluetooth@vger.kernel.org, Gustavo Padovan, Johan Hedberg,
linux-wireless@vger.kernel.org, Mike Frysinger, Hyuckjoo Lee,
Amitkumar Karwar
In-Reply-To: <477F20668A386D41ADCC57781B1F70430F44C59423@SC-VEXCH1.marvell.com>
Hi Bing,
>>> + cmd = (struct btmrvl_cmd *)skb->data;
>>> + cmd->ocf_ogf =
>>> + cpu_to_le16(hci_opcode_pack(OGF, BT_CMD_LOAD_CONFIG_DATA));
>>> + cmd->length = BT_CMD_DATA_SIZE;
>>> + cmd->data[0] = 0x00;
>>> + cmd->data[1] = 0x00;
>>> + cmd->data[2] = 0x00;
>>> + cmd->data[3] = BT_CMD_DATA_SIZE - 4;
>>
>> why not use __hci_cmd_sync() here. It is designed to be used from ->setup() where it is guaranteed
>> that the HCI request lock is held. And it is guaranteed that ->setup() is executed in a workqueue.
>
> The reason of not using __hci_cmd_sync() is that we are sending vendor specific command here (MRVL_VENDOR_PKT). The __hci_cmd_sync seems handle HCI_COMMAND_PKT only.
> Please let us know if you have any suggestion to solve this problem.
what is a MRVL_VENDOR_PKT actually?
If you guys are not using standard HCI command/event for vendor operation, then this obviously does not fit. However a similar model might make sense instead of manually building packets all the time.
Regards
Marcel
^ permalink raw reply
* Re: [PATCH v5 1/2] Bluetooth: btmrvl: add setup handler
From: Marcel Holtmann @ 2013-09-24 4:23 UTC (permalink / raw)
To: Bing Zhao
Cc: linux-bluetooth@vger.kernel.org, Gustavo Padovan, Johan Hedberg,
linux-wireless@vger.kernel.org, Mike Frysinger, Hyuckjoo Lee,
Amitkumar Karwar
In-Reply-To: <477F20668A386D41ADCC57781B1F70430F44C59418@SC-VEXCH1.marvell.com>
Hi Bing,
>>> - btmrvl_send_module_cfg_cmd(priv, MODULE_BRINGUP_REQ);
>>> + hdev->setup = btmrvl_setup;
>>
>> just to make sure you guys understand how ->setup() works. It is only called once. Bringing the
>> adapter down and up again does not call ->setup() a second time. So do you guys need this setup_done
>> variable and if so, then you need to be a bit more verbose and help me understand why.
>
> It's observed that sometimes the setup handler is called twice when Bluetooth daemon is running in background. We will rebase to latest commit on bluetooth-next tree and test again. If the issue is gone with the latest code in -next tree we will remove the setup_done flag.
that is a bug. It should only be ever called once. Could this be due to RFKILL issue we had? Please re-test with Johan's patches applied and check if it makes a difference. Otherwise please send some logs since we want to get this fixed.
Regards
Marcel
^ permalink raw reply
* Re: [RFC] ath10k: replenish HTT RX buffers in a tasklet
From: Kalle Valo @ 2013-09-24 6:22 UTC (permalink / raw)
To: Michal Kazior; +Cc: ath10k, linux-wireless
In-Reply-To: <1379509691-19904-1-git-send-email-michal.kazior@tieto.com>
Michal Kazior <michal.kazior@tieto.com> writes:
> This fixes system starvation when under heavy RX
> traffic. This problem could be observed on AP135
> and led to watchdog resetting the platform.
>
> Patch starves FW RX ring buffer by progressively
> replenishing buffers to auto-balance the RX
> handled to the host system.
>
> Signed-off-by: Michal Kazior <michal.kazior@tieto.com>
Looks good to me. I suspect there is a better way to do this in long
term, but this looks like a viable short term solution.
Does it decrease throughput in a noticeable way?
--
Kalle Valo
^ permalink raw reply
* Re: [RFC 0/4] ath10k: improve RX performance
From: Kalle Valo @ 2013-09-24 6:42 UTC (permalink / raw)
To: Michal Kazior; +Cc: ath10k, linux-wireless
In-Reply-To: <1379335757-15180-1-git-send-email-michal.kazior@tieto.com>
Michal Kazior <michal.kazior@tieto.com> writes:
> This patchset gives clear RX performance
> improvement on AP135. Throughput is at least
> doubled (300mbps -> 600mbps, UDP RX, 2x2).
>
> Patches depend on my RFC patch "mac80211: support
> reporting A-MSDU subframes individually".
Preferably I can apply these changes only after the mac80211 patch goes
to net-next (to avoid unnecessary rebasing). Is there a way to
workaround the need for the mac80211 patch in ath10k so that we could
apply these patches ASAP? And once the mac80211 patch is commited we
could just remove the workaround in ath10k.
--
Kalle Valo
^ permalink raw reply
* Re: [RFC 3/4] ath10k: cleanup RX decap handling
From: Kalle Valo @ 2013-09-24 6:47 UTC (permalink / raw)
To: Michal Kazior; +Cc: ath10k, linux-wireless
In-Reply-To: <CA+BoTQ=q9ojX4bp61rExY7b9Pk+=Zpg_qNxfXYvt8eXscdC=bA@mail.gmail.com>
Michal Kazior <michal.kazior@tieto.com> writes:
> On 16 September 2013 23:30, Kalle Valo <kvalo@qca.qualcomm.com> wrote:
>> Michal Kazior <michal.kazior@tieto.com> writes:
>>
>>> Native Wifi frames are always decapped as non-QoS
>>> data frames meaning mac80211 couldn't set sk_buff
>>> priority properly. The patch fixes this by using
>>> the original 802.11 header.
>>>
>>> Signed-off-by: Michal Kazior <michal.kazior@tieto.com>
>>
>> The patch title doesn't seem to match with the content. Unless I'm
>> mistaken it looks like you are adding native wifi frame format support
>> and doing some cleanup at the same time. They should be in separate
>> patches.
>
> You're right. I'll split it up.
>
> Nwifi was supported, however QoS Data frames were reported as Data
> frames though.
Oh, ok. It would be good to document that in the commit log as well.
>>> case RX_MSDU_DECAP_RAW:
>>> - /* remove trailing FCS */
>>> - skb_trim(skb, skb->len - 4);
>>> + skb_trim(skb, skb->len - FCS_LEN);
>>> break;
>>
>> Please keep the comment still
>
> Why? The point of the comment was to explain the literal "4". Using
> define makes the comment redundant.
I know it's redundant, but this is just to improve readability.
>>> case RX_MSDU_DECAP_ETHERNET2_DIX:
>>> - /* macaddr[6] + macaddr[6] + ethertype[2] */
>>> - skb_pull(skb, 6 + 6 + 2);
>>> + rfc1042 = hdr;
>>> + rfc1042 += roundup(hdr_len, 4);
>>> + rfc1042 += roundup(ath10k_htt_rx_crypto_param_len(enctype), 4);
>>> +
>>> + skb_pull(skb, sizeof(struct ethhdr));
>>> + memcpy(skb_push(skb, sizeof(struct rfc1042_hdr)),
>>> + rfc1042, sizeof(struct rfc1042_hdr));
>>> + memcpy(skb_push(skb, hdr_len), hdr, hdr_len);
>>> break;
>>
>> Ditto.
>
> Comment was supposed to explain where those numbers come from. Using
> structures explains it now.
Sure, the structures are very good here. But like above, having small
comments improve readability. Think of it as a "title" or something like
that.
>>> case RX_MSDU_DECAP_8023_SNAP_LLC:
>>> - /* macaddr[6] + macaddr[6] + len[2] */
>>> - /* we don't need this for non-A-MSDU */
>>> - skb_pull(skb, 6 + 6 + 2);
>>> + skb_pull(skb, sizeof(struct amsdu_subframe_hdr));
>>> + memcpy(skb_push(skb, hdr_len), hdr, hdr_len);
>>> break;
>>
>> And here.
>
> Ditto.
Same here :)
--
Kalle Valo
^ permalink raw reply
* Re: [RFC] ath10k: replenish HTT RX buffers in a tasklet
From: Michal Kazior @ 2013-09-24 6:51 UTC (permalink / raw)
To: Kalle Valo; +Cc: ath10k, linux-wireless
In-Reply-To: <87r4cebuxm.fsf@kamboji.qca.qualcomm.com>
On 24 September 2013 08:22, Kalle Valo <kvalo@qca.qualcomm.com> wrote:
> Michal Kazior <michal.kazior@tieto.com> writes:
>
>> This fixes system starvation when under heavy RX
>> traffic. This problem could be observed on AP135
>> and led to watchdog resetting the platform.
>>
>> Patch starves FW RX ring buffer by progressively
>> replenishing buffers to auto-balance the RX
>> handled to the host system.
>>
>> Signed-off-by: Michal Kazior <michal.kazior@tieto.com>
>
> Looks good to me. I suspect there is a better way to do this in long
> term, but this looks like a viable short term solution.
>
> Does it decrease throughput in a noticeable way?
I have yet to observe any regressions.
Michał.
^ permalink raw reply
* Re: [RFC] ath10k: replenish HTT RX buffers in a tasklet
From: Kalle Valo @ 2013-09-24 6:59 UTC (permalink / raw)
To: Michal Kazior; +Cc: ath10k, linux-wireless
In-Reply-To: <CA+BoTQ=Tg1Qv8qXqw8++hXiDsBXyeQKDjYesWdNg25ORMQJGRg@mail.gmail.com>
Michal Kazior <michal.kazior@tieto.com> writes:
> On 24 September 2013 08:22, Kalle Valo <kvalo@qca.qualcomm.com> wrote:
>> Michal Kazior <michal.kazior@tieto.com> writes:
>>
>>> This fixes system starvation when under heavy RX
>>> traffic. This problem could be observed on AP135
>>> and led to watchdog resetting the platform.
>>>
>>> Patch starves FW RX ring buffer by progressively
>>> replenishing buffers to auto-balance the RX
>>> handled to the host system.
>>>
>>> Signed-off-by: Michal Kazior <michal.kazior@tieto.com>
>>
>> Looks good to me. I suspect there is a better way to do this in long
>> term, but this looks like a viable short term solution.
>>
>> Does it decrease throughput in a noticeable way?
>
> I have yet to observe any regressions.
Good. If you think the patch should be applied please resend it as
"[PATCH]" so that I can apply it.
--
Kalle Valo
^ permalink raw reply
* Re: [RFC 0/4] ath10k: improve RX performance
From: Michal Kazior @ 2013-09-24 7:19 UTC (permalink / raw)
To: Kalle Valo; +Cc: ath10k, linux-wireless
In-Reply-To: <87mwn2bu0i.fsf@kamboji.qca.qualcomm.com>
On 24 September 2013 08:42, Kalle Valo <kvalo@qca.qualcomm.com> wrote:
> Michal Kazior <michal.kazior@tieto.com> writes:
>
>> This patchset gives clear RX performance
>> improvement on AP135. Throughput is at least
>> doubled (300mbps -> 600mbps, UDP RX, 2x2).
>>
>> Patches depend on my RFC patch "mac80211: support
>> reporting A-MSDU subframes individually".
>
> Preferably I can apply these changes only after the mac80211 patch goes
> to net-next (to avoid unnecessary rebasing). Is there a way to
> workaround the need for the mac80211 patch in ath10k so that we could
> apply these patches ASAP? And once the mac80211 patch is commited we
> could just remove the workaround in ath10k.
The workaround could be to clear the retransmission flag when
reporting A-MSDU frames individually.
Michał.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox