Re: [gpsd-dev] scons check fails on NetBSD

[Eric S. Raymond]

Hal Murray <address@hidden>:
> I've got 2 NetBSD boxes.  One works.  The other gets things like this:
> 
> Regression test FAILED: 23 errors in 87 tests total (0 not found).
> Regression test FAILED: 8 errors in 87 tests total (0 not found).
> Regression test FAILED: 23 errors in 87 tests total (0 not found).
> 
> gps/fake.py says:
> # From Hal Murray on NetBSD 6.1.2 on an Intel(R) Celeron(R) CPU 2.80GHz
> #  WRITE_PAD = 0.0 / CLOSE_DELAY = 0.4    Works, takes 688.69s real
> #  WRITE_PAD = 0.0 / CLOSE_DELAY = 0.3    Fails tcp-torture.log, 677.53s real
> (That's the one that works.)
> 
> The one that fails is an
>   Intel(R) Atom(TM) CPU D2500   @ 1.86GHz
> It's slower, but has 2 CPUs.
> 
> With CLOSE_DELAY = 1.2
> Regression test FAILED: 7 errors in 87 tests total (0 not found).
> Regression test FAILED: 30 errors in 87 tests total (0 not found).
> 
> With CLOSE_DELAY = 2.0
> Regression test FAILED: 31 errors in 87 tests total (0 not found).
> 
> With CLOSE_DELAY = 5.0  (13 minutes)
> Regression test FAILED: 15 errors in 87 tests total (0 not found).
> Regression test FAILED: 2 errors in 87 tests total (0 not found). 
> 
> With CLOSE_DELAY = 5.0 and WRITE_PAD = 0.1
> Hung after printing:
>   Processing test/daemon/sl869.log
> Looks like I didn't wait long enough.  That test has 5K lines.
> Another try worked.  52 minutes.
> 
> With CLOSE_DELAY = 5.0 and WRITE_PAD = 0.02
> Regression test FAILED: 12 errors in 87 tests total (0 not found).  (17 
> minutes)
> 
> With CLOSE_DELAY = 5.0 and WRITE_PAD = 0.05
> Worked, 30 minutes.
> 
> With CLOSE_DELAY = 5.0 and WRITE_PAD = 0.04
> Worked, 26 minutes.
> 
> With CLOSE_DELAY = 5.0 and WRITE_PAD = 0.03
> Worked, 22 minutes.
> 
> With CLOSE_DELAY = 1.0 and WRITE_PAD = 0.02
> Regression test FAILED: 17 errors in 87 tests total (0 not found).  (16 
> minutes)
> 
> With CLOSE_DELAY = 1.0 and WRITE_PAD = 0.03
> Worked,  20 minutes.

Yuck.  Those are some horrible test times.  uitting in worst-case
delays is functionally a problem because I want running the regression
tests to be a low-friction process, so it gets done frequently.



> I don't know my way around the scons-check setup.  What does stuff like this 
> mean:
> 
>  $GPGSA,A,3,01,11,29,03,28,30,,,,,,,5.2,3.1,3.4*30
> -$GPGBS,055156,31.47,M,35.54,M,78.20,M*07
> {"class":"TPV","tag":"SS2-20","mode":3,"time":"2009-07-04T05:51:56.000Z","ept":0.005,"lat":53.563090391,"lon":-113.439569974,"alt":631.192,"epx":31.470,"epy":35.543,"epv":78.200,"track":0.0000,"speed":0.000,"climb":0.000,"eps":71.09,"epc":156.40}
> 
> Is that "-" an indication of a missing line?  (as in diff printout)

It is, yes.  Usually means trailing input to a pty just befdore device
close is getting dropped.  I do not know why this happens; as you see,
the padding required to prevent it is both OS- and hardware-dependent.

> Is it time to really debug this stuff?  I'll collect lots of logging
> output or run tests if you tell me what to do.  Or I can set things
> up so you can ssh to that box.

Alas, I believe this problem is below any level we can easily reach,
and due to a race condition either in the Python implementation or the
kernel pty code.  Chasing it from where we are seems unlikely to
be successful.
-- 
                <a href="http://www.catb.org/~esr/";>Eric S. Raymond</a>