definitions from ppbreg.h and move some definitions from ppbreg.h to
pcireg.h.
- Change fast back-to-back "capable" to "enable" in pci_subr.c.
- Print Primary Discard Timer, Secondary Discard Timer, Discard Timer Status
and Discard Timer SERR# Enable bit in pci_subr.c.
- PCI_BRIDGE_PREFETCHBASE32_REG and PCI_BRIDGE_PREFETCHLIMIT32_REG are
"upper" 32bit registers, rename to *UP32_REG to avoid confusion.
- Use macro.
duplicate symbols on netbsd. see PR#54027.
with this disabled, turn on using the symver-config.h for the
gnu.ver processing so that other defines are handled.
fix some depends for gnu.ver processing.
with an IQ that underflows when one attempts to enter it as an
unnormalised 160 bit long long double...
Whoever would believe that (~0 & anything) was a meaningful thing
to write? And three times in one #define. That could not possibly
have been me, could it?
Simplify, simplify, simplify. NFC.
to allow bash to build fdflags on Solaris 10, here are some mods that
fix that, and some other similar issues in the NetBSD version of fdflags.
The bash implementation of fdflags is based upon the one Christos did for
the NetBSD sh, so the issues are similar ... the NetBSD sh cannot yet
(easily anyway) build on anything except NetBSD, so this change makes
no current difference at all (just adds some compile time tests (#ifdef)
which always work out the way things did before, when built on NetBSD).
However, there is no system on which any modern shell can hope to work
which does not support close on exec, or fcntl(F_SETFD,...) to set it.
The O_CLOEXEC and FD_CLOEXEC definitions might not exist, but close on
exec can still be manipulated. Since the primary rationale for
the fdflags builtin was to be able to manipulate that state bit from
scripts, it would be annoying to lose that one, and keep all the (less
important) others, just because O_CLOEXEC is not defined, so do the
fix (workaround) a different way than was done in the bash patch.
Further, more than fdflags() will fail if O_CLOEXEC is not defined,
so handle that as well.
Also fix another oddity ... (noticed by reading the code) - if
fcntl(F_GETFL,...) returned any bits set that we don't understand,
the code was supposed to simply print their values as a hex constant,
when fdflags is run with -v. However, the getflags() function was
clearing all bits that the code did not know about ... so there is
no way any unknown bit could ever make it out to be printed. Handle
that a different way - instead of clearing unknown bits, clear any
bits that get returned which we understand, but do not want to deal
with (stuff like O_WRONLY, which should not be returned from the
fcntl(), but who knows...) Leave any unknown bits that happen to be
set, set, so that printone() can display them if appropriate.
(This is most likely to happen when running an older shell on a new
kernel where the kernel supports some new flag that the shell has
not been taught to understand).
NFCI that anyone should notice anytime soon.
(how many more builds will i find like this? the end result
is that i think we should generate the ./usr/include/$MACHINE
entry, i think, but i have to survey many ports.)
per-user basis not a per-process. We cannot really keep track on
a per-process basis because a parent process can create the semaphore
and a child can free it taking credit for it. There is also a
similar issue about resource exhaustion if we limited the number
of lwps per process as opposed to per user (which we don't).
the real cause of yet.
mark npf_init() as non-static. for a yet-unknown reason, when this
function is inlined by the compiler (or a human!) into the single
caller, some CPUs end up in a hung state that can't be interrupted
eventually leading to system hang. eg:
[ 8.9693040] root on hme0
[ 8.9862690] nfs_boot: trying DHCP/BOOTP
xcall(cpu2,0xf0240ac8) from 0xf0241170: couldn't ping cpus: cpu1
is the symptom though sometimes nfs_boot is actually able to
complete mountroot before it hangs.
this may be a compiler bug but the symptom and the trigger are
far removed and my so-far reading of the "broken" npf_init
inlining has shown no issues, however, i haven't completed a
full scan of this asm in the past month so i'm commiting this
workaround for now.
account the trailing NUL on each name. Some other similar instances of
this idiom already account for this.
(In preparation to factor out this idiom into its own function.)
