Re: kern/54687: ATF tests time out since kern_lwp.c 1.206

[Joerg Sonnenberger <joerg%bec.de@localhost>]

The following reply was made to PR kern/54687; it has been noted by GNATS.

From: Joerg Sonnenberger <joerg%bec.de@localhost>
To: gnats-bugs%netbsd.org@localhost
Cc: joerg%netbsd.org@localhost, gnats-admin%netbsd.org@localhost, netbsd-bugs%netbsd.org@localhost,
	Andreas Gustafsson <gson%gson.org@localhost>
Subject: Re: kern/54687: ATF tests time out since kern_lwp.c 1.206
Date: Sun, 10 Nov 2019 22:41:01 +0100

 On Sun, Nov 10, 2019 at 09:10:01PM +0000, Andreas Gustafsson wrote:
 > The following reply was made to PR kern/54687; it has been noted by GNATS.
 > 
 > From: Andreas Gustafsson <gson%gson.org@localhost>
 > To: joerg%netbsd.org@localhost
 > Cc: gnats-bugs%netbsd.org@localhost
 > Subject: Re: kern/54687: ATF tests time out since kern_lwp.c 1.206
 > Date: Sun, 10 Nov 2019 23:07:13 +0200
 > 
 >  Joerg Sonnenberger wrote:
 >  >  Sonuds like rump is acting up again with random failures in the IPsec
 >  >  tests. Maybe you should ask someone to debug rump?
 >  
 >  I'm not the one making the claim that rump is at fault.  And even if
 >  rump *is* at fault, reverting your commit until rump has been fixed
 >  is the right thing to do.  I would do it myself if that wasn't
 >  specifically prohibited by the developer guidelines.
 
 (1) I can run the ipsec tests in a fresh VM in isolation and they finish
 within 30s. That alone should be a good indicator that the problem with
 those tests is not actually the commit here.
 
 (2) We have a very long history of various rump-based tests timing out
 in one environment and working in another and noone ever bothered to fix
 that. A common example is the quota test cases.
 
 (3) We have a persistent history of RUMP stuff failing because ATF
 doesn't properly cleanup behind failures. E.g. left-over rump_server
 instances breaking random other tests.
 
 All in all, there is literally no indication here that the l_lid change
 has any problem. At most we have some indication that it changes some
 timing and that in turns (re)exposes RUMP bugs. So no, I'm not willing
 to revert a commit based on such shady evidence.
 
 Joerg