"minorversion", since that is what Linux uses.
causing a build breakage is interesting to say the least.
.. so that consistent compilation algorithms are used for both architectures as in practice the binaries are expected to be interchangeable (for time being). Previously i386 used default setting which were equivalent to -march=i486 -mtune=generic. The only difference is using smaller but slower "leave" instructions. Discussed with: jhb, dim MFC after: 29 days
aligned and only except 4K deletes (TRIM). PR: kern/169974 Submitted by: Steven Hartland <firstname.lastname@example.org> Tested by: ak Reviewed by: mav Approved by: cperciva (implicit) MFC after: 1 week
…stall instead of pkg_add
output and replace it with a new visible sysctl kern.ipc.acceptqueue of the same functionality. It specifies the maximum length of the accept queue on a listen socket. The old kern.ipc.somaxconn remains available for reading and writing for compatibility reasons so that existing programs, scripts and configurations continue to work. There no plans to ever remove the orginal and now hidden kern.ipc.somaxconn.
The reason for this is that the SPARC v9 architecture allows nested interrupts of higher priority/level than that of the current interrupt to occur (and we can't just entirely bypass this model, also, at least for tick interrupts, this also wouldn't be wise). However, when a preemption interrupt interrupts another interrupt of lower priority, f.e. PIL_ITHREAD, and that one in turn is nested by a third interrupt, f.e. PIL_TICK, with SCHED_ULE the execution of interrupts higher than PIL_PREEMPT may be migrated to another CPU. In particular, tl1_ret(), which is responsible for restoring the state of the CPU prior to entry to the interrupt based on the (also migrated) trap frame, then is run on a CPU which actually didn't receive the interrupt in question, causing an inappropriate processor interrupt level to be "restored". In turn, this causes interrupts of the first level, i.e. PIL_ITHREAD in the above scenario, to be blocked on the target of the migration until the correct PIL happens to be restored again on that CPU again. Making PIL_PREEMPT the lowest real priority, this effectively prevents this scenario from happening, as preemption interrupts no longer can interrupt any other interrupt besides stray ones (which is no issue). Thanks to attilio@ and especially mav@ for helping me to understand this problem at the 201208DevSummit. - Give PIL_STOP (which is also used for IPI_STOP_HARD, given that there's no real equivalent to NMIs on SPARC v9) the highest possible priority just below the hardwired PIL_TICK, so it has a chance to interrupt more things. MFC after: 1 week
and move it together into one place.
In addition to adding missing `static' keywords: - bin/dd: Pull in `extern.h' to guarantee consistency with source file. - libexec/rpc.rusersd: Move shared globals into an extern.h. - libexec/talkd: Move `debug' and `hostname' into extern.h. - usr.bin/cksum: Put counters in extern.h, as they are used by ckdist/mtree. - usr.bin/m4: Move `end_result' into extern.h. - usr.sbin/services_mkdb: Move shared globals into an extern.h.
…ile more closely. Prodded by: ed
- adds a couple more library strings used in the tree - changes some more to the current groff spelling - changes page footer to match groff style
... otherwise the current thread might be holding ARC locks and thus run into a deadlock. This happens, for example, when a thread does memory allocation in the ARC code and runs into KVA shortage. Also, it really makes the most sense to wait in pageproc, so that the results of ARC reclamation are seen before the page cache is acted upon. In other cases where vm_lowmem is invoked, e.g. on KVA space shortage, the callers perform multiple attempts (up to 8) and wait for rather long intervals between them (up to 4 seconds), so ARC reclaim results should become visible even without explicit waiting on the ARC thread. Note that this is not a critical issue for typical ZFS usages where KVA space should already be large enough. On amd64 systems setting KVA size to twice the physical memory size is known to mitigate KVA fragmentation issues in practice. Side note: perhaps vm_lowmem 'how' parameter should be used to differentiate between causes of the event. Reported by: Nikolay Denev <email@example.com> MFC after: 19 days
Based on prodding and a submission by Lars Engels <firstname.lastname@example.org>. MFC after: 5 days
power of two. - Mention the run time mask is set to block any tracing by default. Reviewed by: jhb
arguments for the NFSv4.1 LayoutCommit operation. As such, only one LayoutCommit is required for all layouts for a file. This allowed the code to be simplified.
changes to reflect differences in computation between the two.
double version, with adaptations for the differences between it and the float version.
…ile glue. It's not yet connected to the build.
PR: kern/172833 Submitted by: "Charles O'Donnell" <cao bus net> MFC after: 1 week
1. Have the resulting C file depend on the resulting H file as it should be. Touch the C file to make sure the C file is newer than the H file to keep make happy. 2. Apply the same fix to the other instance of .ORDER, missed in the previous commit.
make) ended up being built with -DFORCE_MACHINE. This broke the lib32 built for amd64 & powerpc64. This fix is comes with the next import of bmake, but is committed here and now to minimize the exposure to the bug. Submitted by: Simon Gerraty <email@example.com>
The check for a NULL return was already in place so I assume this was just an oversight.
parent adapter's _DOD list, only check the low 16 bits of both _ADR and _DOD. The language in the ACPI spec seems to indicate that the _ADR values should exactly match the entries in _DOD. However, I assume that the masking added to _DOD values was added to work around some known busted machines (the commit history doesn't indicate either way), and the ACPI spec does require that the low 16 bits are unique for all video outputs, so only check the low 16 bits should be fine. This fixes recognition of video outputs that use the new standardized device ID scheme in ACPI 3.0 that set bit 31 such as certain Dell laptops. Tested by: Juergen Lock nox jelal kn-bremen de MFC after: 3 days