Andreas Gustafsson | 1 Aug 2011 16:27

Automated regression tests of NetBSD/sparc failing

Hello NetBSD/sparc users,

The NetBSD project now has a server dedicated to automated regression
testing of NetBSD-current, running the ATF test suite on daily (or
more frequent) builds in qemu virtual machines.  The first two ports
being tested are i386 and sparc; the sparc results are available at

    http://releng.netbsd.org/b5reports/sparc/

Alas, the tests are not yet fully working on sparc.  The first 134 ATF
tests run fine, and most of them succeed, but at one point during the
fs/vfs/t_vnops test, test cases start timing out, ultimately causing
the test run as a whole to time out.  Here is an extract from the ATF
log output around the point where things start to go wrong:

    p2k_ffs_rename_dotdot: Passed.
    p2k_ffs_rename_nametoolong: Passed.
    p2k_ffs_rename_reg_nodir: Passed.
    p2k_ffs_symlink_zerolen: Passed.
    puffs_access_simple: Failed: Test case timed out after 300 seconds
    puffs_attrs: Failed: Test case timed out after 300 seconds
    puffs_create_exist: Failed: Test case timed out after 300 seconds
    puffs_create_nametoolong: Failed: Test case timed out after 300 seconds
    puffs_dir_notempty: Failed: Test case timed out after 300 seconds
    puffs_dir_rmdirdotdot: Failed: Test case timed out after 300 seconds

The complete log output is at

  http://releng.netbsd.org/b5reports/sparc/build/2011.07.31.23.10.58/test.log

(Continue reading)

matthew green | 1 Aug 2011 21:08
Picon
Favicon

re: Automated regression tests of NetBSD/sparc failing


> Alas, the tests are not yet fully working on sparc.  The first 134 ATF
> tests run fine, and most of them succeed, but at one point during the
> fs/vfs/t_vnops test, test cases start timing out, ultimately causing
> the test run as a whole to time out.  Here is an extract from the ATF
> log output around the point where things start to go wrong:

what i see going on when i run atf natively is that rump_server processes
do not exit, but spin on the CPU.  the time out happens when there are
eventually dozens of these all competing for the CPU, and the rest of the
atf run gets very little CPU.

so, this problem seems pretty specific to either rump server or maybe
the sparc pthreads support...

.mrg.

Martin Husemann | 1 Aug 2011 21:12
Picon

Re: Automated regression tests of NetBSD/sparc failing

On Tue, Aug 02, 2011 at 05:08:26AM +1000, matthew green wrote:
> so, this problem seems pretty specific to either rump server or maybe
> the sparc pthreads support...

The latter would be my bet too (noting that not all pthread tests pass).

Martin

Dan Oglesby | 15 Aug 2011 02:13
Favicon

Anyone looking for PROM updates for older SPARC hardware?

A while back I bought an EEPROM programmer with the intention of upgrading my SPARCStation 2 to a more recent
version of PROM.  This was brought about due to trouble booting from the floppies and CD-ROM for the NetBSD
project.  It was guessed that some of the older versions of PROM had trouble booting the newer releases of NetBSD.

Anyways, I finally have a Windows XP machine again, and got the hardware and software running for my
programmer.  I was able to update my SS2 system to the 2.9 version of PROM, and it boots successfully from the
NetBSD 5.1 release CD-ROM.  

I know there was at least one other person on this list interested in getting an updated PROM for their SS2.  If
anyone out there would like a spare PROM with version 2.9 loaded for their SS2 or IPC, let me know.  I have nine
AM27C020 chips that are blanked and ready to be programmed.

If there is any interest in PROM chips for other SPARC systems, let me know.  I have working SS20 and SS5
systems that I can pull ROM images from if they can help others.

--Dan

matthew green | 15 Aug 2011 04:33
Picon
Favicon

call for GCC 4.5.3 testers


hi folks.

for the brave souls running -current, i have an extra request of
you :)  i'd like to switch to GCC 4.5.3 on sparc by default but
first i'd like to hear from others about their experiences with
it.  i've had only one real issue that i've just commited a
workaround to -current for and will hopefully be able to figure
the real bug out sometime soon.

all you need to do is set HAVE_GCC=45 in your build environemnt
(build.sh -V, mk.conf, environment, etc.)  i recommend a clean
objdir to build from, it's pretty nasty trying to clean up after
old builds, but it might be worth doing for a native build.

please let me know of any success or failure!  thanks.

.mrg.

Hauke Fath | 15 Aug 2011 17:39
Picon

Re: call for GCC 4.5.3 testers

At 12:33 Uhr +1000 15.08.2011, matthew green wrote:
>please let me know of any success or failure!  thanks.

Building with

NAMED_USE_PTHREADS= no

(for obvious reasons, like named processes ballooning to 50 MB, and dig
busy-looping at 100% cpu) fails with

[...]
#   compile  libisc/condition.o
/u/netbsd-builds/developer/sparc/tools/bin/sparc--netbsdelf-gcc -O2
-std=gnu99  -Wall -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith
-Wno-sign-compare  -Wno-traditional  -Wa,--fatal-warnings -Werror
-Wno-pointer-sign -fstack-protector -Wstack-protector   --param
ssp-buffer-size=1   --sysroot=/u/netbsd-builds/developer/sparc/destdir
-I/public/netbsd-developer/external/bsd/bind/include
-I/public/netbsd-developer/external/bsd/bind/dist
-I/public/netbsd-developer/external/bsd/bind/dist/lib/dns/include
  -I/public/netbsd-developer/external/bsd/bind/dist/lib/isc/include
-I/public/netbsd-developer/external/bsd/bind/dist/lib/isc/unix/include
-I/public/netbsd-developer/external/bsd/bind/dist/lib/bind9/include
-I/public/netbsd-developer/external/bsd/bind/dist
/lib/isccfg/include
-I/public/netbsd-developer/external/bsd/bind/dist/lib/isccc/include
-I/public/netbsd-developer/external/bsd
/bind/dist/lib/lwres/include
-I/public/netbsd-developer/external/bsd/bind/dist/lib/lwres/unix/include
-DNS_LOCALSTATEDIR=\"/var\"  -DNS_SYSCONFDIR=\"/etc\"
(Continue reading)

matthew green | 15 Aug 2011 20:05
Picon
Favicon

re: call for GCC 4.5.3 testers


> /public/netbsd-developer/external/bsd/bind/dist/lib/isc/nothreads/condition.c:26:1:
> error: 'isc__empty' defined but not used
> *** [condition.o] Error code 1
> nbmake: stopped in /public/netbsd-developer/external/bsd/bind/lib/libisc
> 1 error
> 
> where EMPTY_TRANSLATION_UNIT aka isc__empty() is #defined in
> external/bsd/bind/dist/lib/isc/include/isc/util.h.

try making this line be:

#define EMPTY_TRANSLATION_UNIT static void isc__empty(void) { }

.mrg.

David Laight | 15 Aug 2011 20:14
Picon

Re: call for GCC 4.5.3 testers

On Tue, Aug 16, 2011 at 04:05:54AM +1000, matthew green wrote:
> 
> > /public/netbsd-developer/external/bsd/bind/dist/lib/isc/nothreads/condition.c:26:1:
> > error: 'isc__empty' defined but not used
> > *** [condition.o] Error code 1
> > nbmake: stopped in /public/netbsd-developer/external/bsd/bind/lib/libisc
> > 1 error
> > 
> > where EMPTY_TRANSLATION_UNIT aka isc__empty() is #defined in
> > external/bsd/bind/dist/lib/isc/include/isc/util.h.
> 
> try making this line be:
> 
> #define EMPTY_TRANSLATION_UNIT static void isc__empty(void) { }

Something like
extern int foo;
is probably safer...
Always used to be enough to avoid the 'empty translation unit' message.

	David

--

-- 
David Laight: david <at> l8s.co.uk

Hauke Fath | 17 Aug 2011 09:30
Picon

Re: call for GCC 4.5.3 testers

At 12:33 Uhr +1000 15.8.2011, matthew green wrote:
>please let me know of any success or failure!  thanks.

Sooo...

With the following change (gcc wouldn't have an empty function body in this
place), HEAD builds:

Index: external/bsd/bind/dist/lib/isc/include/isc/util.h
===================================================================
RCS file: /cvsroot/src/external/bsd/bind/dist/lib/isc/include/isc/util.h,v
retrieving revision 1.4
diff -u -u -r1.4 util.h
--- external/bsd/bind/dist/lib/isc/include/isc/util.h   16 Feb 2011
03:47:13 -0000      1.4
+++ external/bsd/bind/dist/lib/isc/include/isc/util.h   17 Aug 2011
07:23:19 -0000
 <at>  <at>  -72,7 +72,7  <at>  <at> 
  * Use this in translation units that would otherwise be empty, to
  * suppress compiler warnings.
  */
-#define EMPTY_TRANSLATION_UNIT static void isc__empty(void) { isc__empty(); }
+#define EMPTY_TRANSLATION_UNIT extern int isc__empty;

 /*
  * We use macros instead of calling the routines directly because

% uname -a
NetBSD pizza.causeuse.org 5.99.55 NetBSD 5.99.55 (PIZZA_PF) #0: Tue Aug 16
18:26:18 CEST 2011
(Continue reading)

matthew green | 17 Aug 2011 11:19
Picon
Favicon

re: call for GCC 4.5.3 testers


OK, i've switched the default to GCC 4.5.3.  my own testing has
also been pretty successful.  i'll figure out the isc__empty
thing sometime soon.

thanks for testing, and now beware everyone else :)

.mrg.


Gmane