Revert rev 1.122:
http://cvsweb.netbsd.org/bsdweb.cgi/src/sys/uvm/uvm_bio.c#rev1.122
If this commit is applied to NFS client, changes to files in client
side are sometimes invisible in server side, which results in file
corruption.
Demonstrated by test code provided by Anthony Mallet:
https://mail-index.netbsd.org/current-users/2020/10/17/msg039708.html
Whether the test case above passes or not depends on architectures
and size of NFS I/O specified by -r and -w options of mount_nfs(8)
(the default size is 32KB for x86 and 8KB for other archs).
Whereas it fails on amd64 and i386 with the default size, it passes
on other archs (aarch64, arm, alpha, m68k, and powerpc at least) with
their default. On most ports, it fails with some I/O sizes.
However, the condition for failure is still unclear; whereas it fails
with 2KB I/O size on amiga (m68k, 8KB page), it passes with same I/O
size on alpha (8KB page). It may depends on some VM parameters or
details in pmap implementation, or some race conditions are involved.
Great thanks to Anthony Mallet for providing the test code, and sorry
everyone for breakage.
"wm_gmii_setup_phytype: Unknown PHY model. OUI=000000, model=0000" and
"PHY type is still unknown." Don't call wm_gmii_setup_phytype() three times if
the interface uses SGMII with internal MDIO.
Tested with I354(Rangeley(SGMII(MDIO))) and I350(SERDES(SFP), SGMII(SFP)).
instructions are stored in little-endian byte-order for BE8,
an only valid binary format for ILP32BE executables.
XXX
Apply similar fixes to armv7{,hf}eb.
(1) Set r13 (sp for arm32 processes) appropriately when stack is
specified to fork1().
(2) For arm32 processes, align stack to 8-byte boundary, instead of
16-byte for native aarch64 processes, to match our 32-bit ABI:
https://nxr.netbsd.org/xref/src/sys/arch/arm/arm32/vm_machdep.c#150
Note that sp alignment checking is disabled in aarch32 mode, and
this works fine with AARCH64_EL0_STACK_ALIGNMENT_CHECK option.
OK ryo
if non-modifiable bits are set in CPSR.
Instead, mask out non-modifiable bits and make this function success
regardless of value in CPSR. New behavior matches that of arm:
https://nxr.netbsd.org/xref/src/sys/arch/arm/arm/process_machdep.c#187
This fixes lib/libc/sys/t_ptrace_wait*:access_regs6 tests, in which
register contents retrieved by PT_GETREGS are set back by PT_SETREGS.
No new regression is observed in full ATF run.
OK ryo
hard-coded EFAULT and use return value from uvm_fault() instead.
There are some paths that do not call uvm_fault():
(1) For fatalabort case, use EFAULT as before.
(2) When va range is invalid, use EFAULT instead of EINVAL.
These change fixes bytes_transfer_eof_* tests in
sys/lib/libc/sys/t_ptrace_wait*.
Note that without (2) above, some tests like
sys/lib/libc/sys/t_wait:write_error become newly failing.
I've confirmed that there's no new regression in full ATF run.
OK ryo
Fix the code reconstructing s87_tw (full tag word) from fx_sw (abridged
tag word) to correctly represent all register states. The previous code
only distinguished between empty/non-empty registers, and assigned
'regular value' to all non-empty registers. The new code explicitly
distinguishes the two other tag word values: empty and special.
I am going to add ATF tests for these two functions, and having them
in a separate file will make it more convenient to build and run them
in userspace.
Fix the machine-dependent ptrace register-related requests (e.g.
PT_GETXMMREGS, PT_GETXSTATE on x86) to correctly respect the LWP number
passed as the data argument. Before this change, these requests
did not operate on the requested LWP of a multithreaded program.
This change required moving ptrace_update_lwp() out of unit scope,
and changing ptrace_machdep_dorequest() function to take a pointer
to pointer as the second argument, consistently with ptrace_regs().
I am planning to extend the ATF ptrace() register tests in the future
to check for regressions in multithreaded programs, as time permits.
Reviewed by kamil.
This flag was only set for virtual interfaces.
All virtual interfaces have a means of knowing if they are going to work
or not and as such now support link state changes.
If we want this flag back, it should be used as an indicator that
the interfaces does not support link state changes that userland can use
so it can make a decision on what to do when the link state is UNKNOWN.
tnn