| Message ID | 20180706080615.25974-1-alex.bennee@linaro.org |
|---|---|
| State | New |
| Headers | show |
| Series | [RFC,for,3.0] tests/tpm-emu: double the timeout | expand |
Hi On Fri, Jul 6, 2018 at 10:06 AM, Alex Bennée <alex.bennee@linaro.org> wrote: > We see various failures on Travis so lets just double the timeout and > see if that makes them go away. This is just waiting for the thread to start and open a socket. It shouldn't be a problem to wait longer, but do you have a Travis error log? > > Signed-off-by: Alex Bennée <alex.bennee@linaro.org> > --- > tests/tpm-emu.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/tests/tpm-emu.c b/tests/tpm-emu.c > index 8c2bd53cad..308f1884f6 100644 > --- a/tests/tpm-emu.c > +++ b/tests/tpm-emu.c > @@ -20,7 +20,7 @@ > > void tpm_emu_test_wait_cond(TestState *s) > { > - gint64 end_time = g_get_monotonic_time() + 5 * G_TIME_SPAN_SECOND; > + gint64 end_time = g_get_monotonic_time() + 10 * G_TIME_SPAN_SECOND; > > g_mutex_lock(&s->data_mutex); > if (!g_cond_wait_until(&s->data_cond, &s->data_mutex, end_time)) { > -- > 2.17.1 > >
Marc-André Lureau <marcandre.lureau@gmail.com> writes: > Hi > > On Fri, Jul 6, 2018 at 10:06 AM, Alex Bennée <alex.bennee@linaro.org> wrote: >> We see various failures on Travis so lets just double the timeout and >> see if that makes them go away. > > This is just waiting for the thread to start and open a socket. It > shouldn't be a problem to wait longer, but do you have a Travis error > log? For example: https://travis-ci.org/qemu/qemu/jobs/400436724#L8971 GTESTER check-qtest-i386 ** ERROR:tests/tpm-emu.c:27:tpm_emu_test_wait_cond: code should not be reached > >> >> Signed-off-by: Alex Bennée <alex.bennee@linaro.org> >> --- >> tests/tpm-emu.c | 2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) >> >> diff --git a/tests/tpm-emu.c b/tests/tpm-emu.c >> index 8c2bd53cad..308f1884f6 100644 >> --- a/tests/tpm-emu.c >> +++ b/tests/tpm-emu.c >> @@ -20,7 +20,7 @@ >> >> void tpm_emu_test_wait_cond(TestState *s) >> { >> - gint64 end_time = g_get_monotonic_time() + 5 * G_TIME_SPAN_SECOND; >> + gint64 end_time = g_get_monotonic_time() + 10 * G_TIME_SPAN_SECOND; >> >> g_mutex_lock(&s->data_mutex); >> if (!g_cond_wait_until(&s->data_cond, &s->data_mutex, end_time)) { >> -- >> 2.17.1 >> >> -- Alex Bennée
On Fri, Jul 6, 2018 at 12:19 PM, Alex Bennée <alex.bennee@linaro.org> wrote: > > Marc-André Lureau <marcandre.lureau@gmail.com> writes: > >> Hi >> >> On Fri, Jul 6, 2018 at 10:06 AM, Alex Bennée <alex.bennee@linaro.org> wrote: >>> We see various failures on Travis so lets just double the timeout and >>> see if that makes them go away. >> >> This is just waiting for the thread to start and open a socket. It >> shouldn't be a problem to wait longer, but do you have a Travis error >> log? > > For example: > > https://travis-ci.org/qemu/qemu/jobs/400436724#L8971 > > GTESTER check-qtest-i386 > ** > ERROR:tests/tpm-emu.c:27:tpm_emu_test_wait_cond: code should not be reached > thanks, what about increasing the timeout to 30s ? I am afraid x2 might not be enough for such overloaded systems. >>> >>> Signed-off-by: Alex Bennée <alex.bennee@linaro.org> >>> --- >>> tests/tpm-emu.c | 2 +- >>> 1 file changed, 1 insertion(+), 1 deletion(-) >>> >>> diff --git a/tests/tpm-emu.c b/tests/tpm-emu.c >>> index 8c2bd53cad..308f1884f6 100644 >>> --- a/tests/tpm-emu.c >>> +++ b/tests/tpm-emu.c >>> @@ -20,7 +20,7 @@ >>> >>> void tpm_emu_test_wait_cond(TestState *s) >>> { >>> - gint64 end_time = g_get_monotonic_time() + 5 * G_TIME_SPAN_SECOND; >>> + gint64 end_time = g_get_monotonic_time() + 10 * G_TIME_SPAN_SECOND; >>> >>> g_mutex_lock(&s->data_mutex); >>> if (!g_cond_wait_until(&s->data_cond, &s->data_mutex, end_time)) { >>> -- >>> 2.17.1 >>> >>> > > > -- > Alex Bennée
Marc-André Lureau <marcandre.lureau@gmail.com> writes: > On Fri, Jul 6, 2018 at 12:19 PM, Alex Bennée <alex.bennee@linaro.org> wrote: >> >> Marc-André Lureau <marcandre.lureau@gmail.com> writes: >> >>> Hi >>> >>> On Fri, Jul 6, 2018 at 10:06 AM, Alex Bennée <alex.bennee@linaro.org> wrote: >>>> We see various failures on Travis so lets just double the timeout and >>>> see if that makes them go away. >>> >>> This is just waiting for the thread to start and open a socket. It >>> shouldn't be a problem to wait longer, but do you have a Travis error >>> log? >> >> For example: >> >> https://travis-ci.org/qemu/qemu/jobs/400436724#L8971 >> >> GTESTER check-qtest-i386 >> ** >> ERROR:tests/tpm-emu.c:27:tpm_emu_test_wait_cond: code should not be reached >> > > thanks, what about increasing the timeout to 30s ? I am afraid x2 > might not be enough for such overloaded systems. Sure - the Travis servers are certainly hammered most of the time. > >>>> >>>> Signed-off-by: Alex Bennée <alex.bennee@linaro.org> >>>> --- >>>> tests/tpm-emu.c | 2 +- >>>> 1 file changed, 1 insertion(+), 1 deletion(-) >>>> >>>> diff --git a/tests/tpm-emu.c b/tests/tpm-emu.c >>>> index 8c2bd53cad..308f1884f6 100644 >>>> --- a/tests/tpm-emu.c >>>> +++ b/tests/tpm-emu.c >>>> @@ -20,7 +20,7 @@ >>>> >>>> void tpm_emu_test_wait_cond(TestState *s) >>>> { >>>> - gint64 end_time = g_get_monotonic_time() + 5 * G_TIME_SPAN_SECOND; >>>> + gint64 end_time = g_get_monotonic_time() + 10 * G_TIME_SPAN_SECOND; >>>> >>>> g_mutex_lock(&s->data_mutex); >>>> if (!g_cond_wait_until(&s->data_cond, &s->data_mutex, end_time)) { >>>> -- >>>> 2.17.1 >>>> >>>> >> >> >> -- >> Alex Bennée -- Alex Bennée
diff --git a/tests/tpm-emu.c b/tests/tpm-emu.c index 8c2bd53cad..308f1884f6 100644 --- a/tests/tpm-emu.c +++ b/tests/tpm-emu.c @@ -20,7 +20,7 @@ void tpm_emu_test_wait_cond(TestState *s) { - gint64 end_time = g_get_monotonic_time() + 5 * G_TIME_SPAN_SECOND; + gint64 end_time = g_get_monotonic_time() + 10 * G_TIME_SPAN_SECOND; g_mutex_lock(&s->data_mutex); if (!g_cond_wait_until(&s->data_cond, &s->data_mutex, end_time)) {
We see various failures on Travis so lets just double the timeout and see if that makes them go away. Signed-off-by: Alex Bennée <alex.bennee@linaro.org> --- tests/tpm-emu.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)