GNU bug report logs - #80164
Tramp tests time out on Fedora 42 AMD Phenom II X4 910e

Previous Next

To reply to this bug, email your comments to 80164 AT debbugs.gnu.org.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Emacs bug reports and feature requests <bug-gnu-emacs <at> gnu.org>
Cc: Michael Albinus <michael.albinus <at> gmx.de>
Subject: Tramp tests time out on Fedora 42 AMD Phenom II X4 910e
Date: Fri, 9 Jan 2026 12:50:59 -0800

[Message part 1 (text/plain, inline)]

This is Emacs master commit 65090ec691d9bd82a9ba3bd25756227e0d43bd80 
dated today, running on Fedora 42 x86-64 on an old, slow CPU (an AMD 
Phenom II X4 910e, a circa 2010 low-power design). The failure symptom 
with "make -j5 check" is in test/lisp/net/tramp-tests.log, a copy of 
which I am attaching.

Perhaps the Tramp tests should have a longer timeout, or maybe run fewer 
tests if it discovers the machine is slow.

[tramp-tests.log (text/x-log, attachment)]

Message #8 received at 80164 <at> debbugs.gnu.org (full text, mbox):

From: Michael Albinus <michael.albinus <at> gmx.de>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: 80164 <at> debbugs.gnu.org
Subject: Re: bug#80164: Tramp tests time out on Fedora 42 AMD Phenom II X4 910e
Date: Sat, 10 Jan 2026 10:56:26 +0100

Paul Eggert <eggert <at> cs.ucla.edu> writes:

Hi Paul,

> This is Emacs master commit 65090ec691d9bd82a9ba3bd25756227e0d43bd80
> dated today, running on Fedora 42 x86-64 on an old, slow CPU (an AMD
> Phenom II X4 910e, a circa 2010 low-power design). The failure symptom
> with "make -j5 check" is in test/lisp/net/tramp-tests.log, a copy of
> which I am attaching.
>
> Perhaps the Tramp tests should have a longer timeout, or maybe run
> fewer tests if it discovers the machine is slow.

I don't believe it is due to a slow machine. I run tramp-tests.el
regularly for over 100 different targets, including remote ones with
poor roundtrip times. No problems with this respect.

However, occasionally the Tramp tests timeout on emba. I couldn't find a
recipe yet how to provoke it. I will try harder to analyze what's up
next time.

In your case, the test case tramp-test47-read-fingerprint didn't
return. Does the problem also happen, if you call "make check"?

Best regards, Michael.

Message #11 received at 80164 <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Michael Albinus <michael.albinus <at> gmx.de>
Cc: 80164 <at> debbugs.gnu.org
Subject: Re: bug#80164: Tramp tests time out on Fedora 42 AMD Phenom II X4 910e
Date: Sat, 10 Jan 2026 15:28:50 -0800

On 2026-01-10 01:56, Michael Albinus wrote:

> In your case, the test case tramp-test47-read-fingerprint didn't
> return. Does the problem also happen, if you call "make check"?

I tried plain 'make check' and the problem does not happen. However, I 
also tried 'make -j5 check' again and the problem still does not happen. 
So it seems to be timing-dependent, unfortunately.

Message #14 received at 80164 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: 80164 <at> debbugs.gnu.org, michael.albinus <at> gmx.de
Subject: Re: bug#80164: Tramp tests time out on Fedora 42 AMD Phenom II X4 910e
Date: Sun, 11 Jan 2026 08:50:06 +0200

> Cc: 80164 <at> debbugs.gnu.org
> Date: Sat, 10 Jan 2026 15:28:50 -0800
> From: Paul Eggert <eggert <at> cs.ucla.edu>
> 
> On 2026-01-10 01:56, Michael Albinus wrote:
> 
> > In your case, the test case tramp-test47-read-fingerprint didn't
> > return. Does the problem also happen, if you call "make check"?
> 
> I tried plain 'make check' and the problem does not happen. However, I 
> also tried 'make -j5 check' again and the problem still does not happen. 
> So it seems to be timing-dependent, unfortunately.

FWIW, I never run the test suite with -jN.  It tends to cause false
positives and wastes our collective energy and time on issues that
have nothing to do with the aspects of Emacs that are being tested in
each case.  Maybe we should simply say that in test/README, and stop
accepting bug reports about tests that fail only in parallel runs.

Message #17 received at 80164 <at> debbugs.gnu.org (full text, mbox):

From: Michael Albinus <michael.albinus <at> gmx.de>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: Paul Eggert <eggert <at> cs.ucla.edu>, 80164 <at> debbugs.gnu.org
Subject: Re: bug#80164: Tramp tests time out on Fedora 42 AMD Phenom II X4 910e
Date: Sun, 11 Jan 2026 10:32:24 +0100

Eli Zaretskii <eliz <at> gnu.org> writes:

Hi Eli,

>> I tried plain 'make check' and the problem does not happen. However, I 
>> also tried 'make -j5 check' again and the problem still does not happen. 
>> So it seems to be timing-dependent, unfortunately.
>
> FWIW, I never run the test suite with -jN.  It tends to cause false
> positives and wastes our collective energy and time on issues that
> have nothing to do with the aspects of Emacs that are being tested in
> each case.  Maybe we should simply say that in test/README, and stop
> accepting bug reports about tests that fail only in parallel runs.

Well, I've never seen an error I could identify caused by "make
-jN". OTOH, on emba the tests run with "make -j \$NPROC". Occasionally,
some test jobs do not finish w/o an explanation. Perhaps this is the
reason?

I've modified test/infra/gitlab-ci.yml to not use this make option. In
test/README, there is a respective recommendation now. Pushed to master.

Should we modify test/Makefile to run all jobs not parallel?  That is,
use the rule

--8<---------------cut here---------------start------------->8---
.NOTPARALLEL:
--8<---------------cut here---------------end--------------->8---

Best regards, Michael.

Message #20 received at 80164 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Michael Albinus <michael.albinus <at> gmx.de>
Cc: eggert <at> cs.ucla.edu, 80164 <at> debbugs.gnu.org
Subject: Re: bug#80164: Tramp tests time out on Fedora 42 AMD Phenom II X4 910e
Date: Sun, 11 Jan 2026 13:26:53 +0200

> From: Michael Albinus <michael.albinus <at> gmx.de>
> Cc: Paul Eggert <eggert <at> cs.ucla.edu>,  80164 <at> debbugs.gnu.org
> Date: Sun, 11 Jan 2026 10:32:24 +0100
> 
> > FWIW, I never run the test suite with -jN.  It tends to cause false
> > positives and wastes our collective energy and time on issues that
> > have nothing to do with the aspects of Emacs that are being tested in
> > each case.  Maybe we should simply say that in test/README, and stop
> > accepting bug reports about tests that fail only in parallel runs.
> 
> Well, I've never seen an error I could identify caused by "make
> -jN". OTOH, on emba the tests run with "make -j \$NPROC". Occasionally,
> some test jobs do not finish w/o an explanation. Perhaps this is the
> reason?

No idea.  My main development machine has so many cores that I cannot
test that in a simple manner.  But it should be clear than running too
many parallel jobs on a system with a small number of execution units
will sometimes run afoul of the (more-or-less arbitrary) timeouts we
have in the test suite.  I consider the effort of cleaning this up be
of secondary or even tertiary importance, except in tests that
specifically test timing and synchronization.  The vast majority of
our tests don't care about timing, they care about correctness.

> I've modified test/infra/gitlab-ci.yml to not use this make option. In
> test/README, there is a respective recommendation now. Pushed to master.

Thanks.

> Should we modify test/Makefile to run all jobs not parallel?  That is,
> use the rule
> 
> --8<---------------cut here---------------start------------->8---
> .NOTPARALLEL:
> --8<---------------cut here---------------end--------------->8---

I think that would be too radical.  Let people who want that use the
parallel execution, but given the recommendation now on file, we
should perhaps start by asking people who report failures to run the
test without parallelism, and if that makes the problem go away, I
think in most cases we can close the bug right there and then.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.