On Wed, Jul 08, 2026 at 01:31:45AM +0200, Thomas Gleixner wrote:
> On Tue, Jul 07 2026 at 23:28, Mark Brown wrote:

> >  1..2
> >  # Starting 2 tests from 1 test cases.
> >  #  RUN           global.requeue_single ...
> >  # futex_requeue.c:28:requeue_single:Expected res (-1) == 0 (0)
> >  # futex_requeue.c:29:requeue_single:waiter failed errno 110: Connection 
> > timed out
> >  # futex_requeue.c:49:requeue_single:Expected 
> > futex_wait_for_thread(&waiter, _metadata) (110) == 0 (0)
> >  # futex_requeue.c:50:requeue_single:Wait for thread failed

> Do you have /proc/ disabled by chance or is it not accessible for the
> test case?

Not intentionally, it's an arm64 defconfig running a Debian rootfs.  The
jobs that do the futex tests actually also run the proc selftests (after
the futex ones) and those are passing, adding checks that /proc is there
seems to confirm it is:

  # mount
  sysfs on /sys type sysfs (rw,nosuid,nodev,noexec,relatime)
  proc on /proc type proc (rw,nosuid,nodev,noexec,relatime)
  ...

ls seems to work too.

> > Full log should be at:

> >    https://lava.sirena.org.uk/scheduler/job/2954705#L13289

> > but I'm having a terrible time with AI scrapers right now so perhaps not
> > usefully.

> Seems to correlate with the test case failure: Connection timed out :)

Bah.  If you've got a fixed IP or IP range I can fiddle with the
firewalling?

Attachment: signature.asc
Description: PGP signature

Reply via email to