Decrease MAXSSIZ from ~256MB to 32MB (same as oea).
This fixes tests in /usr/tests/usr.bin/make, that run with "ulimit -v 200000",
fail with "Cannot map anonymous memory".
Although I'm not fully convinced whether this limit is reasonable or not,
old MAXSSIZ of ~256MB is too much anyway.
The description of the tests is not going to be added anytime soon, as
that would either create redundancy or additional run-time cost.
Parsing and evaluating unit-tests/Makefile is already O(n^2) with regard
to the number of tests, and there are quite a few tests. Therefore don't
add any overhead for now.
indeed quicker, it nonetheless failed to actually fill all the requested
memory with the specified value much of the time if a non-aligned start
address was used.
- powerpc ports work
- m68k ports work, x68k has a new caveat
- hppa works
- mips64eb vs UVMHIST has been fix
- i386 reboot problem fixed (cardbus issue, not GCC related)
early in boot and broken early in boot by requiring a partly static
structure with another structure that must be present by the time
any uses are performed. theoretically platform code could allocate
a chunk while seting up memory and assign it here, giving a dynamic
sizing for the entry list, but the reality is that all users have
a statically allocated entry list as well.
the existing KERNHIST_LINK_STATIC() is used in conjunction with
KERNHIST_INITIALIZER() instead.
this stops a NULL pointer deref when the _LOG() macro is called
before the storage is linked in, which happens with GCC 10 on OCTEON
with UVMHIST enabled, crashing in very early kernel init.
this avoids a strange hang at reboot i am seeing on an old pentium4-m
laptop, that was introduced with kern_mutex.c 1.91/92, though i can
not really explain why that matters (in the waiting thread, a pointer
that should be NULL remains non NULL.) thanks to jmcneill@ for some
helpful review commentary here.
don't panic() if either "cardbus" or "pcmcia" didn't attach and a
card is inserted. this can happen for various reasons, including
some regression in netbsd (-current, and -9, at least) that suggests
using PCI_BUS_FIXUP (though it still fails to attach the card i have.)
both found with GCC 10 testing, though both also occur with GCC 7 in
the netbsd-9 tree as well.
array size from evcnt_sysctl:ev_strings that clang does not like.
the previous "struct xevcnt_sysctl" was well defined as the
evcnt_sysctl with array length of 0 could be placed as the
anywhere in other structures, but with [] it must remain last
and xevcnt_sysctl then places a char array afterwards.
avoid this entirely by removing struct xevcnt_sysctl, combining
the string array + struct evcnt_sysctl size manually for the
allocation, and moving all "ev_string" accesses to be via the
new [] array.
you can have races when multiple processes try to unlink it. Check the link
count to see if we have won the race.
While here:
- use snprintf
- use warn
- use size_t/ssize_t
- use loops instead of goto
- KNF
The word 'write' now means to write to the file that holds the shell
commands to be run later.
The word 'print' is now used exclusively for handling the output of the
child commands and printing them to make's stdout.
No functional change.
http://cvsweb.netbsd.org/bsdweb.cgi/src/external/gpl3/gcc/dist/gcc/config/rs6000/rs6000.c#rev1.13
This was removed accidentally when merging GCC10 into our tree.
Note that some firmwares, e.g., Explora, refuse to execute ELF
kernel image if this program header is present.
Now, GCC10 becomes just fine for all three powerpc sub-archs, i.e.,
oea, booke, and ibm4xx, as far as I can see. No regressions are
observed for ATF.
OK mrg
processors as POWER9 if -misel flag is specified.
rs6000_machine_from_flags() assumes ISEL instructions are supported only
for POWER9 and successors. However, ISEL is also implemented for 32-bit
booke processors.
Since our kernel for booke is compiled with -misel, this regression
completely breaks it.
As a fix, check whether CPU is 64-bit capable or not, before checking
-misel flag.
The problem has been reported as 100108 to upstream:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100108
OK mrg
The locks were held while callout_halt() and workqueue_wait()
without reason.
And the locks also were held at callout and workqueue handler
so that the handler kicked by those function couldn't acquire
the lock.
The reasons why those are unneccesary are:
- Items of callout_t are protected by callout_lock
- Items of struct workqueue and struct work are protected
by q_mutex in struct workqueue
- Items of struct sppp_work protected by atomic_cas(3)
- struct pppoe_softc does not free before workqueue_wait() and
callout_halt() even if the locks are not held
