#define clockframe somethingelse
to:
struct clockframe {
struct somethingelse cf_se;
};
and change access macros accordingly.
That means that, at least for that very issue, things will not go
ka-boomy if you don't have the actual definition of struct clockframe
before including systm.h.
host byte order (eventually the byte swapping could be wired in hardware, on
the 16 bit data bus). This was keept when wdc_exec_command() was created,
and as a result wdc_exec_command() is doing 16bit conversion to host byte
order. This is fine for IDENTIFY but doesn't work for other opaque data
structure, such as the ones for SMART.
So change wdc_exec_command() to do the conversion to host byte order only for
WDCC_IDENTIFY and ATAPI_IDENTIFY_DEVICE. This fixes atactl smart status
on big-endian hosts.
While here change __wdccommand_intr() to only use wdc_data{in,out}_pio, there
is no gain in doing the 32bit data port stuff locally.
comment.
All platforms will now send a change in direction, then the 32 MDO bits
when synchronising with the phy. Rather than sending the change in
direction with the first MDO bit.
bit 2 or 3. Thanks to Takeshi Nakayama for catching it.
(With this mistake the code was still working for the first channel, because
the reset of the second channel would disable/enable the first one).
is set to NULL, use the generic reset code.
Use this to work around a bug in some Acer IDE controllers (like the
one found in some sparc systems) where a controller disable/enable
is required after a reset to avoid data corruption when Ultra-DMA is
used. Workaround from opensolaris, thanks to Hiroki Sato for testing.
and net.bpf.peers sysctls respectively.
A new structure was added to describe the external (user viewable)
representation of a BPF file; a new entry was added to the bpf_d
structure to store the PID of the calling process; a simple_lock was added
to protect the insert/removal from the net.bpf.peers sysctl handler.
This idea came from FreeBSD (Christian S.J. Peron) but while it is
implemented with sysctl's it differs a bit.
Reviewed by: christos@ and atatat@ (who gave me the tip for the net.bpf.peers
sysctl helper function).
Contrast control is different but similar enough, so refactor the code
to support both. Tested by Christer Andersson.
XXX: platid_mask_MACH_HP_LX also matches 360LX. It's not confirmed
whether touch panel in 360LX is connected in the same way. We may
need to regroup platid masks.
the decapsulator dispatch changes in 2001. Problems found and fixed
by Christine Jones of BBN. Specifically:
Check for a packet's protocol to be ENCAP_PROTO, not AF_INET.
Remove one-back cache for last vif, because vif_encapcheck is called
for each vif, rather than being expected to find the appropriate vif.
The cache usage caused packets to be input on the wrong vif and hence
usually dropped.
In vif_encapcheck, verify the local source as well. While mrouted
endeavors not to create multiple tunnels with a peer, a packet
arriving with the wrong local address is still wrong and should not be
accepted. (This is a correctness nit, not a security issue.) Order
checks to fail quickly for packets being checked to see if they match
a vif other than the one they belong on (essentially, check peer
source address in outer header first).
Claim 69 bits of match (32 each from outer src/dst and 5 from checking
that inner dst is within 224/5). This should result in the vif having
a higher priority for multicast packets compared to a parallel gif(4)
tunnel, and that both seems appropriate if both are configured and
seems to match the semantics expected by the decapsulator dispatch
machinery.
(These changes were made in 2.99.15 and about a dozen nodes are
running them with many vifs. ip_mroute.c has not changed
significantly since then (February 2005) and the changes applied
cleanly to current and compile cleanly.)
firmware likes to put PCI memory resources into this range, notably a Rage
IIc which puts the 2nd register aperture to 0x2000.
This should allow a few graphics chips to work with XFree86 which previously
failed with something like this:
(WW) ATI: PCI/AGP Mach64 in slot 2:5:0 could not be detected!
No devices to configure. Configuration failed.
Thanks to Florian Stoehr for doing most of the work tracking this down.
- Don't initialise ic_phytype twice and do initialise ic_state.
- announce available rates.
- mark interface down if firmware crashes for the radio transmitter
gets turned off.
making the mapping not cacheable, and only allow caching if the relevant
flag is passed in.
This doesn't seem to fix, or break anything, but it matches the expected
bus space API.
For example, this used to give false logs of matching fingerprint for
foo.sh while foo.sh don't have an entry, and the program executed (and
matching the fingerprint) is the interpreter - /bin/sh.
IPIs in the MULTIPROCESSOR case. Adjust all callers.
- In fpusave_cpu(), block IPIs for the entire duration (while we have
CPUF_FPUSAVE set in ci_flags) to fix the deadlock that leads to
"panic: fpsave ipi didn't", as described in PR port-alpha/26383.
Many thanks to Michael Hitch for the analysis and initial patch which
this one is derived from.
to use.
Also, add sysctl helper macro SYSCTL_PFX_INT (for SampleRate) that
prepends an arbitrary prefix to the sysctl name, instead of sc->sc_
like SYSCTL_INT. Factor with SYSCTL_INT.
and antenna diversity:
Check the hardware capabilities---transmit power control (TPC),
antenna diversity---before setting up the sysctls that control
those capabilities. Previously, the TPC and ant. diversity sysctls
were not setup because ath_sysctlattach was called before sc_hastpc
and sc_hasdiversity were initialized, so users could not view/control
antenna diversity or TPC settings, even on hardware with those
capabilities.
Obey the user's transmit-antenna selection even when sending IBSS
beacons on hardware with VEOL capability; for all other hardware/modes,
only switch transmit antennas after every four beacons if the user
has not selected a transmit antenna---i.e., they chose antenna 1
or 2 instead of 0 ("auto").
as I thought. The latter actually sets the station listen interval.
We cannot get/set "drop-unencrypted" and "privacy" properties
independently with SIOCS80211NWKEY, so put back IEEE80211_IOC_PRIVACY
and IEEE80211_IOC_DROPUNENCRYPTED.
Thanks Sam Leffler for pointing out my mistakes.
compile support for the duplicate ioctls from FreeBSD if it is a
COMPAT_FREEBSD kernel:
IEEE80211_IOC_SSID
IEEE80211_IOC_WEPTXKEY
IEEE80211_IOC_CHANNEL
IEEE80211_IOC_PRIVACY
IEEE80211_IOC_DROPUNENCRYPTED
IEEE80211_IOC_BSSID
IEEE80211_IOC_BEACON_INTERVAL
IEEE80211_IOC_WEPKEY
in NetBSD 2.0:
* If 2.x compatibility is enabled (#ifdef COMPAT_20),
compile support for OSIOCG80211STATS and OSIOCG80211ZSTATS,
with the same ioctl numbers as SIOCG80211STATS and
SIOCG80211ZSTATS in 2.x. OSIOCG80211STATS and
OSIOCG80211ZSTATS return an ieee80211_ostats struct,
which has the same layout as ieee80211_stats in 2.x.
* Add new ioctl numbers for SIOCG80211STATS and SIOCG80211ZSTATS.
Both these ioctls will copy at most ifr_buflen bytes of
the new ieee80211_stats to ifr_buf.
and size of a userland buffer. The kernel shall not copyout more
than ifr_buflen bytes to ifr_buf. For future ioctls that use
ifr_buf and ifr_buflen instead of ifr_data, the kernel can return
a larger struct in the future than when the ioctl is introduced,
without breaking ABI compatibility, provided that the size, order,
and semantics of the fields at the front of the struct does not
change.
it in pmap_create(), and freeing the lev1map in pmap_destroy(). This
means that pm_lev1map is consistent for the life of the pmap.
2. pmap_extract() now uses vtophys() for the kernel pmap. This avoids
having to lock the kernel pmap, since kernel PT pages are never freed.
3. Because of (1), pmap_asn_alloc() no longer needs to operate on a locked
pmap; pm_lev1map will never change over the life of the pmap, and all
other access to the pmap is done in per-CPU fields or with atomic
operations.
4. Because of (3), pmap_activate() no longer needs to lock the pmap
to do its work, thus eliminating the deadlock with sched_lock described
in PR port-alpha/25599. This is safe because we are guaranteed that
the pmap is still alive, since by definition an LWP that uses that it
is about to run.
Thanks to Michael Hitch for the analysis, and Michael and Ragge for testing.