when -u is specified it is not...
update the docs to say that you can use full device names w/ -u, and
update the examples...
Submitted by: #vbsdcon
MFC after: 3 days
Use it universally. Book-E traps may also need revisiting due to the
introduction of fixed-offset traps and the deprecation of IVORs in POWER
ISA 2.06, but that's very much an issue for another day.
is slightly more complicated and is left unimplemented for now. Also
prevent pmap_mapdev() from mapping over the kernel and KVA regions if
devices happen to have high physical addresses.
MFC after: 2 weeks
This is believed to fix hastd crashes, which might occur during
synchronization, triggered by the failed assertion:
Assertion failed: (amp->am_memtab[ext] > 0),
function activemap_write_complete, file activemap.c, line 351.
MFC after: 1 week
* Remove the unused sdt cdev.
* Don't bother keeping a list of probes in struct sdt_prov; it's not needed.
* Invoke sdt_load and sdt_unload from the module handler instead of
registering separate SYSINITs.
* Keep to within 80 columns.
* Check for errors from dtrace_unregister().
added with "pkg add". If the pkg.conf is configured to check for
signature, then the pkg.txz.sig file will be expected and validated
per r257147
Approved by: bapt
MFC after: 2 days
If the pkg.conf is configured with SIGNATURE_TYPE: FINGERPRINTS,
and FINGERPRINTS: /etc/keys/pkg then a pkg.sig file is fetched along
with pkg.txz. The signature contains the signature provided by the
signing server, and the public key. The .sig is the exact output
from the signing server in the following format:
SIGNATURE
<openssl signed>
CERT
<rsa public key>
END
The signature is verified with the following logic:
- If the .sig file is missing, it fails.
- If the .sig doesn't validate, it fails.
- If the public key in the .sig is not in the known trusted fingerprints,
it fails.
- If the public key is in the revoked key list, it fails.
Approved by: bapt
MFC after: 2 days
Discussed by: bapt with des, jonathan, gavin
For now only /etc/pkg/FreeBSD.conf is supported. Its style is:
Repo: {
URL: "...",
MIRROR_TYPE: "...",
...
}
The configuration will be read from /usr/local/etc/pkg.conf if exists,
otherwise /etc/pkg/FreeBSD.conf
Approved by: bapt
MFC after: 2 days
the code was trying to save the stack pointer rather than the frame pointer,
and the arguments to copyout(9) were reversed, so nothing ended up being
saved on the stack. This would cause process crashes when the pid provider
was being used to instrument calls of a function starting with this
instruction.
Reported by: symbolics@gmx.com
Tested by: symbolics@gmx.com (earlier version)
MFC after: 2 weeks
This is "STA invalid". I saw it during some 4965 testing (kern/183260)
and I still have no idea what is causing it.
Obtained from: Linux drivers/net/wireless/iwlegacy
Some firmware versions seem to get very unhappy if they're sent btcoex
commands when they don't actually have bluetooth hardware in them.
So, disable sending them those commands.
Tested:
* 5100 (which has bluetooth, no problems)
* 4965 (which doesn't have bluetooth, but didn't seem to crash)
* 6200 (no bluetooth, seems to get unhappy being sent bluetooth commands.)
index lookups.
* My recent(ish) change to iwn(4) and the net80211 rate control API to
support 11n rates broke the link quality table use. So, until I or
someone else decides to fix it, let's just disable it for now.
* Teach iwn_tx_data_raw() to use the iwn_rate_to_plcp() function.
* Eliminate two uses of the net80211 rate index lookup functions - they
are only for legacy rates and they're not needed here.
This fixes some invalid looking rate control TX issues that showed up
on my 4965 but it doesn't fix the two TX hangs I've noticed. Those look
like DMA related issues.
Tested:
* 4965, STA mode
* 5100, STA mode
associates compat strings with arbitrary values that mean something to
the driver. This is handy for drivers that support several variations
of similar hardware and need to know which one matched.
Reviewed by: imp, jmg, nwhitehorn
negative diff that should improve reliability somewhat. There should be
no differences in behavior -- please report any that crop up. This has been
tested on ARM and PPC systems.
Tested by: ray
mode as c++ instead of defaulting to c for the binary names CC and clang-CC.
This fixes builds that use cmake, which automatically sets CXX to
/usr/bin/CC by default.
PR: bin/182442
Reviewed by: dwhite, wca
MFC after: 2 days
This manual page intends to describe the structure and behavior of
the FreeBSD test suite installed in /usr/tests. The contents have
been inherited from the NetBSD manual page.
As a side effect, this also updates the hier(7) manual page to
mention /usr/tests and points at tests(7) for more details.
Submitted by: Julio Merino jmmv google.com
Reviewed by: sjg
MFC after: 2 weeks
Populate /usr/tests with the only test programs that currently live
in the tree (those in lib/libcrypt/tests/) and add all the build
machinery to accompany this change.
In particular:
- Add a WITHOUT_TESTS variable that users can define to request that
no tests be put in /usr/tests.
- Add a top-level Kyuafile for /usr/tests and a way to create similar
Kyuafiles in top-level subdirectories.
- Add a BSD.tests.dist file to define the directory layout of
/usr/tests.
Submitted by: Julio Merino jmmv google.com
Reviewed by: sjg
MFC after: 2 weeks
We need to be able to reference the value of TESTSBASE without requiring
the inclusion of bsd.test.mk (e.g. in etc/Makefile), so move its definition
to the more generic bsd.own.mk.
Submitted by: Julio Merino jmmv google.com
Reviewed by: sjg
MFC after: 2 weeks
If a single Makefile wants to recurse into subdirectories and also
wants to install files, bsd.files.mk's targets would get ignored in
favor of those defined by bsd.subdir.mk because installfiles would
not get defined in bsd.files.mk.
Prevent this from happening by defining the targets in bsd.files.mk
with auxiliary names and listing them as dependencies of installfiles
instead.
This is required by bsd.test.mk, which needs to install a Kyuafile
in pretty much all cases but may also need to recurse into
subdirectories for build purposes.
Submitted by: Julio Merino jmmv google.com
Reviewed by: sjg
MFC after: 2 weeks
board.
This is another AR9331 board similar to the Carambola2. It has different
ethernet and LED wiring though.
They make a variety of boards that mostly differ on the amount of RAM/flash
available. Alfa Networks graciously donated a handful of 64MB RAM/16MB flash
boards so I can finish off 802.11s support for the AR93xx chips and do up
a tech demonstration with it.
This is enough to bring up the board.
Tested:
* Alfa networks UB Hornet board - 64MB ram, 16MB flash version.
Thankyou to Alfa Networks for the development boards!
Sponsored by: Alfa Networks (hardware only)
