Re: PROBLEM: network data corruption (bisected to e5a4b0bb803b)

On Wed, Jul 27, 2016 at 08:26:48PM -0400, alexmcwhir...@triadic.us wrote: > I'm going to go ahead and say this is where my issue and the op's issue > begin to branch apart from one another. He's seeing this on all incoming > data, whereas i am only seeing it on ssl data and not on sun4v. > > At

Re: PROBLEM: network data corruption (bisected to e5a4b0bb803b)

On 2016-07-27 20:31, Al Viro wrote: On Wed, Jul 27, 2016 at 04:45:43PM -0700, David Miller wrote: > I highly expect both my issue and OP's issue to revolve not around > commit e5a4b0bb803b specifically, but around other code that no longer > behaves as expected because of it. Indeed, and that

Re: PROBLEM: network data corruption (bisected to e5a4b0bb803b)

On Wed, Jul 27, 2016 at 04:45:43PM -0700, David Miller wrote: > > I highly expect both my issue and OP's issue to revolve not around > > commit e5a4b0bb803b specifically, but around other code that no longer > > behaves as expected because of it. > > Indeed, and that fault address rounding bug

Re: PROBLEM: network data corruption (bisected to e5a4b0bb803b)

From: alexmcwhir...@triadic.us Date: Wed, 27 Jul 2016 19:02:40 -0400 > On 2016-07-27 14:04, alexmcwhir...@triadic.us wrote: >> Just to add some more information to this, the corruption seems to >> effect ssh as well. >> Using a sun hme interface, occasionally upon an ssh connection it will >>

Re: PROBLEM: network data corruption (bisected to e5a4b0bb803b)

On 2016-07-27 14:04, alexmcwhir...@triadic.us wrote: Just to add some more information to this, the corruption seems to effect ssh as well. Using a sun hme interface, occasionally upon an ssh connection it will refuse to authenticate a client with either password or cert authentication. Using

Re: brcm4330 fails to load on newer kernels

Hi Arend, On Wed, Jul 27, 2016 at 5:51 PM, Arend van Spriel wrote: > On 27-07-16 00:35, Fabio Estevam wrote: >> Hi, >> >> On a imx6sl-warp board with a brcm4330 I get the following results >> depending on the kernel version: >> >> - Kernel 4.4.15: place

Re: brcm4330 fails to load on newer kernels

On 27-07-16 00:35, Fabio Estevam wrote: > Hi, > > On a imx6sl-warp board with a brcm4330 I get the following results > depending on the kernel version: > > - Kernel 4.4.15: place brcmfmac4330-sdio.bin and brcmfmac4330-sdio.txt > in the rootfs and the kernel is able to read them correctly. wlan0

Re: PROBLEM: network data corruption (bisected to e5a4b0bb803b)

Just to add some more information to this, the corruption seems to effect ssh as well. Using a sun hme interface, occasionally upon an ssh connection it will refuse to authenticate a client with either password or cert authentication. Using wireshark to capture and decrypt the packets

Re: TCP performance regression in mac80211 triggered by the fq code

Michal Kazior writes: > On 20 July 2016 at 17:24, Toke Høiland-Jørgensen wrote: >> Toke Høiland-Jørgensen writes: >> >>> Felix Fietkau writes: >>> - if I put a hack in the fq code to force the hash to a constant value

Re: [PATCH] ath10k: Allow setting coverage class

On 07/27/2016 01:33 AM, Benjamin Berg wrote: Unfortunately ath10k does not generally allow modifying the coverage class with the stock firmware and Qualcomm has so far refused to implement this feature so that it can be properly supported in ath10k. If we however know the registers that need to

Re: [v3] UCC_GETH/UCC_FAST: Use IS_ERR_VALUE_U32 API to avoid IS_ERR_VALUE abuses.

I am also agree with Arnd Bergmann. We should use 'static inline function' instead of macro to deal with error check. On Tuesday 26 July 2016 05:09 PM, Arnd Bergmann wrote: On Saturday, July 23, 2016 11:35:51 PM CEST Arvind Yadav wrote: diff --git a/include/linux/err.h b/include/linux/err.h

[PATCH] ath10k: Remove driver log suggesting QCA9887 support is experimental

From: Mohammed Shafi Shajakhan Support for QCA9887 is no longer experimental and if there are any issues we need to address them Signed-off-by: Mohammed Shafi Shajakhan --- drivers/net/wireless/ath/ath10k/pci.c | 1 - 1 file changed, 1

Re: [PATCH -next] rtl8xxxu: gen1: Fix non static symbol warning

weiyj...@163.com writes: > From: Wei Yongjun > > Fixes the following sparse warning: > > drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c:898:1: warning: > symbol 'rtl8xxxu_gen1_h2c_cmd' was not declared. Should it be static? > > Signed-off-by: Wei Yongjun

[PATCH 0/1 V3] ath9k: consider return code on ar9300_eeprom_restore_flash

Hi Kale, Just added the two error codes you asked: https://lists.ath9k.org/pipermail/ath9k-devel/2016-July/014686.html Thanks. Eduardo Abinader (1): ath9k: consider return code on ar9300_eeprom_restore_flash drivers/net/wireless/ath/ath9k/ar9003_eeprom.c | 6 -- 1 file changed, 4

[PATCH 1/1 V3] ath9k: consider return code on

just to comply with current ath9k_hw_nvram_read to return value, hence behaving reacting accordingly. Signed-off-by: Eduardo Abinader --- drivers/net/wireless/ath/ath9k/ar9003_eeprom.c | 6 -- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git

Re: [PATCH 2/4] ath10k: Add provision for Rx descriptor abstraction

On 27 July 2016 at 14:59, Thiagarajan, Vasanthakumar wrote: > On Wednesday 27 July 2016 06:13 PM, Michal Kazior wrote: >> On 27 July 2016 at 14:36, Vasanthakumar Thiagarajan [...] >>> --- a/drivers/net/wireless/ath/ath10k/core.c >>> +++

Re: [PATCH 2/4] ath10k: Add provision for Rx descriptor abstraction

On Wednesday 27 July 2016 06:13 PM, Michal Kazior wrote: > On 27 July 2016 at 14:36, Vasanthakumar Thiagarajan > wrote: >> There are slight differences in Rx hw descriptor information >> among different chips. So far driver does not use those new >> information for any

[PATCH] ath10k: Fix rfc1042 header retrieval in QCA4019 with eth decap mode

Chipset from QCA99X0 onwards (QCA99X0, QCA9984, QCA4019 & future) rx_hdr_status is not padded to align in 4-byte boundary. Define a new hw_params field to handle different alignment behaviour between different hw. This patch fixes improper retrieval of rfc1042 header with QCA4019. This patch along

[PATCH 3/4] ath10k: Properly remove padding from the start of rx payload

In QCA99X0 (QCA99X0, QCA9984, QCA9888 and QCA4019) family chips, hw adds padding at the begining of the rx payload to make L3 header 4-byte aligned. In the chips doing this type of padding, the number of bytes padded will be indicated through msdu_end:info1. Define a hw_rx_desc_ops wrapper to

Re: [PATCH 2/4] ath10k: Add provision for Rx descriptor abstraction

On 27 July 2016 at 14:36, Vasanthakumar Thiagarajan wrote: > There are slight differences in Rx hw descriptor information > among different chips. So far driver does not use those new > information for any functionalities, but there is one important > information which

[PATCH 4/4] ath10k: Remove 4-addr padding related hw_param configuration

hw_4addr_pad was added to handle different types of padding in 4-address rx frame. But this padding is not very specific to 4-address, it can happen even with three address + ethernet decap mode. Since the padding information can be obtained through Rx desc for QCA99X0 and newer chips, this

[PATCH 2/4] ath10k: Add provision for Rx descriptor abstraction

There are slight differences in Rx hw descriptor information among different chips. So far driver does not use those new information for any functionalities, but there is one important information which is available from QCA99X0 onwards to indicate the number of bytes that hw padded at the

[PATCH 1/4] ath10k: Move ath10k_hw_params definition to hw.h

This is to prepare for rx descriptor abstraction where we'll be dereferencing ath10k_hw_params member in hw.h. Moreover hw.h looks more suitable to house ath10k_hw_params definition than core.h Signed-off-by: Vasanthakumar Thiagarajan ---

[PATCH 0/4] ath10k: Padding related clean ups in rx

This patch set adds abstraction for rx_hw_desc processing so that we can make use of newer desc fields notifying padding information which is done on rx payload. "ath10k: Properly remove padding from the start of rx payload" fixes padding related bug in ethernet decap mode for QCA99X0, QCA9984 qnd

Re: PROBLEM: network data corruption (bisected to e5a4b0bb803b)

Al Viro wrote: > > Another thing (and if that works, it's *NOT* a proper fix - it would be > papering over the problem, but at least it would show where to look for > it) - try (on top of mainline) the following delta: I tried it on top of v4.6.4 and on top of the very recent v4.7-2509-g59ebc44

Re: [PATCH] ath10k: Allow setting coverage class

Hi, [auto build test ERROR on ath6kl/ath-next] [also build test ERROR on next-20160727] [cannot apply to v4.7] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/Benjamin-Berg/ath10k-Allow-setting

Re: [PATCH] ath10k: Allow setting coverage class

On 27 July 2016 at 10:33, Benjamin Berg wrote: > Unfortunately ath10k does not generally allow modifying the coverage class > with the stock firmware and Qualcomm has so far refused to implement this > feature so that it can be properly supported in ath10k. If we

[PATCH] ath10k: Allow setting coverage class

Unfortunately ath10k does not generally allow modifying the coverage class with the stock firmware and Qualcomm has so far refused to implement this feature so that it can be properly supported in ath10k. If we however know the registers that need to be modified for proper operation with a higher

Re: PROBLEM: network data corruption (bisected to e5a4b0bb803b)

alexmcwhir...@triadic.us writes: > On 2016-07-26 09:59, Christian Lamparter wrote: >> Thanks, I gave the program a try with my WNDA3100 and a WN821N v2 >> devices. >> I did not see any corruptions in any of the tests though. Can you >> tell me >> something about your wireless network too? I would