FreeBSD Tinderbox | 1 Apr 01:07 2004
Picon

[current tinderbox] failure on amd64/amd64

TB --- 2004-03-31 22:07:13 - tinderbox 2.3 running on freebsd-current.sentex.ca
TB --- 2004-03-31 22:07:13 - starting CURRENT tinderbox run for amd64/amd64
TB --- 2004-03-31 22:07:13 - checking out the source tree
TB --- 2004-03-31 22:07:13 - cd /home/tinderbox/sandbox/CURRENT/amd64/amd64
TB --- 2004-03-31 22:07:13 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src
TB --- 2004-03-31 22:12:05 - building world (CFLAGS=-O2 -pipe)
TB --- 2004-03-31 22:12:05 - cd /home/tinderbox/sandbox/CURRENT/amd64/amd64/src
TB --- 2004-03-31 22:12:05 - /usr/bin/make -B buildworld
>>> Rebuilding the temporary build tree
>>> stage 1.1: legacy release compatibility shims
>>> stage 1.2: bootstrap tools
>>> stage 2.1: cleaning up the object tree
>>> stage 2.2: rebuilding the object tree
>>> stage 2.3: build tools
>>> stage 3: cross tools
>>> stage 4.1: building includes
>>> stage 4.2: building libraries
>>> stage 4.3: make dependencies
>>> stage 4.4: building everything
[...]
===> usr.sbin/ndc
cc -O2 -pipe 
-I/other/tinderbox/CURRENT/amd64/amd64/src/usr.sbin/ndc/../../contrib/bind/port/freebsd/include
 -I/other/tinderbox/CURRENT/amd64/amd64/src/usr.sbin/ndc/../../contrib/bind/bin/named
-I/other/tinderbox/CURRENT/amd64/amd64/src/usr.sbin/ndc/../../contrib/bind/include -I.  -c /other/tinderbox/CURRENT/amd64/amd64/src/contrib/bind/bin/ndc/ndc.c
cc -O2 -pipe 
-I/other/tinderbox/CURRENT/amd64/amd64/src/usr.sbin/ndc/../../contrib/bind/port/freebsd/include
 -I/other/tinderbox/CURRENT/amd64/amd64/src/usr.sbin/ndc/../../contrib/bind/bin/named
-I/other/tinderbox/CURRENT/amd64/amd64/src/usr.sbin/ndc/../../contrib/bind/include -I.   -o
ndc ndc.o /other/tinderbox/CURRENT/amd64/amd64/obj/amd64/other/tinderbox/CURRENT/amd64/amd64/src/usr.sbin/ndc/../../lib/libbind/libbind.a
(Continue reading)

Kris Kennaway | 1 Apr 01:43 2004

Re: LOR

On Wed, Mar 31, 2004 at 08:15:17PM +0100, Bob Bishop wrote:
> Hi,
> 
> 1st 0xc22019cc vm object (vm object)  <at>  /usr/src/sys/vm/swap_pager.c:1313
>  2nd 0xc08b7ac0 swap_pager swhash (swap_pager swhash)  <at>  
> /usr/src/sys/vm/swap_pager.c:1803
>  3rd 0xc1040948 vm object (vm object)  <at>  /usr/src/sys/vm/uma_core.c:886

FAQ, harmless.

Kris
Hideyuki KURASHINA | 1 Apr 01:50 2004
Picon

Re: Comments: pflog rc.d-script


>>> On Wed, 31 Mar 2004 18:22:35 +0000, Max Laier <max <at> love2party.net> said:

> Here it is, please try and give me feedback as I plan to commit this soon. 

Why pflog_logfile in etc/defaults/rc.conf (/var/log/pflogd) is not same as
one in etc/rc.d/pflog (/var/log/pflog) ?

-- rushani
_______________________________________________
freebsd-current <at> freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscribe <at> freebsd.org"

Oliver Eikemeier | 1 Apr 02:59 2004

Re: nss_ldap broken

Daniel Eischen wrote:

> Too bad these shared libraries can't be made to use
> the libgcc trick, so they can still be thread-safe
> but not depend on a threads library.

Sorry to ask stpid questions, but what is `the libgcc
trick' here?

-Oliver
_______________________________________________
freebsd-current <at> freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscribe <at> freebsd.org"

llewelly | 1 Apr 03:28 2004

Re: ongoing mozilla problems

Chris Shenton <chris <at> shenton.org> writes:

> Nate Lawson <nate <at> root.org> writes:
> 
> > On Tue, 9 Mar 2004, Joe Marcus Clarke wrote:
> >> On Tue, 2004-03-09 at 00:58, Nate Lawson wrote:
> >> > Any page that includes links to imgs on other pages hangs while loading.
> >>
> >> At least one user has reported that an old IPv6-related resolver bug has
> >> resurfaced in 1.6-based browsers.  If you have IPv6 in your kernel, you
> >> might try removing it temporarily (if you can) to see if this helps
> >> matters.  Other users have reported similar hangs in the past when
> >> trying to load images off of ad caching servers. 
> >
> > I disabled IPv6 and it appears to be working fine again.
> 
> I noticed this on my home 5.2-CURRENT systems with Mozilla-1.6.  When
> I just upgraded my work's 4.9-STABLE system with Moz-1.6 via
> portupgrade and now I see it there too.
> 
> At home I can't disable IPv6 on CURRENT as X11R6-4.3.99.12 seems to
> need it to work.

I ran into this issue too. I put:

#define BuildIPv6		NO

in xc/xc/config/cf/host.def

and recompiled. Then X11 ran fine without ipv6.
(Continue reading)

FreeBSD Tinderbox | 1 Apr 03:59 2004
Picon

[current tinderbox] failure on i386/pc98

TB --- 2004-04-01 00:45:03 - tinderbox 2.3 running on freebsd-current.sentex.ca
TB --- 2004-04-01 00:45:03 - starting CURRENT tinderbox run for i386/pc98
TB --- 2004-04-01 00:45:03 - checking out the source tree
TB --- 2004-04-01 00:45:03 - cd /home/tinderbox/sandbox/CURRENT/i386/pc98
TB --- 2004-04-01 00:45:03 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src
TB --- 2004-04-01 00:50:07 - building world (CFLAGS=-O2 -pipe)
TB --- 2004-04-01 00:50:07 - cd /home/tinderbox/sandbox/CURRENT/i386/pc98/src
TB --- 2004-04-01 00:50:07 - /usr/bin/make -B buildworld
>>> Rebuilding the temporary build tree
>>> stage 1.1: legacy release compatibility shims
>>> stage 1.2: bootstrap tools
>>> stage 2.1: cleaning up the object tree
>>> stage 2.2: rebuilding the object tree
>>> stage 2.3: build tools
>>> stage 3: cross tools
>>> stage 4.1: building includes
>>> stage 4.2: building libraries
>>> stage 4.3: make dependencies
>>> stage 4.4: building everything
TB --- 2004-04-01 01:46:17 - building generic kernel (COPTFLAGS=-O2 -pipe)
TB --- 2004-04-01 01:46:17 - cd /home/tinderbox/sandbox/CURRENT/i386/pc98/src
TB --- 2004-04-01 01:46:17 - /usr/bin/make buildkernel KERNCONF=GENERIC
>>> Kernel build for GENERIC started on Thu Apr  1 01:46:17 GMT 2004
>>> stage 1: configuring the kernel
>>> stage 2.1: cleaning up the object tree
>>> stage 2.2: rebuilding the object tree
>>> stage 2.3: build tools
>>> stage 3.1: making dependencies
>>> stage 3.2: building everything
>>> Kernel build for GENERIC completed on Thu Apr  1 01:59:31 GMT 2004
(Continue reading)

jason | 1 Apr 04:56 2004
Picon

help with acpi on nforce

I have been to the how-to site giving on the list before, but I have a 
problem I could not find answers to.  Here is a copy of what I get:

barton# iasl -d epox.asl

Intel ACPI Component Architecture
ASL Optimizing Compiler / AML Disassembler version 20040311 [Mar 26 2004]
Copyright (C) 2000 - 2004 Intel Corporation
Supports ACPI Specification Revision 2.0c

Loading Acpi table from file epox.asl
 tbutils-0221: *** Warning: Invalid table signature found: [/*
 ]
Table header is invalid!
Couldn't get table from the file
barton#

Does anyone have a acpidump from a nforce2 product that has good headers 
I could try?  I'll post my asl file if anyone would like to take a look 
at it.
_______________________________________________
freebsd-current <at> freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscribe <at> freebsd.org"

Daryl Chance | 1 Apr 05:10 2004
Picon

FBSD 5.2.1-p4 and mysqld problems

we are having a couple problems with mysql on FreeBSD
5.2.1

the dmesg is located here:
http://sql.tribalwar.com/dmesg.today

It's just a generic config with IPv6 removed and the
ix86 stuff removed (just i686 left).

one of the problems we are having is that there is 1
specific table in the db (and it's only 1 database too
that this happens) is getting corrupted and forcing us
to have to repair it.  This one could just be a
problem with mysql and it's just accelerated w/ using
it on FreeBSD 5.x.  We haven't nailed any specific
time that this happens nor any specific
insert/select/update that could cause it.  Is there
any way to verify (through FreeBSD userland commands
or ports that you may know of) that this isn't a drive
problem?  Is there something I can run on FBSD that
will help me to track this problem down (perhaps some
sort of GEOM logging)?

the other problem we are having is that mysql will
lock up.  1 of the mysqld processes freezes (uses up
all the cpu) and it won't allow anymore queries
against it until we shutdown.  Is there any way for me
to debug this and find out where it is hanging?  Is
there a working alternative to truss?  Or should I
just compile option PROCFS in and use it next time it
(Continue reading)

FreeBSD Tinderbox | 1 Apr 06:02 2004
Picon

[current tinderbox] failure on ia64/ia64

TB --- 2004-04-01 01:59:32 - tinderbox 2.3 running on freebsd-current.sentex.ca
TB --- 2004-04-01 01:59:32 - starting CURRENT tinderbox run for ia64/ia64
TB --- 2004-04-01 01:59:32 - checking out the source tree
TB --- 2004-04-01 01:59:32 - cd /home/tinderbox/sandbox/CURRENT/ia64/ia64
TB --- 2004-04-01 01:59:32 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src
TB --- 2004-04-01 02:04:45 - building world (CFLAGS=-O2 -pipe)
TB --- 2004-04-01 02:04:45 - cd /home/tinderbox/sandbox/CURRENT/ia64/ia64/src
TB --- 2004-04-01 02:04:45 - /usr/bin/make -B buildworld
>>> Rebuilding the temporary build tree
>>> stage 1.1: legacy release compatibility shims
>>> stage 1.2: bootstrap tools
>>> stage 2.1: cleaning up the object tree
>>> stage 2.2: rebuilding the object tree
>>> stage 2.3: build tools
>>> stage 3: cross tools
>>> stage 4.1: building includes
>>> stage 4.2: building libraries
>>> stage 4.3: make dependencies
>>> stage 4.4: building everything
TB --- 2004-04-01 03:37:28 - building generic kernel (COPTFLAGS=-O2 -pipe)
TB --- 2004-04-01 03:37:28 - cd /home/tinderbox/sandbox/CURRENT/ia64/ia64/src
TB --- 2004-04-01 03:37:28 - /usr/bin/make buildkernel KERNCONF=GENERIC
>>> Kernel build for GENERIC started on Thu Apr  1 03:37:28 GMT 2004
>>> stage 1: configuring the kernel
>>> stage 2.1: cleaning up the object tree
>>> stage 2.2: rebuilding the object tree
>>> stage 2.3: build tools
>>> stage 3.1: making dependencies
>>> stage 3.2: building everything
>>> Kernel build for GENERIC completed on Thu Apr  1 04:02:48 GMT 2004
(Continue reading)

Daniel Eischen | 1 Apr 08:17 2004

Re: nss_ldap broken

On Thu, 1 Apr 2004, Oliver Eikemeier wrote:

> Daniel Eischen wrote:
> 
> > Too bad these shared libraries can't be made to use
> > the libgcc trick, so they can still be thread-safe
> > but not depend on a threads library.
> 
> Sorry to ask stpid questions, but what is `the libgcc
> trick' here?

See one of my previous posts to this thread WRT #pragma weak.

Another option pointed out, is just to make sure libc
has all the necessary hooks (I think it does) and don't
link shared libraries to libpthread.

--

-- 
Dan Eischen

_______________________________________________
freebsd-current <at> freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscribe <at> freebsd.org"


Gmane