Is there some more information that I can gather in order to resolve
this issue? Note that disabling power management is not a sufficient
workaround for me, but it makes the error much less frequent.
http://bugzilla.kernel.org/show_bug.cgi?id=14267#c55
#56 has a full debug log of the failure
Hi,
Luis R. Rodriguez wrote:
http://bugzilla.kernel.org/show_bug.cgi?id=14267#c55
That bug report is about issues (so far AR5416 only reported with
the PS issue) about disconnections with your AP if PS is left
enabled by default which will trigger dynamic PS to be enabled by
by default,
(linux-wireless posters, please Cc me since I am only subscribed to
ath9k-devel.)
Hello,
I get the above error (and thus loss of connectivity) using
wireless-testing/master as of Dec 13.
phy0: Atheros AR5416 MAC/BB Rev:2 AR5133 RF Rev:81: mem=0xf832, irq=21
I've previously posted various
Hi Luis,
Thanks for the reply!
Luis R. Rodriguez wrote:
This seems like your old comments from an old e-mail, but I guess
you include them since you now include linux-wireless.
Yeah, I tried to summarize previous and new findings for new readers.
Manually disabling power management for
Vivek Natarajan wrote:
So what could give us more information?
If the issue is specific to AR5416 and power save,
I don't think it is. Tonight I saw the problem a third time using
wireless-testing with power management off for the interface. This
time I also had Sujith's 6 patches from
Hello,
Peter Stuge wrote:
I don't think it is. Tonight I saw the problem a third time using
wireless-testing with power management off for the interface. This
time I also had Sujith's 6 patches from 2009-12-14 applied.
5k lines of debug=0x log is available at:
http://stuge.se
Hi Felix,
Felix Fietkau wrote:
Since I never saw this behavior in exactly the same kernel with
another mac80211 driver (ipw2200) the problem must be in the ath9k
driver or in my AR5416 MAC/BB Rev:2 AR5133 RF Rev:81 hardware.
ipw2200 is not a mac80211 driver.
Whoops! That was me not
Peter Stuge wrote:
Then I disabled power management and have now been listening to the
stream for 4½ hours without AP disconnect.
Today I was disconnected twice! First after circa 42 hours, next time
after about two hours. Power management off all the time.
After the first disconnect:
# grep
Today when I came home and resumed my system I got these messages
from the driver:
[302214.156400] phy1: device no longer idle - scanning
[302214.341494] ath: ath_isr status=0009 imask=f4001071 wecare=0001
[302214.341983] ath: ath_isr status=0109 imask=f4001071 wecare=0001
Luis R. Rodriguez wrote:
[302214.359875] ath: Failed to stop TX DMA in 100 msec after killing last
frame
[302214.359900] ath: Unable to stop TxDMA. Reset HAL!
What kernel?
The one that I reported using in the disconnect thread. I'll repeat
in this thread. Sorry that I forgot to mention
Sujith wrote:
Benoit PAPILLAULT wrote:
I am seeing this as well on 2.6.33-rc4-wl, but only at unload
time (modprobe -r ath9k).
Yep, this happens because I changed the debug mask for that message
to FATAL. It is harmless, but can be fixed by cleaning up the
virtual wiphy / idle stuff.
yingqiang Ma wrote:
2010/1/20 Sujith sujith.manoha...@atheros.com
Yep, this happens because I changed the debug mask for that
message to FATAL.
It is harmless,
WTF?! Please make up your mind! Either it's FATAL, or it's harmless -
which is it?
but can be fixed by cleaning up the virtual
Jouni Malinen wrote:
Since the issues so far are obaserved on AR9160 and AR9220
(and not AR9280) and AR9271 (sujith) this might be a bus issue
The current snapshot is very much broken with my AR9280 (at least on 2.4
GHz band) when using AP mode (the assoc resp frame is not reported as
Pavel Roskin wrote:
On Sat, 2010-01-30 at 00:34 +0100, Felix Fietkau wrote:
Please try this patch and see if it helps.
Yes, it worked perfectly!!!
Confirm it also solves the problem on my 168c:0023 AR5008,
AR5416+AR5133.
//Peter
___
Pavel Roskin wrote:
D-Link must be getting really low on model numbers if they are
reusing the same number for a substantially different product.
I think this is pretty common for a few years already.
Horrible, but common. :\
//Peter
___
This is completely off-topic for this mailing list.
Rodolphe Marques wrote:
The only problem is that only the first interface gets the default
gateway configured.
In a normal system there is only one default gateway.
Please consider if you really must handle multiple default gateways.
In any
Rodolphe Marques wrote:
The problem I think is that linux is not expecting to have several
interfaces connected to the same network
The problem is not with Linux, but with you seeming to misunderstand
sockets and IP networks. (You'll get same results on all other OSes.)
I think you need a
Holger Schurig wrote:
Now two high powered, low noise Acess Points with a clear line of
sight would give some real range!
HAMNET
And http://tier.cs.berkeley.edu/wiki/Wireless which changes the MAC
layer a bit, for very nice gain in performance.
//Peter
Luis R. Rodriguez wrote:
and now today we have proper vendor support from at least Atheros.
I haven't seen much of that.
Yes, there is certainly some support, and I completely agree that
Atheros is being far more supportive than most if not all other
vendors, but I think the support has a long
oii...@aol.com wrote:
I don't understant why put the AP and STA side by side would come
out very low throughput, anyway.
The receiver is probably getting saturated, the transmitted signal is
too strong.
//Peter
___
ath9k-devel mailing list
Justin P. Mattock wrote:
ath_print in xmit.c should say Reseting hardware
I think that should be Resetting hardware with two t:s.
//Peter
___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Cloud Strife wrote:
phy0: Atheros AR5416 MAC/BB
That's an AR5008 card. I have one too.
speed is completely instable
Sometimes the card stops working all together
any ideas?
Unfortunately Atheros does not support ath9k for AR5008, only for the
newest generation hardware, so you and I are
Lars Hardy wrote:
I have tried with 2 different Atheros chipset in AP mode, the AR5416
and AR9280. dd-wrt gives a stronger signal with both chipsets
compared with openwrt.
I know the ath9k is under development, so my question is if this is
known by the development team and therefor will be
Björn Smedman wrote:
If I then switch the AP channel (from 1 to 11) performance is looking
good again:
Does it stay consistent and associated for you over say a weekend in
an office building, or a work week, or a month?
//Peter
___
ath9k-devel
Robert Chan wrote:
I am new to openwrt and want to look for an ath9k router with a
serial port to kickoff my learning curve. I have spent some time
on google but to no avail.
I hope this is the right list to ask. Can someone please give me
some pointers?
This isn't really the right list.
Alan wrote:
The Intel 5100 costs 10$ on ebay, and Intel's drivers for Linux
work just fine.
Seems there's little choice but ath9k for plain minipci cards though. :\
//Peter
___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
Lv追风 wrote:
I use the normal AV line, connect to my USB EasyCap,and capture the
video by my PC.
Ok, so both video and wifi runs over USB.
Are you using a USB hub? Any other USB devices? I suggest removing as
many USB devices as possible, and testing again with *only* the wifi
and the video
Vlada Matena wrote:
Connection is very unstable. In fact it is unusable.
..
I am suspecting the card to be defect as its chipset AR5416 +
AR2133 should be supported by ath9k driver.
Should, but I don't believe the driver works very well with the older
ath9k hardware. Most if not all focus is
Alexander Simon wrote:
Examining debugfs a little, i can see there are no rx drops nor lost
interrupts. Does anyone have a hint what this could be related to?
Where should i start investigating?
I hope you'll get some input, but I would not hold my breath if I
were you.
//Peter
madloi...@gmx.net wrote:
WLAN-Card (Atheros AR4516) in PCMCIA-Slot
Note that it's CardBus, not PCMCIA. We know what you mean, but
there's a big difference. PCMCIA is only 16-bit. CardBus is PCI, but
backwards compatible with PCMCIA.
Anyway, unfortunately there is no real support for 5416 here,
c...@netcom.co.uk wrote:
the ath9k driver(s) must be modules, _not_ built into the kernel.
That makes no sense at all. I think it's just another bug if it
doesn't work with built-in drivers.
//Peter
___
ath9k-devel mailing list
Luis R. Rodriguez wrote:
I want to know which tool I can use to analyse logs generated by the
pktlog patch for ath9k. I am using the Ubiquiti SR-71C cards.
We have no permission to open these tools up yet...
Maybe you can say something about their file format.
//Peter
Luis R. Rodriguez wrote:
Any hints on what this elusive 168c:ff1c device (and :ff1d) actually
is? Mac and Windows drivers *do* list these IDs...
No, not sure, perhaps a mistake upon programming the EEPROM somehow?
Except that Mathieu already confirmed it as a known ID. Maybe no more
can be
My system crashed hard a while ago. I guess because the AR9280 card I
have got overheated. The driver was loaded, but the card was not
being used at all.
I got a continous trace on the console, 5-10 pages of messages per
second. It was impossible to discern any details except ath_hw being
Luis R. Rodriguez wrote:
This on wireless-testing from Friday, plus a few debugfs patches
I posted recently.
I was running two STA just fine, and then tried to add 128 more.
You're serious right? I mean I'm happy your serious, but whoa, you
want 130 STAs on one interface working fine?
Ben Greear wrote:
I was hoping the 'deadbeef' registers indicated a particular error
in the NIC that I might could use for further debugging.
I'd guess it's a general error rather than something specific. I get
it on most boots and the driver needs some jerking around before the
card will start
Giuseppe, please do research on the things mentioned by Pat. They are
important when using mailing lists.
pat-lkml wrote:
On 10/9/2010 12:25 PM, giuseppe pes wrote:
But I do not know if the mac802.11 is implemented in software or wifi
card.
mac80211 is the name of a software layer within
gree...@candelatech.com wrote:
From: Ben Greear gree...@candelatech.com
The ath_debug_stat_tx references bf-bf_mpdu, which
is the skb consumed byath_tx_complete. So, call
the ath_debug_stat_tx method first.
Signed-off-by: Ben Greear gree...@candelatech.com
Acked-by: Peter Stuge
that the DMA addresses are cleared as well.
This does not obviously fix any bug, but may make it harder to
cause bugs in the future.
I wanted to follow up to see if there was any interest in this patch,
as it received no comment and has not been accepted upstream.
Acked-by: Peter Stuge pe
Poonam2 Gupta wrote:
we are using 2 wifi cards one on 2.4 Ghz and other on 5 Ghz, when
we do the air-time link metric computaion, then for both the links,
it shows as zero. can you pls let us know why link metric is
computed as zero?
I think you must explain what calculation you are doing,
Robert Szentmihalyi wrote:
Since we need AP mode support for a project we are currently
working on, we are ready to support you resolving this issue.
I wouldn't expect anything related to ath9k to happen that way. :\
//Peter
___
ath9k-devel mailing
Björn Smedman wrote:
1. TX DMA hangs under simultaneous high RX and TX load
2. TX is completely hung but chip is never reset
I have also observed both of these behaviors with just a standard
hostapd single VIF configuration.
Thanx Ben, it's a relief to know I'm not the only one
Quinn Strahl wrote:
I'm running Gentoo 2.6.36-r1, the card is an Atheros AR9285 in an Asus Eee
PC 1000HE, running on the ath9k driver, built-in to the kernel. Using the
latest drivers from compat-wireless made no discernible difference.
Your experience is quite consistent with mine. ath9k
Jay Davidson wrote:
I am looking to buy a few of the best Atheros wireless AR9 series
chipset cards available.
For STA or AP use?
Also for the AR9380, is it's 450Mbits/s phy /300Mbits/s TCP/IP
throughput supported in the ATH9K driver.
For STA use I can not really recommend ath9k. For AP I
Luis R. Rodriguez wrote:
On Sun, Nov 28, 2010 at 3:53 PM, Joe Perches j...@perches.com wrote:
Make the function name match the function purpose.
ath_debug is a debug only facility.
ath_print seems too generic a name for a debug only use.
Nack, I don't see the point.
The point is to
Joe Perches wrote:
+++ b/drivers/net/wireless/ath/ath9k/ar9002_calib.c
..
@@ -734,7 +734,7 @@ static bool ar9285_hw_cl_cal(struct ath_hw *ah, struct
ath9k_channel *chan)
if (!ath9k_hw_wait(ah, AR_PHY_AGC_CONTROL, AR_PHY_AGC_CONTROL_CAL,
0, AH_WAIT_TIMEOUT)) {
Luis R. Rodriguez wrote:
My preference is to automate this and not let the user be involved
and expand the way we propagate location learning information.
Meanwhile, what is needed is a simple tool to reconfigure cards to
have the actual correct country information.
I agree with the Linux
Luis R. Rodriguez wrote:
some other countries like Japan also do not allow country selection.
As a matter of fact US and JP are the only ones I am aware of that
have this explicit restriction.
Aha! Well, there are lots of users in other countries. :) It would be
nice for us to have a method.
Luis R. Rodriguez wrote:
I have considered opening up a tool that lets you do this if we can
determine your country is not US or JP by using GeoClue. I already
had some initial glue code with geoclue for iw
Great idea to add this to iw!
Patch was posted a while ago, but yeah I just
Mohammed Shafi wrote:
The mac filtering has not implemented at ath9k or not?
Yes there is no support to filter a specific MAC address alone and I
am not user whether this can be done because we set the corresponding
bits in the RX_FILTER.
Maybe it can be faked using ebtables, but naturally
Daniel Halperin wrote:
Now I'm starting to see other issues perhaps like those that Peter
alluded to. Deadbeefs, TX DMA warnings, etc.
Right. Also you may notice the symptom that the interface
disassociates from an AP after it does not receive more beacons.
It's not known *why* no more beacons
Lara Deek wrote:
I wanted to ask if anyone has any particular recommendations or
preferences between the two PC cards that I outlined.
Ubiquiti in general makes good products.
//Peter
___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
Luis R. Rodriguez wrote:
It helps if the community acknowledges efforts and tries to work
with companies who are putting good effort on things.
I would love to ack effort if I had experienced some. I've touched on
a plethora of indications of significant issues in the driver a few
times
Vasanthakumar Thiagarajan wrote:
+++ b/drivers/net/wireless/ath/ath9k/xmit.c
@@ -2110,6 +2110,27 @@ static void ath_tx_complete_poll_work(struct
work_struct *work)
} else {
txq-axq_tx_inprogress = true;
Ben Greear wrote:
but at least other clueless users would not go over stable limit
you have found.
I think it's very likely that the problems I find are general
issues that are just much easier to hit with lots of stations.
I strongly support this. I recognize several of your problems
Brian Prodoehl wrote:
I'm adding the WARN_ON that I talked about to my tree,
Where can I grab that commit?
and will post whatever code paths I'm seeing traversed while the
chip is sleeping.
They end up in kernel log, right?
I'm inspired by the recent dialogue and am just about to reboot
Peter Stuge wrote:
After the third hard lock and a power cycle the kernel says:
[0.375411] pci :02:02.0: [:0004] type 4 class 0x04
[0.375416] pci :02:02.0: unknown header type 04, ignoring device
After this I usually need to power cycle a couple of times to get
Luis R. Rodriguez wrote:
On Fri, Jan 07, 2011 at 07:36:07AM -0800, Peter Stuge wrote:
This is also my impression. Since it is important for Atheros to
have bugzilla reports rather than discussion on list
I'm trying to tell you how you can more efficiently work with
developers on reporting
First of all, sorry for dropping linux-wireless from my previous
message, it was mostly about my understanding of ath9k processes.
Crossposting is a bit unnatural for me, I usually strictly use
list-reply. Let's try with this one! :)
Peter Stuge wrote:
So there was a problem while writing
Brian Prodoehl wrote:
Out of curiosity, what's your AP?
July 2006 Linux 2.6.17.6 madwifi-ng Mini PCI AR5212.
wlan: 0.8.4.2 (svn 1531)
ath_hal: module license 'Proprietary' taints kernel.
ath_hal: 0.9.16.16 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413, RF5413)
ath_rate_sample: 1.2 (svn 1531)
Jouni Malinen wrote:
Only ath9k (ie. neither ipw2200 nor ath5k) has ever made a
difference between wpa_supplicant running or not.
You won't need wpa_supplicant for an open network that has only a
single AP and if you never get disconnected (which could happen,
e.g., if you leave the range
Ben Greear wrote:
Hard lock of course means no debug messages. :\ Note not kernel
panic, just CPU stop.
I assume you tried sysrq when it locked hard?
I generally disable sysrq because this is my laptop that goes on the
road. But good point, I've enabled it now.
Also, can you try that
Adrian Chadd wrote:
absolute lack of open discussion about anything firmware level
I've had a lot of success with:
* tweaking things, and seeing what happens;
This is reverse engineering by trial and error, not open discussion
with vendor experts. The reverse engineering effort is only
Peter Stuge wrote:
debug Atheros PCI core.
# while :;do lspci -n -A intel-conf1 -s 2:2; sleep .5s; done
02:02.0 0280: 168c:0029 (rev 01)
02:02.0 0280: 168c:0029 (rev 01)
02:02.0 0004: :0004 (rev 08)
Here's some more detail. The first may be the healthy case, but is
quite rare. Invalid
crocket wrote:
ath9k supports AP mode for all chipsets, but according to people
evidences, AP mode support for AR5xxx chipsets ceases to work several
minutes after the chipsets are turned into AP mode.
If you read it on the internet, it must be true.
I guess the AP mode support in ath9k is
Bernhard Schmidt wrote:
Felix already told me that this is a known issue and going over other
reports on this list and linux-wireless-ml it indeed is. Just wanted
to know if there is any known-good kernel version or a workaround
for that?
I fear you will not get any further info on this
Luis R. Rodriguez wrote:
I fear you will not get any further info on this mailing list. I would
suggest to watch the l-w list and try any patches that are sent there.
They never appear here and there's also no discussion here. Thinking
about it I actually don't really understand the
Luis R. Rodriguez wrote:
Unfortunately due to regulatory considerations which have also come
under recent stress [4] we cannot feature-wise let users overwrite
their own EEPROM, even if they know better.
I think this is good in the driver, but there was some discussion
about writing to the
Cedric Sodhi wrote:
When I boot (Gentoo), everything starts okay, but I get constant
try 1
try 2
try 3
authentication timed out
in dmesg.
Basically one of the issues I've had with ath9k since 2009.
When I restart /etc/init.d/net.wlan1 I get, after wpa_supplicant is
said to start
Jouni Malinen wrote:
SIOCSIFFLAGS: Unknown error 132
Error 132 is ERFKILL
Thanks for this clue!
Does you laptop have a physical switch or some key combination that
may have been hit to disable wireless?
In my case no. I have gotten both minipci ath9k card and cardbus
ath5k stuck in
Peter Stuge wrote:
Here's some more detail.
..
# while :;do lspci -n -A intel-conf1 -s 2:2 -xxx; sleep .5s; done
...
02:02.0 0280: 168c:0029 (rev 01)
00: 8c 16 29 00 00 00 b0 82 01 00 80 02 0c 00 00 00
Looking briefly into these registers the Status register (06) bit 15
says that the card
Luis R. Rodriguez wrote:
On Wed, Feb 23, 2011 at 2:56 PM, Adrian Chadd adr...@freebsd.org wrote:
Nothing's stopping someone from forking ath9k (for example) and creating
ath9k-without-regulatory-enforcement. :-)
That only will discourage companies doing the right thing from
doing it.
I'd
Luis R. Rodriguez wrote:
there was some discussion about writing to the EEPROM from
outside the driver.
We cannot take that step for a while and specifically some countries
explicitly prohibit this.
I understand, and that's fine. Someone else may be able to take the
step meanwhile, in a
Sujith wrote:
The best thing would be to stick to your distribution's kernel,
and use the latest compat-wireless package.
Unlike many binary distributions, Gentoo does not push a particular
kernel down their users' throat. It's very easy to use any kernel
whatsoever and many Gentoo users do
Sujith wrote:
The best thing would be to stick to your distribution's kernel,
and use the latest compat-wireless package.
..
Why a developer team working with wireless-testing.git consistently
recommends using some other code is very difficult to comprehend at
least for this fellow
crocket wrote:
Do those messages imply that I can't use 5Ghz frequencies in AP
mode with ath9k and AR9280?
Luis R. Rodriguez wrote:
this varies by card.
To clarify further that's the card itself, and not the chipset that
is on the card.
The chipset is capable of everything but because
Luis R. Rodriguez wrote:
The only thing that will work in the short term is to
let users change the reg domain in this memory on the card.
Until here.
Should maybe have noted that I do not think such changing should
involve the driver in any way! Also, this is of course only my
opinion of
Sujith wrote:
In that case you need to pay more attention.
You go to hell.
I'm sorry to see that we interpret the reported issue so differently. :\
(I love your hostname though! Noticed it just now. :)
//Peter
___
ath9k-devel mailing list
Sujith wrote:
Sujith wrote:
Peter Stuge wrote:
In that case you need to pay more attention.
You go to hell.
To elaborate a bit more,
Thanks for the clarification!
everyone is incredibly tired of your trollish verbiage and jumping
on every random thread spouting nonsense.
Again
Cedric Sodhi wrote:
Jouni:
So far I had GPIO disabled in the kernel. I enabled it with the
suboptions
CONFIG_GPIO_BASIC_MNIO
CONFIG_GPIO_SCM
(buest guess) but it had no effect.
I think Jouni was refering to GPIO in the AR9271 chipset, and that
maybe something within the USB adapter
Cedric Sodhi wrote:
You need to tell me which module you suggest I should set this modparm
for. Can you give me the exact kernel parameter that I should pass?
modprobe ath9k debug=0x201
(If I remember the value correctly)
//Peter
___
ath9k-devel
Jouni Malinen wrote:
I have no idea why it would do that; you would need to ask Gentoo
developers that. I concluded this by checking what my test laptop with
Gentoo was doing..
Quick grep rfkill -r /lib/rc* /etc/init.d comes up empty.
But ifplugd is used, might it be twiddling rfkill knobs?
Cedric Sodhi wrote:
Wait a second, this can't possibly caused by calling rfkill. I only
installed rfkill to examine why that happens in the first place!
Yes, but there might be a syscall. On second thought I guess that
would be an ioctl, so grep -i instead.
//Peter
Luis R. Rodriguez wrote:
AR9280 should work rock solid with both AP and STA and if it does
not its a regression that should be reported.
Luis,
An issue which has just not been discovered, researched and/or
documented yet is by definition not a regression.
I consider my problems with AR9220 as
Luis R. Rodriguez wrote:
https://lists.ath9k.org/pipermail/ath9k-devel/2011-February/005242.html
DMA failed to stop issues are non-fatal and we were not able to find
an easy way to reproduce,
This reasong is actually the single big flaw that I totally did not
expect from Atheros, and which
crocket wrote:
The DMA issues are on
https://lists.ath9k.org/pipermail/ath9k-devel/2011-March/005384.html
The kernel lockup(or panic) issue is on
https://lists.ath9k.org/pipermail/ath9k-devel/2011-February/005331.html
Both problems make me hesitant about buying AR9280(PCIe) and
Adrian Chadd wrote:
Would you be interested in trying FreeBSD-current out on the AR9280/AR9285?
I've been wanting to do this for some time actually.
How to bootstrap? Can we go directly from Linux to -current, or
should we start with a release .iso?
//Peter
crocket wrote:
I don't know why Luis said DMA failed to stop issues are non-fatal
It definitely stops the chipset and is certainly fatal.
I believe because Luis has only seen the error message in other,
unrelated, circumstances, where the issue is indeed not fatal.
This can of course not
Mohammed Shafi wrote:
not reproducible in 2.6.38-rc7-wl wireless testing under
Ubuntu, dont know where i am missing.
You are in a different environment. Obviously it is not so useful to
try to reproduce an issue in different circumstances. That will only
work for very few and very simple
Baldomero Coll wrote:
Is there a way of overriding regulatory domain
No.
and being able to configure any channel in IBSS mode with no
restriciton in the transmission power
The only option would be to reprogram the reg domain on the card to
something less restricted. So far there is no
Luis R. Rodriguez wrote:
Need to make that utility.
Blindly overwriting EEPROMs is a bad idea,
Such a utility must do the right thing of course! :) Only change the
right bits, in the right way. I haven't looked yet but I expect the
driver will show which bits matter, and how.
You have the
Baldomero Coll wrote:
I don't want to break any rule.
Of course. Neither do I nor any other regular users.
The problem Luis points to is that US and Japanese regulators do not
allow altering regulatory domain to a more permissive one.
That only makes sense assuming that the EEPROM contents is
C Anthony Risinger wrote:
Please try to remember to trim posts that you are replying to,
that people do not have to scroll down hundreds of lines to read
what you write.
... or get a decent email app that folds quotes ;-)
..or posters could trim judiciously, so that there are fewer
alexander barakin wrote:
you can also try the same with Network manager disabled
this system uses connman (http://connman.net/), but this is not
essential. imho.
Agree completely. The issue is with radio control, between kernel and
hardware, not with userspace as per your testing.
Luis R. Rodriguez wrote:
So ultimately with Atheros cards you should not have to muck with
anything,
Except fixing invalid information on cards. But this of course goes
exactly the same for all cards! Nothing special with Atheros. (Except
that maybe noone else than Atheros is using the kernel
Y QM wrote:
get a clear frame transmission function flow in ath9k? Or if there
are some documents can help
Nope, nothing of the sort.
//Peter
___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
Sujith wrote:
How does a newb set power_save off on an AP?
PowerSave support is mandatory for AP mode operation,
so disabling it is not possible.
To clarify a bit, does power_save on mean that *other* nodes can use
power saving on this network, as opposed to meaning that the *local*
node
Mohammed Shafi wrote:
Is this a serious proposal from Atheros, or just your attempt at
a quick fix?
No! its purely a personal idea (am completely responsible for the
mistake),and I will take a look at it carefully to fix this.
Sorry, I didn't mean that you made a mistake, just that the
Hasan Rashid wrote:
The only problem now is that the driver transmit at non-HT rates only.
I guess that is the best it can do with a bogus EEPROM.
//Peter
___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
Adrian Chadd wrote:
Is there an easy way to get an EEPROM/OTP contents dump in ath9k?
No. I have some PCI problem, so no progress in the EEPROM direction
from me.
//Peter
___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
1 - 100 of 199 matches
Mail list logo
