none or if the file doesn't exist (there's no ntp.conf in the base install).
PR: conf/119592
Submitted by: Renaud Waldura <renaud+freebsd@waldura.org>
MFC after: 1 week
o correct mapping of CCK rates to PLCP; was using nonstandard Ralink
values which just happened to also be used by Zydas (so went unnoticed)
o change ieee80211_plcp2rate api to take a phy type instead of a flag
that indicates ofdm/!ofdm
o update drivers to match (restore per-driver code to map rate->PLCP)
Reviewed by: sephe, weongyo, thompsa
o add IEEE80211_C_STA capability to indicate sta mode is supported
(was previously assumed) and mark drivers as capable
o add ieee80211_opcap array to map an opmode to the equivalent capability bit
o move IEEE80211_C_OPMODE definition to where capabilities are defined so it's
clear it should be kept in sync (on future additions)
o check device capabilities in clone create before trying to create a vap;
this makes driver checks unneeded
o make error codes return on failed clone request unique
o temporarily add console printfs on clone request failures to aid in
debugging; these will move under DIAGNOSTIC or similar before release
Instead use the worldwide known MAX() function.
This should fix problems with negative values showing up on
dev.cpu.%d.temperature.
This is slightly different from the fix in the PR.
Submitted by: KOIE Hidetaka <hide at koie.org>
PR: 123542
used to request superpage alignment for the submap.
Request superpage alignment for the kmem_map.
Pass VMFS_ANY_SPACE instead of TRUE to vm_map_find(). (They are currently
equivalent but VMFS_ANY_SPACE is the new preferred spelling.)
Remove a stale comment from kmem_malloc().
support for VMFS_ALIGNED_SPACE, which requests the allocation of an
address range best suited to superpages. The old options TRUE and FALSE
are mapped to VMFS_ANY_SPACE and VMFS_NO_SPACE, so that there is no
immediate need to update all of vm_map_find(9)'s callers.
While I'm here, correct a misstatement about vm_map_find(9)'s return
values in the man page.
hand, it may cause other threads to sleep since kqueue_scan() may mark
some knotes as infux. This could lead to the deadlock.
Before kqueue_scan() sleeps, wakeup the threads that are waiting for the
influx knotes produced by this thread.
Tested by: pho (previous version)
Reviewed by: jmg
MFC after: 2 weeks
closed is the legitimate situation. For instance, filedescriptor with
registered events may be closed in parallel with closing the kqueue.
Properly handle the case instead of asserting that this cannot happen.
Reported and tested by: pho
Reviewed by: jmg
MFC after: 2 weeks
