headers
NetBSD source update | 1 Dec 2011 04:13
Picon

daily CVS update output


Updating src tree:
P src/sys/arch/algor/conf/P4032
P src/sys/arch/evbarm/conf/MV2120
P src/sys/arch/evbarm/conf/mk.mv2120
P src/sys/dev/fss.c
P src/sys/kern/kern_ktrace.c
P src/usr.bin/quota/quota.c
U src/usr.sbin/user/pathnames.h
P src/usr.sbin/user/user.c

Updating xsrc tree:

Killing core files:

Running the SUP scanner:
SUP Scan for current starting at Thu Dec  1 03:04:07 2011
SUP Scan for current completed at Thu Dec  1 03:04:23 2011
SUP Scan for mirror starting at Thu Dec  1 03:04:23 2011
SUP Scan for mirror completed at Thu Dec  1 03:08:37 2011

Updating file list:
-rw-rw-r--  1 srcmastr  netbsd  49617285 Dec  1 03:13 ls-lRA.gz
Permalink | Reply | 0 comments |
headers
David Young | 1 Dec 2011 05:28
Picon
Favicon

Re: using MKDTRACE=yes on -current

On Wed, Nov 30, 2011 at 03:59:55PM -0600, David Young wrote:
> I'm trying to build kernel + userland with DTrace enabled, and hitting
> several roadblocks along the way.  Today:
> 
> --- dependall-games ---
> /home/dyoung/nbsd/T/bin/nbctfmerge -t -L VERSION -g -o adventure main.o init.o done.o save.o subr.o
vocab.o wizard.o io.o data.o crc.o
> ERROR: nbctfmerge: Input file data.o was partially built from C sources, but no CTF data was present
> Removing adventure
> *** [adventure] Error code 1
> nbmake: stopped in /home/dyoung/nbsd/src/games/adventure
> 1 error
> nbmake: stopped in /home/dyoung/nbsd/src/games/adventure
> *** [dependall] Error code 2
> 
> I won't need to DTrace adventure.  Is there an easy way to work around
> this?

This may have something to do with my using 'build.sh -j 8'.

I just ran 'nbmake-i386 obj cleandir dependall' in games/adventure/
without problems. 'nbmake-i386 -j 8 obj cleandir dependall' sometimes
works but sometimes fails.

Dave

--

-- 
David Young
dyoung <at> pobox.com    Urbana, IL    (217) 721-9981
(Continue reading)

Permalink | Reply | 2 comments |
headers
David Holland | 1 Dec 2011 06:24
Picon

Re: using MKDTRACE=yes on -current

On Wed, Nov 30, 2011 at 10:28:06PM -0600, David Young wrote:
 > > --- dependall-games ---
 > > /home/dyoung/nbsd/T/bin/nbctfmerge -t -L VERSION -g -o adventure main.o init.o done.o save.o subr.o
vocab.o wizard.o io.o data.o crc.o
 > > ERROR: nbctfmerge: Input file data.o was partially built from C sources, but no CTF data was present
 > > Removing adventure
 > > *** [adventure] Error code 1
 > > nbmake: stopped in /home/dyoung/nbsd/src/games/adventure
 > > 1 error
 > > nbmake: stopped in /home/dyoung/nbsd/src/games/adventure
 > > *** [dependall] Error code 2
 > > 
 > > I won't need to DTrace adventure.  Is there an easy way to work around
 > > this?
 > 
 > This may have something to do with my using 'build.sh -j 8'.
 > 
 > I just ran 'nbmake-i386 obj cleandir dependall' in games/adventure/
 > without problems. 'nbmake-i386 -j 8 obj cleandir dependall' sometimes
 > works but sometimes fails.

data.c is a generated file; that's about the only thing special about
either data.o or adventure. Are the rules for this nbctfmerge thingy
depending on all the things they need to?

--

-- 
David A. Holland
dholland <at> netbsd.org
(Continue reading)

Permalink | Reply | 0 comments |
headers
Andreas Gustafsson | 1 Dec 2011 08:41

Re: ATF tests still failing to complete within 2 hours on amd64

Last week, Thor Lancelot Simon wrote:
> When I run them as individual test cases rather than in sequence, some
> of them work fine; then others fail because rump processes from earlier
> cases are dangling.  Others do seem to take a very long time but finally
> complete.

Strangely, amd64 and i386 are behaving very differently - on i386, the
tests are not timing out, and there are no dangling rump processes,
just a bunch of failing networking related tests.  To verify that no
rump processes are dangling, I'm now running "ps -glaxw" after the
tests on my own test server, like at the end of this log:

  http://www.gson.org/netbsd/bugs/build/build/2011.11.30.20.00.39/test.log

--

-- 
Andreas Gustafsson, gson <at> gson.org
Permalink | Reply | 39 comments |
headers
Michael van Elst | 1 Dec 2011 08:52
Picon

Re: ATF tests still failing to complete within 2 hours on amd64

gson <at> gson.org (Andreas Gustafsson) writes:

>Strangely, amd64 and i386 are behaving very differently - on i386, the
>tests are not timing out, and there are no dangling rump processes,
>just a bunch of failing networking related tests.  To verify that no
>rump processes are dangling, I'm now running "ps -glaxw" after the
>tests on my own test server, like at the end of this log:

>  http://www.gson.org/netbsd/bugs/build/build/2011.11.30.20.00.39/test.log

I'm running the tests for arch/amiga, some tests fail "randomly",
in particular the net/icmp tests seem to fail when run in a tight
sequence or repeatedly. With some delay they work again.

-- 
--

-- 
                                Michael van Elst
Internet: mlelstv <at> serpens.de
                                "A potential Snark may lurk in every tree."
Permalink | Reply | 0 comments |
headers
Evgeniy Ivanov | 1 Dec 2011 11:14
Picon

Can't build recent HEAD

Hi,

I can't build recent (checked out yesterday) distribution for several
days. Though http://releng.netbsd.org/b5reports/i386/commits-2011.11.html#end
says that everything is OK.
TOOLDIR is /usr/tools. Tools were rebuilt. I do "./build.sh -O ../obj
distribution":

/usr/tools/bin/i486--netbsdelf-ar crsD libopcodes.a
`NM=/usr/tools/bin/i486--netbsdelf-nm
NM=/usr/tools/bin/i486--netbsdelf-nm MKTEMP=/usr/tools/bin/nbmktemp
/usr/tools/bin/nblorder i386-dis.o i386-opc.o dis-buf.o disassemble.o
dis-init.o | /usr/tools/bin/nbtsort -q`
dependall ===> external/gpl3/gdb/lib/libgdb
nbmake: don't know how to make ada-exp.c. Stop

nbmake: stopped in /usr/src/external/gpl3/gdb/lib/libgdb

*** Failed target:  dependall-libgdb

--

-- 
Evgeniy Ivanov
Permalink | Reply | 0 comments |
headers
Matthias Scheler | 1 Dec 2011 13:44
Picon
Favicon

Re: using MKDTRACE=yes on -current

On Wed, Nov 30, 2011 at 10:28:06PM -0600, David Young wrote:
> > --- dependall-games ---
> > /home/dyoung/nbsd/T/bin/nbctfmerge -t -L VERSION -g -o adventure main.o init.o done.o save.o subr.o
vocab.o wizard.o io.o data.o crc.o
> > ERROR: nbctfmerge: Input file data.o was partially built from C sources, but no CTF data was present
> > Removing adventure
> > *** [adventure] Error code 1
> > nbmake: stopped in /home/dyoung/nbsd/src/games/adventure
> > 1 error
> > nbmake: stopped in /home/dyoung/nbsd/src/games/adventure
> > *** [dependall] Error code 2
> > 
> > I won't need to DTrace adventure.  Is there an easy way to work around
> > this?
> 
> This may have something to do with my using 'build.sh -j 8'.
> 
> I just ran 'nbmake-i386 obj cleandir dependall' in games/adventure/
> without problems. 'nbmake-i386 -j 8 obj cleandir dependall' sometimes
> works but sometimes fails.

I've run a complete "build.sh -j 12 ..." with "MKDTRACE" set to "yes"
on a six core machine yesterday. The build completed without problems.

	Kind regards

--

-- 
Matthias Scheler                                  http://zhadum.org.uk/
(Continue reading)

Permalink | Reply | 0 comments |
headers
Thor Lancelot Simon | 1 Dec 2011 16:12
Picon
Favicon

Re: ATF tests still failing to complete within 2 hours on amd64

On Thu, Dec 01, 2011 at 09:41:02AM +0200, Andreas Gustafsson wrote:
> Last week, Thor Lancelot Simon wrote:
> > When I run them as individual test cases rather than in sequence, some
> > of them work fine; then others fail because rump processes from earlier
> > cases are dangling.  Others do seem to take a very long time but finally
> > complete.
> 
> Strangely, amd64 and i386 are behaving very differently - on i386, the
> tests are not timing out, and there are no dangling rump processes,
> just a bunch of failing networking related tests.  To verify that no

Does this persist after my changes to use the libc arc4random() in rump?
It should be the case that rump is now pretty much totally unhooked from
the standard kernel entropy framework (for better or worse -- from my point
of view, "better", because there was not really any testing of the entropy
framework as it was in the real kernel via rump, due to the ifdef mess with
all the special hacks).

Thor
Permalink | Reply | 17 comments |
headers
Martin Husemann | 1 Dec 2011 16:19
Picon

Re: ATF tests still failing to complete within 2 hours on amd64

On Thu, Dec 01, 2011 at 10:12:38AM -0500, Thor Lancelot Simon wrote:
> Does this persist after my changes to use the libc arc4random() in rump?
> It should be the case that rump is now pretty much totally unhooked from
> the standard kernel entropy framework (for better or worse -- from my point
> of view, "better", because there was not really any testing of the entropy
> framework as it was in the real kernel via rump, due to the ifdef mess with
> all the special hacks).

I did a run with current from this morning on (real) sparc64 hardware and
only saw strange rump failures, that do not clearly look entropy related
to me...

http://www.netbsd.org/~martin/sparc64-atf/69_atf.html#failed-tcs-summary

Martin
Permalink | Reply | 10 comments |
headers
Paul Goyette | 1 Dec 2011 16:24

Re: ATF tests still failing to complete within 2 hours on amd64

Yes, amd64 tests are still failing with today's -current

On Thu, 1 Dec 2011, Thor Lancelot Simon wrote:

> On Thu, Dec 01, 2011 at 09:41:02AM +0200, Andreas Gustafsson wrote:
>> Last week, Thor Lancelot Simon wrote:
>>> When I run them as individual test cases rather than in sequence, some
>>> of them work fine; then others fail because rump processes from earlier
>>> cases are dangling.  Others do seem to take a very long time but finally
>>> complete.
>>
>> Strangely, amd64 and i386 are behaving very differently - on i386, the
>> tests are not timing out, and there are no dangling rump processes,
>> just a bunch of failing networking related tests.  To verify that no
>
> Does this persist after my changes to use the libc arc4random() in rump?
> It should be the case that rump is now pretty much totally unhooked from
> the standard kernel entropy framework (for better or worse -- from my point
> of view, "better", because there was not really any testing of the entropy
> framework as it was in the real kernel via rump, due to the ifdef mess with
> all the special hacks).
>
> Thor
>
> !DSPAM:4ed799801969615822199!
>
>
>

-------------------------------------------------------------------------
(Continue reading)

Permalink | Reply | 0 comments |

Gmane