The XC900M acts as a Ubiquiti XR9 (and I _think_ SR9) by default;
it uses the same 900MHz<->2.4GHz downconverter mapping.
However it has an alternative frequency mapping which squeezes in a couple
more half/quarter rate channels. Since the default HAL doesn't support
fractional tuning (sub-1MHz) in 2.4GHz mode on the AR5413/AR5414, they
implement it using a jumper.
Datasheet: http://www.xagyl.com/download/XC900M_Datasheet.pdf
Thankyou to Xagyl Communications for the XC900M NICs and Edgar Martinez
for organising the donation.
Tested:
* XC900M <-> XC900M
* Ubiquiti XR9 <-> XC900M
TODO:
* Test against SR9 and GZ901 if possible (the IEEE channel<->frequency
mapping may not match up, thanks to the slightly different channels
involved)
auditdistd (distributed audit daemon) to the build:
- Manual cross references
- Makefile for auditdistd
- rc.d script, rc.conf entrie
- New group and user for auditdistd; associated aliases, etc.
The audit trail distribution daemon provides reliable,
cryptographically protected (and sandboxed) delivery of audit tails
from live clients to audit server hosts in order to both allow
centralised analysis, and improve resilience in the event of client
compromises: clients are not permitted to change trail contents
after submission.
Submitted by: pjd
Sponsored by: The FreeBSD Foundation (auditdistd)
It also doesn't work with make -s.
Prefer the use of builtin make features.
PR: misc/126312
Reported by: Nejc Skoberne <nejc@skoberne.net>
Submitted by: bdrewery
Approved by: cperciva
MFC after: 1 week
Since I've committed this I've receieved roughly an equal
amount of email thanking me for making this change
and asking me to revert it.
I've resisted making this change because
new users tend to prefer less over more
and these users are the least likely to know
how to change the PAGER on their own.
Requested by: many
Objected to: just as many
Decision made by: core
Approved by: cperciva
MFC after: 3 days
floppies.
Its unlikely that anyone actually uses these or cares about these
anymore, since we support other floppy types and this change doesn't
hurt - just add it.
PR: conf/40777
Submitted by: Antti Kantee <pooka@cubical.fi>
Arrival-Date: Fri Jul 19 08:50:02 PDT 2002
Approved by: cperciva (implicit)
MFC after: 1 week
but committing it helps to get everyone on the same page and makes
sure we make progress.
Tinderbox breakages that are the result of this commit are entirely
the committer's fault -- in other words: buildworld testing on amd64
only.
Credits follow:
Submitted by: Garrett Cooper <yanegomi@gmail.com>
Sponsored by: Isilon Systems
Based on work by: keramida@
Thanks to: gnn@, mdf@, mlaier@, sjg@
Special thanks to: keramida@
local.9600. Whilst the actual binary termios(4) definitions and preceeding
comments for local.9600 indicate that parity is disabled, getty(8)
internally simulates parity based on the presence or absence of the 'np'
flag.
PR: conf/76226
Submitted by: peter
Approved by: grog (co-mentor)
MFC after: 1 month
GIANT from VFS. In addition, disconnect also netsmb, which is a base
requirement for SMBFS.
In the while SMBFS regular users can use FUSE interface and smbnetfs
port to work with their SMBFS partitions.
Also, there are ongoing efforts by vendor to support in-kernel smbfs,
so there are good chances that it will get relinked once properly locked.
This is not targeted for MFC.
GIANT from VFS. This code is particulary broken and fragile and other
in-kernel implementations around, found in other operating systems,
don't really seem clean and solid enough to be imported at all.
If someone wants to reconsider in-kernel NTFS implementation for
inclusion again, a fair effort for completely fixing and cleaning it
up is expected.
In the while NTFS regular users can use FUSE interface and ntfs-3g
port to work with their NTFS partitions.
This is not targeted for MFC.
GIANT from VFS. In addition, disconnect also netncp, which is a base
requirement for NWFS.
In the possibility of a future maintenance of the code and later
readd to the FreeBSD base, maybe we should think about a better location
for netncp. I'm not entirely sure the / top location is actually right,
however I will let network people to comment on that more specifically.
This is not targeted for MFC.
umsX character device returns a read error. Update devd.conf rules
to use "DEVFS" events which are generated after that the umsX
character device node has been created/destroyed, and then there
should be no need for moused to wait up to 10 seconds for umsX to
be ready. Opening umsX should not fail except if the kernel is low
on memory. In that case the user can replug the USB mouse or use
"usbconfig" to reset the device. In case of USB mouse devices,
moused should neither retry to open its character device,
once the first read error has happened. This is an indication
of device detach.
MFC after: 1 week
Trying to determine current lowest C-state after an AC event is racy
with C-states actually being changed by ACPI platform and kernel driver.
MFC after: 3 weeks
systems are fully "ready to go".
'FILESYSTEMS' states: "This is a dummy dependency, for services which
require file systems to be mounted before starting." However, we have
'var' which is was run after 'FILESYSTEMS' and can mount /var if it
already isn't mounted. Furthermore, several scripts cannot use /var
until 'cleanvar' has done its thing. Thus "FILESYSTEMS" hasn't really
meant all critical file systems are fully usable.
gives machine unique values from the firmware.
* The kernel is more likely to be unique than /bin/ls (but no need to
stuff many megabytes into /dev/random, so hash it).
* Change ordering to give larger variance across reboots to reduce
predictability.
r128060 for "hardware-supplied entropy" reversed this without reason,
seems a typo.
* Isolate "better than nothing" implementation to a function.
Submitted by: obrien & Arthur Mesh <arthurmesh@gmail.com>
Sponsored by: Juniper Networks
