On 23/06/2022 13:33, Alexandre Oliva wrote:
Anyway... I was considering this xfail patch before, and I wonder if it
would still be appropriate to install something like it, narrowed down
to rtems < 6.1, or if it would be better to let it fail noisily so that
people look it up, find the fix prope
On Jun 23, 2022, Sebastian Huber wrote:
> On 23/06/2022 08:44, Sebastian Huber wrote:
>> http://devel.rtems.org/ticket/4669
Thanks!
> This problem should be fixed now in the RTEMS master branch.
Double thanks! I've applied the patch, and I haven't seen the fails any
more. It's a little too s
On 23/06/2022 08:44, Sebastian Huber wrote:
On 23/06/2022 02:19, Alexandre Oliva wrote:
On Jun 22, 2022, Sebastian Huber
wrote:
The clock_nanosleep() uses the coarse resolution which may give a time
before now().
Uhh, sorry, hit send too early.
I also meant to ask whether you'd like me to
On 23/06/2022 02:19, Alexandre Oliva wrote:
On Jun 22, 2022, Sebastian Huber wrote:
The clock_nanosleep() uses the coarse resolution which may give a time
before now().
Uhh, sorry, hit send too early.
I also meant to ask whether you'd like me to file an RTEMS ticket about
this issue.
I alr
On Jun 22, 2022, Sebastian Huber wrote:
> The clock_nanosleep() uses the coarse resolution which may give a time
> before now().
Uhh, sorry, hit send too early.
I also meant to ask whether you'd like me to file an RTEMS ticket about
this issue.
--
Alexandre Oliva, happy hacker
On Jun 22, 2022, Sebastian Huber wrote:
> The clock_nanosleep() uses the coarse resolution
Thanks for looking into this. So, is it missing a rounding-up to ensure
the sleep time is >= the requested time, or is it even more elaborate
than that?
--
Alexandre Oliva, happy hackerh
On 22/06/2022 08:22, Sebastian Huber wrote:
On 22/06/2022 08:01, Alexandre Oliva via Gcc-patches wrote:
On rtems under qemu, the frequently-interrupted nanosleep ends up
sleeping shorter than expected, by a margin of less than 0,3%.
I figured failing the library test over a system (emulator?)
On 22/06/2022 08:01, Alexandre Oliva via Gcc-patches wrote:
On rtems under qemu, the frequently-interrupted nanosleep ends up
sleeping shorter than expected, by a margin of less than 0,3%.
I figured failing the library test over a system (emulator?) bug is
undesirable, so I put in some toleranc
On rtems under qemu, the frequently-interrupted nanosleep ends up
sleeping shorter than expected, by a margin of less than 0,3%.
I figured failing the library test over a system (emulator?) bug is
undesirable, so I put in some tolerance for the drift.
Regstrapped on x86_64-linux-gnu, also teste
