hi,
On 12 December 2016 at 12:05, Martin Blumenstingl
wrote:
>
> It seems that there are a few devices out there where the whole EEPROM
> is swab16'ed which switches the position of the 1-byte fields
> opCapFlags and eepMisc.
> those still work fine with the new code, however I had a second patc
Hi,
This tells the wireless stack what rates are possible in 11abg.
See where ath9k_legacy_rates is used in ath9k.
-adrian
On 5 December 2016 at 16:32, 杰尔米 wrote:
> I'm a newbies in 802.11n, please excuse me to ask some unprofessional
> questions:
>
> I found the array ath9k_legacy_rates belo
The ath9k hardware supports up to four separate TX rate entries per TX
descriptor.
-a
On 4 December 2016 at 19:11, 杰尔米 wrote:
> Can anyone give me a clue, please?
> 发自我的iPhone
>
> ___
> ath9k-devel mailing list
> ath9k-devel@lists.ath9k.org
> https:/
Hiya,
maybe the right thing to do is to set a flag that says "please
replumb", then do a reset, and have the reset path see if we need to
replumb keys and do so?
To make locking less terrible, maybe we need to cache the keys in the
ath9k driver somewhere so replumbing doesn't require reaching int
On 15 November 2016 at 01:34, Johannes Berg wrote:
>
>> But there is a per-descriptor TX rate table entry in the driver.
>> FreeBSD uses it to implement its rate control for the intel drivers.
>>
>> What am I missing? :)
>
> Not sure. But there isn't a per-descriptor table in the driver. There's
>
hi,
it should be Y.
-a
On 7 November 2016 at 03:34, Simone Di Domenico
wrote:
> Hi All,
> I am a newbie of Atheros WiFi chipsets and I am trying to use the spectral
> scan feature available on AR9280.
> It's working fine, but I would understand in details the type of data
> returned from che
Hi,
On 25 October 2016 at 22:56, Johannes Berg wrote:
>
>> The intel 7260 and later parts also allow user controllable rate
>> control and provide transmit completion feedback, but I don't know
>> whether it's enough for your needs.
>
> Perhaps. However, existing rate control is *very* tightly co
hi,
person who gave talk here :)
so the mac does do wep, tkip, ccmp encryption. the mfp frames use
another encryption type that the mac doesn't do, so it is then done in
software.
each keycache entry in mac80211 tags things as hw or sw handled.
it clears that flag so mac80211 doesn't attempt to
t it all maps to the known 11abgn encoding
types.
-adrian
>
>
> 2016-10-20 5:54 GMT+09:00 Adrian Chadd :
>>
>> hi,
>>
>> it's done for you in the chip in hardware. not firmware.
>>
>>
>> -a
>>
>>
>> On 17 October 2016 at
hiya,
there's a tplink RTL81xx 11ac NIC that's growing linux and freebsd
support. I believe it's software rate controllable.
The intel 7260 and later parts also allow user controllable rate
control and provide transmit completion feedback, but I don't know
whether it's enough for your needs.
Unf
hi,
it's done for you in the chip in hardware. not firmware.
-a
On 17 October 2016 at 22:46, SangHyuk Kim wrote:
> Dear all,
>
> I'm using ath9k_ar9003 type and ath9k_htc type.
>
> And I'm studying how packet be transmitted through wifi driver.
>
> I have researched from application layer to
hiya,
Oleksij has gone and updated the ath9k-htc-firmware port to use the
latest gcc-6 compiler and updated binutils.
I'd like some further testing before we merge it into trunk.
https://github.com/qca/open-ath9k-htc-firmware/pull/93
He's gone and tested out STA mode - but we're not equipped to
Hi,
So, interrupt handling is finnicky. It's possible there's already a
posted interrupt waiting somewhere. Ideally you'd do a write-then-read
in each of the interrupt blocks between your device and the CPU to
ensure thing are synced. Otherwise the different frequencies in
different blocks in the
On 25 August 2016 at 11:15, Lamar Hansford wrote:
> I am using legacy interrupts in this case. I found the issue where the
> interrupts were not firing (stupid issue on my part). Working on getting the
> data through the pipe.
>
> I still have a question on the meaning for the ASYNC cause.
>
>
Does the ARM board do legacy interrupts as well as MSI?
-a
On 24 August 2016 at 20:50, Lamar Hansford wrote:
> Hi,
> I am trying to port the driver to an ARM platform using SMP where we see a
> hard lock-up (no panic). To address this and a number of secondary issues I
> am refactoring the
Hi!
Firstly - please post your diffs somewhere so people can start to help. :)
ok, so:
I have an open copy of the ar9380 HAL in freebsd - find a freebsd tree
(eg github.com/freebsd/freebsd), it's in
sys/contrib/dev/ath/ath_hal/ar9300/ . Grep _MSI *.c and you'll see
wha'ts going on.
TL;DR:
* t
Hi,
So, there's a keycache index in the RX packet telling you which
keycache entry it matched.
See if it's matching a keycache entry but then failing to decrypt; if
this is happening then an easy check would be "hit some threshold for
crypto failures" => "replumb that keycache slot."
This means a
Hi,
Yeah, delete and re-add should be fine. Just look at whatever the
locking requirements are so you're serialised with anything else
touching the keycache hardware at the same time.
Hopefully it's not such a terrible bug that you end up doing it like,
hundreds of times a second. :)
-adrian
_
hi,
any news?
-a
On 14 July 2016 at 13:10, Adrian Chadd wrote:
> Hi,
>
> Yeah, delete and re-add should be fine. Just look at whatever the
> locking requirements are so you're serialised with anything else
> touching the keycache hardware at the same time.
>
>
Right, I just checked. They have some code that reads the key and mic
to compare against what was programmed, and they're calling it each
iteration of ieee80211_timeout_stations().
That happens pretty infrequently (every second, or 15, or 30? not sure
without digging.)
How about doing some periodi
Also, are you validating both the keycache entry and MIC for TKIP? Do
you have a patch you can share?
-a
On 13 July 2016 at 13:39, Adrian Chadd wrote:
> Hi!
>
> Ok, so! There's actually some bug in the keycache hardware that the
> reference driver calls ATH_SUPPORT_KEYPLUMB
Hi!
Ok, so! There's actually some bug in the keycache hardware that the
reference driver calls ATH_SUPPORT_KEYPLUMB_WAR. It waits to see if
there's crypto errors upon RX and if so, it replumbs the key.
I think this is a workaround that needs to be plumbed into the driver.
Bug me about it again
On 8 July 2016 at 10:55, Ben Greear wrote:
> On 07/08/2016 10:46 AM, Adrian Chadd wrote:
>>
>> hi,
>>
>> There's a transmit descriptor bit, AR_CorruptFCS, which you can set
>> and it will negate the FCS so it always fails.
>>
>> Look in the ar900
hi,
There's a transmit descriptor bit, AR_CorruptFCS, which you can set
and it will negate the FCS so it always fails.
Look in the ar9002_mac.c / ar9003_mac.c where NoAck is set; i think
AR_CorruptFCS should also be set in that (ctl1 for ar9002 and below,
ctl12 for ar9003)
-a
On 8 July 2016 a
Hi,
I don't /think/ the CSI dump provides vectors establishing which
stream(s) appear on which antennas (ie, for stream TX 0, the
per-RX-antenna information.) It's just a magnitude value.
(I'm about to go pull down this stuff and look at it in more detail
because I just got Osprey location servic
Can you post a trace showing the incoming packet, transmitting packet,
transmitting complete packet?
-adrian
On 5 July 2016 at 04:24, Cesar wrote:
> Dear Adrian Chadd,
>
> Thanks for your suggestion...
> After that we did some experiments following your suggestion. We enable
&
thing really silly like context switching between the RX and TX
threads of the driver.
-adrian
On 28 June 2016 at 19:05, Cesar wrote:
> Dear Adrian Chadd,
>
> Thanks for your reply. It's correct that USB may introduce some delays, but
> in our experiment we use mini-pcie devic
Hi,
can you try this using pci/pcie devices instead of USB? There may be
USB scheduling things in the way.
On 27 June 2016 at 20:55, Cesar wrote:
> Hello all,
> We’ve recently tried to test packet injection performace in ath9k monitor
> mode. We set 2 laptops in monitor mode , PC 1 send a 500 By
On 9 June 2016 at 19:56, Adrian Chadd wrote:
> hi,
>
> I've noticed something reasonably quirky with the AR9380 and later
> EDMA engine and I'd like to see if anyone else has seen it with ath9k.
>
> It /looks/ like the TXOP gating for burstTime (ie, WMM bursts) is
&g
[picking a random email to reply to]
I /think/ the TSF is only valid for the last frame of an aggregate.
'more' means "this RX frame is split across multiple RX descriptors"
"moreaggr" means "there's more subframes in this RX'ed A-MPDU"
If you get a TSF in the first frame, it's whatever was lef
hi,
I've noticed something reasonably quirky with the AR9380 and later
EDMA engine and I'd like to see if anyone else has seen it with ath9k.
It /looks/ like the TXOP gating for burstTime (ie, WMM bursts) is
gated by a TX FIFO entry. Ie, if you queue 8 separate TX FIFO entries,
each with a single
On 7 June 2016 at 04:12, Toke Høiland-Jørgensen wrote:
> Toke Høiland-Jørgensen writes:
>
>>> [snip]
>>>
>>> I also found one of my notes in my version of this - how can we
>>> estimate the duration of an A-MPDU, when we only get hardware
>>> de-encapsulated frames?
>>
>> Well in my case I'm side
[snip]
I also found one of my notes in my version of this - how can we
estimate the duration of an A-MPDU, when we only get hardware
de-encapsulated frames?
-adrian
___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailm
> Sandeep.
>
>
> On Saturday, 4 June 2016 10:32 PM, Adrian Chadd wrote:
>
>
> i'm documenting more details in freebsd as I figure stuff out. I'll
> write up a webpage with what I can glean from the drivers/headers.
>
>
>
> -adrian
>
>
> On 2 June
On 5 June 2016 at 03:55, Toke Høiland-Jørgensen wrote:
> Adrian Chadd writes:
>
>> I've been working on something similar in freebsd, so cool to see this
>> happening here!
>
> Cool. Do you have code available somewhere?
not yet. It was mostly what you just did i
hi,
I've been working on something similar in freebsd, so cool to see this
happening here!
The only thing missing atm is STBC and LDPC. My RX airtime code looks
basically like this one too; but I have TODO items for ensuring
LDPC/STBC calculations are sane.
-adrian
On 3 June 2016 at 09:51, T
Thanks & regards
> Sandeep.
>
>
> On Sunday, 29 May 2016 11:44 PM, Adrian Chadd wrote:
>
>
> hiya!
>
> I'm trying to bring up MCI bluetooth coexistence on the QCA9565 on
> FreeBSD. I'm having no end of trouble - it seems that no matter what I
> do, the bl
hiya!
I'm trying to bring up MCI bluetooth coexistence on the QCA9565 on
FreeBSD. I'm having no end of trouble - it seems that no matter what I
do, the bluetooth always wins and the wifi side disconnects when the
bt does an active scan (HCI "inquiry".)
Does anyone remember the deep and amusing de
This is a 10dB transmit signal gain difference, right?
I can go poke someone on the PHY side and see if they have any ideas...
-a
On 20 May 2016 at 12:09, Alexander Couzens wrote:
> On Fri, 20 May 2016 02:31:15 +0200
> Alexander Couzens wrote:
>
>> Changing the table for 5Ghz HT20/HT40 to fi
The other hack that I've seen ath9k do is they actually assign
sequence numbers and CCMP IVs at the point of enqueue-to-hardware,
rather than enqueue-to-driver. I tried this in FreeBSD and dropped it
for other reasons, mostly in favour of shallower (configurable!)
per-station queue depths.
That wa
Well, there shouldn't /also/ be a software queue behind each TXQ at
that point. Eg, in FreeBSD, I queue up to 64 frames per station and
then default to round robining between stations when it's time to form
another aggregate. It's done that way so i or someone else can
implement a wifi queue discip
Hi,
So:
* the hardware can give us a per-AC transmit opportunity;
* software queuing needs to handle the per-STA transmit opportunity;
* they (and I followed convention after testing) found the "best"
compromise was to hardware queue up to two frames, which we could
probably do slightly more of a
i think for the later hardware there's some way to get it as part of
the normal payload, because I /think/ that's how the wifi positioning
stuff gets fine resolution information.
I should really dig it all up.
-adrian
On 8 May 2016 at 19:01, Allen Welkie wrote:
> Adrian Chadd
Hi,
It's just a placeholder for each of the fields defined. look at
ath9k_hw_process_rxdesc_edma() for what those fields mean.
-a
On 13 April 2016 at 08:24, Dan wrote:
> Hi
>
> Could anyone explain the contents of this struct from ar9003_mac.h
>
> struct ar9003_rxs {
> u32 ds_info;
>
On 13 April 2016 at 01:40, Dan wrote:
> Adrian Chadd freebsd.org> writes:
>
>>
>> On 12 April 2016 at 15:05, Dan plezica.com> wrote:
>> > Hi
>> >
>> > I am having some trouble understanding the difference between
>> > channel state
On 12 April 2016 at 15:05, Dan wrote:
> Hi
>
> I am having some trouble understanding the difference between
> channel state information (often requested on the mailing list)
> and what is currently available via spectral scan.
>
>
> My understanding is as follows;
> - spectral scan (once trigger
On 8 April 2016 at 21:56, Johannes Berg wrote:
> On Fri, 2016-04-08 at 21:27 -0400, Avery Pennarun wrote:
>
>> > Just to be clear, this crash is only from *reading* the agg_status
>> > files. I don't know if the crashiness reduces when disabling the
>> > aggregation timeouts, since that's a separ
Hi,
ath9k has support for station powersave, and it's driven by mac80211.
You should be able to implement that policy in mac80211 and then add
hooks so your bluetooth code can get notifications about it.
-a
___
ath9k-devel mailing list
ath9k-devel@list
ld
be there though!
I just don't know if you'll get them if it's being wired as a
BT_ACTIVE pin instead of a GPIO pin..
-adrian
> Regards
> Sandeep.
>
>
> On Thursday, 31 March 2016 1:32 AM, Adrian Chadd wrote:
>
>
> Hi!
>
> I don't know if you
Hi!
I don't know if you can do simulaneous wlan and BT RX - especially
since WLAN RX sometimes requires ACKs to be sent. :) But for
multicast, sure. You'd have to check the NIC schematic and antenna
switch programming to see if you can do simultaneous wlan RX (with no
TXing, eg RTS/CTS, ACK, etc)
On 28 March 2016 at 21:22, sandeep suresh wrote:
> Hello Adrian,
> Thanks for your response. Currently with 2-wire coexistence, BT has
> higher priority when compared to WiFi. You had shared the following
> different bitfields that can be configured with different weights:
>
> WLAN:-
> wait_
On 27 March 2016 at 09:43, sandeep suresh wrote:
> Dear Experts,
>
> WiFi-BT Coexistence:
> To let wireless LAN systems coexist with Bluetooth system, a hardware Packet
> Traffic Arbiter (PTA) scheme is used. Here PTA is based on 2-wire
> coexistence , BT_ACTIVE and WL_ACTIVE. When BT wants to use
hi,
sorry if this hasn't been answered already - only the details in the
last subframe are accurate. the rest aren't!
-a
On 28 October 2015 at 08:34, Jinghao Shi wrote:
> Hi,
>
> Recently I used an OpenWRT router (TP-LINK WDR3500, AR9340, ATH9K) to sniff
> packets, and I found that the MCS in
not ath9k, no.
I think qca988x was the first chip to do that in this family. Maybe
the ath6kl chips also do, since they do have an soc on-chip.
-adrian
On 16 December 2015 at 00:45, Janusz Dziedzic wrote:
> Hello,
>
> Is there ath9k HW that supports l3/l4 checksum offload?
>
> BR
> Janusz
Hi,
I've had someone ask me about japan certification for ath9k. it
apparently now requires the transmitter stop everything, beaconing
included, when it sees an interferer signal.
Apparently ath9k is also beaconing no matter what the interference is.
Has anyone else come across this?
-a
__
ready look into
>>> https://wireless.wiki.kernel.org/en/users/drivers/ath9k/spectral_scan ?
>>>
>>> Greetings,
>>> Vincent
>>>
>>> 2015-08-24 11:29 GMT+02:00 Hemamali G :
>>>
>>> > Hi Adrian,
>>> >
Hi,
IIRC only the data in the last subframe descriptor is "valid". It's
valid for the whole A-MPDU.
-a
On 29 October 2015 at 10:46, Jinghao Shi wrote:
> Hi,
>
> Recently I used an OpenWRT router (TP-LINK WDR3500, AR9340, ATH9K) to sniff
> packets, and I found that the MCS information in the
Hi,
Can you turn on ANI debugging in ath9k and capture what it's doing?
I've seen this happen on some other outdoor stuff with AR9380 but I
think their setup is more "the interference is terrible". But yes, I'd
like to debug ANI more. :)
-adrian
On 8 October 2015 at 21:13, Joe Ayers wrote:
from qca-wifi-1.2:
ar5416phy.h:#define AR_PHY_CCA_NOM_VAL_KIWI_2GHZ -120
ar5416phy.h:#define AR_PHY_CCA_MIN_GOOD_VAL_KIWI_2GHZ-127
ar5416phy.h:#define AR_PHY_CCA_MAX_GOOD_VAL_KIWI_2GHZ-110
.. and:
ar5416phy.h:#define AR_PHY_CCA_NOM_VAL_MERLIN_2GHZ -112
ar5416phy.h:#defi
hiya,
for what it's worth - this looks okay to me. His noise floor looks
about as low as I'd expect on his plots.
-adrian
On 22 July 2015 at 01:42, Martin Blumenstingl
wrote:
> The FreeBSD driver [0] uses the same 2G values as for the AR9280 chips.
> Using the same values in ath9k results in
Hi,
Is that the same thing? I thought the power_save thing is the Station
mode powersave, not the suspend/resume powersave or the PCIe PHY power
control stuff.
-adrian
___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/ma
Hi,
What rate(s) are you trying to inject at?
wifi frames can actually be longer than 1ms...
-a
On 8 September 2015 at 05:35, Paul wrote:
> Hi,
>
> I've been hitting hat seems to be a hard limit for injecting packets
> of 1 / 10ms. I would like o inject
> packets in to the card 1/ms or even
On 24 August 2015 at 08:14, Till Wollenberg
wrote:
> Hi!
>
> * On 23.08.2015 at 21:57 Adrian Chadd wrote:
>> [Getting CSI]
>> ok, I've found a few pieces about this. What exactly are people after?
>
> SNR per OFDM sub-carrier for a rec
I? If you wish you could give me a
> short update by mailing me.
>
> Best wishes.
>
> 2015-08-23 21:57 GMT+02:00 Adrian Chadd :
>>
>> ok, I've found a few pieces about this. What exactly are people after?
>>
>>
>> -a
>>
>>
>> On 22 Au
ok, I've found a few pieces about this. What exactly are people after?
-a
On 22 August 2015 at 11:09, Hemamali G wrote:
> Guys,
>can somebody help me out on this!
>
>
> On Fri, Aug 14, 2015 at 6:42 AM, Adrian Chadd wrote:
>>
>> ugh, someone needs
Hi,
you don't get that from the hardware.
You can likely tap one of the GPIO pins on the NIC and configure it to
be uhm, hm, the TXFRAME signal, maybe? But that may not be exactly
what you want. It's likely closer though.
-adrian
On 23 August 2015 at 10:20, Jeon wrote:
> I am modifying ath9
ugh, someone needs to come to the bay area and keep poking me until I
code it oup. :(
-a
On 13 August 2015 at 13:06, Hemamali wrote:
> Zeyu Wang gmail.com> writes:
>
>>
>> Dear all,
>> I'm a newer PhD student in HKUST and I read a paper which use the CSI
> information to do the localization.
ok, can you re-run this again before the NF patch, so I can compare?
And yeah, I can compile up fft_eval for freebsd. I think I've done it
once or twice before..
-a
On 28 July 2015 at 16:43, Martin Blumenstingl
wrote:
> On Wed, Jul 29, 2015 at 1:37 AM, Adrian Chadd wrote:
>>
On 28 July 2015 at 15:33, Martin Blumenstingl
wrote:
> On Wed, Jul 29, 2015 at 12:22 AM, Adrian Chadd wrote:
>> Hm, doesn't someone have a graphical frontend for this on linux?
> Yep, I just found FFT_eval (screenshot: [0] and ath_spectral
> (screenshot [1]) in the ath9k spe
Hm, doesn't someone have a graphical frontend for this on linux?
-a
On 28 July 2015 at 15:07, Martin Blumenstingl
wrote:
> On Tue, Jul 28, 2015 at 7:25 PM, Adrian Chadd wrote:
>> So the values aren't "bad" on the 1043nd - they're in 1/2 or 1/4dB,
>>
So the values aren't "bad" on the 1043nd - they're in 1/2 or 1/4dB,
but there's no scalar quantity (ie, it's not in dBm.) The 1043nd
calibrates down to around -95 or so, which "sounds" like it's in dBm
but it isn't, and any similarity is just coincidence.
It does sound like your AR9227 sees noise.
AM, Adrian Chadd wrote:
>> is it never getting any readings before your patch? NF Readings all
>> look empty...
> Yes, looks like it. Unfortunately I haven't saved a complete kernel
> log (with ath9k debug level = 0x4449) but only a few parts. Here
> are the interesting
is it never getting any readings before your patch? NF Readings all
look empty...
-adrian
On 27 July 2015 at 15:30, Martin Blumenstingl
wrote:
> Hi Adrian,
>
> On Mon, Jul 27, 2015 at 9:13 PM, Adrian Chadd wrote:
>> I wonder if this is a mis-merge on my part (I'm th
Hi,
I wonder if this is a mis-merge on my part (I'm the freebsd maintainer.)
can you log the noisefloor calibrated values before and after the
patch? I'd like to see how low it calibrrates to.
-a
On 22 July 2015 at 01:42, Martin Blumenstingl
wrote:
> The FreeBSD driver [0] uses the same 2G v
On 16 May 2015 at 14:45, Luiz de Barros Oliveira Neto wrote:
> Hello, Adrian,
>
> I was willing to implement a special type of diversity where an user space
> application would decide based on previous data which chain to use at a
> given time for TX/RX.
> The application would pick either chain0
Hi,
the slow diversity is different - it's if you had say, four antennas
hooked up to two radio chains, via an external antenna switch.
Or, say, horizontal/vertical polarisation configurations.
It won't work (easily) the way you want - it'll receive on both at the
same time, and it'll transmit b
Hi,
Try writing something that periodically checks if the key is in there.
I have a feeling that I've seen this bug in the reference driver, and
they "fixed" it by noticing decrypt failures for a given destination
and replumbing the key if it didn't match. :(
(I always wondered if this would ever
Hi,
So only the /final/ details in the last RX descriptor is valid. It's
possible that the rest of them are corrupted/previous packets.
-a
On 18 April 2015 at 12:57, Kamran Nishat wrote:
> Hi,
> according to wireshark (radiotap.mcs.bw field) some MPDUs in an
> A-MPDU are recieved at 40Mhz
Hi,
You can do a fast channel switch under very specific conditions. It
includes but isn't limited to being on the same band (ie, no fast cc
between 2/5ghz.)
-adrian
___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailm
On 3 April 2015 at 19:51, Sujith Manoharan wrote:
> Bob Copeland wrote:
>> So I'm still missing the part where we wake hardware up on this version.
>> It seemed to work for me though.
>
> Sorry, I was referring to the PS mechanism on chips which don't
> support autosleep.
>
> For autosleep, no spe
Hi,
IIRC, the autosleep stuff only started getting used by the AR9285 and
later, and it should be using the normal beacon interval timers to
work.
The normal way is:
* program normal beacon interval timers, and a "how long to stay awake
at each beacon interval to try and get a delayed beacon" va
Hi,
I'd have a look at what power state the PCI device is in even when
it's blacklisted, and compare it to another NIC when it too is
blacklisted.
I think this is one of those things where you need a PCIe analyser and
digital multimeter to check. Either the USB device is always on, the
PCIe PHY i
down (because of the low battery). I am loathed
>>> to give up and go back to the old abg card as the new n card is
>>> working perfectly in terms of speeds and connections during daily use.
>>>
>>> I'll keep going with it as long as there's hope of a
Maybe leaving WOW enabled is leaving the PCIe PHYs online and active?
And/or USB/bluetooth?
It has to be drawing significant current for it to flatten the battery
whilst suspended, so my guess is that quite a large chunk of the
hardware between the NIC and the battery is not fully suspended.
-a
On 16 March 2015 at 12:48, Frank Zafka wrote:
> Thanks for the response. Old behaviour (on abg Atheros card) battery
> goes from 100% to 85% in 7-8 hours (this is the same when no wifi card
> present). New behaviour (n Atheros) battery goes from 100% to 0% in
> 4-5 hours.
Hm, that's quite a lot o
... how much is "huge loss" ?
-adrian
___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Hi,
There's WoW support and there's bluetooth support, both of which I
think leave parts of the PCIe PHY up.
Try unloading ath9k before suspend and see if that makes things better.
-adrian
On 14 March 2015 at 02:04, Frank Zafka wrote:
> Hello. Looking for some advice regarding a massive pow
On 12 March 2015 at 07:02, Kalle Valo wrote:
> Oleksij Rempel writes:
>
>> Am 10.03.2015 um 16:35 schrieb Adrian Chadd:
>>> Yeah, let's have it warn for a month or two.
>>>
>>> There's some pending work that will break the API with 1.3 firmware,
Yeah, let's have it warn for a month or two.
There's some pending work that will break the API with 1.3 firmware,
so it has to happen sooner rather than later. But yeah, maybe warn for
about a month would be good. the older firmware is still in the git
tree in case people want it.
-adrian
__
On 26 February 2015 at 02:20, Jouni Malinen wrote:
> On Wed, Feb 25, 2015 at 10:14:45AM -0800, Linus Torvalds wrote:
>> While I realize that people may disagree about the exact details of
>> how to fix this in the long run, may I suggest that in the meantime we
>> at least get the two workaround p
On 25 February 2015 at 10:14, Linus Torvalds
wrote:
> While I realize that people may disagree about the exact details of
> how to fix this in the long run, may I suggest that in the meantime we
> at least get the two workaround patches applied?
>
> I'm talking about the two from Jouni - the "do
Hi,
I thought about doing this for rate probing with FreeBSD's sample rate
algorithm, but after actually having to use the damned thing in noisy
environments I realised that it just wasn't worth the effort to
optimise rate control selection whilst doing EAPOL frames.
If we did more useful softwar
On 23 February 2015 at 13:53, Linus Torvalds
wrote:
> On Mon, Feb 23, 2015 at 1:30 PM, Jouni Malinen wrote:
>>
>> How far is the station from the AP? Would it be possible to see whether
>> the behavior changes if you were within, say, five meters or so?
>
> Well, it was pretty much within five me
So the interesting part thus far:
14:07:23.513500: RTM_NEWLINK: operstate=1 ifi_flags=0x1003 ([UP])
14:07:23.513662: RTM_NEWLINK, IFLA_IFNAME: Interface 'wlp1s0' added
14:07:23.513842: nl80211: if_removed already cleared - ignore event
14:07:23.536309: nl80211: Event message available
14:07:23.536
On 22 February 2015 at 17:41, Linus Torvalds
wrote:
> On Sun, Feb 22, 2015 at 4:54 PM, Adrian Chadd wrote:
>>
>> I /think/ it's okay? The removed stuff is the pre-shared key pieces.
>
> Ok. Attached is what seems to be the relevant part of the
> wpa_supplicant.lo
On 22 February 2015 at 15:00, Linus Torvalds
wrote:
> On Sun, Feb 22, 2015 at 1:50 PM, Linus Torvalds
> wrote:
>>
>> Ugh. When I add "-dd" to the command line, it has now worked three
>> times in a row, when before it worked once out of ten tries.
>>
>> So my guess is that it's something timing-d
Hi!
I've rolled some updated firmware images for ath9k-htc:
https://people.freebsd.org/~adrian/ath9k_htc/1.4/
I'd like to get some wider testing before I submit them to
linux-firmware.git for inclusion.
So please test them out and let me know if they do / don't work for
you. Outside of a couple
On 22 February 2015 at 10:30, Linus Torvalds
wrote:
> On Sun, Feb 22, 2015 at 10:24 AM, Adrian Chadd wrote:
>>
>> Just a wild shot - try disabling fast authentication and see if that
>> makes a difference?
>>
>> wpa_supplicant.conf:
>>
>> fa
On 21 February 2015 at 15:34, Linus Torvalds
wrote:
> So I've had problems connecting to some networks before on my
> Chromebook Pixel, but now I'm testing a new Ubiquiti network at home,
> and can see this issue at home too.
>
> I know the wireless works, because other devices work fine on that
>
On 22 January 2015 at 14:21, Sujith Manoharan wrote:
> Adrian Chadd wrote:
>> It's already doing MIMO diversity. If you have a chainmask that has 2
>> or more antennas enabled it already is doing it.
>>
>> I think that variable is slow antenna diversity, not
1 - 100 of 924 matches
Mail list logo
