On 11/30/22 06:28, Randy MacLeod wrote:
On 2022-11-29 10:52, Ross Burton via lists.openembedded.org wrote:
On 28 Nov 2022, at 09:25, Alexander Kanavin via
lists.openembedded.org
<alex.kanavin=gmail....@lists.openembedded.org> wrote:
On Sun, 27 Nov 2022 at 14:39, Xiangyu Chen
<xiangyu.c...@eng.windriver.com> wrote:
* add libgcc in RDEPENDS flag to solve testing failed in
core-image-full-cmdline
+RDEPENDS:${PN} = "libgcc"
This needs to be better investigated first. The change looks like
solving the symptom, but not the actual issue.
It’s not uncommon:
https://bugzilla.yoctoproject.org/show_bug.cgi?id=10954
While it would be good to solve the general case of libgcc dependency
mentioned in that case,
I do wonder if the original issue that Xiangyu saw, goes away if we
_only_ add:
+RDEPENDS:${PN} = "libgcc"
to rngtools without added the upstream timeout after 5 seconds or
it the dependency is only required with the patch?
Xiangyu ?
The software jitter thread will call the pthread_exit after timeout
value reached, the code has already exists there but normally won't be
called, when applying this patch, the timeout logic can go there,
that's the reason missing libgcc which was reported by oe testing
I also don't like the arbitrary timeout and I'd like references
from the board vendor that explains that proper RNG isn't supported!
( I'm not a BSP person so this may be optimistic! )
Note that there is a follow-up patch to make the timeout configurable,
see below.
If we take the original patch, we should take both and require that
the BSP tune
the timeout. We'll get this behaviour once the patches are integrated
into a release
so we might as well figure out if we're going to:
1. have a tuning policy,
2. continually revert the patch or
3. actually get to the root cause of the problem (by working with
board vendors I expect).
After investigating this patch, it just add a mechanism to avoid jitter
thread take long time, but not "really" solve the jitter thread full cpu
usage when it start. But we still need to think about the timeout value
because this commit will contain in next rng-tool release version.
There is another question need to clarify that whether rng-tool built-in
jitter random generator still need after kernel 5.6, the /dev/random
doesn't block anymore, perhaps we can turn built-in jitter random
generator off by default service start parameter because it would take
full CPU cores effort to generate jitter random when it start.
Br,
Xiangyu
../Randy
commit 6e14b8bd491b3f94f60f36748959e0ae7d7c1f95
Author: Dan Horák <d...@danny.cz>
Date: Mon Jul 18 04:47:41 2022
rngd_jitter: make timeout configurable
The current default 5 sec timeout can be too short in some situations
(eg. slow hardware). Introduce a command line option (jitter:timeout)
to make the value configurable. Increasing the default timeout is not
desirable, because it might slow down system startup when there are
other entropy sources.
Signed-off-by: Dan Horák <d...@danny.cz>
commit c29424f10a0dcbd18ac25607fa1c81c18a960e81 (origin/jitter-init)
Author: Neil Horman <nhor...@tuxdriver.com>
Date: Mon May 16 13:38:54 2022
Adjust jitterentropy library to timeout/fail on long delay
When running rngd -l its possible, on platforms that have low jitter
entropy to block for long periods of time. Adjust jitter to
timeout on
init after 5 seconds in the event it takes to long to gether jitter
entropy
Also while we're at it, I might have a build solution for the
presence
of internal timers. When jitterentropy is built without internal
timers, jent_notime_init is defined publically, but when it is built
with timers, its declared as a static symbol, preenting
resolution, so
we can test to see if the function exists. If it does we _don't_
have
notime support. The logic is a bit backwards, but i think it works
Ross
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#174232):
https://lists.openembedded.org/g/openembedded-core/message/174232
Mute This Topic: https://lists.openembedded.org/mt/95288451/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
