This seems to work fine for STA but not HT/20 AP mode.
Further discussion with net80211 people will need to take place
to ensure that the right flags are set based on the negotiated
capabilities of the remote peer, rather than whatever the local
parameters are.
Sending short-gi frames in 20mhz may work on some chips but
it certainly isn't supported on anything currently supported
by the HAL; and sending HT40 frames in HT20 mode just plain
won't work.
settings, it seems that our defines are backwards and don't match what
is in the EEPROM documentation or internal driver.
The ath9k code used to have a bitfield here, rather than a uint8_t, and
there were #defines used to swap the order based on the endian of the
platform - this wasn't because of nybble or bit ordering of the
underlying host but because of what the compiler was doing.
This may be the reason for the backwards field numbers, as ath9k had
similar issues.
the AR9285 so I'll leave it off for that.
Ath9k sources indiciate that one of the ANI modes interferes with
RIFS detection, so match ath9k and disable that.
* The existing interrupt mitigation code didn't mitigate anything - the
per-packet TX/RX interrupts are still occuring. It's possible this
worked for the AR5416 but not any later chipsets; I'll investigate and
update as needed.
* Set both the RX and TX threshold registers whilst I'm at it.
This is verified to work on the AR9220 and AR9160. I'm leaving it off
by default in case it's truely broken, but I need to have it enabled
when doing 11n testing or interrupt loads exceed 10,000 interrupts/sec.
Add new RAID GEOM class, that is going to replace ataraid(4) in supporting
various BIOS-based software RAIDs. Unlike ataraid(4) this implementation
does not depend on legacy ata(4) subsystem and can be used with any disk
drivers, including new CAM-based ones (ahci(4), siis(4), mvs(4), ata(4)
with `options ATA_CAM`). To make code more readable and extensible, this
implementation follows modular design, including core part and two sets
of modules, implementing support for different metadata formats and RAID
levels.
Support for such popular metadata formats is now implemented:
Intel, JMicron, NVIDIA, Promise (also used by AMD/ATI) and SiliconImage.
Such RAID levels are now supported:
RAID0, RAID1, RAID1E, RAID10, SINGLE, CONCAT.
For any all of these RAID levels and metadata formats this class supports
full cycle of volume operations: reading, writing, creation, deletion,
disk removal and insertion, rebuilding, dirty shutdown detection
and resynchronization, bad sector recovery, faulty disks tracking,
hot-spare disks. For Intel and Promise formats there is support multiple
volumes per disk set.
Look graid(8) manual page for additional details.
Co-authored by: imp
Sponsored by: Cisco Systems, Inc. and iXsystems, Inc.
VFS where we know if this is truncate(2) or ftruncate(2). If this is the
latter we should depend on the mode the file was opened and not on the current
permission.
PR: standards/154873
Reported by: Mark Martinec <Mark.Martinec@ijs.si>
Discussed with: Eric Schrock <eric.schrock@delphix.com>
Discussed with: Mark Maybee <Mark.Maybee@Oracle.COM>
MFC after: 1 month
Introduce new type of BIO_GETATTR -- GEOM::setstate, used to inform lower
GEOM about state of it's providers from the point of upper layers.
Make geom_disk use led(4) subsystem to illuminate states in such fashion:
FAILED - "1" (on), REBUILD - "f5" (slow blink), RESYNC - "f1" (fast blink),
ACTIVE - "0" (off).
LED name should be set for each disk via kern.geom.disk.%s.led sysctl.
Later disk API could be extended to allow disk driver to report this info
in custom way via it's own facilities.
- Hold the proc lock while changing the state from PRS_NEW to PRS_NORMAL
in fork to honor the locking requirements. While here, expand the scope
of the PROC_LOCK() on the new process (p2) to avoid some LORs. Previously
the code was locking the new child process (p2) after it had locked the
parent process (p1). However, when locking two processes, the safe order
is to lock the child first, then the parent.
- Fix various places that were checking p_state against PRS_NEW without
having the process locked to use PROC_LOCK(). Every place was already
locking the process, just after the PRS_NEW check.
- Remove or reduce the use of PROC_SLOCK() for places that were checking
p_state against PRS_NEW. The PROC_LOCK() alone is sufficient for reading
the current state.
- Reorder fill_kinfo_proc() slightly so it only acquires PROC_SLOCK() once.
MFC after: 1 week
The symptom: sometimes 11n (and non-11n) throughput is great.
Sometimes it isn't. Much teeth gnashing occured, and much kernel
bisecting happened, until someone figured out it was the order
of which things were rebooted, not the kernel versions.
(Which was great news to me, it meant that I hadn't broken if_ath.)
What we found was that sometimes the WME parameters for the best-effort
queue had a burst window ("txop") in which the station would be allowed
to TX as many packets as it could fit inside that particular burst
window. This improved throughput.
After initially thinking it was a bug - the WME parameters for the
best-effort queue -should- have a txop of 0, Bernard and I discovered
"aggressive mode" in net80211 - where the WME BE queue parameters
are changed if there's not a lot of high priority traffic going on.
The WME parameters announced in the association response and beacon
frames just "change" based on what the current traffic levels are.
So in fact yes, the STA was acutally supposed to be doing this higher
throughput stuff as it's just meant to be configuring things based on
the WME parameters - but it wasn't.
What was eventually happening was this:
* at startup, the wme qosinfo count field would be 0;
* it'd be parsed in ieee80211_parse_wmeparams();
* and it would be bumped (to say 10);
* .. and the WME queue parameters would be correctly parsed and set.
But then, when you restarted the assocation (eg hostap goes away and
comes back with the same qosinfo count field of 10, or if you
destroy the sta VIF and re-create it), the WME qosinfo count field -
which is associated not to the VIF, but to the main interface -
wouldn't be cleared, so the queue default parameters would be used
(which include no burst setting for the BE queue) and would remain
that way until the hostap qosinfo count field changed, or the STA
was actually rebooted.
This fix simply cleares the wme capability field (which has the count
field) to 0, forcing it to be reset by the next received beacon.
Thanks go to Milu for finding it and helping me track down what was
going on, and Bernard Schmidt for working through the net80211 and
WME specific magic.
Change BIO_GETATTR("GEOM::kerneldump") API to make set_dumper() called by
consumer (geom_dev) instead of provider (geom_disk). This allows any geom
insert it's code into the dump call chain, implementing more sophisticated
functionality then just disk partitioning.
queue has its own interrupt. If the exact number that we need is not a
power of 2 and we're using MSI, then switch to interrupt multiplexing.
While here, replace the magic numbers with something more readable.
MFC after: 3 days
At least one AR5416 user has reported measurable throughput drops
with this option. For now, disable it and make it a run-time
twiddle. It won't take affect until the next radio programming
trip though (eg channel scan, channel change.)
vfs_equalopts(). This allows vfs_sanitizeopts() to filter redundant
occurrences of these options. It was possible that for example both "ro"
and "rw" options became active concurrently.
PR: kern/133614
Discussed on: freebsd-hackers
MFC after: 1 month
Also, express this new maximum as a fraction of the kernel's address
space size rather than a constant so that increasing KVA_PAGES will
automatically increase this maximum. As a side-effect of this change,
kern.maxvnodes will automatically increase by a proportional amount.
While I'm here ensure that this change doesn't result in an unintended
increase in maxpipekva on i386. Calculate maxpipekva based upon the
size of the kernel address space and the amount of physical memory
instead of the size of the kmem map. The memory backing pipes is not
allocated from the kmem map. It is allocated from its own submap of
the kernel map. In short, it has no real connection to the kmem map.
(In fact, the commit messages for the maxpipekva auto-sizing talk
about using the kernel map size, cf. r117325 and r117391, even though
the implementation actually used the kmem map size.) Although the
calculation is now done differently, the resulting value for
maxpipekva should remain almost the same on i386. However, on amd64,
the value will be reduced by 2/3. This is intentional. The recent
change to VM_KMEM_SIZE_SCALE on amd64 for the benefit of ZFS also had
the unnecessary side-effect of increasing maxpipekva. This change is
effectively restoring maxpipekva on amd64 to its prior value.
Eliminate init_param3() since it is no longer used.
so there's no need to enable the RX of invalid frames just to do ANI.
The if_ath code and AR5212 ANI code setup the RX filter bits to enable
receiving OFDM/CCK errors if the device doesn't have the hardware
MIB counters. It isn't initialising it for the AR5416+ because all of
those chips have hardware MIB counters.
This fixes the odd (and performance affecting!) situation where if ani
is enabled (via sysctl dev.ath.X.intmit) then suddenly there's be a very
large volume of phy errors - which is good to track, but not what was
intended. Since each PHY error is a received (0 length) frame, it can
significantly tie up the RX side of things.
It's still not ready for prime-time - there's some TX niggles with these 11n
cards that I'm still trying to wrap my head around, and AMPDU-TX is just not
implemented so things will come to a crashing halt if you're not careful.
"extended capabilities" to refer to the new set of capability structures
starting at offset 0x100 in config space for PCI-express devices. For now
both function names will still work. I will merge this to older branches
to ease driver portability, but 9.0 will ship with a new pci_find_extcap()
function that locates extended capabilities instead.
Reviewed by: imp
MFC after: 1 week
This fix modifies the const addac initval array, rather than modifying
a local copy. It means that running >1 AR9160 on a board may prove to
be unpredictable.
The AR5416 init path also does something similar, so supporting
>1 AR5416 of different revisions could cause problems.
The later fix will be to create a private copy of the Addac data
for the AR5416, AR9160 (and AR9100 when it's merged in) and then
modify that as needed.
Obtained From: Linux ath9k
I found this when trying to figure out why the RX PHY error count
didn't match the OFDM error count ANI was using. It turns out
there was two problems:
* What this commit addresses - using the wrong mask for OFDM errors,
and
* The RX filter is set incorrectly after a channel scan (at least)
even if interference mitigation is enabled by default.
ANI is still disabled by default for the AR5416 and later chips.
set as TCP.
- Eliminate the fully linear non-scatter/gather rx path, there is no
harm in using arrays of clusters for both TCP and UDP.
- Implement support for enabling/disabling per-vlan priority pause and
queues via sysctl.
bring it in line with the rest of the register initialisation.
I've verified that the 2/5ghz board values written to the
chip match what was previously written.
* add pspoll/uapsd queue setup defaults;
* enable the exponential backoff window rather than the random
backoff window when doing TX contention management.
would be a problem, make sure it isn't overwritten by whatever is in
there at cold reset.
This brings the > ar5416 init path treatment of AR_MISC_MODE.
