Hi
There was similar issue reported in forum recently:
https://forum.openwrt.org/t/wireless-card-atheros-ar9565/23608
Could you enable ath9k debug and post output?
Please remember to Cc wireless-re...@lists.infradead.org for regdb
changes, adding now.
On Sat, Oct 06, 2018 at 06:02:54PM +0200, Hauke Mehrtens wrote:
> Commit 8607edfdb6568 ("wireless-regdb: Parse wmm rule data") introduced
> a dependency to the python module attr which is not included by
On Wed, Oct 24, 2018 at 09:04:36AM +0200, Johannes Berg wrote:
> From: Johannes Berg
>
> These files have a long history of code changes, but analysing
> the remaining code leads to having only a few changes that are
> not already owned by Intel, notably from
> - Andy Lutomirski
> - Joonwoo
Hi,
This is a follow-up to these two past threads concerning the 4366c firmware:
https://www.spinics.net/lists/linux-wireless/msg159634.html
https://www.spinics.net/lists/linux-wireless/msg172063.html
I wanted to if we can still expect the firmware to be released by the
end of the year? Has
On Wed, Oct 24, 2018 at 08:50:52AM +0300, Kalle Valo wrote:
> Dan Carpenter writes:
>
> > We tried to revert commit d9c52fd17cb4 ("ath9k: fix tx99 with monitor
> > mode interface") but accidentally missed part of the locking change.
> >
> > The lock has to be held earlier so that we're holding
Dan Carpenter writes:
> On Wed, Oct 24, 2018 at 08:50:52AM +0300, Kalle Valo wrote:
>> Dan Carpenter writes:
>>
>> > We tried to revert commit d9c52fd17cb4 ("ath9k: fix tx99 with monitor
>> > mode interface") but accidentally missed part of the locking change.
>> >
>> > The lock has to be held
Hi
Running several tests with dynack enabled on AR9462 card I can see
throughput drop in 10-30Mbps range.
The card is running on 4.9.135 kernel (same issue was present on
3.2.11 with backports4.4.2) while QCA9531 router is running 4.9.111.
Distance between the two is less than 1m. Results:
A new release of wireless-regdb (master-2018-10-24) is available at:
https://www.kernel.org/pub/software/network/wireless-regdb/wireless-regdb-2018.10.24.tar.gz
The short log of changes since the 2018-09-07 release is below.
Thanks,
Seth
---
Hauke Mehrtens (1):
wireless-regdb: remove
Acked-by: Joonwoo Park
On Wed, Oct 24, 2018 at 6:22 AM Stanislaw Gruszka wrote:
>
> On Wed, Oct 24, 2018 at 09:04:36AM +0200, Johannes Berg wrote:
> > From: Johannes Berg
> >
> > These files have a long history of code changes, but analysing
> > the remaining code leads to having only a few
Hi,
well I enabled CONFIG_ATH_DEBUG and booted this kernel, sorry for the
mess of escape sequence but I captured via serial console:
http://ix.io/1pWI
I don't see anything different even if I cranked up ath9k.debug= to the
*any* value. I guess this thing happens so early at boot that nothing
On Wed, Oct 24, 2018 at 12:05 AM Johannes Berg
wrote:
>
> From: Johannes Berg
>
> These files have a long history of code changes, but analysing
> the remaining code leads to having only a few changes that are
> not already owned by Intel, notably from
> - Andy Lutomirski
> - Joonwoo Park
>
Hi,
sure, I enabled atheros wireless debugging in my kernel and am
rebuilding it. After this is done, should I set ath9k.debug= on the
cmdline ? It is built as module, but my filesystem is read-only so no
modprobe.d snippet can be added.
Thanks
Tom Psyborg a écrit :
Hi
There was similar
On Wed, Oct 24, 2018 at 12:05 AM Johannes Berg
wrote:
>
> From: Johannes Berg
>
> These files have a long history of code changes, but analysing
> the remaining code leads to having only a few changes that are
> not already owned by Intel, notably from
> - Andy Lutomirski
> - Joonwoo Park
>
Here's another boot log along with some commands after the system booted
up to show what I did. I don't think I did anything wrong, and yet this
is no different, debug option appears to be completely useless.
http://ix.io/1pY0
Thanks
Tom Psyborg a écrit :
if your system is read-only then you
Hi
Try selecting config option ATH9K_SUPPORT_PCOEM (Support chips used in
PC OEM cards) and rebuild your image.
I'm not familiar with your architecture but it seems you're not
getting debug output. It should print a lot of info right after the:
ath: phy0: WB335 2-ANT card detected
Hi,
CONFIG_ATH9K_PCOEM is already enabled in my kernel build. In fact if it
is disabled my card does not show up at all.
Thanks
Tom Psyborg a écrit :
Hi
Try selecting config option ATH9K_SUPPORT_PCOEM (Support chips used in
PC OEM cards) and rebuild your image.
I'm not familiar with your
if your system is read-only then you should make a build with debug
option enabled:
inside your buildroot create this path: files/etc/modules.d/ and put
file named ath9k there which should contain "ath9k debug=0x"
(more info:
It looks like we wanted to print a maximum of BSSList_rid.ssidLen bytes
of the ssid, but we accidentally use "%*s" (width) instead of "%.*s"
(precision) so if the ssid doesn't have a NUL terminator this could lead
to an overflow.
Fixes: e174961ca1a0 ("net: convert print_mac to %pM")
Dan Carpenter writes:
> It looks like we wanted to print a maximum of BSSList_rid.ssidLen bytes
> of the ssid, but we accidentally use "%*s" (width) instead of "%.*s"
> (precision) so if the ssid doesn't have a NUL terminator this could lead
> to an overflow.
>
> Fixes: e174961ca1a0 ("net:
On Wed, Oct 24, 2018 at 11:56:53AM +0300, Kalle Valo wrote:
> Dan Carpenter writes:
>
> > It looks like we wanted to print a maximum of BSSList_rid.ssidLen bytes
> > of the ssid, but we accidentally use "%*s" (width) instead of "%.*s"
> > (precision) so if the ssid doesn't have a NUL terminator
Dan Carpenter writes:
> On Wed, Oct 24, 2018 at 11:56:53AM +0300, Kalle Valo wrote:
>> Dan Carpenter writes:
>>
>> > It looks like we wanted to print a maximum of BSSList_rid.ssidLen bytes
>> > of the ssid, but we accidentally use "%*s" (width) instead of "%.*s"
>> > (precision) so if the ssid
On Wed, Oct 24, 2018 at 12:23 PM Kalle Valo wrote:
>
> Dan Carpenter writes:
>
> > On Wed, Oct 24, 2018 at 11:56:53AM +0300, Kalle Valo wrote:
> >> Dan Carpenter writes:
> >>
> >> > It looks like we wanted to print a maximum of BSSList_rid.ssidLen bytes
> >> > of the ssid, but we accidentally
On Wed, Oct 24, 2018 at 9:05 AM Johannes Berg wrote:
>
> From: Johannes Berg
>
> These files have a long history of code changes, but analysing
> the remaining code leads to having only a few changes that are
> not already owned by Intel, notably from
> - Andy Lutomirski
> - Joonwoo Park
>
On Wed, 2018-10-24 at 09:33 +0200, Sedat Dilek wrote:
>
> > Align the licenses with their permission to clean up and to
> > make it all identical.
> >
>
> Does it make sense to put the BSD license (text) in a separate file
> (like GPL) and reference it?
I agree that it would, and in fact we
On Wed, Oct 24, 2018 at 12:05 AM Johannes Berg
wrote:
>
> From: Johannes Berg
>
> These files have a long history of code changes, but analysing
> the remaining code leads to having only a few changes that are
> not already owned by Intel, notably from
> - Andy Lutomirski
> - Joonwoo Park
>
From: Johannes Berg
These files have a long history of code changes, but analysing
the remaining code leads to having only a few changes that are
not already owned by Intel, notably from
- Andy Lutomirski
- Joonwoo Park
- Kirtika Ruchandani
- Rajat Jain
- Stanislaw Gruszka
remaining in
On Wed, Oct 24, 2018 at 9:36 AM Johannes Berg wrote:
>
> On Wed, 2018-10-24 at 09:33 +0200, Sedat Dilek wrote:
> >
> > > Align the licenses with their permission to clean up and to
> > > make it all identical.
> > >
> >
> > Does it make sense to put the BSD license (text) in a separate file
> >
27 matches
Mail list logo
