summaryrefslogtreecommitdiffstats
path: root/lib/libc/stdlib/hcreate.c
diff options
context:
space:
mode:
authoradrian <adrian@FreeBSD.org>2012-06-24 05:59:32 +0000
committeradrian <adrian@FreeBSD.org>2012-06-24 05:59:32 +0000
commit926549a58e0b40cf256065af74a4c328b2250506 (patch)
tree7bd37fdf97865843777100d6681c7a7f156ea8ef /lib/libc/stdlib/hcreate.c
parentbe54b17782e6e96ea044ccc043eec5661ed7c817 (diff)
downloadFreeBSD-src-926549a58e0b40cf256065af74a4c328b2250506.zip
FreeBSD-src-926549a58e0b40cf256065af74a4c328b2250506.tar.gz
Sometimes the AR5416 sends back radar PHY errors with both the PHY error
and the CRC error bits set. The radar payload is correct. When this happens, the stack doesn't see them PHY error frames and isn't interpreted as a PHY error. So, no radar detection and no radiotap PHY error handling. Now, this may introduce some weird issues if the MAC sends up some other combination of CRC error + PHY error frames; this commit would break that and mark them as PHY errors instead of CRC errors. I may tinker with this a little more to pass radar/early radar/spectral frames up as PHY errors if the CRC bit is set, to restore the previous behaviour (where if CRC is set on a PHY error frame, it's marked as a CRC error rather than PHY error.) Tested on: AR5416, over the air, to a USRP N200 which is generating a large number of a variety of radar pulses. TODO: Test on AR9130, AR9160, AR9280 (and maybe radar pulses on 2GHz on AR9285/AR9287.) PR: kern/169362
Diffstat (limited to 'lib/libc/stdlib/hcreate.c')
0 files changed, 0 insertions, 0 deletions
OpenPOWER on IntegriCloud