The number of virtqueue maybe change in a part of VirtIO devices
(e.g. vioif(4)). And it is fixed after negotiation of features.
So the configuration is moved into the function.
According to CN50XX-HRM-V0.99E and CN78XX-HM-0.99E:
The entropy is provided by the jitter of 125 of 128 free-running
oscillators XORed into a 128-bit LFSR. The LFSR accumulates entropy
over 81 cycles, after which it is fed into a SHA-1 engine.
[...]
The SHA-1 engine runs once every 81 cycles.
[...]
The hardware produces new 64-bit random number every 81 cycles.
The last sentence means that we only need to wait 81 cycles _between_
consecutive SHA-1 outputs (which isn't relevant anyway because we
reconfigure it into raw mode later), but the first two quotes might
mean that we need to wait 81+81 cycles for the _first_ output to be
produced on boot when running the self-test.
Now, in this case, the self-test is run with the LFSR unhooked, by
clearing the RNM_CTL_STATUS[ENT_EN] bit, so that SHA-1 is computed
from a known input -- this is really just paranoia to make sure that
_some_ functions of the device (which is conjured out of thin air at
a fixed virtual address, with no firmware bindings to guide us)
behave as we expect.
And it's not clear if it really does take 81+81 cycles for the first
SHA-1 output to appear when the LFSR isn't feeding into it anyway.
But experimentally, delay of 81+81 cycles seems to work whereas a
delay of only 81 cycles crashes.
PR kern/57280
XXX pullup-10
XXX pullup-9
to the next instruction. Only ERESTART should return to
the same instruction. Differences to sparc64 reduced.
Test t_ptrace_wait:syscallemu1 now passes on sparc.
Fixes PR kern/52166 "syscallemu does not work on sparc (32-bit)"
Ok: Martin Husemann
EACCES is from the namei(), treat it just like ENOENT or ENOTDIR
(and if that is the final error, the exit status from a failed exec
will be 127). If the EACCES is from the exec() itself, that indicates
the file to be run exists, but has no 'x' permission. That's a
meaningful error (as distinct from just "yet another PATH element
search failure").
While here, return the first meaingful error we encountered while
searching PATH, rather than the last (and ENOENT if there are none
of those).
This change results in some failed command executions returning status
127 now, where they returned 126 before - which better reflects the
intent of those values (127 is simply "not found" whereas 126 is "found
but couldn't be executed").
We still do nothing to distinguish errors encountered looking up the
command name give, with errors encountered (by the kernel) attempting to
run an interpreter needed for the exec to succeed (#! line path, or
/libexec/ld.elf_so and similar - or anything else of a similar nature).
mrg