of this micro-optimization occurs when we call pmap_enter() to wire an
already mapped page. Because of the micro-optimization, we fail to
mark the PTE as wired. Later, on teardown of the address space,
pmap_remove_pages() destroys the PTE before vm_fault_unwire() has
unwired the page. (pmap_remove_pages() is not supposed to destroy
wired PTEs. They are destroyed by a later call to pmap_remove().)
Thus, the page becomes lost.
Note: The page is not lost if the application called munlock(2), only
if it relies on teardown of the address space to unwire its pages.
For the historically inclined, this bug was introduced by a
megacommit, revision 1.182, roughly six years ago.
Leak observed by: green@ and dillon independently
Patch submitted by: dillon at backplane dot com
Reviewed by: tegge@
MFC after: 1 week
correct. Instead, check it against the possible settings (_PRS) when
the link is probed. This is important when using APIC mode but link
devices still have PIC mode settings. This is also what Linux does.
Additional prodding by: Len Brown len dot brown at intel dot com
the depth of the current file relative to the starting
point of the traversal is n. The usual +/- modifiers
to the argument apply.
- while I'm here, fix -maxdepth in the case of a depth-first
traversal
Print the top ten maintainers of python module ports
(works with p5-* too):
find /usr/ports -depth 2 \! -name 'py-*' -prune -o \
-depth 3 -name Makefile -execdir make -VMAINTAINER \; \
| sort | uniq -c | sort -nr | head
PR: 66667
Reviewed by: ru, joerg
Approved by: joerg
MFC after: 2 weeks
trying to exclude the top end of the range since it should hurt to overlap
by 4 bytes in the off-chance the RSDP signature appears incorrectly at the
very top of our search space.
based on the destination sleep state. Add a method to restore the old
state on resume. This is needed for the case of suspending to a very low
state disabling a GPE (i.e. S4), resuming, and then suspending to a higher
state (i.e. S3). This case should now keep the proper GPEs enabled.
device can wake the system. For example:
dev.root0.nexus0.acpi0.acpi_lid0.wake: 1
dev.root0.nexus0.acpi0.acpi_button0.wake: 1
dev.root0.nexus0.acpi0.pcib0.wake: 0
dev.root0.nexus0.acpi0.sio0.wake: 0
been developed for use with FreeBSD, version 4.8 and later.
Submitted by: Hema Joyce
Reviewed by: Prafulla Deuskar
Approved by: Prafulla Deuskar
MFC after: 1 week
there's no need to enable support for it separately
from 'tar.' (The call to enable gnutar support is
now just an alias for the tar support, left in to
avoid API breakage.)
subsystem lock to avoid tripping over an assertion regarding whether
the lock is held or not. This is likely to be the cause of a panic
tripped over by Andrea Campi.
the value for "unknown" 0xffffffff. The underlying kernel drivers should
be updated to only return 255 but the ABI is used by too many userland
utilities.
Also, make this WARNS 6 compatible.
acpi_wake_init:
Evaluate _PRW and set the GPE type
acpi_wake_set_enable:
Enable or disable a device's GPE.
acpi_wake_sleep_prep:
Perform any last-minute changes to the device to prepare it for
entering the given sleep state.
Also, walk the entire namespace when transitioning to a sleep state,
disabling any GPEs which aren't appropriate for the given state. Transition
acpi_lid and acpi_button to the new API.
This clears the way for non-ACPI-aware devices to wake the system (i.e.
modems) and fixes a problem where systems power up after shutdown when a
GPE is triggered.
empty file so if you accidently apply a patch created with diff -N
twice, you get files with duplicate contents.
Reported by: Antoine Brodin <antoine.brodin at laposte.net>
In particular, disabling it was likely to break configurations
involving ng_vlan(4) since the latter couldn't control
the parent's VLAN_MTU in the way vlan(4) did.
Pointed out by: ru
