attilio [Tue, 7 Jun 2011 08:46:13 +0000 (08:46 +0000)]
etire the cpumask_t type and replace it with cpuset_t usage.
This is intended to fix the bug where cpu mask objects are
capped to 32. MAXCPU, then, can now arbitrarely bumped to whatever
value. Anyway, as long as several structures in the kernel are
statically allocated and sized as MAXCPU, it is suggested to keep it
as low as possible for the time being.
Technical notes on this commit itself:
- More functions to handle with cpuset_t objects are introduced.
The most notable are cpusetobj_ffs() (which calculates a ffs(3)
for a cpuset_t object), cpusetobj_strprint() (which prepares a string
representing a cpuset_t object) and cpusetobj_strscan() (which
creates a valid cpuset_t starting from a string representation).
- pc_cpumask and pc_other_cpus are target to be removed soon.
With the moving from cpumask_t to cpuset_t they are now inefficient
and not really useful. Anyway, for the time being, please note that
access to pcpu datas is protected by sched_pin() in order to avoid
migrating the CPU while reading more than one (possible) word
- Please note that size of cpuset_t objects may differ between kernel
and userland. While this is not directly related to the patch itself,
it is good to understand that concept and possibly use the patch
as a reference on how to deal with cpuset_t objects in userland, when
accessing kernland members.
- KTR_CPUMASK is changed and now is represented through a string, to be
set as the example reported in NOTES.
Please additively note that no MAXCPU is bumped in this patch, but
private testing has been done until to MAXCPU=128 on a real 8x8x2(htt)
machine (amd64).
Please note that the FreeBSD version is not yet bumped because of
the upcoming pcpu changes. However, note that this patch is not
targeted for MFC.
People to thank for the time spent on this patch:
- sbruno, pluknet and Nicholas Esborn (nick AT desert DOT net) tested
several revision of the patches and really helped in improving
stability of this work.
- marius fixed several bugs in the sparc64 implementation and reviewed
patches related to ktr.
- jeff and jhb discussed the basic approach followed.
- kib and marcel made targeted review on some specific part of the
patch.
- marius, art, nwhitehorn and andreast reviewed MD specific part of
the patch.
- marius, andreast, gonzo, nwhitehorn and jceel tested MD specific
implementations of the patch.
- Other people have made contributions on other patches that have been
already committed and have been listed separately.
Companies that should be mentioned for having participated at several
degrees:
- Yahoo! for having offered the machines used for testing on big
count of CPUs.
- The FreeBSD Foundation for having sponsored my devsummit attendance,
which has been instrumental.
- Sandvine for having offered offices and infrastructure during
development.
(I really hope I didn't forget anyone, if it happened I apologize in
advance).
Sync ng_nat with recent (r222806) ipfw_nat changes:
Make a behaviour of the libalias based in-kernel NAT a bit closer to
how natd(8) does work. natd(8) drops packets only when libalias returns
PKT_ALIAS_IGNORED and "deny_incoming" option is set, but ipfw_nat
always did drop packets that were not aliased, even if they should
not be aliased and just are going through.
Also add SCTP support: mark response packets to skip firewall processing.
Make a behaviour of the libalias based in-kernel NAT a bit closer to
how natd(8) does work. natd(8) drops packets only when libalias returns
PKT_ALIAS_IGNORED and "deny_incoming" option is set, but ipfw_nat
always did drop packets that were not aliased, even if they should
not be aliased and just are going through.
PR: kern/122109, kern/129093, kern/157379
Submitted by: Alexander V. Chernikov (previous version)
MFC after: 1 month
avg [Tue, 7 Jun 2011 06:18:02 +0000 (06:18 +0000)]
amdsbwd: update to support SB8xx southbridges
Many thanks to Tino <tinotom@gmail.com> for drawing my attention to
this, for doing a lot of testing and providing great feedback.
Many thanks to AMD for continuing to release public specifications for
their chipsets.
ken [Tue, 7 Jun 2011 05:04:37 +0000 (05:04 +0000)]
Set pca.p_bufr to NULL when we haven't allocated a buffer.
Otherwise, p_bufr is set to garbage on the stack, and if that garbage
happens to be non-NULL, and the TOLOG or TOCONS flag is set, putbuf()
will get called and attempt to fill the non-existent buffer.
This is really only relevant for tprintf() (and only when the priority is
not -1), but set it in uprintf() and ttyprintf() for completeness.
The next step, to avoid log buffer scrambling, would be to add the
PRINTF_BUFR_SIZE code to tprintf(), but this should prevent panics.
marcel [Tue, 7 Jun 2011 01:28:12 +0000 (01:28 +0000)]
Fix making kernel dumps from the debugger by creating a command
for it. Do not not expect a developer to call doadump(). Calling
doadump does not necessarily work when it's declared static. Nor
does it necessarily do what was intended in the context of text
dumps. The dump command always creates a core dump.
Move printing of error messages from doadump to the dump command,
now that we don't have to worry about being called from DDB.
marcel [Tue, 7 Jun 2011 00:39:15 +0000 (00:39 +0000)]
Add ia64_sync_icache() and use it to make the I-cache coherent
after loading the kernel's text segment. The kernel will do the
same for loaded modules, so don't worry about that.
jkim [Mon, 6 Jun 2011 23:03:37 +0000 (23:03 +0000)]
Validate INT 15h and 16h vectors more strictly. Traditionally these entry
points are fixed addresses and (U)EFI CSM specification also mandated that.
Unfortunately, (U)EFI CSM specification does not specifically mention this
is to call service routine via interrupt vector table or to jump directly
to the entry point. As a result, some CSM seems to install two routines
and acts differently, depending on how it was executed, unfortunately.
When INT 15h is used, it calls a function pointer (which is probably a UEFI
service function). When it jumps directly to the entry point, it executes
a simple and traditional INT 15h service routine. Therefore, actually there
are two possible fixes, i. e., this fix or jumping directly to the fixed
entry point. However, we chose this fix because a) keyboard typematic
support via BIOS is becoming extremely rarer and b) we cannot support random
service routine installed by a firmware or a boot loader. This should fix
Lenovo X220 laptop, specifically.
Unbreak kernels with non-default PCBGROUP included but no WITNESS.
Rather than including lock.h in in_pcbgroup.c in right order, fix it
for all consumers of in_pcb.h by further header file pollution under
#ifdef KERNEL.
hselasky [Mon, 6 Jun 2011 21:45:09 +0000 (21:45 +0000)]
Improve enumeration of Low- and Full-speed devices connected through a
High-speed USB HUB by resetting the transaction translator (TT)
before trying re-enumeration. Also when clear-stall fails multiple times
try a re-enumeration.
gjb [Mon, 6 Jun 2011 19:33:19 +0000 (19:33 +0000)]
Attempt to clear up some confusion in the following example, by stating
the '-c' argument is passed to the shell, not to su(1), which would
indicate the login class.
'su -m <user> -c <command>'
Submitted by: Warren Block <wblock@wonkity.com> (followup to 157078)
MFC after: 5 days
marcel [Mon, 6 Jun 2011 19:06:15 +0000 (19:06 +0000)]
Improve cpu_idle():
o cpu_idle_hook is expected to be called with interrupts
disabled and re-enables interrupts on return.
o sync with x86: don't idle when the CPU has runnable tasks
o have callers of ia64_call_pal_static() disable interrupts
and re-enable interrupts.
o add, but compile-out, support for idle mode. This will be
enabled at some later time, after proper testing.
Allow custom files to be opened and allow sorting by timestamp.
While implementing a tool to import lastlog entries into utmpx, I
noticed lastlogin doesn't allow custom database files to be opened. Add
a -f switch to support this. Also, add -r and -t similar to ls(1),
ruptime(1), etc. where you can sort entries by timestamp and reverse
them. This allows you to spot active/idle users more easily.
avg [Mon, 6 Jun 2011 14:23:13 +0000 (14:23 +0000)]
don't use cpuid level 4 in x86 cpu topology detection if it's not supported
This regression was introduced in r213323.
There are probably no Intel cpus that support amd64 mode, but do not
support cpuid level 4, but it's better to keep i386 and amd64 versions
of this code in sync.
jhb [Mon, 6 Jun 2011 13:21:11 +0000 (13:21 +0000)]
More properly handle Cardbus cards that that store their CIS in a BAR after
the recent changes to track BAR state explicitly. The code would now
attempt to add the same BAR twice in this case. Instead, change this so
that it recognizes this case and only adds it once and do not delete the
BAR outright after parsing the CIS.
gavin [Mon, 6 Jun 2011 13:13:48 +0000 (13:13 +0000)]
Document that REQUIRES, PROVIDES and KEYWORDS are alos accepted. This
chnage is different to the one suggested in the PR to try to avoid
cluttering the man page too much.
rwatson [Mon, 6 Jun 2011 12:55:02 +0000 (12:55 +0000)]
Implement a CPU-affine TCP and UDP connection lookup data structure,
struct inpcbgroup. pcbgroups, or "connection groups", supplement the
existing inpcbinfo connection hash table, which when pcbgroups are
enabled, might now be thought of more usefully as a per-protocol
4-tuple reservation table.
Connections are assigned to connection groups base on a hash of their
4-tuple; wildcard sockets require special handling, and are members
of all connection groups. During a connection lookup, a
per-connection group lock is employed rather than the global pcbinfo
lock. By aligning connection groups with input path processing,
connection groups take on an effective CPU affinity, especially when
aligned with RSS work placement (see a forthcoming commit for
details). This eliminates cache line migration associated with
global, protocol-layer data structures in steady state TCP and UDP
processing (with the exception of protocol-layer statistics; further
commit to follow).
Elements of this approach were inspired by Willman, Rixner, and Cox's
2006 USENIX paper, "An Evaluation of Network Stack Parallelization
Strategies in Modern Operating Systems". However, there are also
significant differences: we maintain the inpcb lock, rather than using
the connection group lock for per-connection state.
Likewise, the focus of this implementation is alignment with NIC
packet distribution strategies such as RSS, rather than pure software
strategies. Despite that focus, software distribution is supported
through the parallel netisr implementation, and works well in
configurations where the number of hardware threads is greater than
the number of NIC input queues, such as in the RMI XLR threaded MIPS
architecture.
Another important difference is the continued maintenance of existing
hash tables as "reservation tables" -- these are useful both to
distinguish the resource allocation aspect of protocol name management
and the more common-case lookup aspect. In configurations where
connection tables are aligned with hardware hashes, it is desirable to
use the traditional lookup tables for loopback or encapsulated traffic
rather than take the expense of hardware hashes that are hard to
implement efficiently in software (such as RSS Toeplitz).
Connection group support is enabled by compiling "options PCBGROUP"
into your kernel configuration; for the time being, this is an
experimental feature, and hence is not enabled by default.
Subject to the limited MFCability of change dependencies in inpcb,
and its change to the inpcbinfo init function signature, this change
in principle could be merged to FreeBSD 8.x.
Reviewed by: bz
Sponsored by: Juniper Networks, Inc.
hrs [Mon, 6 Jun 2011 03:06:43 +0000 (03:06 +0000)]
- Implement RDNSS and DNSSL options (RFC 6106, IPv6 Router Advertisement
Options for DNS Configuration) into rtadvd(8) and rtsold(8). DNS
information received by rtsold(8) will go to resolv.conf(5) by
resolvconf(8) script. This is based on work by J.R. Oldroyd (kern/156259)
but revised extensively[1].
- rtadvd(8) now supports "noifprefix" to disable gathering on-link prefixes
from interfaces when no "addr" is specified[2]. An entry in rtadvd.conf
with "noifprefix" + no "addr" generates an RA message with no prefix
information option.
- rtadvd(8) now supports RTM_IFANNOUNCE message to fix crashes when an
interface is added or removed.
- Correct bogus ND_OPT_ROUTE_INFO value to one in RFC 4191.
hrs [Mon, 6 Jun 2011 02:37:38 +0000 (02:37 +0000)]
- Make the code more proactively clear an ND6_IFF_IFDISABLED flag when
an explicit action for INET6 configuration happens. The changes are:
1. When an ND6 flag is changed via SIOCSIFINFO_FLAGS ioctl,
setting ND6_IFF_ACCEPT_RTADV and/or ND6_IFF_AUTO_LINKLOCAL now triggers
an attempt to clear the ND6_IFF_IFDISABLED flag.
2. When an AF_INET6 address is added successfully to an interface and
it is marked as ND6_IFF_IFDISABLED, an attempt to clear the
ND6_IFF_IFDISABLED happens.
This simplifies ND6_IFF_IFDISABLED flag manipulation by users via ifconfig(8);
in most cases manual configuration is no longer needed.
- When ND6_IFF_AUTO_LINKLOCAL is set and no link-local address is assigned to
an interface, SIOCSIFINFO_FLAGS ioctl now calls in6_ifattach() to configure
a link-local address.
This change ensures link-local address configuration when "ifconfig IF inet6"
command is invoked. For example, "ifconfig IF inet6 auto_linklocal" now
always try to configure an LL addr even if ND6_IFF_AUTO_LINKLOCAL is already
set to 1 (i.e. down/up cycle is no longer needed).
hrs [Mon, 6 Jun 2011 02:14:23 +0000 (02:14 +0000)]
- Accept Router Advertisement messages even when net.inet6.ip6.forwarding=1.
- A new per-interface knob IFF_ND6_NO_RADR and sysctl IPV6CTL_NO_RADR.
This controls if accepting a route in an RA message as the default route.
The default value for each interface can be set by net.inet6.ip6.no_radr.
The system wide default value is 0.
- A new sysctl: net.inet6.ip6.norbit_raif. This controls if setting R-bit in
NA on RA accepting interfaces. The default is 0 (R-bit is set based on
net.inet6.ip6.forwarding).
Background:
IPv6 host/router model suggests a router sends an RA and a host accepts it for
router discovery. Because of that, KAME implementation does not allow
accepting RAs when net.inet6.ip6.forwarding=1. Accepting RAs on a router can
make the routing table confused since it can change the default router
unintentionally.
However, in practice there are cases where we cannot distinguish a host from
a router clearly. For example, a customer edge router often works as a host
against the ISP, and as a router against the LAN at the same time. Another
example is a complex network configurations like an L2TP tunnel for IPv6
connection to Internet over an Ethernet link with another native IPv6 subnet.
In this case, the physical interface for the native IPv6 subnet works as a
host, and the pseudo-interface for L2TP works as the default IP forwarding
route.
Problem:
Disabling processing RA messages when net.inet6.ip6.forwarding=1 and
accepting them when net.inet6.ip6.forward=0 cause the following practical
issues:
- A router cannot perform SLAAC. It becomes a problem if a box has
multiple interfaces and you want to use SLAAC on some of them, for
example. A customer edge router for IPv6 Internet access service
using an IPv6-over-IPv6 tunnel sometimes needs SLAAC on the
physical interface for administration purpose; updating firmware
and so on (link-local addresses can be used there, but GUAs by
SLAAC are often used for scalability).
- When a host has multiple IPv6 interfaces and it receives multiple RAs on
them, controlling the default route is difficult. Router preferences
defined in RFC 4191 works only when the routers on the links are
under your control.
Details of Implementation Changes:
Router Advertisement messages will be accepted even when
net.inet6.ip6.forwarding=1. More precisely, the conditions are as
follow:
(ACCEPT_RTADV && !NO_RADR && !ip6.forwarding)
=> Normal RA processing on that interface. (as IPv6 host)
(ACCEPT_RTADV && (NO_RADR || ip6.forwarding))
=> Accept RA but add the router to the defroute list with
rtlifetime=0 unconditionally. This effectively prevents
from setting the received router address as the box's
default route.
(!ACCEPT_RTADV)
=> No RA processing on that interface.
ACCEPT_RTADV and NO_RADR are per-interface knob. In short, all interface
are classified as "RA-accepting" or not. An RA-accepting interface always
processes RA messages regardless of ip6.forwarding. The difference caused by
NO_RADR or ip6.forwarding is whether the RA source address is considered as
the default router or not.
R-bit in NA on the RA accepting interfaces is set based on
net.inet6.ip6.forwarding. While RFC 6204 W-1 rule (for CPE case) suggests
a router should disable the R-bit completely even when the box has
net.inet6.ip6.forwarding=1, I believe there is no technical reason with
doing so. This behavior can be set by a new sysctl net.inet6.ip6.norbit_raif
(the default is 0).
Usage:
# ifconfig fxp0 inet6 accept_rtadv
=> accept RA on fxp0
# ifconfig fxp0 inet6 accept_rtadv no_radr
=> accept RA on fxp0 but ignore default route information in it.
# sysctl net.inet6.ip6.norbit_no_radr=1
=> R-bit in NAs on RA accepting interfaces will always be set to 0.
marcel [Mon, 6 Jun 2011 01:52:15 +0000 (01:52 +0000)]
Fix ia64 ISO creation:
o boot/mfsroot.gz is no more. Copy it only when it exists so as still
to be compatible with Makefile.sysinstall.
o while here, make ispfw.ko optional as well.
o '-b bootimage' is not a valid argument for makefs. What was meant
was '-o bootimage'.
o create the boot image in the current directory so that makefs can
find the file. Previously it had to be created under $BASE because
that's how mkisofs wanted it.
mckusick [Sun, 5 Jun 2011 22:36:30 +0000 (22:36 +0000)]
Grammer fix in comment.
Eliminate one (of several) possible conflicting buffer locks when
trying to reclaim blocks. Rest of fix to be incorporated as part
of SUJ update by jeff.
rmacklem [Sun, 5 Jun 2011 20:22:56 +0000 (20:22 +0000)]
Add support for flock(2) locks to the new NFSv4 client. I think this
should be ok, since the client now delays NFSv4 Close operations
until VOP_INACTIVE()/VOP_RECLAIM(). As such, there should be no
risk that the NFSv4 Open is closed while an associated byte range lock
still exists.
rmacklem [Sun, 5 Jun 2011 18:17:37 +0000 (18:17 +0000)]
The new NFSv4 client was erroneously using "p" instead of
"p_leader" for the "id" for POSIX byte range locking. I think
this would only have affected processes created by rfork(2)
with the RFTHREAD flag specified. This patch fixes that by
passing the "id" down through the various functions from
nfs_advlock().
jilles [Sun, 5 Jun 2011 12:46:26 +0000 (12:46 +0000)]
sh: Add already working testcases for $? in here-document.
If the here-document is attached to a compound command or subshell, $?
already works properly. This is both a workaround for bin/41410 and a
requirement for a true fix for bin/41410.
rwatson [Sat, 4 Jun 2011 23:31:41 +0000 (23:31 +0000)]
Allocate four bits from the mbuf flags field to represent the hash
type of a software- or hardware-generated hash held in the
mbuf.m_pkthdr.flowid field, and provide accessor macros to easily
clear, set, receive, and test for hash values. Some of these
constants correspond to RSS hash types, but we don't want to limit
ourselves to that, as a number of other hashing techniques are in
use on hardware supported by FreeBSD.
Mark the M_FLOWID flag as deprecated; I hope to remove this before
9.0, changing drivers and the stack over to using the new
M_HASHTYPEBITS, most likely to use M_HASHTYPE_OPAQUE as we don't yet
want to nail down the KPI for RSS key/bucket management for device
drivers.
MFC after: 3 days
Reviewed by: bz
Sponsored by: Juniper Networks, Inc.
rwatson [Sat, 4 Jun 2011 16:33:06 +0000 (16:33 +0000)]
Add _mbuf() variants of various inpcb-related interfaces, including lookup,
hash install, etc. For now, these are arguments are unused, but as we add
RSS support, we will want to use hashes extracted from mbufs, rather than
manually calculated hashes of header fields, due to the expensive of the
software version of Toeplitz (and similar hashes).
Add notes that it would be nice to be able to pass mbufs into lookup
routines in pf(4), optimising firewall lookup in the same way, but the
code structure there doesn't facilitate that currently.
(In principle there is no reason this couldn't be MFCed -- the change
extends rather than modifies the KBI. However, it won't be useful without
other previous possibly less MFCable changes.)
Reviewed by: bz
Sponsored by: Juniper Networks, Inc.
rwatson [Sat, 4 Jun 2011 16:26:02 +0000 (16:26 +0000)]
IP divert sockets use their inpcbinfo for port reservation, although not
for lookup. I missed its call to in_pcbbind() when preparing previous
patches, which would lead to a lock assertion failure (although problem
not an actual race condition due to global pcbinfo locks providing
required synchronisation -- in this particular case only). This change
adds the missing locking of the pcbhash lock.
(Existing comments in the ipdivert code question the need for using the
global hash to manage the namespace, as really it's a simple port
namespace and not an address/port namespace. Also, although in_pcbbind
is used to manage reservations, the hash tables aren't used for lookup.
It might be a good idea to make them use hashed lookup, or to use a
different reservation scheme.)
rwatson [Sat, 4 Jun 2011 16:25:12 +0000 (16:25 +0000)]
Add a very simple IPDIVERT test, which creates IP divert sockets and
checks for collision/non-collision properties in binding them. This
test would have identified a bug recently reported on current@
involding my disaggregation of the pcbinfo lock.
It would be nice if this test also exercised packet diversion and
injection, but that is for another day.
MFC after: 3 days
Sponsored by: Juniper Networks, Inc.
sobomax [Sat, 4 Jun 2011 16:01:30 +0000 (16:01 +0000)]
Read from the socket using the same max buffer size as we use while
sending. What happens otherwise is that the sender splits all the
traffic into 32k chunks, while the receiver is waiting for the whole
packet. Then for a certain packet sizes, particularly 66607 bytes in
my case, the communication stucks to secondary is expecting to
read one chunk of 66607 bytes, while primary is sending two chunks
of 32768 bytes and third chunk of 1071. Probably due to TCP windowing
and buffering the final chunk gets stuck somewhere, so neither server
not client can make any progress.
This patch also protect from short reads, as according to the manual
page there are some cases when MSG_WAITALL can give less data than
expected.
bschmidt [Sat, 4 Jun 2011 15:05:32 +0000 (15:05 +0000)]
Certain adapters have HT40 support on some but not all channels. The
Intel 4965 devices for example have HT40 on 2GHz completely disabled
but it is still supported for 5GHz. To handle that in sta mode we
need to check if we can "upgrade" to a HT40 channel after the
association, if that is not possible but we are still announcing
support to the remote side we are left with a very flabby connection.
bschmidt [Sat, 4 Jun 2011 14:28:09 +0000 (14:28 +0000)]
Data frames sent over the mgmt path might be part of a TX aggr session
too. In that case don't fiddle with the seqno as drivers are supposed
to handle that.
Currently only the powersave feature does sent QoS-null-data frames
before and after a background scan which must be handled correctly. Due
to this being quite rare we don't fiddle around with starting of aggr
sessions.
bschmidt [Sat, 4 Jun 2011 11:43:09 +0000 (11:43 +0000)]
The firmware of 4965 series adapters seems to die while trying to send
probe requests at 1Mbps while being associated on a 5GHz channel. Sending
those at 6Mbps does work, so use that instead during a background scan.
This workaround allows us to re-enable background scan support for the
4965 adapters.
Also, just enabling one antenna on 5GHz results in better reception of
beacons:
test 00:26:5a:c6:14:1a 40 54M -71:-95 200 E WME HTCAP ATH
vs
test 00:26:5a:c6:14:1a 40 54M -92:-95 200 E WME HTCAP ATH
Due to roam:rssi thresholds set to 7 by default it might have been
impossible to associate to that network. While here use
IEEE80211_IS_CHAN_5GHZ() to determine the band.
andreast [Sat, 4 Jun 2011 09:23:54 +0000 (09:23 +0000)]
- Improve error handling.
- Add a retry loop for the i2c sensor reading.
- Check on busy status of the chip and on invalid values.
- Fix a typo in a comment.
- Replace the constant 2732 with the ZERO_C_TO_K macro.
imp [Sat, 4 Jun 2011 07:06:05 +0000 (07:06 +0000)]
Add support for True IDE mode to the Octeon CF driver. This mode is
signalled when the attribute address for the CF is 0 in the octeon
sysinfo structure. In this mode, the DATA port is 16-bits, but the
other ports are 8-bits, but on a 16-bit bus (so you have to access it
a short at a time, but only believe the lower byte). See the code for
more details on this slightly odd arrangement. I'm still not 100%
happy with the abstractions here on many levels (starting with the
globals for these settings, on down to no bus_space use, etc), but the
driver had these problems before the change.
Also, clean up the code a bit to make this support easier, and the
code a bit easier to read. I tried to follow existing style, but may
have missed a few spots. Add some comments.
Fix probe/attach routine to return a proper error for the simulator.
With this change, my EBH5200 eval board now recognizes the CF well
enough to boot to the login prompt. Before it would say it never
became ready. My CN3010-EVB-HS5 still boots properly. My older
CN3860-based board won't load the 64-bit kernel, either before or
after the change, and I didn't chase that down.
adrian [Sat, 4 Jun 2011 04:14:59 +0000 (04:14 +0000)]
A few changes to make radar detection implementable in a hal_dfs/
module.
* If sc->sc_dodfs is set to 1 by the ath_dfs_radar_enable(),
set the relevant rx filter bit to begin receiving radar PHY
errors. The HAL code already knows how to set the relevant
error mask register to enable radar events.
* Add a missing call to ath_dfs_radar_enable() after ath_hal_reset()
* change ath_dfs_process_phyerr() to take a const char *buf for now,
rather than a descriptor. This way it can get access to the packet
buffer contents.
nwhitehorn [Sat, 4 Jun 2011 04:00:40 +0000 (04:00 +0000)]
Retry the memory map-related portions of r222613, written by andreast,
after some minor tweaks and an increase in the early-boot stack space in
r222632.
nwhitehorn [Sat, 4 Jun 2011 03:22:16 +0000 (03:22 +0000)]
Fix a typo derived from a mismerge from mmu_oea that would cause
pmap_sync_icache() to sync random (possibly uncached or nonexisting!)
memory, causing kernel page faults or machine checks, most easily
triggered by using GDB. While here, add an additional safeguard to only
sync cacheable memory.
rmacklem [Sat, 4 Jun 2011 01:13:09 +0000 (01:13 +0000)]
Modify the new NFS server so that the NFSv3 Pathconf RPC
doesn't return an error when the underlying file system
lacks support for any of the four _PC_xxx values used, by
falling back to default values.
projects / FreeBSD / FreeBSD.git / log