things may happen in a parallel build - especially with rules like the
automatic size adjustment for SYMTAB_SPACE, see long standing failure of
evbarm on the build cluster.
Easy fix: .WAIT for each config to complete, before going on with the
next. Low impact, only minor loss of paralellism, and only in cases where
needed.
limits (often way too high) and skipping the test case if in doubt,
raise the limits as far as we can, and fix a few places in the test where
we could run into the limits and either skip or fail with a reasonable
message.
- cpu_load_pmap: use atomic kcpuset(9) operations; fixes rare crashes.
- Add kcpuset_copybits(9) and replace xen_kcpuset2bits(). Avoids incorrect
ncpu problem in early boot. Also, micro-optimises xen_mcast_invlpg() and
xen_mcast_tlbflush() routines.
Tested by chs@.
caches, merge together pool_drain_start() and pool_drain_end() into
bool pool_drain(struct pool **ppp);
"bool" value indicates whether reclaiming was fully done (true) or not (false)
"ppp" will contain a pointer to the pool that was drained (optional).
See http://mail-index.netbsd.org/tech-kern/2012/06/04/msg013287.html
context, re-enable the portion of code that allows invalidation of CPU-bound
pool caches.
Two reasons:
- CPU cached objects being invalidated, the probability of fetching an
obsolete object from the pool_cache(9) is greatly reduced. This speeds up
pool_cache_get() quite a bit as it does not have to keep destroying objects
until it finds an updated one when an invalidation is in progress.
- for situations where we have to ensure that no obsolete object remains
after a state transition (canonical example: pmap mappings between Xen VM
restoration), invalidating all pool_cache(9) is the safest way to go.
As it uses xcall(9) to broadcast the execution of pool_cache_transfer(),
pool_cache_invalidate() cannot be called from interrupt or softint context
(scheduling a xcall(9) can put a LWP to sleep).
pool_cache_xcall() => pool_cache_transfer() to reflect its use.
Invalidation being a costly process (1000s objects may be destroyed),
all places where pool_cache_invalidate() may be called from
interrupt/softint context will now get caught by the proper KASSERT(), and
fixed. Ping me when you see one.
Tested under i386 and amd64 by running ATF suite within 64MiB HVM
domains (tried triggering pgdaemon a few times).
No objection on tech-kern@.
XXX a similar fix has to be pulled up to NetBSD-6, but with a more
conservative approach.
See http://mail-index.netbsd.org/tech-kern/2012/05/29/msg013245.html
bytes. Newfs does large writes when initializing the filesystem.
First, don't copy the head of a TAILQ to make a copy - the first entry will
still point back to the original head. This caused the ccb list to link to
itself, resulting in a continous loop processing the same ccb and blocked
interrupts. Use TAILQ_CONCAT() to copy the list.
Next, the ccb disposition was not set in the ccb when the ccb was throttled,
losing the CCBDISP_SCSIPI, so when a throttled ccb was resent, it failed to
call scscipi_done(), and left that I/O hanging.
I am now able to newfs an iSCSI device, was well as issued large writes
using dd.
on the order they are passed in through xenstore. While this works for
hand-crafted Xen configuration files, it does not work for XenServer, XCP or
EC2 instances. This means that adding an extra virtual disk can make the
domU unbootable.
ID is actually based on the Linux device major/minor so this approach isn't
entirely correct (for instance, you can specify devices to be non-contiguous
which doesn't fit too well with our autoconf approach), but it works as a
first approximation.
Tested by me on XenServer and riz@ on EC2. OK bouyer@
This value seems to never have been used anywhere.
This makes it consistent with it's cousin p_vm_msize (which is in pages as
well and has several uses).
