On Wed, Aug 29, 2018 at 04:19:01PM -0400, Jes Sorensen wrote:
> On 08/23/2018 09:36 PM, James Cameron wrote:
> > G'day Carlo, Mylene, and James,
> >
> > Thanks for your earlier reports about RTL8723bu. Have you any more
> > recent experiences you might share?
>
if there is anything I can do to help.
--
James Cameron
http://quozl.netrek.org/
problem.
--
James Cameron
http://quozl.netrek.org/
ngly,
> the ASPM L1 latency has been increased from 0 to 7 to fix the instability.
>
> Signed-off-by: Larry Finger <larry.fin...@lwfinger.net>
> Cc: Stable <sta...@vger.kernel.org>
Tested-by: James Cameron <qu...@laptop.org>
With both patches applied to v4.15 on OLPC
vger.kernel.org; ath9k-
> > de...@qca.qualcomm.com
> > Objet : Re: [PATCH v2] ath9k: mark RSSI as invalid if frame received
> > during channel setup
> >
> > On Thu, Feb 15, 2018 at 07:51:28AM +0200, Kalle Valo wrote:
> > > James Cameron <qu...@laptop.org> writes
On Thu, Feb 15, 2018 at 07:51:28AM +0200, Kalle Valo wrote:
> James Cameron <qu...@laptop.org> writes:
>
> > On Wed, Feb 14, 2018 at 04:26:42PM +, Jean Pierre TOSONI wrote:
> >> ath9k returns a wrong RSSI value for frames received in a 30ms time
> >> window
Firmware may average
several readings. Firmware may apply other offsets or calibrations,
based on frequency and temperature. This sounds like a firmware
problem.
> Signed-off-by: Jean Pierre TOSONI <jp.tos...@acksys.fr>
> [...]
--
James Cameron
http://quozl.netrek.org/
t; Cc: Stable <sta...@vger.kernel.org> # 4.14+
> Fix-suggested-by: Pkshih <pks...@realtek.com>
> Signed-off-by: Larry Finger <larry.fin...@lwfinger.net>
Tested-by: James Cameron <qu...@laptop.org> # x86_64 OLPC NL3
Thanks Larry & Pkshih, this does work as well as it did before.
--
James Cameron
http://quozl.netrek.org/
On Wed, Jan 31, 2018 at 11:06:12AM -0600, Larry Finger wrote:
> On 09/12/2017 05:09 PM, James Cameron wrote:
> >Summary: 40b368af4b75 ("rtlwifi: Fix alignment issues") breaks
> >rtl8821ae keep alive, causing "Connection to AP lost" and deauth,
> >but why?
/net/wireless/marvell/mwifiex/sdio.c
> b/drivers/net/wireless/marvell/mwifiex/sdio.c
> index fd5183c..a828801 100644
> --- a/drivers/net/wireless/marvell/mwifiex/sdio.c
> +++ b/drivers/net/wireless/marvell/mwifiex/sdio.c
> @@ -2505,15 +2505,21 @@ static void mwifiex_sdio_generic_fw_dump(struct
> mwifiex_adapter *adapter)
> static void mwifiex_sdio_device_dump_work(struct mwifiex_adapter *adapter)
> {
> struct sdio_mmc_card *card = adapter->card;
> - int drv_info_size;
> - void *drv_info;
>
> - drv_info_size = mwifiex_drv_info_dump(adapter, _info);
> + adapter->devdump_data = vzalloc(MWIFIEX_FW_DUMP_SIZE);
> + if (!adapter->devdump_data) {
> + mwifiex_dbg(adapter, ERROR,
> + "vzalloc devdump data failure!\n");
> + return;
> + }
> +
> + mwifiex_drv_info_dump(adapter);
> if (card->fw_dump_enh)
> mwifiex_sdio_generic_fw_dump(adapter);
> else
> mwifiex_sdio_fw_dump(adapter);
> - mwifiex_upload_device_dump(adapter, drv_info, drv_info_size);
> + mwifiex_prepare_fw_dump_info(adapter);
> + mwifiex_upload_device_dump(adapter);
> }
>
> static void mwifiex_sdio_work(struct work_struct *work)
> --
> 1.9.1
>
--
James Cameron
http://quozl.netrek.org/
On Tue, Nov 21, 2017 at 09:52:12PM +0100, Rákosi Gergely wrote:
> 2017-11-21 21:37 keltezéssel, James Cameron írta:
> > On Tue, Nov 21, 2017 at 03:08:16PM +0100, Rákosi Gergely wrote:
> >> 2017-11-18 16:52 keltezéssel, Larry Finger írta:
> >>> On 11/17/2017
nk is not ready
[ 469.618926] rtl8723be: Init MAC failed
Looking at _rtl8723be_init_mac, there are two false returns; hardware
power on fail, and llt write fail.
Sorry, I don't have rtl8723be hardware.
Rákosi, did any older kernel keep connection?
--
James Cameron
http://quozl.netrek.org/
uot; is redundant and can be removed.
"accordingly" is also redundant.
Perhaps "Firmware do not support change interface from micro-ap mode
to station mode, forbid this operation."
> Signed-off-by: Cathy Luo <c...@marvell.com>
> Signed-off-by: Xinming Hu <h...@marvel
t;adapter, INFO,
> > > + "Skip change virtual interface\n");
> >
> > Is this message easy to understand? Other messages in the same function
> > seem easier; e.g. "%s: changing to %d not supported\n"
>
> OK.
>
> >
> > > + return 0;
> >
> > Should this be -EOPNOTSUPP rather than 0?
>
> Yes.
>
> >
> > > + }
> > > return mwifiex_change_vif_to_sta_adhoc(dev, curr_iftype,
> > > type, params);
> > > break;
> > > --
> > > 1.9.1
> > >
> >
> > --
> > James Cameron
> > http://quozl.netrek.org/
--
James Cameron
http://quozl.netrek.org/
seem easier; e.g. "%s: changing to %d not supported\n"
> + return 0;
Should this be -EOPNOTSUPP rather than 0?
> + }
> return mwifiex_change_vif_to_sta_adhoc(dev, curr_iftype,
> type, params);
> break;
> --
> 1.9.1
>
--
James Cameron
http://quozl.netrek.org/
oot, which implies there is no
register reset in driver start or device reset, which further implies
that the BIOS can easily affect the outcome.
Check also for different behaviour after cold reboot; that is a power
down for 30 seconds then power up.
Do you yet have a known working kernel to bisect a
On Fri, Oct 27, 2017 at 10:23:54PM -0500, David Ashley wrote:
> On 10/26/17, James Cameron <qu...@laptop.org> wrote:
> > Interesting, thanks. It should be a QFN 46 pin chip; you may have
> > counted 15 instead of 14 pins on the long edge. Send me a photograph
> > of t
On Sat, Oct 28, 2017 at 12:02:30AM +0300, nirinA raseliarison wrote:
> On 10/27/2017 07:57 AM, James Cameron wrote:
> >On Fri, Oct 27, 2017 at 04:08:48AM +0300, nirinA raseliarison wrote:
> >>hi all,
> >>i applied the patch against 4.13.8. i still got some
ing works fine.
Your dmesg looks like you removed and reinserted the wireless device
several times. Did you do that, or did the system do it without any
physical action?
A full dmesg from boot may be interesting, at least to better
understand the USB host controller.
--
James Cameron
http://quozl.netrek.org/
(9 pins, 15 pins, 9 pins, 15 pins)
> REALTEK
> RTL8188CUS
> F6J23P2
> GF27 TAIWAN
>
> 6 pin chip (3 pins,3 pins)
> BZ5JA
>
> 40.0 mhz crystal oscillator
>
> I was thinking maybe some serial eeprom would be included, but there wasn't
> one.
>
> -Dav
power cycle (my
> >> assumption is it doesn't).
> >
> > There is NO firmware coded by the factory in the device. It only has enough
> >
> > intelligence to load the real firmware. The exact file that it loads is
> > determined by the model. If you provide the
On Wed, Oct 25, 2017 at 09:08:17AM +0200, Mario Theodoridis wrote:
> On 24/10/17 23:01, James Cameron wrote:
> >Summary: WARN_ON(iwl_mvm_is_dqa_supported(mvm)) in
> >iwl_mvm_rx_tx_cmd_single with v4.13, but code is since changed.
> >
> >On Tue, Oct 24, 2017 at 09:56:31
ied to.
> On 19.10.2017 22:59, James Cameron wrote:
> >On Thu, Oct 19, 2017 at 08:56:46AM +0200, Mario Theodoridis wrote:
> >>On 18/10/17 23:33, James Cameron wrote:
> >>
> >> For your interest, kernel v4.4.93 in stable series just released has
> >>
");
> - pr_cont("\n");
> +for (i = 0; i < ARRAY_SIZE(irq_name); i++)
> +ints += sprintf(ints, " %s%c",
> + irq_name[i], i == irq ? '*' : ' ');
But not on this line.
> +
> +bcma_debug(dev->bus, "core 0x%04x, irq:%s\n", dev->id.id,
> interrupts);
> }
>
> static void bcma_core_mips_dump_irq(struct bcma_bus *bus)
> --
> 2.10.0.rc2.1.g053435c
>
--
James Cameron
http://quozl.netrek.org/
: 00 00 41 57 31 f6 41 56 41 55 41 54 55 53 48 89 fb e8
> e7 fe ff ff 4c 8b 7b 48 49 8b bf 10 9b 00 00 49 8d af 10 9b 00 00 48 39 ef
> <48> 8b 1f 74 44 49 bd 00 01 00 00 00 00 ad de 49 89 de 49 bc 00
> [ 239.701327] RIP: rtl_deinit_core+0x2e/0x90 [rtlwifi] RSP:
> c99a3b40
> [ 239.702028] CR2:
> [ 239.705370] ---[ end trace 6ec9029c0d9c0e13 ]---
> [ 239.706311] udevd[528]: worker [1174] failed while handling
> '/devices/pci:00/:00:1d.0/usb2/2-1/2-1.3/2-1.3:1.0'
>
--
James Cameron
http://quozl.netrek.org/
On Tue, Oct 17, 2017 at 09:35:39PM +0200, Mario Theodoridis wrote:
> On 16.10.2017 05:37, James Cameron wrote:
> >On Sun, Oct 15, 2017 at 06:21:36PM +0200, Mario Theodoridis wrote:
> >>Thanks for the pointers, James.
> >>
> >>On 12.10.2017 23:24, James Camer
On Sun, Oct 15, 2017 at 06:21:36PM +0200, Mario Theodoridis wrote:
> Thanks for the pointers, James.
>
> On 12.10.2017 23:24, James Cameron wrote:
> >There's a good chance this problem has been fixed already. You
> >are using a v4.4 kernel with many patches applied
lingLTSEnablementStack#hwe-16.04
Hope that helps.
> Thanks.
>
> Regards
>
> Mario
[...]
--
James Cameron
http://quozl.netrek.org/
el/git/next/linux-next.git/log/?qt=grep=Himanshu+Jha
>
> Also, James Cameron suggested me to *not self promot* and other useful
> stuff. But I'm not self promoting and the purpose is to avoid the
> initial steps that you generally recommend to a newbie like reading the
> conding guideli
On Thu, Sep 21, 2017 at 09:40:14AM -0500, Larry Finger wrote:
> On 09/21/2017 03:07 AM, James Cameron wrote:
> >My test kernel "-qb" was write_readback = false in sw.c, with 8-bit
> >read of REG_DBI_RDATA, and has been stable for four hours. I'll
> >focus o
On Thu, Sep 21, 2017 at 09:22:28AM +1000, James Cameron wrote:
> On Wed, Sep 20, 2017 at 04:48:23PM -0500, Larry Finger wrote:
> > On 09/20/2017 04:36 AM, James Cameron wrote:
> > >When the problem occurs, register 0x350 bit 25 is set, for which a
> > >comment in _rt
On Wed, Sep 20, 2017 at 04:48:23PM -0500, Larry Finger wrote:
> On 09/20/2017 04:36 AM, James Cameron wrote:
> >When the problem occurs, register 0x350 bit 25 is set, for which a
> >comment in _rtl8821ae_check_pcie_dma_hang says means there is an RX
> >hang.
> >
>
On Tue, Sep 19, 2017 at 07:42:04PM +1000, James Cameron wrote:
> On Thu, Sep 14, 2017 at 07:27:39PM +1000, James Cameron wrote:
> > On Wed, Sep 13, 2017 at 07:39:35PM -0500, Larry Finger wrote:
> > > On 09/13/2017 04:46 PM, James Cameron wrote:
> > > >
> > >
On Thu, Sep 14, 2017 at 07:27:39PM +1000, James Cameron wrote:
> On Wed, Sep 13, 2017 at 07:39:35PM -0500, Larry Finger wrote:
> > On 09/13/2017 04:46 PM, James Cameron wrote:
> > >
> > >I'll give it some more testing and let you know, but it seems as
> > >cap
Z= BIT(22),
> WIPHY_FLAG_HAS_CHANNEL_SWITCH = BIT(23),
> WIPHY_FLAG_HAS_STATIC_WEP = BIT(24),
> + WIPHY_FLAG_SUPPORT_TDLS_BUFFER_STA = BIT(25),
> };
>
> /**
> [...]
--
James Cameron
http://quozl.netrek.org/
On Wed, Sep 13, 2017 at 07:39:35PM -0500, Larry Finger wrote:
> On 09/13/2017 04:46 PM, James Cameron wrote:
> >
> >I'll give it some more testing and let you know, but it seems as
> >capable of keeping a connection as 4.13 plus my earlier revert.
> >
Testing w
cmp_seq=64 ttl=64 time=1.95 ms
64 bytes from nl3-e.lan (10.0.0.94): icmp_seq=65 ttl=64 time=1.68 ms
I'll give it some more testing and let you know, but it seems as
capable of keeping a connection as 4.13 plus my earlier revert.
--
James Cameron
http://quozl.netrek.org/
this path, my guess is that keep alive is
not being set in the device. Or perhaps reading 16-bits perturbs
another register. Is there a way to test?
http://dev.laptop.org/~quozl/z/1drtGD.txt dmesg of 4.13
http://dev.laptop.org/~quozl/z/1drt7c.txt dmesg with 4.13 and revert
of 40b
cle.com>
Reviewed-by: James Cameron <qu...@laptop.org>
--
James Cameron
http://quozl.netrek.org/
On Tue, Jun 14, 2016 at 05:16:11PM +0400, Pavel Andrianov wrote:
> 08.06.2016 02:51, James Cameron пишет:
> >On Tue, Jun 07, 2016 at 09:39:55AM -0500, Dan Williams wrote:
> >>On Tue, 2016-06-07 at 13:30 +0400, Pavel Andrianov wrote:
> >>>Hi!
> >>>
eal race or I have missed something?
>
> Yeah, it looks like it should be grabbing priv->driver_lock before
> clearing priv->currenttxskb in lbs_mac_event_disconnected(). Care to
> submit a patch after testing? Do you have any of that hardware?
I've hardware, with serial console.
resting, we're back to this symptom again.
Nice to see this fix.
Heavy memory pressure on 3.5 caused dev_alloc_skb failure in this
driver. Tracked at OLPC as #12694.
--
James Cameron
http://quozl.netrek.org/
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
th
goto nla_put_failure;
Braces? { }
> if (ies) {
> memcpy(tmpies, ies, ies_len);
> --
> 1.7.9.5
> --
> To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
> the body of a message to majord...@vger.kernel.org
>
s_802_11_key_material aes_key;
struct host_cmd_ds_802_11_key_material_v2 aes_key_v2;
u8 wapi_ie[256];
- u8 wapi_ie_len;
+ u16 wapi_ie_len;
u8 *wps_ie;
- u8 wps_ie_len;
+ u16 wps_ie_len;
u8 wmm_required;
u8 wmm_enabled;
u8 wmm_qosinfo;
or every channel. There
is a time cost for switching, and a time spent listening on each
channel.
--
James Cameron
http://quozl.linux.org.au/
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
(apart from the issue in this
thread), and I don't have a list of what has changed.
--
James Cameron
http://quozl.linux.org.au/
--
To unsubscribe from this list: send the line unsubscribe linux-wireless in
the body of a message to majord...@vger.kernel.org
More majordomo info at http
remains stable.
fwlps=0 alone was not enough.
ips=0 alone was not enough.
Hope that helps.
--
James Cameron
http://quozl.linux.org.au/
--
To unsubscribe from this list: send the line unsubscribe linux-wireless in
the body of a message to majord...@vger.kernel.org
More majordomo info at http
...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line unsubscribe linux-wireless in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
James Cameron
On Sun, Jun 14, 2015 at 06:13:56PM -0500, Larry Finger wrote:
On 06/14/2015 06:04 PM, James Cameron wrote:
On Sun, Jun 14, 2015 at 10:10:30AM -0500, Larry Finger wrote:
To address your problem, power saving does not work correctly on
this device. That is why there are numerous posts on the web
changes.
(I'm also looking into IBSS, because Sugar desktop relies on
ad-hoc. No beacons on creating an IBSS through NetworkManager, but
beacons are fine with iw dev wlan0 ibss join x 2437. But I'm not
yet ready to report problem; still some debugging to do.)
--
James Cameron
http
see this.
However, our experience may not be comparable; we are using 8787 with
a 3.5 kernel, because we haven't the resources to use a later kernel
or get backports working.
Also, we use WOL (wake on lan) heavily; frequent automatic suspends,
with a GPIO wakeup in addition to the SDHCI.
--
James
?
No use case that doesn't risk interference. I've used it in
diagnosis, and in Open Firmware driver.
I think, we should stick to current implementation of sending 1
probe request.
That's fine.
Regards,
Amitkumar
--
James Cameron
http://quozl.linux.org.au/
--
To unsubscribe from this list
?
--
James Cameron
http://quozl.linux.org.au/
--
To unsubscribe from this list: send the line unsubscribe linux-wireless in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
dropped.
--
James Cameron
--
To unsubscribe from this list: send the line unsubscribe linux-wireless in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
/majordomo-info.html
--
James Cameron
http://quozl.linux.org.au/
--
To unsubscribe from this list: send the line unsubscribe linux-wireless in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
, and
the return -1; that you are removing doesn't seem to leave the card
and driver in a useful state.
Your patch is hopefully an improvement.
Have you done any testing of response after skb allocation failure
before and after your patch?
--
James Cameron
http://quozl.linux.org.au/
--
To unsubscribe
-off-by: Yogesh Ashok Powar yoge...@marvell.com
Signed-off-by: Avinash Patil pat...@marvell.com
Signed-off-by: Nishant Sarmukadam nisha...@marvell.com
Signed-off-by: Cathy Luo c...@marvell.com
Signed-off-by: Frank Huang fra...@marvell.com
Reviewed-by: James Cameron qu...@laptop.org
(Not tested
:
type=%d len=%d max_len=%d\n,
pkt_type, pkt_len,
card-mpa_rx.len_arr[pind]);
--
1.9.1
--
James Cameron
http://quozl.linux.org.au/
--
To unsubscribe from this list: send the line unsubscribe linux-wireless
While preparing an ad-hoc start command, the capability info bitmap is
needlessly set from the command, and then the ESS bit cleared.
Change to set the bitmap directly without reference to the command.
Signed-off-by: James Cameron qu...@laptop.org
---
drivers/net/wireless/mwifiex/join.c | 4
when enough
packets are consumed to solve the problem.
Other drivers and user activity can deplete memory. How does this
patch solve the problem when dev_alloc_skb fails? I'm worried the
underlying issue remains; handling out of memory.
--
James Cameron
http://quozl.linux.org.au
, and timing critical bug
goes away.
Serial console? If so, try turning it off, and logging to dmesg
buffer only.
--
James Cameron
http://quozl.linux.org.au/
--
To unsubscribe from this list: send the line unsubscribe linux-wireless in
the body of a message to majord...@vger.kernel.org
More majordomo info
:+v???w?j?mzZ+?ݢj??!
--
James Cameron
http://quozl.linux.org.au/
--
To unsubscribe from this list: send the line unsubscribe linux-wireless in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
62 matches
Mail list logo
