for each transfer to write through to the medium is way slower than just
letting the drive use a cached write and doing DIOCCACHESYNC on the end
Results were (fs block 32KB / frag 4KB, partition aligned on 32KB boundary):
HDD at siisata(4): no-FUA: 108 sec w/FUA: 294 sec
SSD at ahcisata(4): no-FUA: 73 sec w/FUA: 502 sec
change the flag so that FUA is only used for the commit block write;
for journal data write, only pass DPO, rely on the cache flush to get them
to media
trap.c - code that is incorrect anyway, there were originally three lcall
LDT slots, and here only one instruction is decoded.
Given that one of these slots was used by BSDi's syscall, also remove the
references to COMPAT_NOMID to make clear we don't support that (it already
is not enabled).
Note: for some reason, COMPAT_10 does not even compile, because there are
"multiple definitions of _KERNEL_OPT_COMPAT_...", and I don't really
understand where this comes from.
bootpages is set to the pages allocated via uvm_pageboot_alloc().
poolpages is calculated from the list of pools nr_pages members.
this brings us closer to having a valid total of pages known by
the system, vs actual pages originally managed.
XXX: poolpages needs some handling for PR_RECURSIVE pools still.
the IPI and then ignoring responses ( or lack thereof )
- write the .tag field last to avoid a race when polling for an incoming
IPI
- add event counters for IPIs being caught with the mutex not held, and for
messages that are already marked as completed
With this my SS20 made it through 48 hours of pkgsrc with MAKE_JOBS=3 and a
pair of SM81s.
Hypersparcs still crash but instead of craziness we get actual error messages,
apparently one CPU will occasionally do a watchdog reset, which according to
the manual is caused by catching a trap with traps disabled. Now to figure
out how that can even happen...
- fix (debugger-only useful) struct srmmu_pte::pg_pfnum to be the
right size.
- add SRMMU_TEPTERBO as a PTE type -- supersparc-II only feature
of mapping pages in reverse-byte-order (eg little endian by
default, but there's also a global RBO flag, that makes this
flag big-endian.) we don't use it (yet?)
to my message on tech-userlevel ...
Subject: tests/lib/libpthread/t_mutex:mutex6
Date: Thu, 23 Nov 2017 17:34:54 +0700
Message-ID: <28385.1511433294@andromeda.noi.kre.to>
which can be found at:
http://mail-index.netbsd.org/tech-userlevel/2017/11/23/msg011010.html
which analysed the mutex6 test case of this test, and concluded
that it was useless, nonsense, and broken (the whole test is just a
race - not even really using or testing mutexes), let it be henceforth
forever gone.
more precision bits than the data type expects, but (kind of obviously)
does not allow such values to be stored in memory, expecting the value
returned from strtod() (an intermediate result) to be identical (that is,
equal) to a stored value is incorrect.
So instead go back to checking that the two numbers are very very close.
See comments added to the test for more explanation.
typing 'cat /proc/aout_pid/auxv' on whatever a.out binary you're running.
Fortunately, amd64 does not enable EXEC_AOUT by default. Unfortunately,
i386 does enable it by default.
christos