faults.
First, for accesses to direct map region should check for the limit by
which direct map is instantiated.
Second, for accesses to the kernel map, success returned from the
kernacc(9) does not guarantee that consequent attempt to read or write
to the checked address succeed, since other thread might invalidate
the address meantime. Add a new thread private flag TDP_DEVMEMIO,
which instructs vm_fault() to return error when fault happens on the
MAP_ENTRY_NOFAULT entry, instead of panicing. The trap handler would
then see a page fault from access, and recover in normal way, making
/dev/mem access safer.
Remove GIANT_REQUIRED from the amd64 memrw(), since it is not needed
and having Giant locked does not solve issues for amd64.
Note that at least the second issue exists on other architectures, and
requires similar patching for md code.
Reported and tested by: clusteradm (gjb, sbruno)
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
when MBR contains only PMBR entry or it is bootcamp-compatible.
If MBR has PMBR entry and some other, the loader rejects it.
Make these checks to be less strict. If loader decided that PMBR
isn't suitable for GPT, it will use MBR.
Reported by: Paul Thornton
Tested by: Paul Thornton
MFC after: 1 week
This appears to fix a strange condition with X on 32-bit PowerBooks I observed,
caused by one of these bits getting set in the mcontext, but not set in the
thread, which may be a symptom of another problem, more difficult to diagnose.
Since these bits aren't exported anyway, this change makes it more explicit that
the bits aren't MSR-related in SRR1.
MFC after: 3 weeks
ext2fs: minor update to the dirpref policy.
The change in UFS r254996, reverted the change as the
older code seems to work better. This was not visible
in local testing but we can trust UFS is vastly more
exercised in diferent environments.
These are needed to diagnose TX hangs that I and hiren are seeing.
Without it, the only way we'll see debugging is by having ATH_DEBUG_SW_TX
enabled and that is going to be very, very spammy.
ATH_DEBUG_RESET is fine; it's only going to be done during stuck beacon
situations in AP mode.
Whilst I'm here, and now that it's behind debugging, let's just disable
the "print only one" conditional. I'll eventually make it more tunable.
Tested:
* AR9220, hostap mode.
Bring in a minor change to the dirpref policy based on r248623.
This is pretty minimal change to keep the implementation in
sync with UFS but other parts from the original change are not
directly applicable so don't expect improvements in fsck times.
MFC after: 2 weeks
create character devices. The deadlock can happen if an application is
issuing IOCTLs which require USB refcounting, at the same time the USB
device is detaching.
There is already a counter in place in the USB device structure to
detect this situation, but it was not always checked ahead of invoking
functions that might destroy character devices, like detach, set
configuration, set alternate interface or detach active kernel driver.
Reported by: Daniel O'Connor <doconnor@gsoft.com.au>
MFC after: 1 week
device is asleep.
This doesn't avoid logging errors for things that are actually OK to
access whilst the chip is asleep (eg, the RTC registers (0x7000->0x70ff
on the AR5416 and later.)
But, this is a pretty good indicator if things are accessed incorrectly.
Tested:
* AR5416, STA
This way the state changes from sleep->awake before the registers are poked
and from awake->sleep after the registers are poked.
This way spurious warnings aren't printed by my (to be committed)
debugging code.
Tested:
* AR5416, STA
Yes, this means that sc_invalid is slightly racy, but there are other
issues here which need fixing.
This fixes a source of eventual LORs - ath_init() grabs ATH_LOCK to do
work and releases it before it calls ieee80211_start_all().
ieee80211_start_all() will grab the net80211 comlock to iterate over
the VAPs.
TODO:
* .. I should just migrate the ieee80211_start_all() work to a
deferred task so it can be done later; it doesn't have to be
immediately done.
Tested:
* AR5416, STA mode
1. move unmapped_buf_allowed to machdep.c.
2. map both pmap_mapbios() and pmap_mapdev() to pmap_mapdev_attr()
and have the actual work done by pmap_mapdev_priv() (renamed from
pmap_mapdev()). Use pmap_mapdev_priv() to map the I/O port space
because we can't use CTR() that early.
3. add pmap_pinit_common() that's used by both pmap_pinit0() and
pmap_pinit(). Previously pmap_pinit0() would call pmap_pinit(),
but that would create 2 KTR events. While here, use pmap_t instead
of "struct pmap *".
4. fix pmap_kenter() to use vm_paddr_t as the type for the physical.
5. various white-space adjustments for consistency.
6. use C99 and KNF for function definitions where appropriate.
7. slightly re-order prototypes and defines in <machine/pmap.h>
No functional change (other than the creation of KTR_PMAP events).
Also, remove the expression which calculated the location of the
strings for a new image and grown over the time to be
non-comprehensible. Instead, calculate the offsets by steps, which
also makes fixing the alignments much cleaner.
Reported and reviewed by: alc
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
ifi_oqdrops. This is a temporary workaround until ifqueue(9) vanishes.
While here, remove the pointless ifi_vhid assignment. It has
sense only when we are exporting ifaddrs, not ifnets.
Sponsored by: Netflix
Sponsored by: Nginx, Inc.
called with interrupts enabled. Calling fasttrap_pid_probe() with interrupts
disabled can lead to deadlock if fasttrap writes to the process' address
space.
Reviewed by: rpaulo
MFC after: 3 weeks
then threads can sleep on the pip condition.
Avoid to deadlock such threads by correctly awakening the sleeping ones
after the pip is finished.
swapoff side of the bug can likely result in shutdown deadlocks.
Sponsored by: EMC / Isilon Storage Division
Reported by: pho, pluknet
Tested by: pho
1. Name the kernel option XTRACE instead of EXCEPTION_TRACING
2. Put support functions in ia64/ia64/xtrace.c
3. Make it work with SMP by giving each CPU its own buffer
4. Save 16 key registers in the buffer for every exception
5. In ia64_handle_intr() and trap() transfer the trace record
to the KTR trace buffer using CTRx() and with some basic
information for now
6. Use a tunable to anble tracing and stop tracing as soon as
we enter the debugger
Room for improvements:
1. Transferring exception-relevant information to KTR
2. Add a sysctl to enable/disable tracing
- Retire long time unused (basically always unused) sys__umtx_lock()
and sys__umtx_unlock() syscalls
- struct umtx and their supporting definitions
- UMUTEX_ERROR_CHECK flag
- Retire UMTX_OP_LOCK/UMTX_OP_UNLOCK from _umtx_op() syscall
__FreeBSD_version is not bumped yet because it is expected that further
breakages to the umtx interface will follow up in the next days.
However there will be a final bump when necessary.
Sponsored by: EMC / Isilon storage division
Reviewed by: jhb
- More flexible cluster size selection, including the ability to fall
back to a safe cluster size (PAGE_SIZE from zone_jumbop by default) in
case an allocation of a larger size fails.
- A single get_fl_payload() function that assembles the payload into an
mbuf chain for any kind of freelist. This replaces two variants: one
for freelists with buffer packing enabled and another for those without.
- Buffer packing with any sized cluster. It was limited to 4K clusters
only before this change.
- Enable buffer packing for TOE rx queues as well.
- Statistics and tunables to go with all these changes. The driver's
man page will be updated separately.
MFC after: 5 weeks
bridge takes ownership of the transaction, so bsf of the requester is
the bridge and not a device behind it. As result, code needs to walk
the hierarchy up to use correct context.
Note that PCIe->PCI-X bridges are not handled quite correctly since
such bridges are allowed to only take ownership of some transactions.
Also, weird but unrealistic cases of PCIe behind PCI bus are also not
handled.
Still, the patch provides significant step forward for the bridge
handling.
Submitted by: Jason Harmening <jason.harmening@gmail.com>
MFC after: 1 week
table. Among them, some (old AMI ?) BIOSes report entries with range
like (bf7ec000, bf7ebfff). Attempts to ignore the bogus entries
result in faults, so the range must be covered somehow.
Provide a workaround by identity mapping the 32 pages after the bogus
entry start, which seems to be enough for the reported BIOS.
Reported and tested by: Jason Harmening <jason.harmening@gmail.com>
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
mbuf should be owned by if_transmit function in any case.
Submitted-by: Andrew Rybchenko <Andrew.Rybchenko at oktetlabs.ru>
Sponsored by: Solarflare Communications, Inc.
