Re: FreeBSD current RT3071 can't connect to 5G network
On Wed, Aug 20, 2014 at 1:29 PM, Adrian Chadd adr...@freebsd.org wrote: Are you seeing RX CRC errors for all rates? CCK? OFDM? HT? At all distances? CCK not sure, OFDM and HT yes. And at wide range of distances. (Tx rates usually hit mcs 12 to 14 with 2s ht20 ap) There's a handful of things we can look at to see what's causing it once some more digging is done. (Eg, HT? could be guard interval. OFDM has similar issues, there's typically ways to configure how much time between each symbol is left before transmitting the next one. It may not be doing CTS-to-self, or it may not be advertising the right thing via NAV, or it may be ignoring CCK, or the receive gain tables are all messed up, etc.) I have looked into stuff I was able to dig out from other src codes, ie protection, ifs, nav, bk slot. (Because I do not have datasheet, every thing is based on my guesses.) One thing I could not figure out is if on-chip memory is properly allocated for rx pkt. (It seems memory can be allocated for different things, ie beacon, enc keys). -a ___ 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: kern/177451: [ieee80211] page fault in ieee80211_tx_mgt_timeout
The following reply was made to PR kern/177451; it has been noted by GNATS. From: PseudoCylon moonlightak...@yahoo.ca To: bug-follo...@freebsd.org, dav...@freebsd.org Cc: Subject: Re: kern/177451: [ieee80211] page fault in ieee80211_tx_mgt_timeout Date: Fri, 29 Mar 2013 16:37:20 -0600 Oops. The code casts the enum to the pointer to begin, so it works. Sorry, for the noise. On Fri, Mar 29, 2013 at 3:21 PM, PseudoCylon moonlightak...@yahoo.ca wrote: http://fxr.watson.org/fxr/source/net80211/ieee80211_output.c?v=FREEBSD91#L2506 enum ieee80211_state ostate = (enum ieee80211_state) arg; casting a pointer to an enum http://fxr.watson.org/fxr/source/net80211/ieee80211_output.c?v=FREEBSD91#L2519 if (vap-iv_state == ostate) So that, this test is always false - callout_reset() will never be called - by the time the callout timer runs out, ni could be freed. ___ 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: [RFT] net80211 TX serialisation, take #4
On Mon, Feb 25, 2013 at 12:27 AM, Adrian Chadd adr...@freebsd.org wrote:
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.
Actually, to prevent that, there is an extra queue.
To begin
driver_queue:packet1--packet2--3--4--...
working_queue:empty
hadware_queue:empty
After multiple thread dequeue
lock dequeue enqueue unlock
lock dequeue enqueue unlock
They look like,
driver_queue:2--3--4--...
working_queue:1--2 (the lock preserves the order)
hardware_queue: empty
If a thread has packet #1 finished first, there is no problem.
If a thread has packet #2 finished first, it will try to dequeue the
packet #1 (head of the queue) from the working_queue. But the packet
isn't marked as completed, so it will just return.
Queue still look like
driver_queue:2--3--4--...
(of course, other threads are processing remaining packets,
but to simplify, no change in driver_queue.)
working_queue: 1--2
hardware: empty
Later, once the thread with #1 finished processing, it will
lock while (completed) {dequeue enqueue} unlock
At the end, queue look like,
driver_queue:2--3--4--...
working_queue: empty
hardware_queue: 1--2 (the lock preserves the order)
Just wanted to clarify. I will soon test the latest txlock patch.
AK
___
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: [RFT] net80211 TX serialisation, take #4
On Sun, Feb 24, 2013 at 12:45 AM, Adrian Chadd adr...@freebsd.org wrote:
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 it'll be sure the lock is held when it decides to
grab/increment sequence numbers from ni-ni_txseqs[].
I don't think
lock();
ni-ni_txseqs[]++;
unlock();
can fix the problem because no one can guarantee which process/thread
grabs the lock next.
Yup, that's definitely a problem.
The problem here is that packets coming into net80211 - either via
vap-input() (bpf injection) or vap-transmit() (802.3) , have to do
this:
There isn't any sequence relations between bpf injection and packets
from vap-transmit(). First come first enqueue should work.
80211 stack generated packets --\
bpf_injection - ieee80211_output()--\
vap_transmit() - vap_queue - 80211stack -- driver_queue
* processed in order;
* the same order as they're then pushed into the power save / age queue;
* the same order that these frames get assigned sequence numbers and
enforce state (eg considering things for ampdu, power save, etc);
* the same order that they're queued to the driver;
* the same order that they're dequeued from the driver;
* the same order that they're processed (eg crypto encaps);
* the same order that it's then passed down into the driver - either
via direct dispatch or deferred queue.
* .. and do this without tearing my hair out.
The sequence will be messed up during moving packets from one queue to
another, i.e from driver queue to hardware queue. As long as packets
are in a queue (in a linked list) sequence won't change unless we
explicitly write such code. So...
Saving your hair option 1
tx()
{
for() {
lock();
dequeue(m);/* assuming queue is in order */
ni_txseqs[]++
enqueue_working_queue(m);
unlock();
...
process m
...
lock();
/*
* m may change here.
* Whichever the thread does dequeues, m0 will be
* the head of the queue, so sequence will be kept intact.
* But, need to test if processing of m0 has been completed.
*/
dequeue_working_queue(m0);
enqueue_driver_queue(m0); /* or hardware_queue() */
unlock();
}
}
This will keep sequence intact.
Right. This is similar to my idea (or two.)
There's a few other issues though!
ic_raw_xmit() is called by a bunch of places to generate both raw
frames and management frames. This bypasses the vap queue and calls
the driver direct. As an example, injected EAPOL frames have CCMP IV
numbers (as they're encrypted!) but not necessarily sequence numbers.
Because the CCMP IV gets calculated int he driver at some point after
it's been queued, ANY slight race here causes some other frame to get
queued with a CCMP IV -after- the EAPOL frame, and it will get
dropped. Then you get your session dropped. :-)
That's a tricky one. (I didn't think about encryption.) Queue only
maintains the order of packets. It doesn't mean packets are processed
in order. If packets need to be processed in order, should be done
while the lock is held. I think this should do the trick.
lock();
dequeue_working_queue();/* or driver_queue */
if (IEEE80211_FC1_WEP)
ieee80211_crypto_encap();
pass_to_hardware();
unlock();
ic_raw_xmit() is also an ic method, not a vap method. Yes, it bypasses
the vap queue.
the same as bpf injection part
There's deferred transmission going on (eg ath_start() getting called
from TX completion, as an example.) Should that be called under the
above lock() in your example?
Yes. With encryption stuff, if_start or if_transmission will look like this.
if_start/_transmit()
{
for () {
lock();
dequeue_driver_queue();
enqueue_working_queue();
unlock();
...
process
...
lock();
dequeue_working_queue();
if (IEEE80211_FC1_WEP)
ieee80211_crypto_encap();
pass_to_hardware();
unlock();
}
}
And the TX sequence number stuff in iwn and ath, because the
aggregation code reuses the ni_txseqs[] array. So yes, the locking
wouldn't clash with the rest of net80211 (as only either the non-agg
TX path in net80211 or the TX path in ath/iwn would be using that
variable) but it's still a pain in the ass.
If we do a good job on serialization -- matching actual order of
packets sent out
Re: [RFT] net80211 TX serialisation, take #4
--
Message: 12
Date: Fri, 22 Feb 2013 17:18:44 -0800
From: Adrian Chadd adr...@freebsd.org
To: freebsd-wireless@freebsd.org
Subject: Re: [RFT] net80211 TX serialisation, take #4
Message-ID:
CAJ-Vmom8HNLNc-=CogiF1v2pJHcn73rB0w9EOHoBtTjAp=j...@mail.gmail.com
Content-Type: text/plain; charset=ISO-8859-1
On 22 February 2013 15:25, Adrian Chadd adr...@freebsd.org 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 lock is held when it decides to
grab/increment sequence numbers from ni-ni_txseqs[].
I don't think
lock();
ni-ni_txseqs[]++;
unlock();
can fix the problem because no one can guarantee which process/thread
grabs the lock next.
i.e. concurrently, without lock,
- Thread A is processing packet seq#1
- Thread B is processing packet seq#2
When the time to do ni_txseqs[]++, how can we guarantee thread A grabs
the lock before thread B? In other word, if thread A always grabs the
lock first, we don't need to serialize the Tx, do we?
* .. and do this without tearing my hair out.
The sequence will be messed up during moving packets from one queue to
another, i.e from driver queue to hardware queue. As long as packets
are in a queue (in a linked list) sequence won't change unless we
explicitly write such code. So...
Saving your hair option 1
tx()
{
for() {
lock();
dequeue(m);/* assuming queue is in order */
ni_txseqs[]++
enqueue_working_queue(m);
unlock();
...
process m
...
lock();
/*
* m may change here.
* Whichever the thread does dequeues, m0 will be
* the head of the queue, so sequence will be kept intact.
* But, need to test if processing of m0 has been completed.
*/
dequeue_working_queue(m0);
enqueue_driver_queue(m0); /* or hardware_queue() */
unlock();
}
}
This will keep sequence intact.
Saving your hair option 2
Shave your head until you fix the problem. Hair will grow again, you
know. No bad hair day is a bonus.
AK
___
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: kern/176201: [net80211] [patch] 11n station includes unrelated ht params into ASSOC_REQ packet
On Fri, Feb 22, 2013 at 12:05 PM, Bernhard Schmidt bschm...@techwires.net wrote: On Friday, February 22, 2013 07:52:47 PM Adrian Chadd wrote: 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? 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 back whatever it has received in probe resp packet. Why aren't we just advertising the VAP ampdumax and ampdudensity no matter what the operating mode? Why are we capping those parameters to the learnt-from-AP parameters? Because the AP would otherwise deny the association request. Should ap only allow node which caps match ap's to associate? (By the way, can anyone point me to the code does denial? I couldn't find it.) AK ___ 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: negotiating HT params at assoc in sta mode
On Wed, Feb 20, 2013 at 9:40 PM, Adrian Chadd adr...@freebsd.org wrote: On 20 February 2013 20:38, PseudoCylon moonlightak...@yahoo.ca 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 asked for. run(4) still generates lots of Rx errors. I cannot tell if the patch does any good. I can only tell the AP does receive the driver defined ht param, now. When doing aggregation? Try upping the ampdu density to something like 8 or 16 microseconds, maybe it needs more spacing between frames. What are you using as a transmitter in your run(4) tests? Currently, using my ISP supplied modem/router. I cannot set those param by hand on the ap. At least, the sta requests 16ms spacing, but no improvements. I'll be comparing with linux driver, and see what the differences are. I've got a good idea on registers and descriptors. But, most of bbps are still mystery. Maybe, blindly copy past their value. (Hope I have a datasheet.) AK ___ 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: negotiating HT params at assoc in sta mode
On Wed, Feb 20, 2013 at 4:52 PM, Adrian Chadd adr...@freebsd.org wrote: 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 ? 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 asked for. run(4) still generates lots of Rx errors. I cannot tell if the patch does any good. I can only tell the AP does receive the driver defined ht param, now. AK ___ 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] serialising net80211 TX
On Fri, Feb 15, 2013 at 4:03 PM, Adrian Chadd adr...@freebsd.org wrote: 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 thread for deferred transmit. How's that sound? I think that's good because if_start/transmit == data packet if_raw_xmit == mgmt packet is no longer true. http://svnweb.freebsd.org/base?view=revisionrevision=222682 And, all-in-one Tx path works with run(4) at least. AK ___ 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: Wireless Ralink Adapter is detected but doesn't work
-- Message: 5 Date: Fri, 23 Nov 2012 17:21:30 +0300 From: Nikolay Tychina niktych...@gmail.com To: freebsd-wireless@freebsd.org Subject: Wireless Ralink Adapter is detected but doesn't work Message-ID: CAEXpyJv-=ivrfvrpzq3_dgi5-xbo8sgb+jd1yo8zmtdf1ep...@mail.gmail.com Content-Type: text/plain; charset=ISO-8859-1 Hi! I got TP-LINK TL-W727N adapter with a Ralink chipset, added product RALINK RT5370 0x5370 RT5370 // to usbdevs RUN_DEV(RALINK, RT5370), // to if_run.c RT5370 has not been supported, yet. AK ___ 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] How the TX path works; I'd like to fix this before 10.x
--
Message: 4
Date: Fri, 5 Oct 2012 23:44:10 -0700
From: Adrian Chadd adr...@freebsd.org
Subject: [RFC] How the TX path works; I'd like to fix this before 10.x
To: freebsd-wireless@freebsd.org
Message-ID:
CAJ-VmomS=7Udyixqqss_1261EXzEpeYBuAWqwiKEah=5v4r...@mail.gmail.com
Content-Type: text/plain; charset=ISO-8859-1
Before I continue - if_transmit() is not the answer. if_transmit()
guarantess _no_ serialisation at all. So we'd stlil have to stuff
things into queues. And ensure only one thing is running at once.
As far as I know, if_transmit/if_start are options for drivers, not
for the serialisation.
if_transmit to use device specific queue
if_start to use if_snd queue
i.e.
http://fxr.watson.org/fxr/source/dev/e1000/if_em.c#L2941
I could wrap a big VAP TX lock around ieee80211_output() and
ieee80211_start(), ensuring they don't run over each other. But
long-held locks need to go away and die. yes, even the ones in the
ath(4) driver that I've introduced. They're there because of a lack of
synchronisation and queue design. A lot of the gige/10ge drivers use
long-held locks.. sigh.
I could create a net80211 TX tasklet for each vap (or ic, _maybe_)
which serialises the TX path. ieee80211_start() would just schedule
the tasklet to run. That would serialise all of the parallel TX entry
points and solve a bunch of the subtle sequence number and other TX
state races that are occuring. That doesn't solve the ic_raw_xmit() or
ieee80211_output() problem, as both of those can also do TX 802.11
encapsulation and kick off parts of the state machine.
I prefer taskqueue over new lock. I have had enough of LORs already.
We just need to decide where/how to funnel all tx entries.
Currently,
pseudo devices (i.e. if_bridge) \
IP stack -- ieee80211 stack -- driver
ic_raw_xmit /
so we need to ensure serialization (by lock or taskqueue) at 2 points,
1) between upper layer and ieee80211,
2) driver and ieee80211.
If we solve the raw_xmit problem, there will be only 1 point to take care.
An idea
Guarantee only one thread is running at any moment. So, first queued
first dequeued and tx'd without a lock.
if_start() {
if (sc_task == NOT_RUNNING)
wakeup(sc_txtask);
}
if_txtask() {
for (;sc_txtask_exit != DONE;) {
IFQ_DRV_DEQUEUE();
if (m == NULL) {
sc_txtask = NOT_RUNNING;
tsleep();
sc_txtask = RUNNING;
} else
tx();
}
}
tx_callback() {
...
if (sc_task == NOT_RUNNING)
wakeup(sc_txtask);
}
iv_vap_create() {
...
taskqueue_enqueue(sc_taskqueue);
}
iv_vap_delete() {
...
sc_txtask_exit = DONE;
if (sc_task == NOT_RUNNING)
wakeup(sc_txtask);
}
It doesn't solve the same issues with the drivers .Yes, even if we
converted them to use if_transmit(). iwn(4) solves this by just having
a big IWN_LOCK() but it releases it when doing anything stack related.
I'm not sure if it holds it across the whole TX path through
iwn_start(). In any case, it's a big lock. ath(4) can and does have
multiple ath_start() instances running in multiple kernel threads,
fighting to dequeue frames from the ifnet. This still can cause issues
with non-aggregate sequence number and CCMP IV counter allocation.
Sigh.
God even knows what to do about USB devices in all of this.
Similar to other drivers, i.e. iwn(4). The difference is USB drivers
create per-USB-pipe queue in addition to if_snd queue. So that, tx
path look like
if_transmit - queue - if_start - dequeue - driver_tx - usb_queue
- usb_stack
It seems redundant. I'd like to change that to (for run(4))
if_transmit - driver_tx - usb_queue - usb_stack
AK
___
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: ath0_node_lock ath0_com_lock lor
-- Message: 1 Date: Thu, 27 Sep 2012 12:44:04 -0700 From: Adrian Chadd adr...@freebsd.org Subject: Re: ath0_node_lock ath0_com_lock lor To: Kim Culhan w8hd...@gmail.com Cc: freebsd-wireless@freebsd.org Message-ID: CAJ-Vmo=kVMFJ+RBr0EBo=e9trp97e+povvj9hokzktaqrrc...@mail.gmail.com Content-Type: text/plain; charset=ISO-8859-1 Hm, that's odd. Who wants to go digging to figure out which code paths are causing this? :) A suggestion in setmlme_dropsta() http://fxr.watson.org/fxr/source/net80211/ieee80211_ioctl.c#L1331 Just forget about node lock and call ieee80211_find_node() instead of ieee80211_find_node_locked(). (I believe this lor occurs only in AP mode.) AK PS This lor is already documented in wifi debug wiki. On 26 September 2012 12:49, Kim Culhan w8hd...@gmail.com wrote: Have not seen an lor in some time, this noted today fyi lock order reversal: 1st 0xff80009267f0 ath0_node_lock (ath0_node_lock) @ /usr/src/sys/net80211/ieee80211_ioctl.c:1341 2nd 0xff8000925018 ath0_com_lock (ath0_com_lock) @ /usr/src/sys/net80211/ieee80211_node.c:2619 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b kdb_backtrace() at kdb_backtrace+0x39 witness_checkorder() at witness_checkorder+0xc37 _mtx_lock_flags() at _mtx_lock_flags+0x83 ieee80211_node_leave() at ieee80211_node_leave+0x97 setmlme_common() at setmlme_common+0x3f7 ieee80211_ioctl_setmlme() at ieee80211_ioctl_setmlme+0x87 ieee80211_ioctl_set80211() at ieee80211_ioctl_set80211+0x5a5 in_control() at in_control+0x216 ifioctl() at ifioctl+0x1020 kern_ioctl() at kern_ioctl+0x1b0 sys_ioctl() at sys_ioctl+0x11f amd64_syscall() at amd64_syscall+0x25a Xfast_syscall() at Xfast_syscall+0xfb --- syscall (54, FreeBSD ELF64, sys_ioctl), rip = 0x801203b8a, rsp = 0x7fffd9b8, rbp = 0x7fffda20 --- -- thanks -kim ___ 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
