On 26 April 2013 01:45, Adrian Chadd adr...@freebsd.org wrote:
Hi,
Wait. sysctl dev.ath.0.forcebstuck=1 didn't fix it?
So the descriptors are mostly completed. I really need to hack the
reset path to continue printing everything in the queue, not just the
frames that were completed
On 26 April 2013 14:14, Lev Serebryakov l...@freebsd.org wrote:
Hello, Adrian.
You wrote 26 апреля 2013 г., 18:56:57:
AC And please cc -wireless with your debugging results :)
Ok.
It is interesting how throughput is not connected to rate after
these problems. Now I have client at
You're not doing something like leaving bgscan enabled, or not
defining a channel up front?
There's a lot of resets hre.
adrian
On 26 April 2013 14:28, Lev Serebryakov l...@freebsd.org wrote:
Hello, Adrian.
You wrote 26 апреля 2013 г., 12:51:17:
Wait. sysctl dev.ath.0.forcebstuck=1 didn't
Hi,
I've just committed something to -HEAD that logs -all- the descriptors
in the TX queue during a reset.
This requires ATH_DEBUG_RESET to be set (0x20), so use the same debug
mask as before.
Thanks!
Adrian
___
freebsd-wireless@freebsd.org mailing
Ok. Next time it happens, force a stuck beacon:
sysctl dev.ath.X.forcebstuck=1
That will cause the right kind of reset in order to log the frames in
the TX queue.
Make sure you have the right debug mask though!
Adrian
___
Try dropping it down to a HT20 channel.
adrian
On 23 April 2013 05:41, Lev Serebryakov l...@freebsd.org wrote:
Hello, Freebsd-wireless.
Now my router/AP is new hardware in new case, and it is not
overheating for sure.
AP's WiFi card is Ubiquity SR-71E MiniPCIe card. Client is Intel
On 23 April 2013 12:57, Petko Bordjukov bordju...@gmail.com wrote:
Falling back to a ht:20- channel did considerably lower the number of stuck
beacon messages on my AR9220. It still periodically hangs though (is this
why ``baseband hangs?'' is listed in the wiki?).
Well, partially.
I'm seeing
On 20 April 2013 07:31, Rushil Paul rushilp...@gmail.com wrote:
There are various tools out but we're not aware of any good ones that work
with 802.11 and are generally available.
There is a popular tool called scapy which is built on python and it
supports all the major protocols
Hiya,
Now that the missing piece of support is almost done (hostap mode
powersave/pspoll support) I'm going to move onto the next thing -
doing automated FreeBSD builds for people to run on AP equipment.
What I have that is publicly available:
* Ubiquiti Routerstation
* Ubiquiti Routerstation
On 20 April 2013 22:07, Warner Losh i...@bsdimp.com wrote:
I'm just wrapping up some automated build scripts now and I expect to
start building test images in the next week or so.
That sounds cool, but do we need another st of scripts to build images? What
does yours give that others don't
Hi,
I've just committed some changes to -HEAD. Please update to the latest
-HEAD and paste me the ath0 dmesg output.
It will include the chainmask information.
Thanks,
Adrian
___
freebsd-wireless@freebsd.org mailing list
irq256: hpet0:t0 8426 30
irq257: hpet0:t1 1823 6
irq258: hpet0:t2 1992 7
irq259: hpet0:t3 2112 7
irq264: hdac0 118 0
irq265: ahci0 4026 14
Total 20607 75
On Thursday 18 April 2013 06:56:14 Adrian Chadd wrote:
I've just tested -HEAD on a WB197 (AR9287 + bluetooth.) It works fine.
I
Is this with or without AH_DEBUG ?
Sent from my Palm Pre on ATamp;T
On Apr 18, 2013 6:43 PM, Mike lt;russian...@gmail.comgt; wrote:
Hello!
I just wanted to notice, that Adrian's ath-hal git repository still
has one error, which prevents building of ath-hal with clang.
Hm, ok.
Well, file a PR and then try updating to -HEAD. Maybe my latest fix is
good enough to fix it.
ADrian
On 16 April 2013 13:19, russian...@gmail.com wrote:
Yea, stuck beacons are often seen in dmesg
--Original Message--
From: Adrian Chadd
Sender: adrian.ch...@gmail.com
On 8 April 2013 09:17, Raphael Kubo da Costa rak...@freebsd.org wrote:
AR9485 here. I updated qcamain_open_hal_public to commit 89885db and
sys/dev/ath is at r249255.
Everything still works fine in my very common and not-demanding workflow
(ie. connecting to a WPA2 AP and using Bluetooth
Hm, ok. Please file a PR and i'll go investigate.
Thanks!
adrian
On 7 April 2013 01:28, Lev Serebryakov l...@freebsd.org wrote:
Hello, Freebsd-wireless.
It looks like ieee80211_regdomain.h should be regenerated (or
fixed?):
/data/src/sys/net80211/ieee80211_regdomain.h: SKU_ROW
Hi,
I've done a bunch of changes!
Driver:
* lots of busdma related tidying up;
* fixed the EDMA Can't run on machines with 4GB issue;
ar9300 support:
* updated to the latest internal HAL;
* added ar9300 tx power configuration support, so you can configure
lower tx power if you'd like.
On 3 April 2013 17:34, Adrian Chadd adr...@freebsd.org wrote:
.. ok, I finally can test it on an AR9580, and it's erroring out for me.
It wasn't erroring out on an earlier NIC (AR5416) but that doesn't use EDMA.
I'll go do some more debugging.
Wow, there's some screwed up stuff right
On 3 April 2013 19:02, Joshua Isom jri...@gmail.com wrote:
It seems to be working for me now at full memory. I did a search on the
BUS_DMASYNC_PREREAD, one nic for freebsd had a patch full of replacing
PREREAD with PREWRITE, so maybe a doc needs updated.
Where'd you find that?
Adrian
using 4GB is that hw.busdma.zone0.lowaddr is
0xfff, 60 bits and not 64, but when 32GB it's 0x, 32
bits. I don't know if that has anything to do with it, but it seems
strange.
On 4/2/2013 1:35 AM, Adrian Chadd wrote:
.. and there's been some more work in -HEAD, so please
Ok, can you:
* bring the interface down cleanly (ifconfig wlan0 down);
* unload the ath driver (kldunload if_ath and kldunload if_ath_pci)
* sysctl hw.busdma, and just add it to the list here?
I'd like to make sure that it's freeing all the bounce buffer pages.
Thanks,
adrian
On 2 April 2013 17:44, Joshua Isom jri...@gmail.com wrote:
I did get a couple bounced after pinging for a while via ssh, but only one
ping packet dropped, so it should be good for anything tcp.
So what, 8GB almost-but-not-quite worked?
How much RAM do I need to ensure that things will break
On 2 April 2013 17:33, Joshua Isom jri...@gmail.com wrote:
But this really will be interesting. It seems to be fine at 8GB of ram, not
just at 4GB. I'm not getting any dma issues or dropped packets so far. But
booting with 12GB will cause problems.
Chances are at 8GB of RAM it's just not
On 2 April 2013 18:13, Joshua Isom jri...@gmail.com wrote:
I went half an hour being ok, and 12GB was dropping TCP connections in five
minutes. I'm estimating a little, but it was unusable in just a little
time.
Using 10GB seems fine, but get's a lot bounced. The connections stable and
So, can you test end-to-end pings? With full memory booted up?
What I'd like to try and do is narrow down whether it's a TX or RX (or both.)
Do you have control over something on the other end? Can you tcpdump
the wifi interface and see if it's pings, pongs, or both being
disabled?
Also, can
On 1 April 2013 08:44, Raphael Kubo da Costa rak...@freebsd.org wrote:
On a side note: this card is also supposed to provide Bluetooth support,
right? Is any of your work going to help with that as well?
I forget what the deal is there. I think it'll work out of the box on
AR9485, but the
64 bit kernel? 4 gig RAM?
Adrian
On 1 April 2013 08:07, Raphael Kubo da Costa rak...@freebsd.org wrote:
Adrian Chadd adr...@freebsd.org writes:
I've just updated the AR9300 HAL to the March 13 snapshot from QCA.
This includes calibration and TX power calibration changes that may
improve
On 1 April 2013 08:44, Raphael Kubo da Costa rak...@freebsd.org wrote:
Adrian Chadd adr...@freebsd.org writes:
Please reboot with 4GB of RAM configured.
See if that fixes it.
Indeed, booting with hw.physmem=4G makes the connection much more
reliable -- I do see some of those warnings
On 31 March 2013 15:24, Adrian Chadd adrian.ch...@gmail.com wrote:
The problem isn't contigmalloc, it's making sure that it gets bounced via
the local 32 bits of address space right.
I'll talk with other developers and see what the deal is with 64 bit address
space for 32 bit nics.
Please do
update again again; I just did some TX related changes.
adrian
On 1 April 2013 14:04, Joshua Isom jri...@gmail.com wrote:
I just tested it, the network problem's the same.
On 4/1/2013 3:22 PM, Adrian Chadd wrote:
On 31 March 2013 15:24, Adrian Chadd adrian.ch...@gmail.com wrote
Hi,
9.x doesn't implement 11n aggregation transmission. It only supports
11n MCS rate transmission (with no aggregation) and 11n RX with MCS
and aggregation.
If you update to -HEAD you should see the performance increase.
Adrian
On 1 April 2013 15:10, Gleb Romanov groma...@hellok.org wrote:
does downgrading the motherboard/ram fix it?
You were already running 64 bit, right? What if you just boot with 2gb of ram?
adrian
On 30 March 2013 18:04, Joshua Isom jri...@gmail.com wrote:
I've been longing to upgrade my motherboard and ram, and with a tax refund
it came time. The
of the router. Even at 8Gb,
it's not guaranteed on boot, but rebooting does seem to fix it. At
16Gb, I tried two different sticks just to see if maybe it was one bad
chip but it didn't change it. That means it's probably an address
conflict, or cache size issue, right?
On 3/31/2013 1:25 AM, Adrian
, Joshua Isom lt;jri...@gmail.comgt; wrote:
From if_ath.c:2995: For some situations (eg EDMA TX completion),
there isn't a requirement for the ath_buf entries to be allocated.
The EDMA code uses malloc, but would contigmalloc work instead?
On 3/31/2013 1:38 PM, Adrian Chadd wrote:
gt
Look in ath/makefile .. At the bottom. There's clang warning overrides there.
Uncomment them!
Adrian
Sent from my Palm Pre on ATamp;T
On Mar 31, 2013 11:54 AM, Raphael Kubo da Costa lt;rak...@freebsd.orggt;
wrote:
Adrian Chadd lt;adr...@freebsd.orggt; writes:
gt; I've just updated
.. anything with an Atheros PCI/PCIe chipset will work.
The only chipset I don't have support for atm is:
* AR5523, but i doubt you'll ever see this unless you still use cardbus;
* QCA9880 and derivates (11ac) - but that won't work at the moment and
likely won't do raw injection more for
Hi,
I've just updated the AR9300 HAL to the March 13 snapshot from QCA.
This includes calibration and TX power calibration changes that may
improve stability.
As always, it's possible I broke something!
I'd appreciate it if people would test this in STA and AP mode.
Thanks!
Adrian
On 28 March 2013 13:11, Joshua Isom jri...@gmail.com wrote:
I'd like to see if any other TX queue has a frame hanging around in it
that hasn't been completed.
I had syslogd pipe the output to a perl script to set the sysctl, not ideal
but effective I hope. I've got two today.
Mar 28
On 28 March 2013 13:31, Joshua Isom jri...@gmail.com wrote:
Right. None of these have any frames stuck in the FIFO. Good. Now, I
have to go chase down why we're seeing this.
I just noticed something odd, it counts from 0, 1, 2, 3, 8. It skips 4-7
and 9. Why aren't the rest set up?
On 27 March 2013 16:35, Joshua Isom jri...@gmail.com wrote:
So far 22 hours uptime. Other than what's probably debug messages,
everything seems to be working fine.
Please post the debug messages. Anything the driver spits out needs to
be fixed. :-)
Adrian
Ok, update to -HEAD again.
Adrian
___
freebsd-wireless@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-wireless
To unsubscribe, send any mail to freebsd-wireless-unsubscr...@freebsd.org
255.255.0.0
defaultrouter=10.71.0.1
wlans_ath0=wlan0
ifconfig_wlan0=WPA DHCP
Regards,
-Mark Austin
All else is in doubt, so this is the truth that I cling to.
My Website: http://www.silverdire.com
On Mon, Mar 25, 2013 at 12:36 PM, Adrian Chadd adr...@freebsd.org wrote:
Sweet. Looks good
Hi,
Please update the git repository and try again.
I just fixed the TKIP key programming in the AR9300 HAL.
Adrian
___
freebsd-wireless@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-wireless
To unsubscribe, send any
Ok, do you get crashdumps? Can you attach the core.X.txt files from /var/crash ?
Thanks,
Adrian
On 23 March 2013 16:40, Joshua Isom jri...@gmail.com wrote:
I'm getting periodic panics with the latest ath driver. I've had six panics
today where the debugger was not entered and it just
Hi,
I'm cc'ing -wireless now, as this is actually good to have public.
Ok, can you post (or re-post) the ath device line from 'pciconf -lv' ? I'd
like to see which device it is.
And, inline:
On 22 March 2013 08:44, Mark Austin ganth...@gmail.com wrote:
Hey Adrian,
Okay. I was able to
On 22 March 2013 12:11, Mark Austin ganth...@gmail.com wrote:
Okay. I made the 2 requested changes to the kernel source code and changed
my kenv var before reloading the module.
The kernel messages log shows (my emphasis in bold):
**
*Mar 22 19:02:49 asher kernel: ath_hal_init_channels:
Hi,
I have no plans to backport this to stable, sorry. :(
Adrian
On 20 March 2013 19:43, Joshua Isom jri...@gmail.com wrote:
On 3/19/2013 10:31 PM, Adrian Chadd wrote:
On 19 March 2013 12:39, Adrian Chadd adr...@freebsd.org wrote:
Hi all,
I've just committed some new RX handling code
Hi,
I've had a few people ask why AR9380 hostap mode isn't working yet and
when I expect to have that working.
Firstly - it's because I have a day job, and that day job isn't FreeBSD. Honest.
But all jokes aside, the last main thing to deal with at the moment is
tidying up the TX path -
On 19 March 2013 12:39, Adrian Chadd adr...@freebsd.org wrote:
Hi all,
I've just committed some new RX handling code. Since the RX FIFO on
the AR9380 and later chips is very shallow (128 entries), you have to
refill the FIFO much quicker than you can handle frames.
.. and an AR9390 STA
I've just fixed a couple things with the AR9300 HAL:
* I've implemented a get slot time method, so one stub function call
message should disappear;
* I've fixed a quirk with slot/ack/rtscts timeout calculations in HT40
- the AR9300 HAL was compensating for the 40Mhz width of the channel,
but
Fixed!
Adrian
On 17 March 2013 15:27, Joshua Isom jri...@gmail.com wrote:
There's no issues for the fork, only the master.
On 3/17/2013 4:40 PM, Adrian Chadd wrote:
Just go to my github - github.com/erikarn/ - then click on
repositories, then the HAL fork, then just file an issue
It's likely some hack done by the wifi vendors to look good'.
There's a split between basic (Required) and extended rates. You don't
need to talk extended rates to associate.
So your tool(s) are demonstrably broken. You should be able to get
right up to 54mbit. :)
Adrian
On 14 March 2013
://www.tp-link.com/en/products/details/?model=TL-WDN4800
On 3/14/2013 9:02 PM, Adrian Chadd wrote:
0x3112? What nic is that?
I'll go and take a quick look at the reference driver. Can you google
your laptop model and see what you can find?
Adrian
Sent from my Palm Pre on ATT
.. and here I am, hoping you're user #1 (with me being user #0) of this HAL. :)
Adrian
On 14 March 2013 19:20, Adrian Chadd adrian.ch...@gmail.com wrote:
Oh!
http://wikidevi.com/wiki/TP-LINK_TL-WDN4800
Silly me, I was reading the wrong number on my phone.
Yes, 0x0030 is Osprey (AR9380
On 9 March 2013 10:54, Adrian Chadd adr...@freebsd.org wrote:
What's tested:
* legacy, 1x1 and 2x2 HT20/HT40, STA mode
* AR9380 (1x1, 2x2 - 2/5ghz)
* AR9485 (1x1, 2ghz only)
I can now add two more NICs to this list:
* AR9390 (HB116)
* AR9462 (WB225)
Thanks,
Adrian
correct. Unfortunately, I get a kernel panic on boot with scsi_cd,
so I'll have to wait until that's dealt with before trying the ath driver.
On 3/13/2013 7:30 PM, Adrian Chadd wrote:
Hi,
I've fixed some warnings - please update the git repo youre using.
I've also added some clang workarounds
longer.
adrian
On 13 March 2013 19:16, Adrian Chadd adr...@freebsd.org wrote:
Can you please post the patch and the specific compile issue?
adrian
On 13 March 2013 18:41, Joshua Isom jri...@gmail.com wrote:
I added a cast to u_int64_t first on line 63 of ar9300_gpio.c to get
Try this:
adrian@cynthia:~/git/github/erikarn$
g...@github.com:erikarn/qcamain_open_hal_public.git
-bash: g...@github.com:erikarn/qcamain_open_hal_public.git: No such
file or directory
adrian@cynthia:~/git/github/erikarn$ git clone
https://github.com/erikarn/qcamain_open_hal_public.git
Cloning
check to see if someone
tried your code.
On 3/11/2013 6:41 PM, Adrian Chadd wrote:
Ooh.. add the debug options to your kernel, sorry!
options ATH_DEBUG
options AH_DEBUG
options ATH_DIAGAPI
I'm sorry, I've never tested it outside of a debug build before.
Adrian
the
FreeBSD community. :)
Adrian
On 11 March 2013 17:41, Adrian Chadd adr...@freebsd.org wrote:
Is this with clang?
adrian
On 11 March 2013 17:39, Joshua Isom jri...@gmail.com wrote:
Still no luck, and some errors look like I'm missing more.
/root/ATH/head/sys/modules/ath/../../dev/ath
On 11 March 2013 17:43, Adrian Chadd adr...@freebsd.org wrote:
.. and yeah, that code is wrong. GCC doesn't complain; just change it to:
if ((ahp-ah_enterprise_mode AR_ENT_OTP_MIN_PKT_SIZE_DISABLE)
to:
if ((ahp-ah_enterprise_mode AR_ENT_OTP_MIN_PKT_SIZE_DISABLE)
Thanks
Ok, I see that clang is doing some odd expansion there. I've poked the
clang nerds about it, I'll see what they say.
Anyway - I've shifted its location - now please create a new directory
- sys/contrib/dev/ath/ath_hal/ar9300/, and put your symlinks in there.
Then uncomment in ath/Makefile like
You didn't check out the local/freebsd branch.
On 10 March 2013 09:29, Joshua Isom jri...@gmail.com wrote:
I patched according to the instructions, but it fails with these four
missing files:
ash_amem.h
ar9300_freebsd.c
ar9300_stub_funcs.c
ar9300_stub.c
I tried commenting them out, the
Yes, you need to do this:
Git clone ...
Cd openhal...
Git checkout local/freebsd
It'll create the branch based off of my branch in git.
Then do the ln -s ing.. Then build.
Adrian
Sent from my Palm Pre on ATamp;T
On Mar 10, 2013 5:07 PM, Rui Paulo lt;rpa...@felyko.comgt; wrote:
On
I finally got the legal all-clear to push this open source version of
the QCA mainline HAL into open source.
So, without further ado:
https://github.com/qca/
The open HAL is there.
I then forked it:
https://github.com/erikarn/qcamain_open_hal_public
.. and then I created a branch, called
On 4 March 2013 09:50, Lev Serebryakov l...@freebsd.org wrote:
Hello, Freebsd-wireless.
Situation (theoretical one, I didn't try it, but I'm thinking about
WiFi coverage of my parent's cottage and lot): WiFi card with 2
antennas, in 802.11g (or single-channel 802.11n) mode. Both antennas
Yup, that's what you expect for OFDM 54MB rates.
Why do you ask?
Adrian
On 4 March 2013 12:49, Dmitry Kolosov o...@z-up.ru wrote:
Hello dear FreeBSD users!
What is maximum wireless throughput you have reached (seen) on -STABLE (mean
11g only mode)? I have 54Mbps as for `ifconfig` and
Hi,
I have finished this round of work, intended for -HEAD.
Besides the stuff in the ath and iwn driver, here's what I'd like to commit:
http://people.freebsd.org/~adrian/ath/20130303-net80211_tx-1.diff
What it implements:
* the code that transmits a VAP frame is now in ieee80211_start_pkt().
Hi,
So this stuff breaks Monthadar's meshing code.
The mesh forwarding stuff takes mesh frames in mesh_input() that are
destined for another node and potentially stuffs them back into the
parent transmit queue, bypassing the rest of the stack.
This has a bunch of potential interesting
Here we go:
http://people.freebsd.org/~adrian/ath/20130225-net80211-txlock.diff
See what you think.
Adrian
___
freebsd-wireless@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-wireless
To unsubscribe, send any mail to
On 23 February 2013 22:30, PseudoCylon moonlightak...@yahoo.ca wrote:
So, this is all pretty terrible. The only sane solution for now is to
make my VAP TX lock an IC TX lock,and grab said IC TX lock for all
VAPs. That way the driver can grab the IC TX lock when it's doing
deferred sends and
Hi,
As part of the AR9380 support that's hopefully appearing soon, I
finally found the motivation to tidy up how the chainmask handling is
done.
The summary:
* introduce a new HAL method that changes the currently configured
TX/RX chainmask;
* leave the TX chainmask as 1 for non-HT and the
Hm, we need to use MIN(rxmax) and MAX(density) regardless, right?
If an AP is transmitting to a STA that has a lower rxmax or higher
density, it should obey that.
The same rules apply for mesh, ibss, tdma operational modes.
So yes, what we should do is:
* initialise rxmax/density with the VAP
Ah, damn. Sorry. I was thinking about the node versus vap
configuration and got confused.
IBSS is the same as the APmode of operation - you advertise what
you're capable of and sending stations just calculate the
MIN(ampdusize) and MAX(ampdudensity) when sending to you. Exactly the
same needs to
Hm, it's possible in my sleep deprived state that I'm on the right but
wrong track here.
The OP problem is that we're not advertising the right capabilities
when we associate, right?
Why aren't we just advertising the VAP ampdumax and ampdudensity no
matter what the operating mode? Why are we
Hi,
Here's take four of the TX serialisation.
http://people.freebsd.org/~adrian/ath/20130223-net80211-tx-lock-4.diff
This patch increases the lock reach so it locks the encap path for
both data and management frames, so the path between sequence number
allocation and driver queuing is held.
On 22 February 2013 15:25, Adrian Chadd adr...@freebsd.org wrote:
Hi,
Here's take four of the TX serialisation.
http://people.freebsd.org/~adrian/ath/20130223-net80211-tx-lock-4.diff
This patch increases the lock reach so it locks the encap path for
both data and management frames, so
.. and as a reference, Linux mac80211 seems to just do TX through a
single-threaded workqueue. Ie, all of the mac80211 TX is done deferred
and serialised that way.
Grrr.. I'm very tempted to just do this and be done with it for now.
Adrian
___
On 15 February 2013 21:18, Adrian Chadd adr...@freebsd.org wrote:
Oh lordie. :-)
Please file a PR so we don't forget to fix this? :)
Ok, you filed a PR with a patch.
Who can we rope in to review whether this is being done right ?
Adrian
35197341
Am 11.02.13 19:59, schrieb Adrian Chadd:
Hi,
Would you please look at the output of vmstat -i, see if the ath0
device is receiving interrupts?
Thanks,
Adrian
On 10 February 2013 23:30, Kamil Szczesny k.s.m...@gmx.net wrote:
Hi,
after a downgrade to 9.0-RELEASE
On 9 February 2013 06:47, Eitan Adler li...@eitanadler.com wrote:
I recently encountered a kernel panic upon removing a urtw0 device.
This removal occurred during machine shutdown.
The crashing kernel and textdump is available upon request.
Unread portion of the kernel message buffer:
Yes to both - i think some USB stack / memory buffer changes are
responsible for your issue. :-)
Adrian
On 9 February 2013 15:51, Eitan Adler li...@eitanadler.com wrote:
On 9 February 2013 14:01, Adrian Chadd adr...@freebsd.org wrote:
On 9 February 2013 06:47, Eitan Adler li
Hi,
The problem is that no-one's really championing / maintaining the
FreeBSD in-tree support for the rt chips.
ray@ and bschmidt@ did a bunch of work to port over some more driver
support, but they're both busy on other things now.
A few devices in FreeBSD sorely need maintainers to actively
Hi,
On 2 February 2013 07:59, Lay, Nathan ns...@my.fsu.edu wrote:
Hi Adrian,
That's a good question. I'm going to try various things this week to pinpoint
the problem. I'll let you know what I find.
Please do. I have an earlier model Roku that doesn't show any of the
same behaviour.
Hm, see if it's a beacon miss thing:
sysctl dev.ath.0.debug=0x80
adrian
On 27 January 2013 04:31, Vincent Hoffman vi...@unsane.co.uk wrote:
Hi all,
I'm running a recent -current (r245741) and seem to be getting
interface flaps. Since this machine is mainly used for home mail and a
On 27 January 2013 09:44, Lev Serebryakov l...@freebsd.org wrote:
AC For 2GHz in noisy environments, use it in HT20 mode.
I'm using HT20, and it seems, card in my box overheats with 802.11n
clients (it hangs very hard under load with 802.11n client), so I
don't use 802.11n on notebook (I
Hi,
So the AR5416 and later NICs almost all implement MIMO. The only
exception is the AR9285 which is a 1x1 with the diversity
implementation matching previous (pre-11n) NICs.
Anyway, for MIMO, all the antennas are on by default. So yes, you need
to connect all of the antennas.
If you want to
Hi,
Please list the commands that you've used?
And is anything logged in dmesg?
A lot of mesh fixes are in -HEAD, have you tried that?
Adrian
On 23 January 2013 05:11, paranormal paranor...@isgroup.com.ua wrote:
Today I was trying what mesh is.
I have ap (stable) atheros 5008 and my
-HEAD or -9 ?
Adrian
On 14 January 2013 15:59, Jakub Lach jakub_l...@mailplus.pl wrote:
Have dependencies changed?
I've only have ath and ath_pci, they always gave me everything I needed
for my card.
/usr/src/sys/modules/ath/../../dev/ath/ath_hal/ar9002/ar9285_attach.c:144:35:
error:
Duh, 9-STABLE.
Guess it wasn't build tested before commit? Odd...
Adrian
___
freebsd-wireless@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-wireless
To unsubscribe, send any mail to
The problem here is I can't easily test this. We detach and re-attach
cardbus devices during suspend/resume, so although I have AR9220
mini-PCI NICs, they don't stay connected the normal way. The slot gets
fully powered down and reset upon power up.
Adrian
Right. That should be a good indication.
It's a shame you can't just get a multimeter and measure the relevant pins. :)
Adrian
___
freebsd-wireless@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-wireless
To unsubscribe,
.. and it may not be the slot power. It could also be the PCI bridge
(re) programming. It needs to have the right BAR and such programmed
into it, or it won't route things correctly to child slots.
I had this problem with cardbus a few months ago. After a resume, not
all of the relevant PCI
It was likely a specific client.
Traffic levels can affect things - the macosx wifi stuff will do
background scans if traffic is under a certain threshold and stop it
otherwise.
Adrian
___
freebsd-wireless@freebsd.org mailing list
Hi,
The reason I haven't (yet) written any particular directions up on
this is because I'm still trying to come up with relevant workarounds
for spectral scan on the AR9280, when it's active with traffic.
Since some of you will likely enable it with traffic and then discover
that things hang
Well. Compare the other bridges too, out of interest.
Adrian
Sent from my Palm Pre on ATamp;T
On Jan 13, 2013 4:40 PM, Slawa Olhovchenkov lt;s...@zxy.spb.rugt; wrote:
On Sun, Jan 13, 2013 at 04:32:16PM -0500, Adrian Chadd wrote:
gt; Ok. So don't use that :)
gt;
gt; I'll dig up
-read
those config registers.
Thanks,
Adrian
On 12 January 2013 07:44, Slawa Olhovchenkov s...@zxy.spb.ru wrote:
On Sat, Jan 12, 2013 at 07:27:02AM -0800, Adrian Chadd wrote:
Hi,
There's no firmware for the AR9220 .. it's all in the driver/HAL.
If XP restore isn't working; maybe there's
.. right, try flipping the rf kill switch off/on after suspend, dump
the config registers.
Adrian
On 12 January 2013 08:28, Slawa Olhovchenkov s...@zxy.spb.ru wrote:
On Sat, Jan 12, 2013 at 07:52:19AM -0800, Adrian Chadd wrote:
Ah, is it perhaps rfkill related?
I've seen issues
On 12 January 2013 08:37, Slawa Olhovchenkov s...@zxy.spb.ru wrote:
On Sat, Jan 12, 2013 at 08:25:22AM -0800, Adrian Chadd wrote:
.. right, try flipping the rf kill switch off/on after suspend, dump
the config registers.
don't react -- 255 times 'ff'
Okay. Well, I'll see if there's anything
On 12 January 2013 09:13, Slawa Olhovchenkov s...@zxy.spb.ru wrote:
On Sat, Jan 12, 2013 at 09:05:37AM -0800, Adrian Chadd wrote:
We can't patch pci space if they're all 0x, that means nothing is
there.
That's the point; the card hasn't come back on from suspend. So we
need to do
901 - 1000 of 1065 matches
Mail list logo
