AcpiOsMapMemory()/AcpiOsUnmapMemory() (-> pmap_mapbios()/pmap_unmapbios())
for AcpiOsReadMemory() and AcpiOsWriteMemory(). Although they do not sound
too obvious, these functions are exclusively used to access memory mapped
IO in ACPICA.
MACHINE_CPUARCH isn't defined. I believe that this will cover all
options.
I didn't define it in kern.mk because $M is set to MACHINE_CPUARCH and
then is expanded for the genassym.o rule in kern.post.mk and kern.mk
is included after this, so the expansion isn't quite right. I think
this is a bug in make, but don't have the time to track it to ground
(and even if I did, fixing it would require a MFC of the change to the
very old systems we're targetting with this fix).
According to ACPICA User Guide and Programmer Reference, the read data must
be zero extended to fill the 64-bit return value even if the bit width of
the location is less than 64.
- Return error when 64-bit access is requested as we do not support 64-bit
PCI register access (yet). XXX We may have to split it up into two 32-bit
accesses if it is really required.
to avoid sending multiple ACCESS/GETATTR RPCs during a single open()
between VOP_LOOKUP() and VOP_OPEN(). Now we always send the RPC in
VOP_LOOKUP() and not VOP_OPEN() in the cases that multiple RPCs could be
sent.
MFC after: 2 weeks
Move attribute cache flushes from VOP_OPEN() to VOP_LOOKUP() to provide
more graceful recovery for stale filehandles and eliminate the need for
conditionally clearing the attribute cache in the !NMODIFIED case in
VOP_OPEN().
Reviewed by: rmacklem
MFC after: 2 weeks
Remove the internal jailparam_vlist, in favor of using variants of its
logic separately in jail_setv and jail_getv.
Free the temporary parameter list and exported values in jail_setv
and jail_getv.
Noted by: Stanislav Uzunchev
MFC after: 3 days
According to ACPICA User Guide and Programmer Reference, the read data must
be zero extended to fill the 32-bit return value even if the bit width of
the port is less than 32.
- Remove 64-bit read/write from AcpiOsReadMemory() and AcpiOsWriteMemory().
These functions do not support 64-bit access (yet). Clean up style nits
and unnecessary bit masking while I am here.
Reported by: Liu, Jinsong (jinsong dot liu at intel dot com) via
Lin Ming (ming dot m dot lin at intel dot com) [1]
instead of calling pmap_invalidate_page() for each PG_G mapping, call
pmap_invalidate_range() for each range of PG_G mappings. In addition,
eliminate a redundant call to pmap_invalidate_page(). Both
pmap_remove_pte() and pmap_remove_page() called pmap_invalidate_page()
when the mapping had the PG_G attribute. Now, only pmap_remove_page()
calls pmap_invalidate_page(). Altogether, these changes eliminate 53%
of the TLB shootdowns for a "buildworld" on a ZFS file system. On
FFS, the reduction is 3%.
MFC after: 6 weeks
- The 6000 series WiMAX devices need a separate firmware.
- The b-gen devices are not hooked because the hardware revision type
is not know.
Obtained from: OpenBSD
MFC after: 1 week
emulation of misaligned memory accesses). We cannot map the unaligned
memory access functions to the ones used for aligned accesses, so do
not define TUKLIB_FAST_UNALIGNED_ACCESS.
released a reference count on nfsv4rootfs_lock erroneously when
administrative revocation of state was done.
Submitted by: zack.kirsch at isilon.com
MFC after: 2 weeks
Move inappropriate stuff in cpu.h elsewhere:
{s,g}et_intr_mask -> md_var.h
num_tlbentries -> tlb.h
Remove #define clockframe trapframe and fix clock, which was the only place
this was used.
All the rest of this stuff was unused.
# we're not quite minimal yet, since we duplicate a few status register things
# here...
Inspired by: bde@
used on powerpc64 as well (build scripts, for instance), and the MFS root
must be adjusted upward on powerpc64 as well.
This doesn't completely solve things: sysinstall stil needs some
persuasion to deal with a default kernel named GENERIC64.
