connect madvise(2) and mincore(2) - apparently the newer Linux libs
don't stub it anymore, so allow the application to take advantage
of them
the Linux calls appear to be compatible in the flag values and semantics,
so a wrapper is not necessary
don't stub it anymore, so allow the application to take advantage
of them
the Linux calls appear to be compatible in the flag values and semantics,
so a wrapper is not necessary
than two days backward (same as old behaviour) or more than two years
forward. I have lots of test machines I don't power on every two days.
XXX - this should be handled more consistent across the different
ports. While here, move the default time -- in the unlikely event that
we have neither rtc nor file system time -- to this millenium.
Use this to reset the channel before doing a dump, instead of the hack in
wdc_exec_xfer() based on C_POLL. This hack was causing problems on
controllers with a shared queue, because we now can have C_POLL set during
concurent channels probes (problem found and analysed on sparc64 by
Martin Husemann).
This should even make core dumps marginally more reliable on ATA drives.
freebsd drivers for the same. if found and supported, export a
"machdep.speedstep_state" sysctl that can be set to "0" (low) or "1"
(high).
tested on a dell inspiron 8500 (supported, working) and a dual P4
system (supports ichlpcib not speedstep, comes up properly disabled.)
the background. The problem was exposed when setting a non-black color
as the background, as the shift did not produce the expected fill value
(for black it worked because 0 is black).
completely. In particular, accept them in monitor mode (where we generally
aren't doing anything unless we're in promiscuous mode anyway) and host-AP
mode (where we want to see neighbor APs).
WSDISPLAY_BORDER_COLOR option, broken by a last-minute change.
Pointed out by xtraeme@.
Also back out the previous change by dogcow@, which was an attempt
to fix kernel builds that didn't define WSDISPLAY_CUSTOM_BORDER;
shouldn't be needed now. (Problem also introduced by the same
last-minute change; sorry).
at the moment.
This includes the addition of two new wsdisplay ioctls, WSDISPLAY_{G,S}BORDER,
one to get the actual color and one to set it, respectively. Possible colors
match those defined by ANSI (and listed in wsdisplayvar.h).
It also adds two accessops to the underlying graphics device, getborder and
setborder, which mach their ioctl counterparts.
Two kernel options are added: WSDISPLAY_CUSTOM_BORDER, which enables the
ioctls described above (to customize the border color from userland after
boot), and WSDISPLAY_BORDER_COLOR, which sets the color at boot time.
The former is enabled by default on the GENERIC kernel, but not on INSTALL
(among others). The later is always commented out, leaving the usual black
border as a default.
wsconsctl is modified to allow accessing this value easily. For example,
'wsconsctl -d -w border=blue'.
ieee80211_input():
* Do not discard management frames in station mode just because they have
the wrong BSSID.
* Do not discard beacons in station and host-AP mode when not scanning.
* Some minor rearrangement. Update node statistics even if the packet is
rejected.
ieee80211_recv_mgmt():
* Accept probe responses and beacons in station and host-AP even when not
scanning.
* Do not immediately free the node created by a beacon or probe response.
XXX Should I check BSSIDs more carefully in ieee80211_recv_mgmt() --
specifically for ASSOC_RESP, REASSOC_RESP, AUTH, DEAUTH and DISASSOC?
Fix a problem with APs that advertise multiple SSIDs:
Change the footprint of ieee80211_find_node_with_channel() to take a SSID as
well, and, if not empty, compared it with the existing nodes. This causes
us to allocate multiple nodes for the same AP. Without this we were only
leaving one SSID in the node table, which might not be the desired one, and
so the interface would fail to fully initialize. (Reported by he@ with a
Cisco 350 AP.)
tacha