* Re: [PATCH 2/2] ath9k: disable RNG by default
From: Stephan Mueller @ 2016-08-09 10:06 UTC (permalink / raw)
To: Herbert Xu
Cc: Pan, Miaoqing, Matt Mackall, miaoqing@codeaurora.org, Valo, Kalle,
linux-wireless@vger.kernel.org, ath9k-devel,
linux-crypto@vger.kernel.org, jason@lakedaemon.net,
Sepehrdad, Pouyan
In-Reply-To: <20160809095657.GB6618@gondor.apana.org.au>
Am Dienstag, 9. August 2016, 17:56:57 CEST schrieb Herbert Xu:
Hi Herbert,
> On Tue, Aug 09, 2016 at 11:56:08AM +0200, Stephan Mueller wrote:
> > Am Dienstag, 9. August 2016, 17:46:56 CEST schrieb Herbert Xu:
> >
> > Hi Herbert,
> >
> > > You're supposed to tweak the quality of the input. In any case,
> >
> > How is that tweak supposed to happen? The rngd does not allow changing the
> > amount of read data relative to the assumed entropy.
>
> Hmm, I guess it depends on your distro. Some do.
>
> Cheers,
RHEL 7 and Fedora do not adjust it. So, shall we consider those rng-tools then
broken (at least in those large distros)?
Ciao
Stephan
^ permalink raw reply
* Re: [PATCH 2/2] ath9k: disable RNG by default
From: Herbert Xu @ 2016-08-09 9:56 UTC (permalink / raw)
To: Stephan Mueller
Cc: Pan, Miaoqing, Matt Mackall, miaoqing@codeaurora.org, Valo, Kalle,
linux-wireless@vger.kernel.org, ath9k-devel,
linux-crypto@vger.kernel.org, jason@lakedaemon.net,
Sepehrdad, Pouyan
In-Reply-To: <12791731.pG3fmEhvyp@tauon.atsec.com>
On Tue, Aug 09, 2016 at 11:56:08AM +0200, Stephan Mueller wrote:
> Am Dienstag, 9. August 2016, 17:46:56 CEST schrieb Herbert Xu:
>
> Hi Herbert,
> >
> > You're supposed to tweak the quality of the input. In any case,
>
> How is that tweak supposed to happen? The rngd does not allow changing the
> amount of read data relative to the assumed entropy.
Hmm, I guess it depends on your distro. Some do.
Cheers,
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [PATCH 2/2] ath9k: disable RNG by default
From: Stephan Mueller @ 2016-08-09 9:56 UTC (permalink / raw)
To: Herbert Xu
Cc: Pan, Miaoqing, Matt Mackall, miaoqing@codeaurora.org, Valo, Kalle,
linux-wireless@vger.kernel.org, ath9k-devel,
linux-crypto@vger.kernel.org, jason@lakedaemon.net,
Sepehrdad, Pouyan
In-Reply-To: <20160809094656.GB6529@gondor.apana.org.au>
Am Dienstag, 9. August 2016, 17:46:56 CEST schrieb Herbert Xu:
Hi Herbert,
>
> You're supposed to tweak the quality of the input. In any case,
How is that tweak supposed to happen? The rngd does not allow changing the
amount of read data relative to the assumed entropy.
> this is not affected by whether we whiten the result.
I understand that.
Ciao
Stephan
^ permalink raw reply
* Re: [PATCH 2/2] ath9k: disable RNG by default
From: Herbert Xu @ 2016-08-09 9:46 UTC (permalink / raw)
To: Stephan Mueller
Cc: Pan, Miaoqing, Matt Mackall, miaoqing@codeaurora.org, Valo, Kalle,
linux-wireless@vger.kernel.org, ath9k-devel,
linux-crypto@vger.kernel.org, jason@lakedaemon.net,
Sepehrdad, Pouyan
In-Reply-To: <1645997.7cVzaEi3NG@tauon.atsec.com>
On Tue, Aug 09, 2016 at 11:37:39AM +0200, Stephan Mueller wrote:
> Am Dienstag, 9. August 2016, 17:17:55 CEST schrieb Herbert Xu:
>
> Hi Herbert,
>
> > On Tue, Aug 09, 2016 at 11:02:58AM +0200, Stephan Mueller wrote:
> > > But shouldn't the default of the rngd then be adjusted a bit?
> >
> > Please elaborate.
>
> in rngd_linux.c:random_add_entropy(void *buf, size_t size):
>
> entropy.ent_count = size * 8;
> entropy.size = size;
> memcpy(entropy.data, buf, size);
>
> if (ioctl(random_fd, RNDADDENTROPY, &entropy) != 0) {
>
> ...
>
>
> in rngd.c:do_loop():
>
> retval = iter->xread(buf, sizeof buf, iter);
> ...
> rc = update_kernel_random(random_step,
> buf, iter->fipsctx);
>
> where update_kernel_random simply invokes random_add_entropy in chunks.
>
> Hence, the rngd reads some bytes from /dev/hwrand and injects it into /dev/
> random with an entropy estimate that is equal to the read bytes.
>
> With less than perfect noise sources, entropy.ent_count should be much
> smaller.
You're supposed to tweak the quality of the input. In any case,
this is not affected by whether we whiten the result.
Cheers,
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [PATCH 2/2] ath9k: disable RNG by default
From: Stephan Mueller @ 2016-08-09 9:37 UTC (permalink / raw)
To: Herbert Xu
Cc: Pan, Miaoqing, Matt Mackall, miaoqing@codeaurora.org, Valo, Kalle,
linux-wireless@vger.kernel.org, ath9k-devel,
linux-crypto@vger.kernel.org, jason@lakedaemon.net,
Sepehrdad, Pouyan
In-Reply-To: <20160809091755.GA6370@gondor.apana.org.au>
Am Dienstag, 9. August 2016, 17:17:55 CEST schrieb Herbert Xu:
Hi Herbert,
> On Tue, Aug 09, 2016 at 11:02:58AM +0200, Stephan Mueller wrote:
> > But shouldn't the default of the rngd then be adjusted a bit?
>
> Please elaborate.
in rngd_linux.c:random_add_entropy(void *buf, size_t size):
entropy.ent_count = size * 8;
entropy.size = size;
memcpy(entropy.data, buf, size);
if (ioctl(random_fd, RNDADDENTROPY, &entropy) != 0) {
...
in rngd.c:do_loop():
retval = iter->xread(buf, sizeof buf, iter);
...
rc = update_kernel_random(random_step,
buf, iter->fipsctx);
where update_kernel_random simply invokes random_add_entropy in chunks.
Hence, the rngd reads some bytes from /dev/hwrand and injects it into /dev/
random with an entropy estimate that is equal to the read bytes.
With less than perfect noise sources, entropy.ent_count should be much
smaller.
>
> Thanks,
Ciao
Stephan
^ permalink raw reply
* Re: [PATCH 2/2] ath9k: disable RNG by default
From: Herbert Xu @ 2016-08-09 9:17 UTC (permalink / raw)
To: Stephan Mueller
Cc: Pan, Miaoqing, Matt Mackall, miaoqing@codeaurora.org, Valo, Kalle,
linux-wireless@vger.kernel.org, ath9k-devel,
linux-crypto@vger.kernel.org, jason@lakedaemon.net,
Sepehrdad, Pouyan
In-Reply-To: <2569442.q63FVBJjUH@tauon.atsec.com>
On Tue, Aug 09, 2016 at 11:02:58AM +0200, Stephan Mueller wrote:
>
> But shouldn't the default of the rngd then be adjusted a bit?
Please elaborate.
Thanks,
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [PATCH 2/2] ath9k: disable RNG by default
From: Stephan Mueller @ 2016-08-09 9:02 UTC (permalink / raw)
To: Herbert Xu
Cc: Pan, Miaoqing, Matt Mackall, miaoqing@codeaurora.org, Valo, Kalle,
linux-wireless@vger.kernel.org, ath9k-devel,
linux-crypto@vger.kernel.org, jason@lakedaemon.net,
Sepehrdad, Pouyan
In-Reply-To: <20160809085858.GA6172@gondor.apana.org.au>
Am Dienstag, 9. August 2016, 16:58:58 CEST schrieb Herbert Xu:
Hi Herbert,
> On Tue, Aug 09, 2016 at 10:07:29AM +0200, Stephan Mueller wrote:
> > Herbert, Matt, should such noise sources be added to the HW random
> > framework? The thing is that the in-kernel HW random to input_pool link
> > per default uses a more conservative entropy estimate than the user space
> > rngd. I would think that the in-kernel link would appropriate for that
> > rng. But the user space rngd tool with its default behavior is not really
> > suited here.
>
> Yes hwrng would be the best fit, with a quality of zero to be safe.
>
> Contrary to the quoted thread, there is no need to whiten the output
> /dev/hw_random. It was always meant to go through some intermediate
> processing such as rngd before it is used.
But shouldn't the default of the rngd then be adjusted a bit?
>
> Cheers,
Ciao
Stephan
^ permalink raw reply
* Re: [PATCH 2/2] ath9k: disable RNG by default
From: Herbert Xu @ 2016-08-09 8:58 UTC (permalink / raw)
To: Stephan Mueller
Cc: Pan, Miaoqing, Matt Mackall, miaoqing@codeaurora.org, Valo, Kalle,
linux-wireless@vger.kernel.org, ath9k-devel,
linux-crypto@vger.kernel.org, jason@lakedaemon.net,
Sepehrdad, Pouyan
In-Reply-To: <4731753.YZZKimtrHM@tauon.atsec.com>
On Tue, Aug 09, 2016 at 10:07:29AM +0200, Stephan Mueller wrote:
>
> Herbert, Matt, should such noise sources be added to the HW random framework?
> The thing is that the in-kernel HW random to input_pool link per default uses
> a more conservative entropy estimate than the user space rngd. I would think
> that the in-kernel link would appropriate for that rng. But the user space
> rngd tool with its default behavior is not really suited here.
Yes hwrng would be the best fit, with a quality of zero to be safe.
Contrary to the quoted thread, there is no need to whiten the output
/dev/hw_random. It was always meant to go through some intermediate
processing such as rngd before it is used.
Cheers,
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [PATCH 2/2] ath9k: disable RNG by default
From: Stephan Mueller @ 2016-08-09 8:07 UTC (permalink / raw)
To: Pan, Miaoqing, herbert, Matt Mackall
Cc: miaoqing@codeaurora.org, Valo, Kalle,
linux-wireless@vger.kernel.org, ath9k-devel,
linux-crypto@vger.kernel.org, jason@lakedaemon.net,
Sepehrdad, Pouyan
In-Reply-To: <69af156ac93a4fe6ab1844dfcc35c266@aptaiexm02f.ap.qualcomm.com>
Am Dienstag, 9. August 2016, 07:35:33 CEST schrieb Pan, Miaoqing:
Hi Miaoqing, Herbert, Matt,
> Hi Stephan,
>
> So your suggestion is to use HW Random framework ? Actually, which was
> done by the commit 6301566e0b2d ("ath9k: export HW random number
> generator"), but it was reverted, you can refer to
> https://www.mail-archive.com/linux-crypto%40vger.kernel.org/msg15483.html
> for more information.
I see, it is the same RNG we talked about earlier. The issue is that the
suggested rngd per default assumes one bit of entropy with every data bit.
This is not given with this noise source. This is the basis of my reply last
time.
Herbert, Matt, should such noise sources be added to the HW random framework?
The thing is that the in-kernel HW random to input_pool link per default uses
a more conservative entropy estimate than the user space rngd. I would think
that the in-kernel link would appropriate for that rng. But the user space
rngd tool with its default behavior is not really suited here.
Thanks
Stephan
^ permalink raw reply
* Re: [PATCH v4] cfg80211: Provision to allow the support for different beacon intervals
From: Johannes Berg @ 2016-08-09 7:56 UTC (permalink / raw)
To: Undekari, Sunil Dutt, Kushwaha, Purushottam
Cc: linux-wireless@vger.kernel.org, Malinen, Jouni,
Kondabattini, Ganesh, Kalikot Veetil, Mahesh Kumar,
Hullur Subramanyam, Amarnath, Kumar, Deepak (QCA)
In-Reply-To: <9513d3caf9354aeda408f65128b4a079@aphydexm01f.ap.qualcomm.com>
> I guess , we can extend this to mesh and IBSS as well.
I don't know what your firmware/hardware capabilities are :)
> > It seems to me that if I were to specify beacon intervals which
> > have a very small GCD, you'll run into trouble when actually
> > sending beacons.
> > Perhaps there should be a requirement on the GCD?
> Can we have this published by the host drivers through a new wiphy
> parameter , say "min_diff_beacon_interval_multiplier". This set's the
> expectation that any different beacon intervals on the wiphy shall
> be a multiple of this parameter which is advertised by the host
> driver , isn't ?
>
I'd argue that instead of having the interface combinations flag, that
nl80211 attribute could carry the GCD?
johannes
^ permalink raw reply
* RE: [PATCH 2/2] ath9k: disable RNG by default
From: Pan, Miaoqing @ 2016-08-09 7:35 UTC (permalink / raw)
To: Stephan Mueller, miaoqing@codeaurora.org
Cc: Valo, Kalle, linux-wireless@vger.kernel.org, ath9k-devel,
linux-crypto@vger.kernel.org, jason@lakedaemon.net,
Sepehrdad, Pouyan
In-Reply-To: <4627645.oz3l49ICL3@tauon.atsec.com>
Hi Stephan,
So your suggestion is to use HW Random framework ? Actually, which was done by the commit 6301566e0b2d ("ath9k: export HW random number generator"), but it was reverted, you can refer to https://www.mail-archive.com/linux-crypto%40vger.kernel.org/msg15483.html for more information.
--
Miaoqing
-----Original Message-----
From: Stephan Mueller [mailto:smueller@chronox.de]
Sent: Tuesday, August 09, 2016 3:15 PM
To: miaoqing@codeaurora.org
Cc: Valo, Kalle <kvalo@qca.qualcomm.com>; linux-wireless@vger.kernel.org; ath9k-devel <ath9k-devel@qca.qualcomm.com>; linux-crypto@vger.kernel.org; jason@lakedaemon.net; Sepehrdad, Pouyan <pouyans@qti.qualcomm.com>
Subject: Re: [PATCH 2/2] ath9k: disable RNG by default
Am Dienstag, 9. August 2016, 15:02:27 CEST schrieb miaoqing@codeaurora.org:
Hi Miaoqing,
> From: Miaoqing Pan <miaoqing@codeaurora.org>
>
> ath9k RNG will dominates all the noise sources from the real HW RNG,
> disable it by default. But we strongly recommand to enable it if the
> system without HW RNG, especially on embedded systems.
>
> Signed-off-by: Miaoqing Pan <miaoqing@codeaurora.org>
As a short term solution:
Acked-by: Stephan Mueller <smueller@chronox.de>
But as Jason outlined, there should be nothing that prevents using this code with the HW Random framework. This framework also has logic to limit the rate of injection and allows the setting of the entropy threshold at runtime.
> ---
> drivers/net/wireless/ath/ath9k/Kconfig | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/net/wireless/ath/ath9k/Kconfig
> b/drivers/net/wireless/ath/ath9k/Kconfig index f68cb00..8f231c6 100644
> --- a/drivers/net/wireless/ath/ath9k/Kconfig
> +++ b/drivers/net/wireless/ath/ath9k/Kconfig
> @@ -180,7 +180,7 @@ config ATH9K_HTC_DEBUGFS config ATH9K_HWRNG
> bool "Random number generator support"
> depends on ATH9K && (HW_RANDOM = y || HW_RANDOM = ATH9K)
> - default y
> + default n
> ---help---
> This option incorporates the ADC register output as a source of
> randomness into Linux entropy pool (/dev/urandom and /dev/random)
Ciao
Stephan
^ permalink raw reply
* Re: [PATCH 2/2] ath9k: disable RNG by default
From: Stephan Mueller @ 2016-08-09 7:14 UTC (permalink / raw)
To: miaoqing; +Cc: kvalo, linux-wireless, ath9k-devel, linux-crypto, jason, pouyans
In-Reply-To: <1470726147-30095-2-git-send-email-miaoqing@codeaurora.org>
Am Dienstag, 9. August 2016, 15:02:27 CEST schrieb miaoqing@codeaurora.org:
Hi Miaoqing,
> From: Miaoqing Pan <miaoqing@codeaurora.org>
>
> ath9k RNG will dominates all the noise sources from the real HW
> RNG, disable it by default. But we strongly recommand to enable
> it if the system without HW RNG, especially on embedded systems.
>
> Signed-off-by: Miaoqing Pan <miaoqing@codeaurora.org>
As a short term solution:
Acked-by: Stephan Mueller <smueller@chronox.de>
But as Jason outlined, there should be nothing that prevents using this code
with the HW Random framework. This framework also has logic to limit the rate
of injection and allows the setting of the entropy threshold at runtime.
> ---
> drivers/net/wireless/ath/ath9k/Kconfig | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/net/wireless/ath/ath9k/Kconfig
> b/drivers/net/wireless/ath/ath9k/Kconfig index f68cb00..8f231c6 100644
> --- a/drivers/net/wireless/ath/ath9k/Kconfig
> +++ b/drivers/net/wireless/ath/ath9k/Kconfig
> @@ -180,7 +180,7 @@ config ATH9K_HTC_DEBUGFS
> config ATH9K_HWRNG
> bool "Random number generator support"
> depends on ATH9K && (HW_RANDOM = y || HW_RANDOM = ATH9K)
> - default y
> + default n
> ---help---
> This option incorporates the ADC register output as a source of
> randomness into Linux entropy pool (/dev/urandom and /dev/random)
Ciao
Stephan
^ permalink raw reply
* Re: [BUG] 4.8-rc1: wlcore: NULL pointer dereference in wlcore_op_get_expected_throughput
From: H. Nikolaus Schaller @ 2016-08-09 7:09 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless, LKML, Discussions about the Letux Kernel
In-Reply-To: <1470724641.28531.6.camel@sipsolutions.net>
> Am 09.08.2016 um 08:37 schrieb Johannes Berg <johannes@sipsolutions.net>:
>
> 2439ca0402091badb24415e1b073ba12b34ba423
Ah, nice!
Thanks,
Nikolaus
^ permalink raw reply
* [PATCH 2/2] ath9k: disable RNG by default
From: miaoqing @ 2016-08-09 7:02 UTC (permalink / raw)
To: kvalo
Cc: linux-wireless, ath9k-devel, linux-crypto, smueller, jason,
pouyans, Miaoqing Pan
In-Reply-To: <1470726147-30095-1-git-send-email-miaoqing@codeaurora.org>
From: Miaoqing Pan <miaoqing@codeaurora.org>
ath9k RNG will dominates all the noise sources from the real HW
RNG, disable it by default. But we strongly recommand to enable
it if the system without HW RNG, especially on embedded systems.
Signed-off-by: Miaoqing Pan <miaoqing@codeaurora.org>
---
drivers/net/wireless/ath/ath9k/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/wireless/ath/ath9k/Kconfig b/drivers/net/wireless/ath/ath9k/Kconfig
index f68cb00..8f231c6 100644
--- a/drivers/net/wireless/ath/ath9k/Kconfig
+++ b/drivers/net/wireless/ath/ath9k/Kconfig
@@ -180,7 +180,7 @@ config ATH9K_HTC_DEBUGFS
config ATH9K_HWRNG
bool "Random number generator support"
depends on ATH9K && (HW_RANDOM = y || HW_RANDOM = ATH9K)
- default y
+ default n
---help---
This option incorporates the ADC register output as a source of
randomness into Linux entropy pool (/dev/urandom and /dev/random)
--
1.9.1
^ permalink raw reply related
* [PATCH 1/2] ath9k: change entropy formula for easier understanding
From: miaoqing @ 2016-08-09 7:02 UTC (permalink / raw)
To: kvalo
Cc: linux-wireless, ath9k-devel, linux-crypto, smueller, jason,
pouyans, Miaoqing Pan
From: Miaoqing Pan <miaoqing@codeaurora.org>
The quality of ADC entropy is 10 bits of min-entropy for
a 32-bit value, change '(((x) * 8 * 320) >> 10)' to
'(((x) * 8 * 10) >> 5)' for easier understanding.
Signed-off-by: Miaoqing Pan <miaoqing@codeaurora.org>
---
drivers/net/wireless/ath/ath9k/rng.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/wireless/ath/ath9k/rng.c b/drivers/net/wireless/ath/ath9k/rng.c
index d38e50f..568b1c6 100644
--- a/drivers/net/wireless/ath/ath9k/rng.c
+++ b/drivers/net/wireless/ath/ath9k/rng.c
@@ -22,7 +22,7 @@
#include "ar9003_phy.h"
#define ATH9K_RNG_BUF_SIZE 320
-#define ATH9K_RNG_ENTROPY(x) (((x) * 8 * 320) >> 10) /* quality: 320/1024 */
+#define ATH9K_RNG_ENTROPY(x) (((x) * 8 * 10) >> 5) /* quality: 10/32 */
static int ath9k_rng_data_read(struct ath_softc *sc, u32 *buf, u32 buf_size)
{
--
1.9.1
^ permalink raw reply related
* Re: [BUG] 4.8-rc1: wlcore: NULL pointer dereference in wlcore_op_get_expected_throughput
From: Johannes Berg @ 2016-08-09 6:37 UTC (permalink / raw)
To: H. Nikolaus Schaller, linux-wireless
Cc: LKML, Discussions about the Letux Kernel
In-Reply-To: <4FEB5780-826B-49C3-81E9-D361CD12DD4A@goldelico.com>
On Mon, 2016-08-08 at 23:26 +0200, H. Nikolaus Schaller wrote:
> Here is what I see in 4.8-rc1 on Pyra device after typing "poweroff".
> I hope someone knows what it means.
>
> BR and thanks,
> Nikolaus
[snip]
> [ 616.041894] [<bf4de050>] (wlcore_op_get_expected_throughput
> [wlcore]) from [<bf40cf20>] (sta_set_sinfo+0xc18/0x1110 [mac80211])
> [ 616.054542] [<bf40cf20>] (sta_set_sinfo [mac80211]) from
[snip]
This is already fixed by 2439ca0402091badb24415e1b073ba12b34ba423
johannes
>
^ permalink raw reply
* Re: Wireless Workshop accepted into the 2016 Linux Kernel Summit and Linux Plumbers Conference
From: Johannes Berg @ 2016-08-09 6:35 UTC (permalink / raw)
To: linux-wireless
In-Reply-To: <1470724262.28531.2.camel@sipsolutions.net>
On Tue, 2016-08-09 at 08:31 +0200, Johannes Berg wrote:
> Please make plans as soon as you can [...]
To clarify - I'm not asking you to book travel right now now, but be
reasonably sure that you'll be able to attend *and tell me* (or add
yourself to the wiki page), so that I can sort out the registration
situation.
johannes
^ permalink raw reply
* [PATCH v2] ath10k: fix group privacy action frame decryption for qca4019
From: Rajkumar Manoharan @ 2016-08-09 6:31 UTC (permalink / raw)
To: ath10k; +Cc: linux-wireless, rmanohar, Rajkumar Manoharan
Recent commit 'mac80211: Encrypt "Group addressed privacy" action frames'
encrypts group privacy action frames. But qca99x0 family chipset delivers
broadcast/multicast management frames as encrypted and it should be
decrypted by mac80211. Setting RX_FLAG_DECRYPTED stats for those frames
is breaking mesh connection establishment.
Signed-off-by: Rajkumar Manoharan <rmanohar@qti.qualcomm.com>
---
v2: is_broadcast_ether_addr check not needed
drivers/net/wireless/ath/ath10k/core.c | 4 ++++
drivers/net/wireless/ath/ath10k/core.h | 5 +++++
drivers/net/wireless/ath/ath10k/wmi.c | 29 ++++++++++++++++++++++++-----
3 files changed, 33 insertions(+), 5 deletions(-)
diff --git a/drivers/net/wireless/ath/ath10k/core.c b/drivers/net/wireless/ath/ath10k/core.c
index 0ca58cf0ffea..c4d1a5ba216e 100644
--- a/drivers/net/wireless/ath/ath10k/core.c
+++ b/drivers/net/wireless/ath/ath10k/core.c
@@ -182,6 +182,7 @@ static const struct ath10k_hw_params ath10k_hw_params_list[] = {
.board_size = QCA99X0_BOARD_DATA_SZ,
.board_ext_size = QCA99X0_BOARD_EXT_DATA_SZ,
},
+ .sw_decrypt_mcast_mgmt = true,
},
{
.id = QCA9984_HW_1_0_DEV_VERSION,
@@ -205,6 +206,7 @@ static const struct ath10k_hw_params ath10k_hw_params_list[] = {
.board_size = QCA99X0_BOARD_DATA_SZ,
.board_ext_size = QCA99X0_BOARD_EXT_DATA_SZ,
},
+ .sw_decrypt_mcast_mgmt = true,
},
{
.id = QCA9888_HW_2_0_DEV_VERSION,
@@ -227,6 +229,7 @@ static const struct ath10k_hw_params ath10k_hw_params_list[] = {
.board_size = QCA99X0_BOARD_DATA_SZ,
.board_ext_size = QCA99X0_BOARD_EXT_DATA_SZ,
},
+ .sw_decrypt_mcast_mgmt = true,
},
{
.id = QCA9377_HW_1_0_DEV_VERSION,
@@ -285,6 +288,7 @@ static const struct ath10k_hw_params ath10k_hw_params_list[] = {
.board_size = QCA4019_BOARD_DATA_SZ,
.board_ext_size = QCA4019_BOARD_EXT_DATA_SZ,
},
+ .sw_decrypt_mcast_mgmt = true,
},
};
diff --git a/drivers/net/wireless/ath/ath10k/core.h b/drivers/net/wireless/ath/ath10k/core.h
index f36c2b274ee5..7254bd3e7c82 100644
--- a/drivers/net/wireless/ath/ath10k/core.h
+++ b/drivers/net/wireless/ath/ath10k/core.h
@@ -765,6 +765,11 @@ struct ath10k {
size_t board_size;
size_t board_ext_size;
} fw;
+
+ /* qca99x0 family chips deliver broadcast/multicast management
+ * frames encrypted and expect software do decryption.
+ */
+ bool sw_decrypt_mcast_mgmt;
} hw_params;
/* contains the firmware images used with ATH10K_FIRMWARE_MODE_NORMAL */
diff --git a/drivers/net/wireless/ath/ath10k/wmi.c b/drivers/net/wireless/ath/ath10k/wmi.c
index 169cd2e783eb..29b7eca071fc 100644
--- a/drivers/net/wireless/ath/ath10k/wmi.c
+++ b/drivers/net/wireless/ath/ath10k/wmi.c
@@ -2240,6 +2240,29 @@ static int ath10k_wmi_10_4_op_pull_mgmt_rx_ev(struct ath10k *ar,
return 0;
}
+static bool ath10k_wmi_rx_is_decrypted(struct ath10k *ar,
+ struct ieee80211_hdr *hdr)
+{
+ if (!ieee80211_has_protected(hdr->frame_control))
+ return false;
+
+ /* FW delivers WEP Shared Auth frame with Protected Bit set and
+ * encrypted payload. However in case of PMF it delivers decrypted
+ * frames with Protected Bit set.
+ */
+ if (ieee80211_is_auth(hdr->frame_control))
+ return false;
+
+ /* qca99x0 based FW delivers broadcast or multicast management frames
+ * (ex: group privacy action frames in mesh) as encrypted payload.
+ */
+ if (is_multicast_ether_addr(ieee80211_get_DA(hdr)) &&
+ ar->hw_params.sw_decrypt_mcast_mgmt)
+ return false;
+
+ return true;
+}
+
int ath10k_wmi_event_mgmt_rx(struct ath10k *ar, struct sk_buff *skb)
{
struct wmi_mgmt_rx_ev_arg arg = {};
@@ -2326,11 +2349,7 @@ int ath10k_wmi_event_mgmt_rx(struct ath10k *ar, struct sk_buff *skb)
ath10k_wmi_handle_wep_reauth(ar, skb, status);
- /* FW delivers WEP Shared Auth frame with Protected Bit set and
- * encrypted payload. However in case of PMF it delivers decrypted
- * frames with Protected Bit set. */
- if (ieee80211_has_protected(hdr->frame_control) &&
- !ieee80211_is_auth(hdr->frame_control)) {
+ if (ath10k_wmi_rx_is_decrypted(ar, hdr)) {
status->flag |= RX_FLAG_DECRYPTED;
if (!ieee80211_is_action(hdr->frame_control) &&
--
2.9.2
^ permalink raw reply related
* Re: Wireless Workshop accepted into the 2016 Linux Kernel Summit and Linux Plumbers Conference
From: Johannes Berg @ 2016-08-09 6:31 UTC (permalink / raw)
To: linux-wireless
In-Reply-To: <1470331975.29954.9.camel@sipsolutions.net>
> Please consider adding yourself, I have a number of free/reduced
> passes to hand out so I'll assign those maybe next week. You do need
> to be registered for LPC, which is currently closed for
> registrations, but I'm trying to see if we can get reservations or
> maybe workshop-only tickets.
Instead of that, we also have some reserved passes at a full rate now.
Please make plans as soon as you can, if you intend to participate.
I want to hand those out (getting the names to the LPC committee)
before full registration opens on August 27th. First come first serve,
since I don't have a better mechanism.
johannes
^ permalink raw reply
* RE: [PATCH v2] RANDOM: ATH9K RNG delivers zero bits of entropy
From: Pan, Miaoqing @ 2016-08-09 6:30 UTC (permalink / raw)
To: Jason Cooper, Stephan Mueller
Cc: Ted Tso, Sepehrdad, Pouyan, herbert@gondor.apana.org.au,
linux-kernel@vger.kernel.org, linux-crypto@vger.kernel.org,
ath9k-devel, linux-wireless@vger.kernel.org,
ath9k-devel@lists.ath9k.org, Kalle Valo
In-Reply-To: <20160808172930.GD4511@io.lakedaemon.net>
Hi Jason, Stephan,
Agree with Jason's point, also understand Stephan's concern. The date rate can be roughly estimated by 'cat /dev/random |rngtest -c 1000', the average speed is 1111.294Kibits/s. I will sent the patch to disable ath9k RNG by default.
Thanks,
Miaoqing
-----Original Message-----
From: Jason Cooper [mailto:jason@lakedaemon.net]
Sent: Tuesday, August 09, 2016 1:30 AM
To: Stephan Mueller <smueller@chronox.de>
Cc: Pan, Miaoqing <miaoqing@qti.qualcomm.com>; Ted Tso <tytso@mit.edu>; Sepehrdad, Pouyan <pouyans@qti.qualcomm.com>; herbert@gondor.apana.org.au; linux-kernel@vger.kernel.org; linux-crypto@vger.kernel.org; ath9k-devel <ath9k-devel@qca.qualcomm.com>; linux-wireless@vger.kernel.org; ath9k-devel@lists.ath9k.org; Kalle Valo <kvalo@codeaurora.org>
Subject: Re: [PATCH v2] RANDOM: ATH9K RNG delivers zero bits of entropy
Hi Stephan, Miaoqing Pan,
On Mon, Aug 08, 2016 at 08:41:36AM +0200, Stephan Mueller wrote:
> Am Montag, 8. August 2016, 02:03:36 CEST schrieb Pan, Miaoqing:
> > The entropy was evaluated by crypto expert, the analysis report
> > show the ADC with at least 10bits and up to 22 bits of min-entropy
> > for a 32 bits value, we conservatively assume the min-entropy is 10
> > bits out of 32 bits, so that's why set entropy quality to 320/1024 = 10/32.
Ok, so the relevant commit is:
ed14dc0af7cce ath9k: feeding entropy in kernel from ADC capture
Which refers to a previous commit:
6301566e0b2d ath9k: export HW random number generator
> > Also we have explained in the commit message why can't use the HW
> > RNG framework.
>From ed14dc0af7cce:
"""
Since ADC was not designed to be a dedicated HW RNG, we do not want to bind it to /dev/hwrng framework directly.
"""
> Where is the description of the RNG, where is the test implementation?
> >
> > Otherwise, your patch will cause high CPU load, as continuously
> > read ADC data if entropy bits under write_wakeup_threshold.
>
> The issue is that although you may have analyzed it, others are unable
> to measure the quality of the RNG and assess the design as well as the
> implementation of the RNG. This RNG is the only implementation of a
> hardware RNG that per default and without being able to change it at
> runtime injects data into the input_pool where the noise source cannot
> be audited. Note, even other respected RNG noise sources like the
> Intel RDRAND will not feed into / dev/random per default in a way that dominates all other noise sources.
>
> I would like to be able to deactivate that noise source to the extent
> that it does not cause /dev/random to unblock. The reason is that your
> noise source starts to dominate all other noise sources.
I think the short-term problem here is the config logic:
config ATH9K_HWRNG
bool "Random number generator support"
depends on ATH9K && (HW_RANDOM = y || HW_RANDOM = ATH9K)
default y
If you have *any* hwrngs you want to use and you have an ath9k card (HW_RANDOM = y and ATH9K != n), you get the behavior Stephan is pointing out.
Short term, we should just default no here.
> If you think that this patch is a challenge because your driver starts
> to spin, please help and offer another solution.
Well, I don't buy the reasoning listed above for not using the hwrng framework. Interrupt timings were never designed to be a source of entropy either. We need to grab it where ever we can find it, especially on embedded systems. Documentation/hw_random.txt even says:
"""
This data is NOT CHECKED by any fitness tests, and could potentially be bogus (if the hardware is faulty or has been tampered with).
"""
I really don't think there's a problem with adding these sorts of sources under char/hw_random/. I think the only thing we would be concerned about, other than the already addressed entropy estimation, would be constraining the data rate.
Is ath9k the only wireless card that exposes ADC registers? What about sound cards?
thx,
Jason.
^ permalink raw reply
* Re: [Letux-kernel] [BUG] 4.8-rc1: wlcore: NULL pointer dereference in wlcore_op_get_expected_throughput
From: H. Nikolaus Schaller @ 2016-08-09 5:25 UTC (permalink / raw)
To: Discussions about the Letux Kernel; +Cc: linux-wireless, LKML
In-Reply-To: <20160808234959.47us7rukzpwplsdo@zver>
Hi Andrey,
> Am 09.08.2016 um 01:49 schrieb Andrey Utkin <andrey_utkin@fastmail.com>:
>
> On Mon, Aug 08, 2016 at 11:26:38PM +0200, H. Nikolaus Schaller wrote:
>> Here is what I see in 4.8-rc1 on Pyra device after typing "poweroff".
>> I hope someone knows what it means.
>>
>> BR and thanks,
>> Nikolaus
>>
>> root@letux:~# poweroff
>>
>> Broadcast message from root@letux (pts/0) (Mon Aug 8 21:19:21 2016):
>>
>> The system is going down for system halt NOW!
>>
>> xinit: unexpected signal 15
>> [info] Using makefile-style concurrent boot in runlevel 0.
>> [....] Stopping ISC DHCP server: dhcpd failed!
>> [....] Stopping bluetooth: /usr/sbin/bluetoothd. ok
>> [....] Stopping automount.... ok
>> [....] Not running dhcpcd because /etc/network/interfaces ... failed!
>> [....] defines some interfaces that will use a DHCP client ... failed!
>> [....] Shutting down ALSA...done.
>> [....] Asking all remaining processes to terminate...done.
>> [....] All processes ended within 1 seconds...done.
>> [....] Stopping enhanced syslogd: rsyslogd. ok
>> [....] Deconfiguring network interfaces...SIOCDELRT: No such process
>> Device "usb0" does not exist.
>> Cannot find device "usb0"
>> done.
>> [info] Saving the system clock.
>> [info] Hardware Clock updated to Mon Aug 8 21:19:30 UTC 2016.
>> [....] Unmounting temporary filesystems...done.
>> [....] Deactivating swap...done.
>> [....] Unmounting local filesystems...done.
>> [ 613.196751] EXT4-fs (mmcblk1p2): re-mounted. Opts: (null)
>> [info] Will now halt.
>> [ 615.348870] wlan0: deauthenticating from 00:12:bf:7d:ce:e6 by local choice (Reason: 3=DEAUTH_LEAVING)
>> [ 615.589721] Unable to handle kernel NULL pointer dereference at virtual address 00000a2a
>> [ 615.598249] pgd = ec3a4000
>> [ 615.601220] [00000a2a] *pgd=ab60f835, *pte=00000000, *ppte=00000000
>> [ 615.607868] Internal error: Oops: 17 [#1] PREEMPT SMP ARM
>> [ 615.613551] Modules linked in: hci_uart bnep bluetooth autofs4 usb_f_ecm usb_f_rndis u_ether libcomposite configfs ipv6 cdc_ether usbnet cdc_acm arc4 wl18xx wlcore mac80211 omapdrm cfg80211 drm_kms_helper cfbfillrect syscopyarea cfbimgblt sysfillrect sysimgblt fb_sys_fops cfbcopyarea snd_soc_omap_hdmi_audio panel_mipi_debug drm dwc3 connector_hdmi encoder_tpd12s015 w2cbw003_bluetooth snd_soc_omap_abe_twl6040 snd_soc_twl6040 wwan_on_off leds_gpio omapdss pwm_omap_dmtimer pwm_bl ehci_omap wlcore_sdio dwc3_omap leds_is31fl319x snd_soc_ts3a225e gpio_twl6040 bq27xxx_battery_i2c tsc2007 bq27xxx_battery leds_tca6507 crtouch_mt bq2429x_charger twl6040_vibra ina2xx palmas_pwrbutton palmas_gpadc as5013 tca8418_keypad usb3503 bma150 bmg160_i2c bno055 bmg160_core input_polldev snd_soc_omap_mcpdm snd_soc_omap_mcbsp snd_soc_omap snd_pcm_dmaengine [last unloaded: g_ether]
>> [ 615.694303] CPU: 0 PID: 3788 Comm: halt Tainted: G B W 4.8.0-rc1-letux+ #655
>> [ 615.702727] Hardware name: Generic OMAP5 (Flattened Device Tree)
>> [ 615.709052] task: eb2564c0 task.stack: ec456000
>> [ 615.713913] PC is at wlcore_op_get_expected_throughput+0x14/0x20 [wlcore]
>> [ 615.721357] LR is at sta_set_sinfo+0xc18/0x1110 [mac80211]
>> [ 615.727145] pc : [<bf4de050>] lr : [<bf40cf20>] psr: a00f0013
>> [ 615.727145] sp : ec457c48 ip : 00000000 fp : 400f0013
>> [ 615.739237] r10: ec414620 r9 : eb604b30 r8 : eb604c90
>> [ 615.744735] r7 : c0b02554 r6 : bf4815c4 r5 : bf4de03c r4 : ec823400
>> [ 615.751613] r3 : 00000000 r2 : 00000000 r1 : 000000c8 r0 : 000003e8
>> [ 615.758492] Flags: NzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment none
>> [ 615.766008] Control: 10c5387d Table: ac3a406a DAC: 00000051
>> [ 615.772062] Process halt (pid: 3788, stack limit = 0xec456218)
>> [ 615.778208] Stack: (0xec457c48 to 0xec458000)
>> [ 615.782806] 7c40: 00000001 00000000 bf40d540 c0a76630 eb604f3c bf40d540
>> [ 615.791434] 7c60: ec414620 00000000 00000000 eb604a8c eb604c90 00000000 00000001 eb604800
>> [ 615.800049] 7c80: ec823400 ec45a600 ec45a600 ec414b2c 00000001 ec414b94 00000000 bf40d540
>> [ 615.808682] 7ca0: 00000000 00000003 ec457cb0 ec414b94 ec457cb8 bf40d75c eb604808 eb604808
>> [ 615.817308] 7cc0: 00000000 ec45a600 00000000 ec414620 ec45ac50 ec457d1e 000000c0 00000003
>> [ 615.825940] 7ce0: ffffffff bf4629e8 00000001 ec457d1e ec45a600 ec457d60 ec457d1e 00000001
>> [ 615.834563] 7d00: bf38707c bf386c94 00000003 bf4680cc ec457d1e 00000000 ec45a67c 00c00000
>> [ 615.843178] 7d20: 12000000 e6ce7dbf efbeadde 12000000 e6ce7dbf 00030000 00000001 ec892bd4
>> [ 615.851801] 7d40: ec45a000 c0b02554 ec4142a0 bf38707c bf386c94 00000003 ffffffff bf352b58
>> [ 615.860428] 7d60: ec892bd4 00000000 00000000 00000003 ec45a648 ec45a608 ec414000 ec414000
>> [ 615.869051] 7d80: ec414000 ec45a000 00000003 bf3590c0 00000000 00000003 00000000 ec45a000
>> [ 615.877674] 7da0: ec414000 ec45a648 ec45a608 ec414000 ec414000 00000009 ec96cc0c 00000000
>> [ 615.886300] 7dc0: ffffffff bf31cba8 ec45a608 ec4142a0 ec45a000 bf31cd70 00000000 00000000
>> [ 615.894918] 7de0: c06d0594 c06da874 c0b98444 fffffff7 00000000 00000009 ec457e3c bf47bb38
>> [ 615.903540] 7e00: ec96cc0c 00000000 ffffffff c0152df8 ec45a000 ec457e58 00001042 00001003
>> [ 615.912162] 7e20: 00000000 c0152e40 00000000 00000009 ec457e3c c0620eb4 00000009 ec45a000
>> [ 615.920786] 7e40: c062b690 c0620fd0 ec45a04c ec45a000 00000001 c0621134 ec45a04c ec45a04c
>> [ 615.929410] 7e60: c062b690 c062b97c ec45a000 00001003 ec45a150 ec45a000 00000000 c062ba38
>> [ 615.938027] 7e80: ec8f7600 00000000 ec96cc00 ec45a000 00000000 c0697f8c 00000000 beabc47c
>> [ 615.946652] 7ea0: 00000020 00000000 6e616c77 00000030 00000000 00000000 00001042 8202a8c0
>> [ 615.955275] 7ec0: 00000000 00000000 00000000 00008914 ed5014a0 beabc47c c0b90c80 ed501480
>> [ 615.963900] 7ee0: 00000003 00000000 00000001 c0609a30 beabc47c ed5014a0 eb34b140 c026560c
>> [ 615.972524] 7f00: 00000003 c0264ac4 0000c000 c02654a4 600f0013 c135c654 c08a43f4 eb2dccb4
>> [ 615.981145] 7f20: ec456000 00000000 00000003 eb34b140 ec456000 00000000 00000001 c0271cd8
>> [ 615.989769] 7f40: 00000000 00000000 c0271a44 c0255308 c0b03bc0 00000000 ed501480 c0609684
>> [ 615.998389] 7f60: ed813710 00000000 eb34b140 eb34b140 beabc47c 00008914 00000003 00000000
>> [ 616.007012] 7f80: 00000001 c026560c 00001042 beabc47c 00000000 beabc49c 00000036 c0107204
>> [ 616.015636] 7fa0: ec456000 c0107060 beabc47c 00000000 00000003 00008914 beabc47c 00001042
>> [ 616.024253] 7fc0: beabc47c 00000000 beabc49c 00000036 000230f0 00023100 00000003 00000001
>> [ 616.032875] 7fe0: 00023054 beabc44c 0001135b b6e83206 a00f0030 00000003 00000000 00000000
>> [ 616.041894] [<bf4de050>] (wlcore_op_get_expected_throughput [wlcore]) from [<bf40cf20>] (sta_set_sinfo+0xc18/0x1110 [mac80211])
>> [ 616.054542] [<bf40cf20>] (sta_set_sinfo [mac80211]) from [<bf40d540>] (__sta_info_destroy_part2+0x128/0x194 [mac80211])
>> [ 616.066426] [<bf40d540>] (__sta_info_destroy_part2 [mac80211]) from [<bf40d75c>] (__sta_info_flush+0xf8/0x13c [mac80211])
>> [ 616.078513] [<bf40d75c>] (__sta_info_flush [mac80211]) from [<bf4629e8>] (ieee80211_set_disassoc+0x168/0x2f8 [mac80211])
>> [ 616.090512] [<bf4629e8>] (ieee80211_set_disassoc [mac80211]) from [<bf4680cc>] (ieee80211_mgd_deauth+0x3dc/0x9fc [mac80211])
>> [ 616.102861] [<bf4680cc>] (ieee80211_mgd_deauth [mac80211]) from [<bf352b58>] (cfg80211_mlme_deauth+0x1f4/0x458 [cfg80211])
>> [ 616.114978] [<bf352b58>] (cfg80211_mlme_deauth [cfg80211]) from [<bf3590c0>] (cfg80211_disconnect+0xa0/0x4a4 [cfg80211])
>> [ 616.126880] [<bf3590c0>] (cfg80211_disconnect [cfg80211]) from [<bf31cba8>] (cfg80211_leave+0x28/0x34 [cfg80211])
>> [ 616.138137] [<bf31cba8>] (cfg80211_leave [cfg80211]) from [<bf31cd70>] (cfg80211_netdev_notifier_call+0x1bc/0x84c [cfg80211])
>> [ 616.150287] [<bf31cd70>] (cfg80211_netdev_notifier_call [cfg80211]) from [<c0152df8>] (notifier_call_chain+0x40/0x68)
>> [ 616.161479] [<c0152df8>] (notifier_call_chain) from [<c0152e40>] (raw_notifier_call_chain+0x14/0x1c)
>> [ 616.171111] [<c0152e40>] (raw_notifier_call_chain) from [<c0620eb4>] (call_netdevice_notifiers+0xc/0x14)
>> [ 616.181108] [<c0620eb4>] (call_netdevice_notifiers) from [<c0620fd0>] (__dev_close_many+0x48/0xb8)
>> [ 616.190551] [<c0620fd0>] (__dev_close_many) from [<c0621134>] (__dev_close+0x20/0x34)
>> [ 616.198806] [<c0621134>] (__dev_close) from [<c062b97c>] (__dev_change_flags+0x8c/0x130)
>> [ 616.207347] [<c062b97c>] (__dev_change_flags) from [<c062ba38>] (dev_change_flags+0x18/0x48)
>> [ 616.216255] [<c062ba38>] (dev_change_flags) from [<c0697f8c>] (devinet_ioctl+0x338/0x704)
>> [ 616.224883] [<c0697f8c>] (devinet_ioctl) from [<c0609a30>] (sock_ioctl+0x288/0x2d8)
>> [ 616.232959] [<c0609a30>] (sock_ioctl) from [<c0264ac4>] (vfs_ioctl+0x20/0x34)
>> [ 616.240482] [<c0264ac4>] (vfs_ioctl) from [<c02654a4>] (do_vfs_ioctl+0x854/0x970)
>> [ 616.248369] [<c02654a4>] (do_vfs_ioctl) from [<c026560c>] (SyS_ioctl+0x4c/0x74)
>> [ 616.256078] [<c026560c>] (SyS_ioctl) from [<c0107060>] (ret_fast_syscall+0x0/0x1c)
>> [ 616.264075] Code: e3a010c8 e5d02098 e3a00ffa e0233291 (e5d33a2a)
>> [ 616.272268] ---[ end trace 00ab29170ed628ed ]---
>> Segmentation fault
>> [....] startpar: service(s) skipped, program is not configured: dhcpcd ... (warning).
>> INIT: no more processes left in this runlevel
>
> Just curious - in which way did you get this log? netconsole, serial line or what?
serial port.
>
> Does this happen with older kernels? I guess yes.
No, I didn't see it before moving to 4.8-rc1
>
> Looks like insanity in net/mac80211/sta_info.c to me. The module is
> going to destroy sta_info (whatever it means), then it calls again
> sta_set_sinfo() which seems doing a lot of initialization work, which in
> turn involves calling a routine from hardware-specific driver (wlcore),
> which apparently doesn't expect to be run in context of shutdown, so to
> say. My speculation is very rough, but I think this worth forwarding to
> net/mac80211/sta_info.c maintainers. I haven't CCed them for now, but I
> would do so.
Yes, please do so!
>
> $ ./scripts/get_maintainer.pl -f net/mac80211/sta_info.c
> Johannes Berg <johannes@sipsolutions.net> (maintainer:MAC80211)
> "David S. Miller" <davem@davemloft.net> (maintainer:NETWORKING [GENERAL])
> linux-wireless@vger.kernel.org (open list:MAC80211)
> netdev@vger.kernel.org (open list:NETWORKING [GENERAL])
> linux-kernel@vger.kernel.org (open list)
>
> $ ./scripts/get_maintainer.pl -f drivers/net/wireless/ti/wlcore
> Kalle Valo <kvalo@codeaurora.org> (maintainer:NETWORKING DRIVERS (WIRELESS),commit_signer:24/31=77%)
> Eliad Peller <eliad@wizery.com> (commit_signer:6/31=19%,authored:5/31=16%)
> Guy Mishol <guym@ti.com> (commit_signer:4/31=13%,authored:3/31=10%)
> Uri Mashiach <uri.mashiach@compulab.co.il> (commit_signer:4/31=13%,authored:4/31=13%)
> Johannes Berg <johannes.berg@intel.com> (commit_signer:4/31=13%)
> "Reizer, Eyal" <eyalr@ti.com> (authored:2/31=6%)
> Maxim Altshul <maxim.altshul@ti.com> (authored:2/31=6%)
> linux-wireless@vger.kernel.org (open list:TI WILINK WIRELESS DRIVERS)
> netdev@vger.kernel.org (open list:NETWORKING DRIVERS)
> linux-kernel@vger.kernel.org (open list)
BR and thanks,
Nikolaus
^ permalink raw reply
* net-next is OPEN
From: David Miller @ 2016-08-09 5:24 UTC (permalink / raw)
To: netdev; +Cc: linux-wireless, netfilter-devel
I've merged 'net' into 'net-next' and applied a bunch of pending stuff.
Fire at will...
^ permalink raw reply
* Re: [Letux-kernel] [BUG] 4.8-rc1: wlcore: NULL pointer dereference in wlcore_op_get_expected_throughput
From: Andrey Utkin @ 2016-08-08 23:49 UTC (permalink / raw)
To: Discussions about the Letux Kernel; +Cc: linux-wireless, LKML
In-Reply-To: <4FEB5780-826B-49C3-81E9-D361CD12DD4A@goldelico.com>
On Mon, Aug 08, 2016 at 11:26:38PM +0200, H. Nikolaus Schaller wrote:
> Here is what I see in 4.8-rc1 on Pyra device after typing "poweroff".
> I hope someone knows what it means.
>
> BR and thanks,
> Nikolaus
>
> root@letux:~# poweroff
>
> Broadcast message from root@letux (pts/0) (Mon Aug 8 21:19:21 2016):
>
> The system is going down for system halt NOW!
>
> xinit: unexpected signal 15
> [info] Using makefile-style concurrent boot in runlevel 0.
> [....] Stopping ISC DHCP server: dhcpd failed!
> [....] Stopping bluetooth: /usr/sbin/bluetoothd. ok
> [....] Stopping automount.... ok
> [....] Not running dhcpcd because /etc/network/interfaces ... failed!
> [....] defines some interfaces that will use a DHCP client ... failed!
> [....] Shutting down ALSA...done.
> [....] Asking all remaining processes to terminate...done.
> [....] All processes ended within 1 seconds...done.
> [....] Stopping enhanced syslogd: rsyslogd. ok
> [....] Deconfiguring network interfaces...SIOCDELRT: No such process
> Device "usb0" does not exist.
> Cannot find device "usb0"
> done.
> [info] Saving the system clock.
> [info] Hardware Clock updated to Mon Aug 8 21:19:30 UTC 2016.
> [....] Unmounting temporary filesystems...done.
> [....] Deactivating swap...done.
> [....] Unmounting local filesystems...done.
> [ 613.196751] EXT4-fs (mmcblk1p2): re-mounted. Opts: (null)
> [info] Will now halt.
> [ 615.348870] wlan0: deauthenticating from 00:12:bf:7d:ce:e6 by local choice (Reason: 3=DEAUTH_LEAVING)
> [ 615.589721] Unable to handle kernel NULL pointer dereference at virtual address 00000a2a
> [ 615.598249] pgd = ec3a4000
> [ 615.601220] [00000a2a] *pgd=ab60f835, *pte=00000000, *ppte=00000000
> [ 615.607868] Internal error: Oops: 17 [#1] PREEMPT SMP ARM
> [ 615.613551] Modules linked in: hci_uart bnep bluetooth autofs4 usb_f_ecm usb_f_rndis u_ether libcomposite configfs ipv6 cdc_ether usbnet cdc_acm arc4 wl18xx wlcore mac80211 omapdrm cfg80211 drm_kms_helper cfbfillrect syscopyarea cfbimgblt sysfillrect sysimgblt fb_sys_fops cfbcopyarea snd_soc_omap_hdmi_audio panel_mipi_debug drm dwc3 connector_hdmi encoder_tpd12s015 w2cbw003_bluetooth snd_soc_omap_abe_twl6040 snd_soc_twl6040 wwan_on_off leds_gpio omapdss pwm_omap_dmtimer pwm_bl ehci_omap wlcore_sdio dwc3_omap leds_is31fl319x snd_soc_ts3a225e gpio_twl6040 bq27xxx_battery_i2c tsc2007 bq27xxx_battery leds_tca6507 crtouch_mt bq2429x_charger twl6040_vibra ina2xx palmas_pwrbutton palmas_gpadc as5013 tca8418_keypad usb3503 bma150 bmg160_i2c bno055 bmg160_core input_polldev snd_soc_omap_mcpdm snd_soc_omap_mcbsp snd_soc_omap snd_pcm_dmaengine [last unloaded: g_ether]
> [ 615.694303] CPU: 0 PID: 3788 Comm: halt Tainted: G B W 4.8.0-rc1-letux+ #655
> [ 615.702727] Hardware name: Generic OMAP5 (Flattened Device Tree)
> [ 615.709052] task: eb2564c0 task.stack: ec456000
> [ 615.713913] PC is at wlcore_op_get_expected_throughput+0x14/0x20 [wlcore]
> [ 615.721357] LR is at sta_set_sinfo+0xc18/0x1110 [mac80211]
> [ 615.727145] pc : [<bf4de050>] lr : [<bf40cf20>] psr: a00f0013
> [ 615.727145] sp : ec457c48 ip : 00000000 fp : 400f0013
> [ 615.739237] r10: ec414620 r9 : eb604b30 r8 : eb604c90
> [ 615.744735] r7 : c0b02554 r6 : bf4815c4 r5 : bf4de03c r4 : ec823400
> [ 615.751613] r3 : 00000000 r2 : 00000000 r1 : 000000c8 r0 : 000003e8
> [ 615.758492] Flags: NzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment none
> [ 615.766008] Control: 10c5387d Table: ac3a406a DAC: 00000051
> [ 615.772062] Process halt (pid: 3788, stack limit = 0xec456218)
> [ 615.778208] Stack: (0xec457c48 to 0xec458000)
> [ 615.782806] 7c40: 00000001 00000000 bf40d540 c0a76630 eb604f3c bf40d540
> [ 615.791434] 7c60: ec414620 00000000 00000000 eb604a8c eb604c90 00000000 00000001 eb604800
> [ 615.800049] 7c80: ec823400 ec45a600 ec45a600 ec414b2c 00000001 ec414b94 00000000 bf40d540
> [ 615.808682] 7ca0: 00000000 00000003 ec457cb0 ec414b94 ec457cb8 bf40d75c eb604808 eb604808
> [ 615.817308] 7cc0: 00000000 ec45a600 00000000 ec414620 ec45ac50 ec457d1e 000000c0 00000003
> [ 615.825940] 7ce0: ffffffff bf4629e8 00000001 ec457d1e ec45a600 ec457d60 ec457d1e 00000001
> [ 615.834563] 7d00: bf38707c bf386c94 00000003 bf4680cc ec457d1e 00000000 ec45a67c 00c00000
> [ 615.843178] 7d20: 12000000 e6ce7dbf efbeadde 12000000 e6ce7dbf 00030000 00000001 ec892bd4
> [ 615.851801] 7d40: ec45a000 c0b02554 ec4142a0 bf38707c bf386c94 00000003 ffffffff bf352b58
> [ 615.860428] 7d60: ec892bd4 00000000 00000000 00000003 ec45a648 ec45a608 ec414000 ec414000
> [ 615.869051] 7d80: ec414000 ec45a000 00000003 bf3590c0 00000000 00000003 00000000 ec45a000
> [ 615.877674] 7da0: ec414000 ec45a648 ec45a608 ec414000 ec414000 00000009 ec96cc0c 00000000
> [ 615.886300] 7dc0: ffffffff bf31cba8 ec45a608 ec4142a0 ec45a000 bf31cd70 00000000 00000000
> [ 615.894918] 7de0: c06d0594 c06da874 c0b98444 fffffff7 00000000 00000009 ec457e3c bf47bb38
> [ 615.903540] 7e00: ec96cc0c 00000000 ffffffff c0152df8 ec45a000 ec457e58 00001042 00001003
> [ 615.912162] 7e20: 00000000 c0152e40 00000000 00000009 ec457e3c c0620eb4 00000009 ec45a000
> [ 615.920786] 7e40: c062b690 c0620fd0 ec45a04c ec45a000 00000001 c0621134 ec45a04c ec45a04c
> [ 615.929410] 7e60: c062b690 c062b97c ec45a000 00001003 ec45a150 ec45a000 00000000 c062ba38
> [ 615.938027] 7e80: ec8f7600 00000000 ec96cc00 ec45a000 00000000 c0697f8c 00000000 beabc47c
> [ 615.946652] 7ea0: 00000020 00000000 6e616c77 00000030 00000000 00000000 00001042 8202a8c0
> [ 615.955275] 7ec0: 00000000 00000000 00000000 00008914 ed5014a0 beabc47c c0b90c80 ed501480
> [ 615.963900] 7ee0: 00000003 00000000 00000001 c0609a30 beabc47c ed5014a0 eb34b140 c026560c
> [ 615.972524] 7f00: 00000003 c0264ac4 0000c000 c02654a4 600f0013 c135c654 c08a43f4 eb2dccb4
> [ 615.981145] 7f20: ec456000 00000000 00000003 eb34b140 ec456000 00000000 00000001 c0271cd8
> [ 615.989769] 7f40: 00000000 00000000 c0271a44 c0255308 c0b03bc0 00000000 ed501480 c0609684
> [ 615.998389] 7f60: ed813710 00000000 eb34b140 eb34b140 beabc47c 00008914 00000003 00000000
> [ 616.007012] 7f80: 00000001 c026560c 00001042 beabc47c 00000000 beabc49c 00000036 c0107204
> [ 616.015636] 7fa0: ec456000 c0107060 beabc47c 00000000 00000003 00008914 beabc47c 00001042
> [ 616.024253] 7fc0: beabc47c 00000000 beabc49c 00000036 000230f0 00023100 00000003 00000001
> [ 616.032875] 7fe0: 00023054 beabc44c 0001135b b6e83206 a00f0030 00000003 00000000 00000000
> [ 616.041894] [<bf4de050>] (wlcore_op_get_expected_throughput [wlcore]) from [<bf40cf20>] (sta_set_sinfo+0xc18/0x1110 [mac80211])
> [ 616.054542] [<bf40cf20>] (sta_set_sinfo [mac80211]) from [<bf40d540>] (__sta_info_destroy_part2+0x128/0x194 [mac80211])
> [ 616.066426] [<bf40d540>] (__sta_info_destroy_part2 [mac80211]) from [<bf40d75c>] (__sta_info_flush+0xf8/0x13c [mac80211])
> [ 616.078513] [<bf40d75c>] (__sta_info_flush [mac80211]) from [<bf4629e8>] (ieee80211_set_disassoc+0x168/0x2f8 [mac80211])
> [ 616.090512] [<bf4629e8>] (ieee80211_set_disassoc [mac80211]) from [<bf4680cc>] (ieee80211_mgd_deauth+0x3dc/0x9fc [mac80211])
> [ 616.102861] [<bf4680cc>] (ieee80211_mgd_deauth [mac80211]) from [<bf352b58>] (cfg80211_mlme_deauth+0x1f4/0x458 [cfg80211])
> [ 616.114978] [<bf352b58>] (cfg80211_mlme_deauth [cfg80211]) from [<bf3590c0>] (cfg80211_disconnect+0xa0/0x4a4 [cfg80211])
> [ 616.126880] [<bf3590c0>] (cfg80211_disconnect [cfg80211]) from [<bf31cba8>] (cfg80211_leave+0x28/0x34 [cfg80211])
> [ 616.138137] [<bf31cba8>] (cfg80211_leave [cfg80211]) from [<bf31cd70>] (cfg80211_netdev_notifier_call+0x1bc/0x84c [cfg80211])
> [ 616.150287] [<bf31cd70>] (cfg80211_netdev_notifier_call [cfg80211]) from [<c0152df8>] (notifier_call_chain+0x40/0x68)
> [ 616.161479] [<c0152df8>] (notifier_call_chain) from [<c0152e40>] (raw_notifier_call_chain+0x14/0x1c)
> [ 616.171111] [<c0152e40>] (raw_notifier_call_chain) from [<c0620eb4>] (call_netdevice_notifiers+0xc/0x14)
> [ 616.181108] [<c0620eb4>] (call_netdevice_notifiers) from [<c0620fd0>] (__dev_close_many+0x48/0xb8)
> [ 616.190551] [<c0620fd0>] (__dev_close_many) from [<c0621134>] (__dev_close+0x20/0x34)
> [ 616.198806] [<c0621134>] (__dev_close) from [<c062b97c>] (__dev_change_flags+0x8c/0x130)
> [ 616.207347] [<c062b97c>] (__dev_change_flags) from [<c062ba38>] (dev_change_flags+0x18/0x48)
> [ 616.216255] [<c062ba38>] (dev_change_flags) from [<c0697f8c>] (devinet_ioctl+0x338/0x704)
> [ 616.224883] [<c0697f8c>] (devinet_ioctl) from [<c0609a30>] (sock_ioctl+0x288/0x2d8)
> [ 616.232959] [<c0609a30>] (sock_ioctl) from [<c0264ac4>] (vfs_ioctl+0x20/0x34)
> [ 616.240482] [<c0264ac4>] (vfs_ioctl) from [<c02654a4>] (do_vfs_ioctl+0x854/0x970)
> [ 616.248369] [<c02654a4>] (do_vfs_ioctl) from [<c026560c>] (SyS_ioctl+0x4c/0x74)
> [ 616.256078] [<c026560c>] (SyS_ioctl) from [<c0107060>] (ret_fast_syscall+0x0/0x1c)
> [ 616.264075] Code: e3a010c8 e5d02098 e3a00ffa e0233291 (e5d33a2a)
> [ 616.272268] ---[ end trace 00ab29170ed628ed ]---
> Segmentation fault
> [....] startpar: service(s) skipped, program is not configured: dhcpcd ... (warning).
> INIT: no more processes left in this runlevel
Just curious - in which way did you get this log? netconsole, serial line or what?
Does this happen with older kernels? I guess yes.
Looks like insanity in net/mac80211/sta_info.c to me. The module is
going to destroy sta_info (whatever it means), then it calls again
sta_set_sinfo() which seems doing a lot of initialization work, which in
turn involves calling a routine from hardware-specific driver (wlcore),
which apparently doesn't expect to be run in context of shutdown, so to
say. My speculation is very rough, but I think this worth forwarding to
net/mac80211/sta_info.c maintainers. I haven't CCed them for now, but I
would do so.
$ ./scripts/get_maintainer.pl -f net/mac80211/sta_info.c
Johannes Berg <johannes@sipsolutions.net> (maintainer:MAC80211)
"David S. Miller" <davem@davemloft.net> (maintainer:NETWORKING [GENERAL])
linux-wireless@vger.kernel.org (open list:MAC80211)
netdev@vger.kernel.org (open list:NETWORKING [GENERAL])
linux-kernel@vger.kernel.org (open list)
$ ./scripts/get_maintainer.pl -f drivers/net/wireless/ti/wlcore
Kalle Valo <kvalo@codeaurora.org> (maintainer:NETWORKING DRIVERS (WIRELESS),commit_signer:24/31=77%)
Eliad Peller <eliad@wizery.com> (commit_signer:6/31=19%,authored:5/31=16%)
Guy Mishol <guym@ti.com> (commit_signer:4/31=13%,authored:3/31=10%)
Uri Mashiach <uri.mashiach@compulab.co.il> (commit_signer:4/31=13%,authored:4/31=13%)
Johannes Berg <johannes.berg@intel.com> (commit_signer:4/31=13%)
"Reizer, Eyal" <eyalr@ti.com> (authored:2/31=6%)
Maxim Altshul <maxim.altshul@ti.com> (authored:2/31=6%)
linux-wireless@vger.kernel.org (open list:TI WILINK WIRELESS DRIVERS)
netdev@vger.kernel.org (open list:NETWORKING DRIVERS)
linux-kernel@vger.kernel.org (open list)
^ permalink raw reply
* Re: [PATCH v2] RANDOM: ATH9K RNG delivers zero bits of entropy
From: Jason Cooper @ 2016-08-08 22:04 UTC (permalink / raw)
To: Stephan Mueller
Cc: Pan, Miaoqing, Ted Tso, Sepehrdad, Pouyan,
herbert@gondor.apana.org.au, linux-kernel@vger.kernel.org,
linux-crypto@vger.kernel.org, ath9k-devel,
linux-wireless@vger.kernel.org, ath9k-devel@lists.ath9k.org,
Kalle Valo
In-Reply-To: <20160808172930.GD4511@io.lakedaemon.net>
Hi Stephan,
On Mon, Aug 08, 2016 at 05:29:30PM +0000, Jason Cooper wrote:
> On Mon, Aug 08, 2016 at 08:41:36AM +0200, Stephan Mueller wrote:
...
> > If you think that this patch is a challenge because your driver starts to
> > spin, please help and offer another solution.
>
> Well, I don't buy the reasoning listed above for not using the hwrng
> framework. Interrupt timings were never designed to be a source of entropy
> either. We need to grab it where ever we can find it, especially on
> embedded systems. Documentation/hw_random.txt even says:
>
> """
> This data is NOT CHECKED by any fitness tests, and could potentially be
> bogus (if the hardware is faulty or has been tampered with).
> """
>
> I really don't think there's a problem with adding these sorts of
> sources under char/hw_random/. I think the only thing we would be
> concerned about, other than the already addressed entropy estimation,
> would be constraining the data rate.
Further research yields char/hw_random/timeriomem-rng.c
It could use an update to ->read() vice data_{present,read}(), but it's
functionally exactly what the ath9k rng is doing. :)
thx,
Jason.
^ permalink raw reply
* [BUG] 4.8-rc1: wlcore: NULL pointer dereference in wlcore_op_get_expected_throughput
From: H. Nikolaus Schaller @ 2016-08-08 21:26 UTC (permalink / raw)
To: linux-wireless; +Cc: LKML, Discussions about the Letux Kernel
Here is what I see in 4.8-rc1 on Pyra device after typing "poweroff".
I hope someone knows what it means.
BR and thanks,
Nikolaus
root@letux:~# poweroff
Broadcast message from root@letux (pts/0) (Mon Aug 8 21:19:21 2016):
The system is going down for system halt NOW!
xinit: unexpected signal 15
[info] Using makefile-style concurrent boot in runlevel 0.
[....] Stopping ISC DHCP server: dhcpd failed!
[....] Stopping bluetooth: /usr/sbin/bluetoothd. ok
[....] Stopping automount.... ok
[....] Not running dhcpcd because /etc/network/interfaces ... failed!
[....] defines some interfaces that will use a DHCP client ... failed!
[....] Shutting down ALSA...done.
[....] Asking all remaining processes to terminate...done.
[....] All processes ended within 1 seconds...done.
[....] Stopping enhanced syslogd: rsyslogd. ok
[....] Deconfiguring network interfaces...SIOCDELRT: No such process
Device "usb0" does not exist.
Cannot find device "usb0"
done.
[info] Saving the system clock.
[info] Hardware Clock updated to Mon Aug 8 21:19:30 UTC 2016.
[....] Unmounting temporary filesystems...done.
[....] Deactivating swap...done.
[....] Unmounting local filesystems...done.
[ 613.196751] EXT4-fs (mmcblk1p2): re-mounted. Opts: (null)
[info] Will now halt.
[ 615.348870] wlan0: deauthenticating from 00:12:bf:7d:ce:e6 by local choice (Reason: 3=DEAUTH_LEAVING)
[ 615.589721] Unable to handle kernel NULL pointer dereference at virtual address 00000a2a
[ 615.598249] pgd = ec3a4000
[ 615.601220] [00000a2a] *pgd=ab60f835, *pte=00000000, *ppte=00000000
[ 615.607868] Internal error: Oops: 17 [#1] PREEMPT SMP ARM
[ 615.613551] Modules linked in: hci_uart bnep bluetooth autofs4 usb_f_ecm usb_f_rndis u_ether libcomposite configfs ipv6 cdc_ether usbnet cdc_acm arc4 wl18xx wlcore mac80211 omapdrm cfg80211 drm_kms_helper cfbfillrect syscopyarea cfbimgblt sysfillrect sysimgblt fb_sys_fops cfbcopyarea snd_soc_omap_hdmi_audio panel_mipi_debug drm dwc3 connector_hdmi encoder_tpd12s015 w2cbw003_bluetooth snd_soc_omap_abe_twl6040 snd_soc_twl6040 wwan_on_off leds_gpio omapdss pwm_omap_dmtimer pwm_bl ehci_omap wlcore_sdio dwc3_omap leds_is31fl319x snd_soc_ts3a225e gpio_twl6040 bq27xxx_battery_i2c tsc2007 bq27xxx_battery leds_tca6507 crtouch_mt bq2429x_charger twl6040_vibra ina2xx palmas_pwrbutton palmas_gpadc as5013 tca8418_keypad usb3503 bma150 bmg160_i2c bno055 bmg160_core input_polldev snd_soc_omap_mcpdm snd_soc_omap_mcbsp snd_soc_omap snd_pcm_dmaengine [last unloaded: g_ether]
[ 615.694303] CPU: 0 PID: 3788 Comm: halt Tainted: G B W 4.8.0-rc1-letux+ #655
[ 615.702727] Hardware name: Generic OMAP5 (Flattened Device Tree)
[ 615.709052] task: eb2564c0 task.stack: ec456000
[ 615.713913] PC is at wlcore_op_get_expected_throughput+0x14/0x20 [wlcore]
[ 615.721357] LR is at sta_set_sinfo+0xc18/0x1110 [mac80211]
[ 615.727145] pc : [<bf4de050>] lr : [<bf40cf20>] psr: a00f0013
[ 615.727145] sp : ec457c48 ip : 00000000 fp : 400f0013
[ 615.739237] r10: ec414620 r9 : eb604b30 r8 : eb604c90
[ 615.744735] r7 : c0b02554 r6 : bf4815c4 r5 : bf4de03c r4 : ec823400
[ 615.751613] r3 : 00000000 r2 : 00000000 r1 : 000000c8 r0 : 000003e8
[ 615.758492] Flags: NzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment none
[ 615.766008] Control: 10c5387d Table: ac3a406a DAC: 00000051
[ 615.772062] Process halt (pid: 3788, stack limit = 0xec456218)
[ 615.778208] Stack: (0xec457c48 to 0xec458000)
[ 615.782806] 7c40: 00000001 00000000 bf40d540 c0a76630 eb604f3c bf40d540
[ 615.791434] 7c60: ec414620 00000000 00000000 eb604a8c eb604c90 00000000 00000001 eb604800
[ 615.800049] 7c80: ec823400 ec45a600 ec45a600 ec414b2c 00000001 ec414b94 00000000 bf40d540
[ 615.808682] 7ca0: 00000000 00000003 ec457cb0 ec414b94 ec457cb8 bf40d75c eb604808 eb604808
[ 615.817308] 7cc0: 00000000 ec45a600 00000000 ec414620 ec45ac50 ec457d1e 000000c0 00000003
[ 615.825940] 7ce0: ffffffff bf4629e8 00000001 ec457d1e ec45a600 ec457d60 ec457d1e 00000001
[ 615.834563] 7d00: bf38707c bf386c94 00000003 bf4680cc ec457d1e 00000000 ec45a67c 00c00000
[ 615.843178] 7d20: 12000000 e6ce7dbf efbeadde 12000000 e6ce7dbf 00030000 00000001 ec892bd4
[ 615.851801] 7d40: ec45a000 c0b02554 ec4142a0 bf38707c bf386c94 00000003 ffffffff bf352b58
[ 615.860428] 7d60: ec892bd4 00000000 00000000 00000003 ec45a648 ec45a608 ec414000 ec414000
[ 615.869051] 7d80: ec414000 ec45a000 00000003 bf3590c0 00000000 00000003 00000000 ec45a000
[ 615.877674] 7da0: ec414000 ec45a648 ec45a608 ec414000 ec414000 00000009 ec96cc0c 00000000
[ 615.886300] 7dc0: ffffffff bf31cba8 ec45a608 ec4142a0 ec45a000 bf31cd70 00000000 00000000
[ 615.894918] 7de0: c06d0594 c06da874 c0b98444 fffffff7 00000000 00000009 ec457e3c bf47bb38
[ 615.903540] 7e00: ec96cc0c 00000000 ffffffff c0152df8 ec45a000 ec457e58 00001042 00001003
[ 615.912162] 7e20: 00000000 c0152e40 00000000 00000009 ec457e3c c0620eb4 00000009 ec45a000
[ 615.920786] 7e40: c062b690 c0620fd0 ec45a04c ec45a000 00000001 c0621134 ec45a04c ec45a04c
[ 615.929410] 7e60: c062b690 c062b97c ec45a000 00001003 ec45a150 ec45a000 00000000 c062ba38
[ 615.938027] 7e80: ec8f7600 00000000 ec96cc00 ec45a000 00000000 c0697f8c 00000000 beabc47c
[ 615.946652] 7ea0: 00000020 00000000 6e616c77 00000030 00000000 00000000 00001042 8202a8c0
[ 615.955275] 7ec0: 00000000 00000000 00000000 00008914 ed5014a0 beabc47c c0b90c80 ed501480
[ 615.963900] 7ee0: 00000003 00000000 00000001 c0609a30 beabc47c ed5014a0 eb34b140 c026560c
[ 615.972524] 7f00: 00000003 c0264ac4 0000c000 c02654a4 600f0013 c135c654 c08a43f4 eb2dccb4
[ 615.981145] 7f20: ec456000 00000000 00000003 eb34b140 ec456000 00000000 00000001 c0271cd8
[ 615.989769] 7f40: 00000000 00000000 c0271a44 c0255308 c0b03bc0 00000000 ed501480 c0609684
[ 615.998389] 7f60: ed813710 00000000 eb34b140 eb34b140 beabc47c 00008914 00000003 00000000
[ 616.007012] 7f80: 00000001 c026560c 00001042 beabc47c 00000000 beabc49c 00000036 c0107204
[ 616.015636] 7fa0: ec456000 c0107060 beabc47c 00000000 00000003 00008914 beabc47c 00001042
[ 616.024253] 7fc0: beabc47c 00000000 beabc49c 00000036 000230f0 00023100 00000003 00000001
[ 616.032875] 7fe0: 00023054 beabc44c 0001135b b6e83206 a00f0030 00000003 00000000 00000000
[ 616.041894] [<bf4de050>] (wlcore_op_get_expected_throughput [wlcore]) from [<bf40cf20>] (sta_set_sinfo+0xc18/0x1110 [mac80211])
[ 616.054542] [<bf40cf20>] (sta_set_sinfo [mac80211]) from [<bf40d540>] (__sta_info_destroy_part2+0x128/0x194 [mac80211])
[ 616.066426] [<bf40d540>] (__sta_info_destroy_part2 [mac80211]) from [<bf40d75c>] (__sta_info_flush+0xf8/0x13c [mac80211])
[ 616.078513] [<bf40d75c>] (__sta_info_flush [mac80211]) from [<bf4629e8>] (ieee80211_set_disassoc+0x168/0x2f8 [mac80211])
[ 616.090512] [<bf4629e8>] (ieee80211_set_disassoc [mac80211]) from [<bf4680cc>] (ieee80211_mgd_deauth+0x3dc/0x9fc [mac80211])
[ 616.102861] [<bf4680cc>] (ieee80211_mgd_deauth [mac80211]) from [<bf352b58>] (cfg80211_mlme_deauth+0x1f4/0x458 [cfg80211])
[ 616.114978] [<bf352b58>] (cfg80211_mlme_deauth [cfg80211]) from [<bf3590c0>] (cfg80211_disconnect+0xa0/0x4a4 [cfg80211])
[ 616.126880] [<bf3590c0>] (cfg80211_disconnect [cfg80211]) from [<bf31cba8>] (cfg80211_leave+0x28/0x34 [cfg80211])
[ 616.138137] [<bf31cba8>] (cfg80211_leave [cfg80211]) from [<bf31cd70>] (cfg80211_netdev_notifier_call+0x1bc/0x84c [cfg80211])
[ 616.150287] [<bf31cd70>] (cfg80211_netdev_notifier_call [cfg80211]) from [<c0152df8>] (notifier_call_chain+0x40/0x68)
[ 616.161479] [<c0152df8>] (notifier_call_chain) from [<c0152e40>] (raw_notifier_call_chain+0x14/0x1c)
[ 616.171111] [<c0152e40>] (raw_notifier_call_chain) from [<c0620eb4>] (call_netdevice_notifiers+0xc/0x14)
[ 616.181108] [<c0620eb4>] (call_netdevice_notifiers) from [<c0620fd0>] (__dev_close_many+0x48/0xb8)
[ 616.190551] [<c0620fd0>] (__dev_close_many) from [<c0621134>] (__dev_close+0x20/0x34)
[ 616.198806] [<c0621134>] (__dev_close) from [<c062b97c>] (__dev_change_flags+0x8c/0x130)
[ 616.207347] [<c062b97c>] (__dev_change_flags) from [<c062ba38>] (dev_change_flags+0x18/0x48)
[ 616.216255] [<c062ba38>] (dev_change_flags) from [<c0697f8c>] (devinet_ioctl+0x338/0x704)
[ 616.224883] [<c0697f8c>] (devinet_ioctl) from [<c0609a30>] (sock_ioctl+0x288/0x2d8)
[ 616.232959] [<c0609a30>] (sock_ioctl) from [<c0264ac4>] (vfs_ioctl+0x20/0x34)
[ 616.240482] [<c0264ac4>] (vfs_ioctl) from [<c02654a4>] (do_vfs_ioctl+0x854/0x970)
[ 616.248369] [<c02654a4>] (do_vfs_ioctl) from [<c026560c>] (SyS_ioctl+0x4c/0x74)
[ 616.256078] [<c026560c>] (SyS_ioctl) from [<c0107060>] (ret_fast_syscall+0x0/0x1c)
[ 616.264075] Code: e3a010c8 e5d02098 e3a00ffa e0233291 (e5d33a2a)
[ 616.272268] ---[ end trace 00ab29170ed628ed ]---
Segmentation fault
[....] startpar: service(s) skipped, program is not configured: dhcpcd ... (warning).
INIT: no more processes left in this runlevel
^ 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