Re: 9-STABLE kernel ath build problem, probably related to r245429

-HEAD or -9 ? Adrian On 14 January 2013 15:59, Jakub Lach 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: > use of und

Re: 9-STABLE kernel ath build problem, probably related to r245429

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 "freebsd-wireless-unsubscr...@freebsd.or

Re: mesh between AR5008 and AR5212

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 wrote: > Today I was trying what mesh is. > > I have ap (stable) atheros 5008 and my laptop (stable) atheros 5

Re: mesh between AR5008 and AR5212

. One host (ap) sent packets, another (laptop) was dumb even with arp. Actually I had my mother notebook with windows, and cheapest wifi repeater tenda a3, both devices couldn't see mesh network. Is it normal? Unfortunately I will not be able to test HEAD's code. On Wed, 20

Re: stuck beacon hung wifi adapter AR5008

Hi! Try putting it into ht20 mode. Do you have all three antennas connected? Adrian Sent from my Palm Pre on AT&T On Jan 26, 2013 10:01 AM, paranormal wrote: Hi list. My system is -STABLE. Since 9.1 MFC, may be a few months earlier, something was happened,

Re: stuck beacon hung wifi adapter AR5008

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 av

Re: wireless link flaps (ath ar9280)

Hm, see if it's a beacon miss thing: sysctl dev.ath.0.debug=0x80 adrian On 27 January 2013 04:31, Vincent Hoffman 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 > little light

Re: stuck beacon hung wifi adapter AR5008

Are you using it in HT40 or HT20 mode? For 2GHz in noisy environments, use it in HT20 mode. adrian On 27 January 2013 02:06, Lev Serebryakov wrote: > Hello, paranormal. > You wrote 26 января 2013 г., 22:01:03: > > p> 70 Jan 26 17:41:48 mbsd kernel: ath0: stuck beacon; resetting (bmiss > p> co

Re: stuck beacon hung wifi adapter AR5008

On 27 January 2013 09:44, Lev Serebryakov 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 want to chang

Re: wireless link flaps (ath ar9280)

January 2013 13:56, Vincent Hoffman wrote: > On 27/01/2013 17:11, Adrian Chadd wrote: >> Hm, see if it's a beacon miss thing: >> >> >> sysctl dev.ath.0.debug=0x80 > now with added debugging. > > Jan 27 21:49:09 ostracod kernel: ath0: ath_bmiss

Re: stuck beacon hung wifi adapter AR5008

On 30 January 2013 08:29, paranormal wrote: > Thank you Adrian, your advice was perfect. > > I have a gym friend whose job is blacksmith (the friend has right hands, > and I don't), I gave him my 3 antennas, and hi made them fitted with my > wireless card. ooo! > My card is able to reset it now.

howto: tinkering with spectral scan

Hi, Here's the 30 second rundown for spectral scan: * update to -HEAD; * "make" and "make install" in src/tools/tools/ath/; (so you get athspectral) * checkout svn://svn.freebsd.org/base/user/adrian/ath_radar_stuff; * install SDL and the SDL TTF font ports; * "make" in ath_radar_stuff/lib; * "mak

Re: Block ACK in Ralink RT2860

Hi, So the 30 second version: * the maximum aggregation size in 802.11n is 65536 bytes, including the between-frame delimiters; * mpdu density defines how big those delimiters are - they're calculated either in bytes or as a function of the currently selected rate and duration, which ends up bein

Re: ath "stops working" in hostap mode

n if_ath and FreeBSD. > > Nate > > > From: Lay, Nathan > Sent: Saturday, February 02, 2013 1:26 AM > To: Adrian Chadd > Subject: RE: ath "stops working" in hostap mode > > Hi Adrian, > Ugh, I neglected to provide this

Re: ath "stops working" in hostap mode

Hi, On 2 February 2013 07:59, Lay, Nathan 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. adrian

Re: FreeBSD IEEE802.11 Mesh status update.

ome. > > Thnx to Alexander, Bernhard, Rui and everyone on freebsd-git IRC channel! > And a special thnx to Adrian Chadd for being my mentor and friend. > > Thnx everyone and keep up the great work on net80211! > > br, > > -- > Monthadar Al Jaberi > __

Re: D-link DWA-525

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 de

Re: panic on removing urtw0

On 9 February 2013 06:47, Eitan Adler 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: > urtw0: failed to st

Re: panic on removing urtw0

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 wrote: > On 9 February 2013 14:01, Adrian Chadd wrote: >> On 9 February 2013 06:47, Eitan Adler wrote: >>> I recently encounte

Re: ath0: device timeout on 9.1-RELEASE

Hi, Would you please try 9.0-RELEASE too? Adrian On 10 February 2013 00:38, Kamil Szczesny wrote: > Hello, > > I'm facing a problem with ath0 on FreeBSD 9.1-RELEASE, that was not existent > on 8.x-RELEASE. > > The issue seems to be the similar to this one: > http://lists.freebsd.org/pipermai

[ath] headsup - I'm likely going to revert a bunch of work in ath(4) soon

Hi all, I'm likely going to revert a bunch of my work in ath(4) soon. I've been trying to chase down some performance issues that have crept in with my if_transmit() and software queue changes and .. well, to be honest, I'm just plain unhappy with it. It's utterly terrible - performance seems to h

Re: ath0: device timeout on 9.1-RELEASE

thentication timeout entries. > > regards, > Kamil > > Am 10.02.13 20:10, schrieb Adrian Chadd: > >> Hi, >> >> Would you please try 9.0-RELEASE too? >> >> >> >> Adrian >> >> >> On 10 February 2013 00:38, Kamil Szczesny

Re: ath0: device timeout on 9.1-RELEASE

cpu3:timer 3053 29 > Total 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? >> >>

Re: FreeBSD wireless event

On 12 February 2013 14:45, Monthadar Al Jaberi wrote: > Hi, > > Is there a FreeBSD / BSD conference that all the wireless and network > gurus of the BSD world gather? Is there a special event or is it more > like adhoc on the different event scattered around? There's no specific event. Try to com

[RFC] serialising net80211 TX

Hi, I'd like to work on the net80211 TX serialisation now. I'll worry about driver serialisation and if_transmit methods later. The 30 second version - it happens in parallel, which means preemption and multi-core devices can and will hit lots of subtle and hard-to-debug races in the TX path. We

Re: [RFC] serialising net80211 TX

On 14 February 2013 11:50, Monthadar Al Jaberi wrote: > Seems like the best architectural wise, first-in first out. I am just > thinking of one can extend this too have like more than one queue, > more like the QoS concept, and each packet have a time-stamp assigned > to it.Would that help? Well

Re: ath0: device timeout on 9.1-RELEASE

bad FCS > 105 average rssi (beacons only) > 84 average rssi (all rx'd frames) > Antenna profile: > [1] tx0 rx32484 > > Is it somewhat helpful? > > regards, > Kamil > > Am 11.02.2013 20:43, schrieb Adrian Chadd: > >> Ok.

Re: ath0: device timeout on 9.1-RELEASE

On 15 February 2013 12:09, Kamil Szczesny wrote: > ehm, well.. ath0 seems to be, wlan0 however not: Well, wlan0 is what matters. I'm sorry, I can't be more help at the moment. I'm really busy making other things work. I'd use athstats -z (as root) and then watch your device associate. See if t

Re: [RFC] serialising net80211 TX

The (many) problems include the two TX paths - one is via _start / _transmit, and one is the raw xmit path. So in the short term it'll be easier (!) to just wrap all TX entry points with a VAP TX lock. Once that's done and we've debugged it, we can look at breaking it into a queue with a taskqueue

Re: negotiating HT params at assoc in sta mode

Hm, that sounds right, what's the code doing wrong? Adrian On 15 February 2013 17:09, PseudoCylon wrote: > http://fxr.watson.org/fxr/source/net80211/ieee80211_ht.c?#L2656 > Shouldn't a sta include iv_ampdu_rxmax and iv_ampdu_density instead > when associating? > > 1) A driver initiates iv_amp

Re: negotiating HT params at assoc in sta mode

On 15 February 2013 18:21, PseudoCylon wrote: > On Fri, Feb 15, 2013 at 6:20 PM, Adrian Chadd wrote: >> Hm, that sounds right, what's the code doing wrong? > > Currently, it seems the sta sends back ht params the ap included in a > PROBE_RESP packet. So, the ap could se

Re: negotiating HT params at assoc in sta mode

Oh lordie. :-) Please file a PR so we don't forget to fix this? :) 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.o

Re: Support for Mini PCie card WLE300NX( (AR9380)

Oops, I didn't reply in public! On 15 February 2013 09:03, Adrian Chadd wrote: > Yup! I'm working on open sourcing the HAL side of things soon. I'm going through final code approval now. Then, of course, there's all this extra work required to get it somewhat valida

Re: [RFC] serialising net80211 TX

Yeah - gluing TX into a single send queue is going to work, but there's definite queuing / QoS issues. You really want the management frames to be able to go out even if there's a _large_ amount of data frames going out. That's a side-issue though. I have a test patch that just wraps the output, m

Re: [RFC] serialising net80211 TX

Hi, Here's the patch: * break out the per-packet send code into ieee80211_start_pkt() * introduce a per-vap TX lock * wrap the normal TX path ieee80211_encap(), parent->if_transmit and ic->ic_raw_xmit with the TX lock TODO: * the rest of the encap calls need to be wrapped in the TX lock - wds,

Re: [RFC] serialising net80211 TX

Here's version two of the patch: it includes the rest of the TX paths locked as well as some extra assertions about the state of the TX lock requirements. I've only lightly tested this in STA mode. I haven't yet really tested this in hostap mode. I gather it's going to panic all the things. Thus,

Re: Problems with an older Acer Aspire One

Well, what's it do when it loses wireless connection? is anything logged? adrian On 16 February 2013 18:01, Kurt Buff wrote: > I have an older model of the model mentioned in the subject line, and > it loses its wireless connection every few days, requiring a reboot to > bring it back. This h

Re: Problems with an older Acer Aspire One

Hi, So "hal status 3" is HAL_EIO - which means the hardware didn't respond as expected. So maybe the hardware is getting all angry during reset. Compile up athpeek and athregs from src/tools/tools/ath/, compile your kernel with: ATH_DEBUG AH_DEBUG ATH_DIAGAPI and then when it happens again, do

Re: [RFC] serialising net80211 TX

On 18 February 2013 02:05, Monthadar Al Jaberi wrote: > On Sun, Feb 17, 2013 at 1:46 AM, Adrian Chadd wrote: >> Here's version two of the patch: it includes the rest of the TX paths >> locked as well as some extra assertions about the state of the TX lock >> requ

Re: WiFi TDMA AR7161, results and moving forward

On 18 February 2013 03:31, Mukunda Haveri wrote: > > Thanks to Adrian's WiFi scripts, we were able to get the TDMA working on the > Compex-AR7161 board. The results were surprising; we are able to do, close > to 100 mbps one way iperf tests and 40 mbps bidirectional Iperf in non-TDMA > mode. We we

Re: [RFC] serialising net80211 TX

oh.. right. We talked about this on irc a bit. Yes, mesh_transmit_to_gate() looks like a copy of what I put in ieee80211_start_pkt(). We'll refactor this common code out later. :-) Same as what we should do with the rest of the duplicate code in the input path for various net80211 modules.. adr

Re: Ralink rt2860 Broadcast rates

On 19 February 2013 05:52, Ramanujan Seshadri wrote: > Hi All, >I had a quick quesiton regarding the broadcast rates set by Ralink > rt2860 driver. It seems like the broadcast rates are always set to MCS 0. > Suppose i want to increase the broadcast rates to higher MCS's which > function shoul

Re: [RFC] serialising net80211 TX

Here's my current patch. I've tested it lightly in AP mode. Adrian 20130218-net80211-tx-lock-3.diff Description: Binary data ___ freebsd-wireless@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-wireless To unsubscribe, send

Re: ath0: device timeout on 9.1-RELEASE

On 19 February 2013 08:32, Adrian Chadd wrote: > 0x2003 will make things appear. Just do an active scan (ifconfig wlanX > scan) to ensure something happens. Hi, (Cc'ing the list so people can see the progress of debugging this.) It looks like this happens: * a channel change occurs

Re: [RFC] serialising net80211 TX

On 19 February 2013 07:50, Monthadar Al Jaberi wrote: > On Tue, Feb 19, 2013 at 4:10 PM, Adrian Chadd wrote: >> Here's my current patch. I've tested it lightly in AP mode. > > Its identical to 20130216-net80211-tx-lock-2.diff? > Good. That means I haven't accide

Re: [RFC] serialising net80211 TX

On 19 February 2013 09:44, Monthadar Al Jaberi wrote: > I have tested between two meshSTAand run iperf UDP until I get close > to getting lost packets. > > Current FreeBSD (r246983): 17 Mbits/ > Current FreeBSD (r246983) + with your patch: 15 Mbit/s > > Good news no panic! But looks like a bit sl

[rft] atheros users, please update and test

Hi all, I've been working on the TX underrun issues that I've only just noticed! * I've just made the TX underrun and TX FIFO adjustment code in the driver match what the reference driver does. * That is, the thresholds that are being used for when to start refilling the TX FIFO now match what

Re: negotiating HT params at assoc in sta mode

On 15 February 2013 21:18, Adrian Chadd 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

Re: negotiating HT params at assoc in sta mode

On 20 February 2013 20:38, PseudoCylon wrote: >> Who can we rope in to review whether this is being done "right" ? > > Since it is ht param issue, anyone with 11n capable hardware with > working driver, or anyone with an AP which can tell Tx'd ampdu packets > are smaller than what the station has

Re: [rft] atheros users, please update and test

Yup, please test any atheros chip :) adrian On 21 February 2013 00:39, Monthadar Al Jaberi wrote: > On Wed, Feb 20, 2013 at 10:40 PM, Adrian Chadd wrote: >> Hi all, >> >> I've been working on the TX underrun issues that I've only just noticed! >> >&

Re: negotiating HT params at assoc in sta mode

Well, the ampdu density is in microseconds, and you can tune the STA side. THe hostap side should be obeying what mpdudensity you set the STA side to before it associates. It should (!) then be limiting the MPDU density per-STA. Thanks, Adrian ___ fr

Re: svn commit: r247145 - head/sys/dev/ath/ath_hal/ar5416

Hi, Here's a fun little workaround for the AR5416, AR9130 and AR9160. If you use those chips, please update to -HEAD and let me know how it goes. Thanks! Adrian On 21 February 2013 23:07, Adrian Chadd wrote: > Author: adrian > Date: Fri Feb 22 07:07:11 2013 > New Revision

[rft] ath - tx/rx chainmask tidyup in preparation for AR9380 support

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 hardw

Re: kern/176201: [net80211] [patch] 11n station includes unrelated ht params into ASSOC_REQ packet

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 c

Re: kern/176201: [net80211] [patch] 11n station includes unrelated ht params into ASSOC_REQ packet

Hi, Why isn't it a per-node thing for the AP case? Ie, what should the AP do if the ampdu density it supports is 0 but the STA AMPDU density on the RX side is 8? Adrian ___ freebsd-wireless@freebsd.org mailing list http://lists.freebsd.org/mailman/li

Re: kern/176201: [net80211] [patch] 11n station includes unrelated ht params into ASSOC_REQ packet

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 b

Re: kern/176201: [net80211] [patch] 11n station includes unrelated ht params into ASSOC_REQ packet

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 capp

Re: kern/176201: [net80211] [patch] 11n station includes unrelated ht params into ASSOC_REQ packet

On 22 February 2013 13:26, PseudoCylon wrote: >>> The OP problem is that we're not advertising the right capabilities >>> when we associate, right? >> >> Correct. > > I didn't patch it right, but all of us agree on sta isn't sending > correct param at association. With current code, sta sends bac

[RFT] net80211 TX serialisation, take #4

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. T

Re: [RFT] net80211 TX serialisation, take #4

On 22 February 2013 15:25, Adrian Chadd 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

Re: [RFT] net80211 TX serialisation, take #4

.. 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 ___ freebsd

Re: ath performance degradation between Oct-12 and now?

On 23 February 2013 12:16, Sven Hazejager wrote: > I have just upgraded my ALIX router (with an Atheros 9160) from > FreeBSD-HEAD r241243 (Oct 6, 2012) to r247155 (today) and I am > noticing slightly lower throughput rates. > > With iperf, sitting 1 meter from the router, I consistently get 79-81

Re: [RFT] net80211 TX serialisation, take #4

On 23 February 2013 22:30, PseudoCylon 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 it'll be sure the

Re: [RFT] net80211 TX serialisation, take #4

The trouble with using a queue is that things will dequeue frames out of order, bceause multiple dequeue contexts (ie, each call to driver_start / driver_transmit) will execute in-parallel. Yay. adrian ___ freebsd-wireless@freebsd.org mailing list htt

Re: [RFT] net80211 TX serialisation, take #4

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 "fre

[CFT] STBC is enabled for AR9280 and later

Hiya, I've just enabled STBC TX and RX on the AR9280 and later. * STBC TX requires two chains to work right. So enabling a single chain only or the single chain NICs (AR9285) won't work; * STBC RX works with one chain but you really need two chains to get the benefit; * STBC is only supported for

Re: ath0 Device Timeout Issues

These are only during probe requests, right? adrian On 27 February 2013 16:30, Derrick Dantavious Edwards wrote: > Hi, > During recent upgrades to Current, I have been experiencing timeouts with the > ath0 device. These are the errors that I am receiving. Any ideas? > > V/r > > Derri

Re: ath0 Device Timeout Issues

On 27 February 2013 18:59, Derrick Dantavious Edwards wrote: > > Yes. When I start the system, I get those messages. Wireless Link fails to > establish thus causing all services requring link to failie NFS . Soon > after I am at the command prompt or GUI, I can ping hosts however, I have t

Re: Are 802.11s and "classical" AP compatible?

not yet, sorry. adrian On 28 February 2013 02:03, Lev Serebryakov wrote: > Hello, Freebsd-wireless. > > ath could have several VAPs, each with its own SSID and security > settings (but with shared channel(s), of course). > > Is it possible to do 802.11s node and "classical" AP on one car

Re: Are 802.11s and "classical" AP compatible?

On 28 February 2013 02:11, Lev Serebryakov wrote: > Hello, Adrian. > You wrote 28 февраля 2013 г., 14:04:41: > > AC> not yet, sorry. > Is it limitation of FreeBSD's drivers or "universal" one? Friend of > my have some ideas about such gateway, but he could use Linux-based > "firmaware" (OpenWRT-b

Re: ath0 Device Timeout Issues

Just experiment with changing the kern.eventtimer.periodic and kern.timecounter.hardware values. Thanks, Adrian On 28 February 2013 03:20, Derrick Dantavious Edwards wrote: > On 27 February 2013 18:59, Derrick Dantavious Edwards > wrote: >> >> Yes. When I start the system, I get those me

Re: [RFT] net80211 TX serialisation, take #4

Hi, Right - but then I still need to hold long held locks here across the net80211 _and_ the driver. Ie: * net80211 needs to hold a lock for the entire process of dequeuing a frame and running it to completion. It can't do this: * grab lock * dequeue frame * release lock --> here things race

[RFC] replace ic->ic_raw_xmit() calls with a method - ieee80211_raw_xmit()

Hi, As part of eventually making ic_raw_xmit() go via the vap/ic queue, I'd like to methodise this. Right now the stack calls ic->ic_raw_xmit(ni, mbuf, params) directly. I'd like to stick it inside a method call. Later on the raw frames can be queued via the VAP TX queue and processed in-order.

[RFC] net80211 TX, take 4 (final)

Hi, So here's where I'm at: * There's the serialisation of frames that have 802.11 state attached - eg, the encap path for normal VAP TX, for management frame TX, mesh, FF TX, etc; * There's then the serialisation of _dispatching those frames in order to the driver_; * The former will be too hard

Re: negotiating HT params at assoc in sta mode

Did we ever get any consensus on the right thing to do here? :) 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"

Re: [RFC] net80211 TX, take 4 (final)

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().

Re: [RFC] net80211 TX, take 4 (final)

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 implicatio

Re: Does ath in 802.11g builds map of client <-> antenna "distance"?

On 4 March 2013 09:50, Lev Serebryakov 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 > are attac

Re: Max wireless throughput

.. and it's an 11n 1x1 NIC that can do either 20 or 40MHz wide channels. So if you're running -HEAD you can get upwards of 100mbit on TCP. Adrian On 4 March 2013 13:05, Adrian Chadd wrote: > Yup, that's what you expect for OFDM 54MB rates. > > Why do you ask? >

Re: Max wireless throughput

Yup, that's what you expect for OFDM 54MB rates. Why do you ask? Adrian On 4 March 2013 12:49, Dmitry Kolosov 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 24-28Mbps as fo

Fine, OK, here's my initial AR9380/AR9485 support

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 loca

Re: Fine, OK, here's my initial AR9380/AR9485 support

You didn't check out the local/freebsd branch. On 10 March 2013 09:29, Joshua Isom 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 .c files

Re: Fine, OK, here's my initial AR9380/AR9485 support

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 AT&T On Mar 10, 2013 5:07 PM, Rui Paulo wrote: On 2013/03/10, at

Re: Fine, OK, here's my initial AR9380/AR9485 support

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 int

Re: Fine, OK, here's my initial AR9380/AR9485 support

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 On 11 March 2013 16:38, Joshua Isom wrote: > Here's me retrying everything. I also tried running make with -DAH

Re: Fine, OK, here's my initial AR9380/AR9485 support

reg.h and hardcoded. > > At least you figured out an easy way to genuine 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_DEBU

Re: Fine, OK, here's my initial AR9380/AR9485 support

bug that I can file as having come from the FreeBSD community. :) Adrian On 11 March 2013 17:41, Adrian Chadd wrote: > Is this with clang? > > > > > adrian > > > On 11 March 2013 17:39, Joshua Isom wrote: >> Still no luck, and some errors look like I'

Re: Fine, OK, here's my initial AR9380/AR9485 support

On 11 March 2013 17:43, Adrian Chadd 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

Re: Fine, OK, here's my initial AR9380/AR9485 support

On 11 March 2013 17:43, Adrian Chadd 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

Re: Fine, OK, here's my initial AR9380/AR9485 support

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 th

Re: Fine, OK, here's my initial AR9380/AR9485 support

On 12 March 2013 14:12, Joshua Isom wrote: > I had to remove the /sys/ from the PATH and CFLAGS to point to the right > directory, it's still failing with warnings. I tried gcc and clang. I'll > try to see how much I can patch myself without knowing the code at all. Hi, Where's it failing with

Re: Fine, OK, here's my initial AR9380/AR9485 support

what other build errors you're seeing. Thanks, Adrian On 12 March 2013 15:06, Joshua Isom wrote: > On 3/12/2013 4:14 PM, Adrian Chadd wrote: >> >> On 12 March 2013 14:12, Joshua Isom wrote: >>> >>> I had to remove the /sys/ from the PATH and CFLAGS to poin

Re: Fine, OK, here's my initial AR9380/AR9485 support

On 9 March 2013 10:54, Adrian Chadd 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 (WB22

Re: Fine, OK, here's my initial AR9380/AR9485 support

t; actually 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 - pl

Re: Fine, OK, here's my initial AR9380/AR9485 support

ically not compile in any longer. adrian On 13 March 2013 19:16, Adrian Chadd wrote: > Can you please post the patch and the specific compile issue? > > > > adrian > > > On 13 March 2013 18:41, Joshua Isom wrote: >> I added a cast to u_int64_t first on line 63 of

Re: Why FreeBSD AP announce rates over 18Mbit/s as "Extended"?

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 16:

Re: Fine, OK, here's my initial AR9380/AR9485 support

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 AT&T On Mar 14, 2013 6:31 PM, Joshua Isom <jri...@gmail.com> wrote: On 3/13/2013 7:31 PM, Adrian Chadd

Re: Fine, OK, here's my initial AR9380/AR9485 support

w.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

Re: Fine, OK, here's my initial AR9380/AR9485 support

.. 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 wrote: > Oh! > > http://wikidevi.com/wiki/TP-LINK_TL-WDN4800 > > Silly me, I was reading the wrong number on my phone. > > Yes, 0x0030 is Os

Re: Fine, OK, here's my initial AR9380/AR9485 support

Did you remove ath/ath_hal/ath_rate_sample from your kernel config file when you rebuilt? The default system ships with ath/ath_hal/ath_rate_sample compiled into the kernel rather than as modules. Thanks, Adrian On 14 March 2013 19:57, Joshua Isom wrote: > On 3/14/2013 9:20 PM, Adr

<    1   2   3   4   5   6   7   8   9   10   >