When disabling and enabling a nic (bfe0) my system warm boots itself (sometimes)
On Mon, 15 Nov 2004 12:01:09 +0000 (GMT),
freebsd-stable-request@freebsd.org
<freebsd-stable-request@freebsd.org> wrote:> Send freebsd-stable mailing list submissions to
> freebsd-stable@freebsd.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> http://lists.freebsd.org/mailman/listinfo/freebsd-stable
> or, via email, send a message with subject or body 'help' to
> freebsd-stable-request@freebsd.org
>
> You can reach the person managing the list at
> freebsd-stable-owner@freebsd.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of freebsd-stable digest..."
>
> Today's Topics:
>
> 1. subscription to 5.3 stable mailing list, thanks (marco foglia)
> 2. Re: IPv6 bridge + gif tunnel (Hideki Yamamoto)
> 3. Re: Build of RELENG_5 fails in libmagic (Massimiliano Stucchi)
> 4. Can't compile 5.3-STABLE from 5.3-RC2 (Ralf Folkerts)
> 5. new threads problem? pthread_cond_timedwait ? (David Gilbert)
> 6. Either I do something wrong or there is a regexp bug in sed
> !! (Zoltan Frombach)
> 7. Re: Either I do something wrong or there is a regexp bug in
> sed !! (Brandon S. Allbery KF8NH)
> 8. Re: Can't compile 5.3-STABLE from 5.3-RC2 (Alex de Kruijff)
> 9. Re: Either I do something wrong or there is a regexp bug in
> sed !! (Zoltan Frombach)
> 10. Re: Either I do something wrong or there is a regexp bug in
> sed !! (Bj?rn K?nig)
> 11. New 5.x packages uploaded (Kris Kennaway)
> 12. New 5.x packages uploaded (Kris Kennaway)
> 13. Re: Either I do something wrong or there is a regexp bug in
> sed !! (Maxime Henrion)
> 14. Re: Either I do something wrong or there is a regexp bug in
> sed !! (Zoltan Frombach)
> 15. Re: New 5.x packages uploaded (Matthias Andree)
> 16. Re: New 5.x packages uploaded (Kris Kennaway)
> 17. Re: New 5.x packages uploaded (Matthias Andree)
> 18. Re: New 5.x packages uploaded (Kris Kennaway)
> 19. gvinum setstate missing? (Zaphod Beeblebrox)
> 20. SIIG cards and puc (Paul Sandys)
> 21. panic: APIC: Previous IPI is stuck (Adrian Wontroba)
> 22. gvinum again? (Zaphod Beeblebrox)
> 23. Re: msdosfs - support for large disks? (Torfinn Ingolfsen)
> 24. Re: gvinum again? (Paul Mather)
> 25. Re: gvinum again? (Zaphod Beeblebrox)
> 26. (Andrei Grudiy)
> 27. Re: panic: APIC: Previous IPI is stuck (Adrian Wontroba)
> 28. 100.chksetuid in /etc/periodic/security resets the mashine
> (Andrei Grudiy)
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Sun, 14 Nov 2004 15:05:24 +0100
> From: marco foglia <priv@tucsoft.com>
> Subject: subscription to 5.3 stable mailing list, thanks
> To: stable@FreeBSD.org
> Message-ID: <41976624.4020103@tucsoft.com>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
> ------------------------------
>
> Message: 2
> Date: Sun, 14 Nov 2004 23:24:23 +0900 (JST)
> From: Hideki Yamamoto <yamamoto436@oki.com>
> Subject: Re: IPv6 bridge + gif tunnel
> To: freebsd-stable@freebsd.org, freebsd-ipfw@freebsd.org
> Message-ID: <20041114.232423.71097254.yamamoto436@oki.com>
> Content-Type: Text/Plain; charset=us-ascii
>
> Hi,
>
> About the combination between bridge function and gif tunnel function,
> I have tested it on FreeBSD 4.10, but not succeeded. FreeBSD 4.10 box
> shows the message when we typed 'sysctl
net.link.ether.bridge_cfg=rl0,gif0',
>
> gif0 is not an ethernet, continue
> interface gif0 Not found in bridge.
>
> I changed operating system from FreeBSD to OpneBSD 3.5, and succeeded.
> Multicast and unicast UDP packets, ICMP packets are bridged without
> losing packets. It seems that the bridge function on OpenBSD is
> better than FreeBSD. Though I will use OpenBSD for a while as a test
> tool, I hope OpenBSD bridge function will be ported into FreeBSD in
> the future. Does anyone have a plan to port it?
>
> Regards,
>
> Hideki Yamamoto.
>
> From: Hideki Yamamoto <yamamoto436@oki.com>
> Subject: Re: IPv6 bridge + gif tunnel
> Date: Sun, 07 Nov 2004 06:15:47 +0900 (JST)
> Message-ID: <20041107.061547.71182690.yamamoto436@oki.com>
>
> >
> > Hi,
> >
> > I would like to make my problems clear.
> > I have two questions about bridge function in the following figure.
> >
> > (1) Can we use bridge function over psuedo devices such as
> > gif and tun?
> >
> > box3# ifconfig bge0 inet 133.149.0.2 netmask 255.255.255.0
> > box2# ifconfig create gif0
> > box2# gifconfig gif0 inet 133.149.0.2 133.149.1.2
> > box2# sysctl net.link.ether.bridge: 1
> > box2# sysctl net.link.ether.bridge_cfg: fxp0,gif0
> >
> > box3# ifconfig bge1 inet 133.149.1.2 netmask 255.255.255.0
> > box3# ifconfig create gif1
> > box3# gifconfig gif1 inet 133.149.1.2 133.149.0.2
> > box3# sysctl net.link.ether.bridge: 1
> > box3# sysctl net.link.ether.bridge_cfg: gif1,fxp0
> >
> > (2) Can any protocols go through between IPv6 MC router and
> > IPv6 terminal in this step2 figure? Are there any limitations?
> > Is IPv6 packet available?
> >
> > > <<STEP2>> IPv6 bridge cascaded by gif tunnel
> > >
> > > +------box#2------------------+
> > > [IPv6 MC router ]-+---------+-(fxp0) IPv6 bridge |
> > > | |
> > > | |
> > > (IPv4)133.149.0.2 +--+-(bge0) IPv6 bridge and IPv4 |
> > > | | (gif0) IPv6 over IPv4 |
> > > | +-----------------------------+
> > > |
> > > <IPv4 router>
> > > |
> > > | +-------box#3-----------------+
> > > (IPv4)133.149.1.2 +--+-(bge1) IPv6 bridge and IPv4 |
> > > | (gif1) IPv6 over IPv4 |
> > > | |
> > > | |
> > > | |
> > > +--+-(fxp0) IPv6 bridge |
> > > | +-----------------------------+
> > > |
> > > | term#2
> > > +-----[IPv6 terminal(NDP client)]
> > >
> >
> > Thanks in advance
> >
> > Hidei Yamamoto
> >
> -----------------------------------------------------------------
> Hideki YAMAMOTO |
> Broadband Media Solutions Department | E-mail: yamamoto436@oki.com
> Broadband Media Company | Tel: +81-48-420-7012
> Oki Electric Industry Co., Ltd. | FAX: +81-48-420-7016
>
> ------------------------------
>
> Message: 3
> Date: Sun, 14 Nov 2004 18:44:08 +0100
> From: Massimiliano Stucchi <stucchi@willystudios.com>
> Subject: Re: Build of RELENG_5 fails in libmagic
> To: Mark Dixon <mark@markdnet.demon.co.uk>
> Cc: stable@freebsd.org
> Message-ID: <20041114174408.GI2180@willystudios.com>
> Content-Type: text/plain; charset="us-ascii"
>
> On 130104, 19:37, Mark Dixon wrote:
> >
> > I'm trying to build 5-STABLE, I have cvsuped the latest source,
cleared
> > out /usr/obj and I still get this problem. Any idea what could be
causing it?
> >
> > /usr/obj/usr/src/i386/usr/bin/ld: cannot find -lc
> > *** Error code 1
>
> I had the same exact problem while tryint to buildworld on an amd64 box
> I have, but this disappeared when I issued a make clean in /usr/src.
> Maybe it could help.
>
> Ciao !
> --
>
> Massimiliano Stucchi
> WillyStudios.com
> stucchi@willystudios.com
> Http://www.willystudios.com/max/
> -------------- next part --------------
> A non-text attachment was scrubbed...
> Name: not available
> Type: application/pgp-signature
> Size: 187 bytes
> Desc: not available
> Url :
http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20041114/53dbb440/attachment-0001.bin
>
> ------------------------------
>
> Message: 4
> Date: Sun, 14 Nov 2004 20:31:36 +0100
> From: Ralf Folkerts <ralf.folkerts@gmx.de>
> Subject: Can't compile 5.3-STABLE from 5.3-RC2
> To: stable@freebsd.org
> Message-ID: <1100460696.34540.11.camel@beaster>
> Content-Type: text/plain; charset="us-ascii"
>
> Hi,
>
> I wanted to Update my System that runs FreeBSD 5.3-RC2 to the
"final"
> 5.3-Level.
>
> However, compile reproducible stops in libstdc++, claiming a missing
> "unwind.h".
>
> I already removed /usr/src and re-cvsupped it and also searched
> the /usr/src/UPDATING and the CURRENT- and STABLE-Lists for such
> Problems.
>
> The Update from 5.2.1 to 5.3-RC2 ran just fine on that machine (after
> removing the CXXFLAGS from /etc/make.conf).
>
> uname -a:
> FreeBSD beaster.home.folkerts-net.de 5.3-RC2 FreeBSD 5.3-RC2 #1: Mon Nov
> 1 15:42:06 CET 2004
> toor@beaster.home.folkerts-net.de:/usr/obj/usr/src/sys/BEASTERKERNEL
> i386
>
> I'll paste the libstdc++-Output and my /etc/make.conf below.
>
> What did I do wrong? As it worked fine from 5.2.1 to 5.3 I hope it's
> just a small Problem ;-)
>
> Would be great if I could get a hint!
> MTIA,
> cheers,
> _ralf_
>
> --- /etc/make.conf ---
> PUTYPE=athlon-xp
> CFLAGS= -O -pipe
> NO_LPR=yes
> CUPS_OVERWRITE_BASE=yes
> NOINET6=true
> NOPROFILE=true
> COMPAT4X=yes
> # -- use.perl generated deltas -- #
> # Created: Sat Jan 17 12:55:06 2004
> # Setting to use base perl from ports:
> PERL_VER=5.6.1
> PERL_VERSION=5.6.1
> PERL_ARCH=mach
> NOPERL=yo
> NO_PERL=yo
> NO_PERL_WRAPPER=yo
> X_WINDOW_SYSTEM=xfree86-4
> --- end of /etc/make.conf ---
>
> ===> gnu/lib/libreadline/readline/doc
> ===> gnu/lib/libstdc++
> ln -sf /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc
> ++/config/cpu/i486/atomicity.h atomicity.cc
> rm -f .depend
> mkdep -f .depend -a -DIN_GLIBCPP_V3 -DHAVE_CONFIG_H
> -I/usr/src/gnu/lib/libstdc++ -I/usr/src/gnu/lib/libstdc
> ++/../../../contrib/libstdc++/libsupc++ -I/usr/src/gnu/lib/libstdc
> ++/../../../contrib/gcc -I/usr/src/gnu/lib/libstdc
> ++/../../../contrib/libstdc++/include /usr/src/gnu/lib/libstdc
> ++/../../../contrib/libstdc
> ++/libmath/signbitf.c /usr/src/gnu/lib/libstdc
> ++/../../../contrib/libstdc
> ++/libmath/signbitl.c /usr/src/gnu/lib/libstdc
> ++/../../../contrib/libstdc++/libmath/stubs.c/usr/src/gnu/lib/libstdc
> ++/../../../contrib/gcc/cp-demangle.c
> mkdep -f .depend -a /usr/src/gnu/lib/libstdc
> ++/../../../contrib/libstdc++/src/allocator.cc /usr/src/gnu/lib/libstdc
> ++/../../../contrib/libstdc++/src/codecvt.cc /usr/src/gnu/lib/libstdc
> ++/../../../contrib/libstdc++/src/complex_io.cc /usr/src/gnu/lib/libstdc
> ++/../../../contrib/libstdc++/src/ctype.cc /usr/src/gnu/lib/libstdc
> ++/../../../contrib/libstdc++/src/debug.cc /usr/src/gnu/lib/libstdc
> ++/../../../contrib/libstdc
> ++/src/functexcept.cc /usr/src/gnu/lib/libstdc
> ++/../../../contrib/libstdc
> ++/src/globals_locale.cc /usr/src/gnu/lib/libstdc
> ++/../../../contrib/libstdc++/src/globals_io.cc /usr/src/gnu/lib/libstdc
> ++/../../../contrib/libstdc++/src/ios.cc /usr/src/gnu/lib/libstdc
> ++/../../../contrib/libstdc
> ++/src/ios_failure.cc /usr/src/gnu/lib/libstdc
> ++/../../../contrib/libstdc++/src/ios_init.cc/usr/src/gnu/lib/libstdc
> ++/../../../contrib/libstdc++/src/ios_locale.cc /usr/src/gnu/lib/libstdc
> ++/../../../contrib/libstdc++/src/limits.cc /usr/src/gnu/lib/libstdc
> ++/../../../contrib/libstdc++/src/list.cc /usr/src/gnu/lib/libstdc
> ++/../../../contrib/libstdc++/src/locale.cc /usr/src/gnu/lib/libstdc
> ++/../../../contrib/libstdc
> ++/src/locale_init.cc /usr/src/gnu/lib/libstdc
> ++/../../../contrib/libstdc
> ++/src/locale_facets.cc /usr/src/gnu/lib/libstdc
> ++/../../../contrib/libstdc++/src/localename.cc /usr/src/gnu/lib/libstdc
> ++/../../../contrib/libstdc++/src/stdexcept.cc /usr/src/gnu/lib/libstdc
> ++/../../../contrib/libstdc++/src/strstream.cc /usr/src/gnu/lib/libstdc
> ++/../../../contrib/libstdc++/src/tree.cc /usr/src/gnu/lib/libstdc
> ++/../../../contrib/libstdc
> ++/src/allocator-inst.cc /usr/src/gnu/lib/libstdc
> ++/../../../contrib/libstdc
> ++/src/concept-inst.cc /usr/src/gnu/lib/libstdc
> ++/../../../contrib/libstdc
> ++/src/fstream-inst.cc /usr/src/gnu/lib/libstdc
> ++/../../../contrib/libstdc++/src/ext-inst.cc /usr/src/gnu/lib/libstdc
> ++/../../../contrib/libstdc++/src/io-inst.cc /usr/src/gnu/lib/libstdc
> ++/../../../contrib/libstdc
> ++/src/istream-inst.cc /usr/src/gnu/lib/libstdc
> ++/../../../contrib/libstdc
> ++/src/locale-inst.cc /usr/src/gnu/lib/libstdc
> ++/../../../contrib/libstdc
> ++/src/locale-misc-inst.cc /usr/src/gnu/lib/libstdc
> ++/../../../contrib/libstdc++/src/misc-inst.cc /usr/src/gnu/lib/libstdc
> ++/../../../contrib/libstdc
> ++/src/ostream-inst.cc /usr/src/gnu/lib/libstdc
> ++/../../../contrib/libstdc
> ++/src/sstream-inst.cc /usr/src/gnu/lib/libstdc
> ++/../../../contrib/libstdc
> ++/src/streambuf-inst.cc /usr/src/gnu/lib/libstdc
> ++/../../../contrib/libstdc
> ++/src/string-inst.cc /usr/src/gnu/lib/libstdc
> ++/../../../contrib/libstdc
> ++/src/valarray-inst.cc /usr/src/gnu/lib/libstdc
> ++/../../../contrib/libstdc
> ++/src/wlocale-inst.cc /usr/src/gnu/lib/libstdc
> ++/../../../contrib/libstdc++/src/wstring-inst.cc
> atomicity.cc /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc
> ++/config/locale/generic/codecvt_members.cc /usr/src/gnu/lib/libstdc
> ++/../../../contrib/libstdc
> ++/config/locale/generic/collate_members.cc /usr/src/gnu/lib/libstdc
> ++/../../../contrib/libstdc
> ++/config/locale/generic/ctype_members.cc /usr/src/gnu/lib/libstdc
> ++/../../../contrib/libstdc
> ++/config/locale/generic/messages_members.cc /usr/src/gnu/lib/libstdc
> ++/../../../contrib/libstdc
> ++/config/locale/generic/monetary_members.cc /usr/src/gnu/lib/libstdc
> ++/../../../contrib/libstdc
> ++/config/locale/generic/numeric_members.cc /usr/src/gnu/lib/libstdc
> ++/../../../contrib/libstdc
> ++/config/locale/generic/time_members.cc /usr/src/gnu/lib/libstdc
> ++/../../../contrib/libstdc
> ++/config/io/basic_file_stdio.cc/usr/src/gnu/lib/libstdc
> ++/../../../contrib/libstdc
> ++/config/locale/generic/c_locale.cc /usr/src/gnu/lib/libstdc
> ++/../../../contrib/libstdc++/libsupc
> ++/del_op.cc /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc
> ++/libsupc++/del_opnt.cc /usr/src/gnu/lib/libstdc
> ++/../../../contrib/libstdc++/libsupc
> ++/del_opv.cc /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc
> ++/libsupc++/del_opvnt.cc /usr/src/gnu/lib/libstdc
> ++/../../../contrib/libstdc++/libsupc
> ++/eh_alloc.cc /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc
> ++/libsupc++/eh_aux_runtime.cc /usr/src/gnu/lib/libstdc
> ++/../../../contrib/libstdc++/libsupc
> ++/eh_catch.cc /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc
> ++/libsupc++/eh_exception.cc /usr/src/gnu/lib/libstdc
> ++/../../../contrib/libstdc++/libsupc
> ++/eh_globals.cc /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc
> ++/libsupc++/eh_personality.cc /usr/src/gnu/lib/libstdc
> ++/../../../contrib/libstdc++/libsupc
> ++/eh_term_handler.cc /usr/src/gnu/lib/libstdc
> ++/../../../contrib/libstdc++/libsupc
> ++/eh_terminate.cc /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc
> ++/libsupc++/eh_throw.cc /usr/src/gnu/lib/libstdc
> ++/../../../contrib/libstdc++/libsupc
> ++/eh_type.cc /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc
> ++/libsupc++/eh_unex_handler.cc /usr/src/gnu/lib/libstdc
> ++/../../../contrib/libstdc++/libsupc
> ++/guard.cc /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc
> ++/libsupc++/new_handler.cc /usr/src/gnu/lib/libstdc
> ++/../../../contrib/libstdc++/libsupc
> ++/new_op.cc /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc
> ++/libsupc++/new_opnt.cc /usr/src/gnu/lib/libstdc
> ++/../../../contrib/libstdc++/libsupc
> ++/new_opv.cc /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc
> ++/libsupc++/new_opvnt.cc /usr/src/gnu/lib/libstdc
> ++/../../../contrib/libstdc++/libsupc++/pure.cc /usr/src/gnu/lib/libstdc
> ++/../../../contrib/libstdc++/libsupc
> ++/tinfo.cc /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc
> ++/libsupc++/tinfo2.cc /usr/src/gnu/lib/libstdc
> ++/../../../contrib/libstdc++/libsupc++/vec.cc /usr/src/gnu/lib/libstdc
> ++/../../../contrib/libstdc++/libsupc++/vterminate.cc
> In file included from /usr/src/gnu/lib/libstdc
> ++/../../../contrib/libstdc++/libsupc++/eh_alloc.cc:37:
> /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/libsupc
> ++/unwind-cxx.h:41:20: unwind.h: No such file or directory
> In file included from /usr/src/gnu/lib/libstdc
> ++/../../../contrib/libstdc++/libsupc++/eh_aux_runtime.cc:34:
> /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/libsupc
> ++/unwind-cxx.h:41:20: unwind.h: No such file or directory
> In file included from /usr/src/gnu/lib/libstdc
> ++/../../../contrib/libstdc++/libsupc++/eh_catch.cc:32:
> /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/libsupc
> ++/unwind-cxx.h:41:20: unwind.h: No such file or directory
> In file included from /usr/src/gnu/lib/libstdc
> ++/../../../contrib/libstdc++/libsupc++/eh_exception.cc:34:
> /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/libsupc
> ++/unwind-cxx.h:41:20: unwind.h: No such file or directory
> In file included from /usr/src/gnu/lib/libstdc
> ++/../../../contrib/libstdc++/libsupc++/eh_globals.cc:33:
> /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/libsupc
> ++/unwind-cxx.h:41:20: unwind.h: No such file or directory
> In file included from /usr/src/gnu/lib/libstdc
> ++/../../../contrib/libstdc++/libsupc++/eh_personality.cc:34:
> /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/libsupc
> ++/unwind-cxx.h:41:20: unwind.h: No such file or directory
> /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/libsupc
> ++/eh_personality.cc:38:23: unwind-pe.h: No such file or directory
> In file included from /usr/src/gnu/lib/libstdc
> ++/../../../contrib/libstdc++/libsupc++/eh_term_handler.cc:30:
> /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/libsupc
> ++/unwind-cxx.h:41:20: unwind.h: No such file or directory
> In file included from /usr/src/gnu/lib/libstdc
> ++/../../../contrib/libstdc++/libsupc++/eh_terminate.cc:34:
> /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/libsupc
> ++/unwind-cxx.h:41:20: unwind.h: No such file or directory
> In file included from /usr/src/gnu/lib/libstdc
> ++/../../../contrib/libstdc++/libsupc++/eh_throw.cc:32:
> /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/libsupc
> ++/unwind-cxx.h:41:20: unwind.h: No such file or directory
> In file included from /usr/src/gnu/lib/libstdc
> ++/../../../contrib/libstdc++/libsupc++/eh_type.cc:32:
> /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/libsupc
> ++/unwind-cxx.h:41:20: unwind.h: No such file or directory
> In file included from /usr/src/gnu/lib/libstdc
> ++/../../../contrib/libstdc++/libsupc++/eh_unex_handler.cc:30:
> /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/libsupc
> ++/unwind-cxx.h:41:20: unwind.h: No such file or directory
> In file included from /usr/src/gnu/lib/libstdc
> ++/../../../contrib/libstdc++/libsupc++/pure.cc:31:
> /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/libsupc
> ++/unwind-cxx.h:41:20: unwind.h: No such file or directory
> In file included from /usr/src/gnu/lib/libstdc
> ++/../../../contrib/libstdc++/libsupc++/vec.cc:37:
> /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/libsupc
> ++/unwind-cxx.h:41:20: unwind.h: No such file or directory
> mkdep: compile failed
> *** Error code 1
>
> Stop in /usr/src/gnu/lib/libstdc++.
> *** Error code 1
>
> Stop in /usr/src/gnu/lib.
> *** Error code 1
>
> Stop in /usr/src.
> *** Error code 1
>
> Stop in /usr/src.
> *** Error code 1
>
> Stop in /usr/src.
> *** Error code 1
>
> Stop in /usr/src.
> [-su]beaster:src$
>
> -------------- next part --------------
> A non-text attachment was scrubbed...
> Name: not available
> Type: application/pgp-signature
> Size: 187 bytes
> Desc: Dies ist ein digital signierter Nachrichtenteil
> Url :
http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20041114/1e3cda6b/attachment-0001.bin
>
> ------------------------------
>
> Message: 5
> Date: Sun, 14 Nov 2004 18:03:32 -0500
> From: David Gilbert <dgilbert@dclg.ca>
> Subject: new threads problem? pthread_cond_timedwait ?
> To: freebsd-stable@freebsd.org
> Message-ID: <16791.58436.511616.733270@canoe.dclg.ca>
> Content-Type: text/plain; charset=us-ascii
>
> My hard drive failed right around FreeBSD-5.3, so I got to do a fresh
> install of 5.3-RC1 followed by a cvsup to -STABLE (yesterday).
>
> Due to my nvidia video driver, I still have libmap.conf forcing
> libpthread to use libc_r.
>
> When compiling audio/xmms-imms, I get the following error, and I don't
> know how to deal with it:
>
> c++ -L/usr/X11R6/lib `xmms-config --libs` -lc -lm -lpcre -lsqlite3 -lz
-ltag analyzer.o spectrum.o `pkg-config fftw3f --libs` libimmscore.a -o
analyzer
> /usr/local/lib/libgthread12.so.3: undefined reference to
`pthread_cond_timedwait'
>
> Dave.
>
> --
>
===========================================================================>
|David Gilbert, Independent Contractor. | Two things can only be |
> |Mail: dave@daveg.ca | equal if and only if they
|
> |http://daveg.ca | are precisely opposite.
|
>
=========================================================GLO===============>
> ------------------------------
>
> Message: 6
> Date: Sun, 14 Nov 2004 15:39:00 -0800
> From: "Zoltan Frombach" <tssajo@hotmail.com>
> Subject: Either I do something wrong or there is a regexp bug in sed
> !!
> To: <freebsd-stable@freebsd.org>, <freebsd-current@freebsd.org>
> Message-ID: <BAY2-DAV16kTgbLYluL0001ec55@hotmail.com>
> Content-Type: text/plain; format=flowed;
charset="iso-8859-1";
> reply-type=original
>
> I'm trying to use sed under FreeBSD 5.3-RELEASE in a new
'netqmail' port I
> am currently working on. I want to replace a bunch of digits (in plain
> English: a decimal number) in a text file at the beginning of a line. Here
> is how the original file looks before I do anything (this file is part of
> the netqmail-1.05 package, but it is unimportant):
>
> --- file conf-split begins
> 23
>
> This is the queue subdirectory split.
> --- file conf-split ends
>
> Okay, so I try to replace 23 (or whatever number is there!) at the
beginning
> of the first line to let's say 199 in this file using sed. I would
expect
> this to work:
>
> sed -e "s/^[0-9]+/199/" conf-split > conf-split.new
>
> But it doesn't change anything in conf-spilt.new!! My regexp ^[0-9]+
doesn't
> match anything! After spending like an hour investigating this, I realized
> that the + after my bracket expression ( I'm talking about this part
here:
> [0-9]+ ) does not match! If I omit the use of + and use * instead, I can
> make my regexp to match. So this works - but IMHO it's ugly:
>
> sed -e "s/^[0-9][0-9]*/199/" conf-split > conf-split.new
>
> It gives this output, which is what I always wanted:
>
> --- file conf-split.new begins
> 199
>
> This is the queue subdirectory split.
> --- file conf-split.new ends
>
> According to the sed man page, the regexp syntax that is used by sed is
> documented in the re_format man page. And according to the re_format man
> page: "A piece is an atom possibly followed by a single= `*',
`+', `?', or
> bound. An atom followed by `*' matches a sequence of 0 or more matches
of
> the atom. An atom followed by `+' matches a sequence of 1 or more
matches
> of the atom. ..."
> And the definition of an "atom" is (quoted from the same man
page): "An atom
> is a regular expression enclosed in `()' (matching a match for the
regular
> expression), an empty set of `()' (matching the null string)=, a
bracket
> expression (see below) ..."
>
> So either my bracket expression ( [0-9] ) in my first sed command was not
> recognized as an atom, or if it was recognized as an atom then the + that
> followed it was not interpreted properly... Can anyone please tell me why?
>
> I believe this is a bug in sed or in the regexp library which sed uses. If
> it is a regexp library issue, then there is a chance that it affects other
> programs that use it, as well! At least it can break all programs that use
> sed regexps, especially ports...
>
> My uname -a is:
> FreeBSD www.xxxxxxxx.com 5.3-RELEASE FreeBSD 5.3-RELEASE #0: Fri Nov 12
> 01:07:41 PST 2004 xxx@www.xxxxxxxx.com:/usr/obj/usr/src/sys/XXXXXXXX
> i386
>
> Zoltan
>
> ------------------------------
>
> Message: 7
> Date: Sun, 14 Nov 2004 18:48:27 -0500
> From: "Brandon S. Allbery KF8NH" <allbery@ece.cmu.edu>
> Subject: Re: Either I do something wrong or there is a regexp bug in
> sed !!
> To: Zoltan Frombach <tssajo@hotmail.com>
> Cc: freebsd-current@freebsd.org
> Message-ID: <1100476106.10768.4.camel@rushlight.kf8nh.com>
> Content-Type: text/plain
>
> On Sun, 2004-11-14 at 18:39, Zoltan Frombach wrote:
> > match anything! After spending like an hour investigating this, I
realized
> > that the + after my bracket expression ( I'm talking about this
part here:
>
> Normal.
>
> > According to the sed man page, the regexp syntax that is used by sed
is
> > documented in the re_format man page. And according to the re_format
man
> > page: "A piece is an atom possibly followed by a single= `*',
`+', `?', or
>
> You need to read it more carefully. There are two kinds of regular
> expressions, "basic" and "extended". sed, ed, and grep
speak BRE
> syntax, whereas awk and egrep speak ERE syntax. + is special only in
> ERE syntax.
>
> (And then there's GNU, where the difference between BRE and ERE is that
> some things use a preceding backslash in BRE and don't in ERE, and vice
> versa, so GNU sed does what you want if you use \+ instead of +.)
>
> --
> brandon s. allbery [linux,solaris,freebsd,perl] allbery@kf8nh.com
> system administrator [WAY too many hats] allbery@ece.cmu.edu
> electrical and computer engineering, carnegie mellon univ. KF8NH
>
> ------------------------------
>
> Message: 8
> Date: Mon, 15 Nov 2004 00:49:08 +0100
> From: Alex de Kruijff <freebsd@akruijff.dds.nl>
> Subject: Re: Can't compile 5.3-STABLE from 5.3-RC2
> To: Ralf Folkerts <ralf.folkerts@gmx.de>
> Cc: stable@freebsd.org
> Message-ID: <20041114234908.GA746@alex.lan>
> Content-Type: text/plain; charset=us-ascii
>
> On Sun, Nov 14, 2004 at 08:31:36PM +0100, Ralf Folkerts wrote:
> > Hi,
> >
> > I wanted to Update my System that runs FreeBSD 5.3-RC2 to the
"final"
> > 5.3-Level.
> >
> > However, compile reproducible stops in libstdc++, claiming a missing
> > "unwind.h".
> >
> > I already removed /usr/src and re-cvsupped it and also searched
> > the /usr/src/UPDATING and the CURRENT- and STABLE-Lists for such
> > Problems.
> >
> > The Update from 5.2.1 to 5.3-RC2 ran just fine on that machine (after
> > removing the CXXFLAGS from /etc/make.conf).
> >
> > uname -a:
> > FreeBSD beaster.home.folkerts-net.de 5.3-RC2 FreeBSD 5.3-RC2 #1: Mon
Nov
> > 1 15:42:06 CET 2004
> > toor@beaster.home.folkerts-net.de:/usr/obj/usr/src/sys/BEASTERKERNEL
> > i386
> >
> > I'll paste the libstdc++-Output and my /etc/make.conf below.
> >
> > What did I do wrong? As it worked fine from 5.2.1 to 5.3 I hope
it's
> > just a small Problem ;-)
>
> Did you follow the handbook to the letter? I was succesful at compileing
> from RC2 to STABLE. You could try my script. I've put it in
> www.kruijff.org/files/FreeBSD/update.sh
>
> Options are:
> update.sh cvs
> update.sh build (fails to build my special kernels)
> update.sh install GENERIC
>
> Log files goto /var/world/
>
> --
> Alex
>
> Please copy the original recipients, otherwise I may not read your reply.
> WWW: http://www.kruijff.org/alex/FreeBSD/
>
> ------------------------------
>
> Message: 9
> Date: Sun, 14 Nov 2004 16:05:15 -0800
> From: "Zoltan Frombach" <tssajo@hotmail.com>
> Subject: Re: Either I do something wrong or there is a regexp bug in
> sed !!
> To: "Brandon S. Allbery KF8NH" <allbery@ece.cmu.edu>
> Cc: freebsd-current@freebsd.org
> Message-ID: <BAY2-DAV8cm9t0CI76r0001ef19@hotmail.com>
> Content-Type: text/plain; format=flowed;
charset="iso-8859-1";
> reply-type=original
>
> You are right. My mistake. This indeed works:
>
> sed -E -e "s/^[0-9]+/199/" conf-split > conf-split.new
>
> Thanks for clearing this up.
>
> Zoltan
>
> > On Sun, 2004-11-14 at 18:39, Zoltan Frombach wrote:
> >> match anything! After spending like an hour investigating this, I
> >> realized
> >> that the + after my bracket expression ( I'm talking about
this part
> >> here:
> >
> > Normal.
> >
> >> According to the sed man page, the regexp syntax that is used by
sed is
> >> documented in the re_format man page. And according to the
re_format man
> >> page: "A piece is an atom possibly followed by a single=
`*', `+', `?',
> >> or
> >
> > You need to read it more carefully. There are two kinds of regular
> > expressions, "basic" and "extended". sed, ed, and
grep speak BRE
> > syntax, whereas awk and egrep speak ERE syntax. + is special only in
> > ERE syntax.
> >
> > (And then there's GNU, where the difference between BRE and ERE is
that
> > some things use a preceding backslash in BRE and don't in ERE, and
vice
> > versa, so GNU sed does what you want if you use \+ instead of +.)
> >
> > --
> > brandon s. allbery [linux,solaris,freebsd,perl]
allbery@kf8nh.com
> > system administrator [WAY too many hats]
allbery@ece.cmu.edu
> > electrical and computer engineering, carnegie mellon univ.
KF8NH
>
> ------------------------------
>
> Message: 10
> Date: Mon, 15 Nov 2004 01:16:35 +0100
> From: Bj?rn K?nig<bkoenig@cs.tu-berlin.de>
> Subject: Re: Either I do something wrong or there is a regexp bug in
> sed !!
> To: <freebsd-stable@freebsd.org>
> Message-ID: <20041115001914.2C366615D@mail.alpha-tierchen.de>
> Content-Type: text/plain; charset="utf-8"
>
> use -E
>
> ------------------------------
>
> Message: 11
> Date: Sun, 14 Nov 2004 16:50:16 -0800
> From: Kris Kennaway <kris@obsecurity.org>
> Subject: New 5.x packages uploaded
> To: stable@FreeBSD.org
> Cc: ports@FreeBSD.org
> Message-ID: <20041115005016.GA4384@xor.obsecurity.org>
> Content-Type: text/plain; charset="us-ascii"
>
> I've uploaded new packages for 5.3-stable; they'll make their way
onto
> the ftp mirrors over the next day or so. Included are the new
> versions of GNOME and KDE, among others.
>
> Kris
>
> -------------- next part --------------
> A non-text attachment was scrubbed...
> Name: not available
> Type: application/pgp-signature
> Size: 187 bytes
> Desc: not available
> Url :
http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20041114/97d6ada6/attachment-0002.bin
>
> ------------------------------
>
> Message: 12
> Date: Sun, 14 Nov 2004 16:50:16 -0800
> From: Kris Kennaway <kris@obsecurity.org>
> Subject: New 5.x packages uploaded
> To: stable@FreeBSD.org
> Cc: ports@FreeBSD.org
> Message-ID: <20041115005016.GA4384@xor.obsecurity.org>
> Content-Type: text/plain; charset="us-ascii"
>
> I've uploaded new packages for 5.3-stable; they'll make their way
onto
> the ftp mirrors over the next day or so. Included are the new
> versions of GNOME and KDE, among others.
>
> Kris
>
> -------------- next part --------------
> A non-text attachment was scrubbed...
> Name: not available
> Type: application/pgp-signature
> Size: 187 bytes
> Desc: not available
> Url :
http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20041114/97d6ada6/attachment-0003.bin
>
> ------------------------------
>
> Message: 13
> Date: Mon, 15 Nov 2004 02:42:21 +0100
> From: Maxime Henrion <mux@freebsd.org>
> Subject: Re: Either I do something wrong or there is a regexp bug in
> sed !!
> To: Zoltan Frombach <tssajo@hotmail.com>
> Cc: freebsd-current@freebsd.org
> Message-ID: <20041115014221.GF32839@elvis.mu.org>
> Content-Type: text/plain; charset=us-ascii
>
> Zoltan Frombach wrote:
> > You are right. My mistake. This indeed works:
> >
> > sed -E -e "s/^[0-9]+/199/" conf-split > conf-split.new
> >
> > Thanks for clearing this up.
>
> For what it's worth, there is another way to write this regexp without
> using the -E flag. Since x+ == xx*, you can write it:
> "s/^[0-9][0-9]*/199/". The reason for not using -E is that
it's not
> portable, since it's not specified by the standard. GNU sed uses -r
for
> extended REs.
>
> Cheers,
> Maxime
>
> ------------------------------
>
> Message: 14
> Date: Sun, 14 Nov 2004 18:10:40 -0800
> From: "Zoltan Frombach" <tssajo@hotmail.com>
> Subject: Re: Either I do something wrong or there is a regexp bug in
> sed !!
> To: "Maxime Henrion" <mux@freebsd.org>
> Cc: freebsd-current@freebsd.org
> Message-ID: <BAY2-DAV16wRPQIWDO30001f1cc@hotmail.com>
> Content-Type: text/plain; format=flowed;
charset="iso-8859-1";
> reply-type=original
>
> Thanks. I will not use the -E flag then.
>
> Zoltan
>
> > Zoltan Frombach wrote:
> >> You are right. My mistake. This indeed works:
> >>
> >> sed -E -e "s/^[0-9]+/199/" conf-split >
conf-split.new
> >>
> >> Thanks for clearing this up.
> >
> > For what it's worth, there is another way to write this regexp
without
> > using the -E flag. Since x+ == xx*, you can write it:
> > "s/^[0-9][0-9]*/199/". The reason for not using -E is that
it's not
> > portable, since it's not specified by the standard. GNU sed uses
-r for
> > extended REs.
> >
> > Cheers,
> > Maxime
>
> ------------------------------
>
> Message: 15
> Date: Mon, 15 Nov 2004 04:06:07 +0100
> From: Matthias Andree <ma@dt.e-technik.uni-dortmund.de>
> Subject: Re: New 5.x packages uploaded
> To: Kris Kennaway <kris@obsecurity.org>
> Cc: ports@freebsd.org
> Message-ID: <m3d5yfvmjk.fsf@merlin.emma.line.org>
> Content-Type: text/plain; charset=us-ascii
>
> Kris Kennaway <kris@obsecurity.org> writes:
>
> > I've uploaded new packages for 5.3-stable; they'll make their
way onto
> > the ftp mirrors over the next day or so. Included are the new
> > versions of GNOME and KDE, among others.
>
> BTW, are we getting long-standing security issues in ports fixed, for
> instance cups-base, open-motif, others? Yeah I know send patches, but my
> ressources are limited and committers are also overworked already...
>
> The general question I'd like to raise is how long will we allow ports
> with known security flaws linger around before they are marked BROKEN?
>
> --
> Matthias Andree
>
> ------------------------------
>
> Message: 16
> Date: Sun, 14 Nov 2004 19:13:14 -0800
> From: Kris Kennaway <kris@obsecurity.org>
> Subject: Re: New 5.x packages uploaded
> To: Matthias Andree <ma@dt.e-technik.uni-dortmund.de>
> Cc: ports@freebsd.org
> Message-ID: <20041115031314.GA43451@xor.obsecurity.org>
> Content-Type: text/plain; charset="us-ascii"
>
> On Mon, Nov 15, 2004 at 04:06:07AM +0100, Matthias Andree wrote:
> > Kris Kennaway <kris@obsecurity.org> writes:
> >
> > > I've uploaded new packages for 5.3-stable; they'll make
their way onto
> > > the ftp mirrors over the next day or so. Included are the new
> > > versions of GNOME and KDE, among others.
> >
> > BTW, are we getting long-standing security issues in ports fixed, for
> > instance cups-base, open-motif, others? Yeah I know send patches, but
my
> > ressources are limited and committers are also overworked already...
> >
> > The general question I'd like to raise is how long will we allow
ports
> > with known security flaws linger around before they are marked BROKEN?
>
> In general serious security flaws should be marked FORBIDDEN
> immediately, and they generally are. Fixing the security issues is up
> to the community.
>
> Kris
> -------------- next part --------------
> A non-text attachment was scrubbed...
> Name: not available
> Type: application/pgp-signature
> Size: 187 bytes
> Desc: not available
> Url :
http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20041114/82ac00d9/attachment-0002.bin
>
> ------------------------------
>
> Message: 17
> Date: Mon, 15 Nov 2004 04:06:07 +0100
> From: Matthias Andree <ma@dt.e-technik.uni-dortmund.de>
> Subject: Re: New 5.x packages uploaded
> To: Kris Kennaway <kris@obsecurity.org>
> Cc: ports@freebsd.org
> Message-ID: <m3d5yfvmjk.fsf@merlin.emma.line.org>
> Content-Type: text/plain; charset=us-ascii
>
> Kris Kennaway <kris@obsecurity.org> writes:
>
> > I've uploaded new packages for 5.3-stable; they'll make their
way onto
> > the ftp mirrors over the next day or so. Included are the new
> > versions of GNOME and KDE, among others.
>
> BTW, are we getting long-standing security issues in ports fixed, for
> instance cups-base, open-motif, others? Yeah I know send patches, but my
> ressources are limited and committers are also overworked already...
>
> The general question I'd like to raise is how long will we allow ports
> with known security flaws linger around before they are marked BROKEN?
>
> --
> Matthias Andree
> _______________________________________________
> freebsd-ports@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-ports
> To unsubscribe, send any mail to
"freebsd-ports-unsubscribe@freebsd.org"
>
> ------------------------------
>
> Message: 18
> Date: Sun, 14 Nov 2004 19:13:14 -0800
> From: Kris Kennaway <kris@obsecurity.org>
> Subject: Re: New 5.x packages uploaded
> To: Matthias Andree <ma@dt.e-technik.uni-dortmund.de>
> Cc: ports@freebsd.org
> Message-ID: <20041115031314.GA43451@xor.obsecurity.org>
> Content-Type: text/plain; charset="us-ascii"
>
> On Mon, Nov 15, 2004 at 04:06:07AM +0100, Matthias Andree wrote:
> > Kris Kennaway <kris@obsecurity.org> writes:
> >
> > > I've uploaded new packages for 5.3-stable; they'll make
their way onto
> > > the ftp mirrors over the next day or so. Included are the new
> > > versions of GNOME and KDE, among others.
> >
> > BTW, are we getting long-standing security issues in ports fixed, for
> > instance cups-base, open-motif, others? Yeah I know send patches, but
my
> > ressources are limited and committers are also overworked already...
> >
> > The general question I'd like to raise is how long will we allow
ports
> > with known security flaws linger around before they are marked BROKEN?
>
> In general serious security flaws should be marked FORBIDDEN
> immediately, and they generally are. Fixing the security issues is up
> to the community.
>
> Kris
> -------------- next part --------------
> A non-text attachment was scrubbed...
> Name: not available
> Type: application/pgp-signature
> Size: 187 bytes
> Desc: not available
> Url :
http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20041114/82ac00d9/attachment-0003.bin
>
> ------------------------------
>
> Message: 19
> Date: Sun, 14 Nov 2004 23:20:15 -0500
> From: Zaphod Beeblebrox <zbeeble@gmail.com>
> Subject: gvinum setstate missing?
> To: freebsd-stable@freebsd.org
> Message-ID: <5f67a8c404111420204e29b1bd@mail.gmail.com>
> Content-Type: text/plain; charset=US-ASCII
>
> I'm in the uncomfortable position of needing to setstate down a gvinum
> drive. I can't seem to effect this as the gvinum command doesn't
> understand setstate (even though it proclaims that it does in "gvinum
> help").
>
> Is there a way of making this so?
>
> ------------------------------
>
> Message: 20
> Date: Sun, 14 Nov 2004 23:25:17 -0500 (EST)
> From: Paul Sandys <myj@nyct.net>
> Subject: SIIG cards and puc
> To: freebsd-stable@freebsd.org
> Message-ID: <20041114231939.Y71461@bsd3.nyct.net>
> Content-Type: TEXT/PLAIN; charset=US-ASCII
>
> I've tried to get one of the 20x family 16C650 64-byte buffer SIIG
cards to
> work. It does not work out of the box.
>
> I had to add 0x40000001 into the flags in pucdata.c for my card and
"options
> COM_MULTIPORT" into the kernel config. It's still limited to
115200 baud, but
> all I was interested is 9600 anyway.
>
> Can this be implemented into the source tree ?
>
> P.
>
<-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_->
> < myj@nyct.net Paul Sandys | New York Connect
http://www.nyct.net >
> < network operations manager | Total Solution provider
>
>
<------------------------------------------------------------------------->
> < " The Internet Solutions Provider You Can Count On !
" >
>
<-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_->
>
> ------------------------------
>
> Message: 21
> Date: Mon, 15 Nov 2004 04:59:13 +0000
> From: Adrian Wontroba <aw1@stade.co.uk>
> Subject: panic: APIC: Previous IPI is stuck
> To: stable@freebsd.org
> Message-ID: <20041115045912.A79200@titus.hanley.stade.co.uk>
> Content-Type: text/plain; charset=us-ascii
>
> At work, I've just taken an old cast off NT server and used it as
> a replacement for an equally elderly low end PC which performs an
> important monitoring task.
>
> I took the opportunity to upgrade to 5.3 (5.3-RC2 now, yesterday's
> 5.3-STABLE when I get to work again) rather than stay on 4.10-RELEASE.
>
> The rationale was this would be a nice resilient machine, demonstrating
> how FreeBSD can extend the useful working life of aging hardware.
>
> The practice is that it it has now crashed three times in a couple of
> days with "panic: APIC: Previous IPI is stuck", the most recent
one
> dragging me out from home early in a Monday morning.
>
> Over in current there are a couple of threads starting in late September
> where a few people are suffering this problem. Like them, I'm using an
> old (1997) Pentium Pro multiprocessor, in my case a 4 way Fujitsu M700.
>
> The machine is running with the SMP kernel (ie GENERIC + SMP), 4BSD
> scheduler, without preemption.
>
> I've set kern.sched.ipiwakeup.enabled=0 and crossed my fingers.
>
> I'm a SMP novice. Would the machine become stable if I switched to a
> non-SMP kernel? Reliability is more important than speed in this case,
> and the opportunity for experimentation close to zero. Creditability
> has already been damaged by the gvinum RAID5 experience (8-(
>
> I'm not knocking 5.3 - in all other respects it seems wonderful.
>
> "me too" diagnostics:
>
> kern.sched.name: 4BSD
> kern.sched.quantum: 100000
> kern.sched.ipiwakeup.enabled: 1
> kern.sched.ipiwakeup.requested: 858129
> kern.sched.ipiwakeup.delivered: 858129
> kern.sched.ipiwakeup.usemask: 1
> kern.sched.ipiwakeup.useloop: 0
> kern.sched.ipiwakeup.onecpu: 0
> kern.sched.ipiwakeup.htt2: 0
> kern.sched.followon: 0
> kern.sched.pfollowons: 0
> kern.sched.kgfollowons: 0
> kern.sched.runq_fuzz: 1
>
>
===========================================================================>
> MPTable, version 2.0.15
>
> looking for EBDA pointer @ 0x040e, found, searching EBDA @ 0x0008f000
> searching CMOS 'top of mem' @ 0x0008ec00 (571K)
> searching default 'top of mem' @ 0x0009fc00 (639K)
> searching BIOS @ 0x000f0000
>
> MP FPS found in BIOS @ physical addr: 0x000fdc30
>
>
----------------------------------------------------------------------------
>
> MP Floating Pointer Structure:
>
> location: BIOS
> physical address: 0x000fdc30
> signature: '_MP_'
> length: 16 bytes
> version: 1.4
> checksum: 0x56
> mode: Virtual Wire
>
>
----------------------------------------------------------------------------
>
> MP Config Table Header:
>
> physical address: 0x0008f151
> signature: 'PCMP'
> base table length: 332
> version: 1.4
> checksum: 0x05
> OEM ID: 'Fujitsu '
> Product ID: 'Pro Server '
> OEM table pointer: 0x00000000
> OEM table size: 0
> entry count: 30
> local APIC address: 0xfee00000
> extended table length: 0
> extended table checksum: 0
>
>
----------------------------------------------------------------------------
>
> MP Config Base Table Entries:
>
> --
> Processors: APIC ID Version State Family Model Step
> Flags
> 3 0x11 BSP, usable 6 1 9
> 0xfbff
> 0 0x11 AP, usable 6 1 9
> 0xfbff
> 1 0x11 AP, usable 6 1 9
> 0xfbff
> 2 0x11 AP, usable 6 1 9
> 0xfbff
> --
> Bus: Bus ID Type
> 0 PCI
> 1 PCI
> 2 EISA
> --
> I/O APICs: APIC ID Version State Address
> 8 0x11 usable 0xfec00000
> 9 0x11 usable 0xfec0c000
> --
> I/O Ints: Type Polarity Trigger Bus ID IRQ APIC ID
PIN#
> ExtINT active-hi edge 2 0 8 0
> INT conforms conforms 2 1 8 1
> INT conforms conforms 2 2 8 2
> INT conforms conforms 2 3 8 3
> INT conforms conforms 2 4 8 4
> INT conforms conforms 2 5 8 5
> INT conforms conforms 2 6 8 6
> INT conforms conforms 2 7 8 7
> INT conforms conforms 2 8 8 8
> INT conforms conforms 2 9 8 9
> INT conforms conforms 2 10 8 10
> INT conforms conforms 2 11 8 11
> INT conforms conforms 2 12 8 12
> INT conforms conforms 2 13 8 13
> INT conforms conforms 2 14 8 14
> INT conforms conforms 2 15 8 15
> INT active-lo level 0 1:A 9 11
> INT active-lo level 1 1:A 9 12
> INT active-lo level 1 2:A 9 12
> --
> Local Ints: Type Polarity Trigger Bus ID IRQ APIC ID
PIN#
> ExtINT active-hi edge 0 0:A 255 0
> NMI active-hi edge 0 0:A 255 1
>
>
----------------------------------------------------------------------------
>
> dmesg output:
>
> Copyright (c) 1992-2004 The FreeBSD Project.
> Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
> The Regents of the University of California. All rights reserved.
> FreeBSD 5.3-RC2 #0: Thu Nov 4 03:48:56 GMT 2004
>
> toor@xjamesfriis.<CENSORED>:/usr/src/sys/i386/compile/JAMESFRIIS
> MPTable: <Fujitsu Pro Server >
> Timecounter "i8254" frequency 1193182 Hz quality 0
> CPU: Pentium Pro (199.84-MHz 686-class CPU)
> Origin = "GenuineIntel" Id = 0x619 Stepping = 9
>
>
Features=0xfbff<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMO
> V>
> real memory = 2147483648 (2048 MB)
> avail memory = 2095947776 (1998 MB)
> FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs
> cpu0 (BSP): APIC ID: 3
> cpu1 (AP): APIC ID: 0
> cpu2 (AP): APIC ID: 1
> cpu3 (AP): APIC ID: 2
> ioapic0: Assuming intbase of 0
> ioapic1: Assuming intbase of 16
> ioapic0 <Version 1.1> irqs 0-15 on motherboard
> ioapic1 <Version 1.1> irqs 16-31 on motherboard
> npx0: [FAST]
> npx0: <math processor> on motherboard
> npx0: INT 16 interface
> pcib0: <MPTable Host-PCI bridge> pcibus 0 on motherboard
> pci0: <PCI bus> on pcib0
> fxp0: <Intel 82557 Pro/100 Ethernet> port 0xfce0-0xfcff mem
> 0xfe900000-0xfe9fffff,0xfe8ff000-0xfe8fffff irq 27 at device 1.0 on pci0
> miibus0: <MII bus> on fxp0
> ukphy0: <Generic IEEE 802.3u media interface> on miibus0
> ukphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
> fxp0: Ethernet address: 00:10:a8:00:10:d6
> pci0: <display, VGA> at device 2.0 (no driver attached)
> eisab0: <PCI-EISA bridge> at device 3.0 on pci0
> eisa0: <EISA bus> on eisab0
> mainboard0: <FUJc081 (System Board)> on eisa0 slot 0
> isa0: <ISA bus> on eisab0
> pcib1: <MPTable Host-PCI bridge> pcibus 1 on motherboard
> pci1: <PCI bus> on pcib1
> ahc0: <Adaptec aic7880 Ultra SCSI adapter> port 0xf800-0xf8ff mem
> 0xfceef000-0xfceeffff irq 28 at device 1.0 on pci1
> ahc0: [GIANT-LOCKED]
> aic7880: Ultra Wide Channel A, SCSI Id=7, 16/253 SCBs
> ahc1: <Adaptec aic7880 Ultra SCSI adapter> port 0xf400-0xf4ff mem
> 0xfceee000-0xfceeefff irq 28 at device 2.0 on pci1
> ahc1: [GIANT-LOCKED]
> aic7880: Ultra Wide Channel A, SCSI Id=7, 16/253 SCBs
> pci1: <base peripheral> at device 3.0 (no driver attached)
> cpu0 on motherboard
> cpu1 on motherboard
> cpu2 on motherboard
> cpu3 on motherboard
> orm0: <ISA Option ROM> at iomem 0xc0000-0xc7fff on isa0
> pmtimer0 on isa0
> ata0 at port 0x3f6,0x1f0-0x1f7 irq 14 on isa0
> ata1 at port 0x376,0x170-0x177 irq 15 on isa0
> atkbdc0: <Keyboard controller (i8042)> at port 0x64,0x60 on isa0
> atkbd0: <AT Keyboard> irq 1 on atkbdc0
> kbd0 at atkbd0
> atkbd0: [GIANT-LOCKED]
> psm0: <PS/2 Mouse> irq 12 on atkbdc0
> psm0: [GIANT-LOCKED]
> psm0: model MouseMan+, device ID 0
> fdc0: <Enhanced floppy controller> at port 0x3f0-0x3f5 irq 6 drq 2 on
isa0
> fdc0: [FAST]
> fd0: <1440-KB 3.5" drive> on fdc0 drive 0
> ppc0: <Parallel port> at port 0x378-0x37f irq 7 on isa0
> ppc0: Generic chipset (NIBBLE-only) in COMPATIBLE mode
> ppbus0: <Parallel port bus> on ppc0
> plip0: <PLIP network interface> on ppbus0
> lpt0: <Printer> on ppbus0
> lpt0: Interrupt-driven port
> ppi0: <Parallel I/O> on ppbus0
> sc0: <System console> at flags 0x100 on isa0
> sc0: VGA <16 virtual consoles, flags=0x300>
> sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0
> sio0: type 16550A
> sio1 at port 0x2f8-0x2ff irq 3 on isa0
> sio1: type 16550A
> vga0: <Generic ISA VGA> at port 0x3c0-0x3df iomem 0xa0000-0xbffff on
isa0
> unknown: <IBM Enhanced (101/102-key) KC> can't assign resources
(port)
> unknown: <PNP0501> can't assign resources (port)
> unknown: <PNP0501> can't assign resources (port)
> unknown: <PNP0401> can't assign resources (port)
> unknown: <PNP0700> can't assign resources (port)
> Timecounters tick every 10.000 msec
> Waiting 15 seconds for SCSI devices to settle
> (probe6:ahc0:0:6:0): AutoSense Failed
> (probe5:ahc0:0:6:1): AutoSense Failed
> (probe0:ahc0:0:6:2): AutoSense Failed
> (probe5:ahc0:0:6:3): AutoSense Failed
> (probe5:ahc0:0:6:4): AutoSense Failed
> (probe0:ahc0:0:6:5): AutoSense Failed
> (probe0:ahc0:0:6:6): AutoSense Failed
> (probe0:ahc0:0:6:7): AutoSense Failed
> (probe21:ahc1:0:6:0): AutoSense Failed
> (probe1:ahc1:0:6:1): AutoSense Failed
> (probe1:ahc1:0:6:2): AutoSense Failed
> (probe1:ahc1:0:6:3): AutoSense Failed
> (probe1:ahc1:0:6:4): AutoSense Failed
> (probe1:ahc1:0:6:5): AutoSense Failed
> (probe1:ahc1:0:6:6): AutoSense Failed
> (probe1:ahc1:0:6:7): AutoSense Failed
> sa0 at ahc0 bus 0 target 4 lun 0
> sa0: <WangDAT Model 3400DX 04j0> Removable Sequential Access SCSI-2
device
> sa0: 10.000MB/s transfers (10.000MHz, offset 15)
> ses0 at ahc0 bus 0 target 6 lun 0
> ses0: <FUJITSU SAF-TE PROCESSOR 1.00> Fixed Processor SCSI-2 device
> ses0: 3.300MB/s transfers
> ses0: SAF-TE Compliant Device
> ses1 at ahc1 bus 0 target 6 lun 0
> ses1: <FUJITSU SAF-TE PROCESSOR 1.00> Fixed Processor SCSI-2 device
> ses1: 3.300MB/s transfers
> ses1: SAF-TE Compliant Device
> da0 at ahc0 bus 0 target 0 lun 0
> da0: <FUJITSU M2954E-512 0162> Fixed Direct Access SCSI-2 device
> da0: 40.000MB/s transfers (20.000MHz, offset 8, 16bit), Tagged Queueing
> Enabled
> da0: 4149MB (8498506 512 byte sectors: 255H 63S/T 529C)
> da1 at ahc0 bus 0 target 1 lun 0
> da1: <FUJITSU M2954E-512 0162> Fixed Direct Access SCSI-2 device
> da1: 40.000MB/s transfers (20.000MHz, offset 8, 16bit), Tagged Queueing
> Enabled
> da1: 4149MB (8498506 512 byte sectors: 255H 63S/T 529C)
> da2 at ahc0 bus 0 target 2 lun 0
> da2: <FUJITSU M2954E-512 0162> Fixed Direct Access SCSI-2 device
> da2: 40.000MB/s transfers (20.000MHz, offset 8, 16bit), Tagged Queueing
> Enabled
> da2: 4149MB (8498506 512 byte sectors: 255H 63S/T 529C)
> da3 at ahc1 bus 0 target 0 lun 0
> da3: <FUJITSU M2954E-512 0162> Fixed Direct Access SCSI-2 device
> da3: 40.000MB/s transfers (20.000MHz, offset 8, 16bit), Tagged Queueing
> Enabled
> da3: 4149MB (8498506 512 byte sectors: 255H 63S/T 529C)
> da4 at ahc1 bus 0 target 1 lun 0
> da4: <FUJITSU M2954E-512 0162> Fixed Direct Access SCSI-2 device
> da4: 40.000MB/s transfers (20.000MHz, offset 8, 16bit), Tagged Queueing
> Enabled
> da4: 4149MB (8498506 512 byte sectors: 255H 63S/T 529C)
> da5 at ahc1 bus 0 target 2 lun 0
> da5: <SEAGATE ST39102LC 0006> Fixed Direct Access SCSI-2 device
> da5: 40.000MB/s transfers (20.000MHz, offset 8, 16bit), Tagged Queueing
> Enabled
> da5: 8683MB (17783240 512 byte sectors: 255H 63S/T 1106C)
> cd0 at ahc0 bus 0 target 5 lun 0
> cd0: <MATSHITA CD-ROM CR-508 XS03> Removable CD-ROM SCSI-2 device
> cd0: 10.000MB/s transfers (10.000MHz, offset 15)
> cd0: Attempt to query device size failed: NOT READY, Medium not present
> GEOM_MIRROR: Device mirror0 created (id=138753045).
> GEOM_MIRROR: Device mirror0: provider da0 detected.
> GEOM_CONCAT: Device usr2 created (id=1051984440).
> GEOM_CONCAT: Disk da1 attached to usr2.
> GEOM_CONCAT: Disk da2 attached to usr2.
> GEOM_MIRROR: Device mirror0: provider da3 detected.
> GEOM_MIRROR: Device mirror0: provider da3 activated.
> GEOM_MIRROR: Device mirror0: provider mirror/mirror0 launched.
> GEOM_MIRROR: Device mirror0: rebuilding provider da0.
> GEOM_CONCAT: Disk da4 attached to usr2.
> GEOM_CONCAT: Disk da5 attached to usr2.
> GEOM_CONCAT: Device usr2 activated.
> SMP: AP CPU #3 Launched!
> SMP: AP CPU #1 Launched!
> SMP: AP CPU #2 Launched!
> Mounting root from ufs:/dev/mirror/mirror0a
> WARNING: / was not properly dismounted
> WARNING: /var was not properly dismounted
> WARNING: /usr was not properly dismounted
> /usr: mount pending error: blocks 4 files 2
> WARNING: /usr2 was not properly dismounted
>
> --
> Adrian Wontroba
>
> ------------------------------
>
> Message: 22
> Date: Mon, 15 Nov 2004 00:36:53 -0500
> From: Zaphod Beeblebrox <zbeeble@gmail.com>
> Subject: gvinum again?
> To: freebsd-stable@freebsd.org
> Message-ID: <5f67a8c4041114213657cdb434@mail.gmail.com>
> Content-Type: text/plain; charset=US-ASCII
>
> I'm looking at gstat while fsck'ing a gvinum partition. The
trouble
> I'm seeing is that I don't see activity on the second disk. Now...
> I'm using fsck -n ... just checking things ... so there's no
writes,
> but does gvinum not (yet) load balance on reads?
>
> ------------------------------
>
> Message: 23
> Date: Mon, 15 Nov 2004 06:59:27 +0100
> From: Torfinn Ingolfsen <torfinn.ingolfsen@broadpark.no>
> Subject: Re: msdosfs - support for large disks?
> To: freebsd-stable@freebsd.org
> Message-ID: <20041115065927.4599047a.torfinn.ingolfsen@broadpark.no>
> Content-Type: text/plain; charset=US-ASCII
>
> On Sun, 31 Oct 2004 18:27:08 +0200
> Saulius Menkevicius <bob@nulis.lt> wrote:
>
> > It support those, you just have to include
> > options MSDOSFS_LARGE
> > in you kernel config file.
>
> OK, I found that (shouldn't this be documented in the NOTES file,
> even if it is an experimental patch?), and made a new kernel with it.
>
> > At least it works for me on 184GB fat32 partition.
>
> Well, it works here too, on a 234GB partition. Sort of, at least.
> I can mount the partition, and copy files to (and from) it, make
> directories and so on. But, I get lots of "invalid file handle"
messages
> when I try to copy files to it. That makes it unusable for me.
>
> I guess I'll have to use something else.
> --
> Regards,
> Torfinn Ingolfsen,
> Norway
>
> ------------------------------
>
> Message: 24
> Date: Mon, 15 Nov 2004 01:26:54 -0500
> From: Paul Mather <paul@gromit.dlib.vt.edu>
> Subject: Re: gvinum again?
> To: Zaphod Beeblebrox <zbeeble@gmail.com>
> Cc: freebsd-stable@freebsd.org
> Message-ID: <1100500014.24190.147.camel@zappa.Chelsea-Ct.Org>
> Content-Type: text/plain
>
> On Mon, 2004-11-15 at 00:36 -0500, Zaphod Beeblebrox wrote:
> > I'm looking at gstat while fsck'ing a gvinum partition. The
trouble
> > I'm seeing is that I don't see activity on the second disk.
Now...
> > I'm using fsck -n ... just checking things ... so there's no
writes,
> > but does gvinum not (yet) load balance on reads?
>
> Your observation is correct: it doesn't (yet) load balance across
plexes
> of mirrored volumes; geom_mirror (gmirror) does, though (and offers
> various load-balancing options).
>
> Cheers,
>
> Paul.
> --
> e-mail: paul@gromit.dlib.vt.edu
>
> "Without music to decorate it, time is just a bunch of boring
production
> deadlines or dates by which bills must be paid."
> --- Frank Vincent Zappa
>
> ------------------------------
>
> Message: 25
> Date: Mon, 15 Nov 2004 02:31:49 -0500
> From: Zaphod Beeblebrox <zbeeble@gmail.com>
> Subject: Re: gvinum again?
> To: Paul Mather <paul@gromit.dlib.vt.edu>
> Cc: freebsd-stable@freebsd.org
> Message-ID: <5f67a8c404111423317b721cfe@mail.gmail.com>
> Content-Type: text/plain; charset=US-ASCII
>
> On Mon, 15 Nov 2004 01:26:54 -0500, Paul Mather
<paul@gromit.dlib.vt.edu> wrote:
>
> > Your observation is correct: it doesn't (yet) load balance across
plexes
> > of mirrored volumes; geom_mirror (gmirror) does, though (and offers
> > various load-balancing options).
>
> Is this something planned for the near future? I'm migrating legacy
> units here, so I don't really have a choice.
>
> ... also ... I suspect, whatever form it eventually takes, that volume
> management and geom and/or vinum is essential.
>
> ------------------------------
>
> Message: 26
> Date: Mon, 15 Nov 2004 10:11:18 +0200
> From: Andrei Grudiy <gruand@interexc.com>
> To: freebsd-security@freebsd.org, freebsd-stable@freebsd.org
> Message-ID: <20041115081118.GD5411@interexc.com>
> Content-Type: text/plain; charset=us-ascii
>
> freebsd-questions@freebsd.org
> Cc:
> Bcc:gruand
> Subject: Re: 100.chksetuid in /etc/periodic/security resets the mashine
> Reply-To:
> In-Reply-To: <20041112173824.GT26202@horsey.gshapiro.net>
>
> Hello, kolleages!
> I have a problem.
> When I (or system) start the script 100.chksetuid in
> /etc/periodic/security my machine resets.
> The machine:
> Timecounter "i8254" frequency 1193182 Hz
> CPU: Intel(R) Xeon(TM) CPU 3.06GHz (3056.82-MHz 686-class CPU)
> System version:
> FreeBSD 4.10-STABLE #0: Mon Nov 8 06:50:54 PST 2004
>
> I will glad to have help.
> Thank you in advance.
> --
> Andrei Grudiy.
> Ukraine.
>
> ------------------------------
>
> Message: 27
> Date: Mon, 15 Nov 2004 08:22:35 +0000
> From: Adrian Wontroba <aw1@stade.co.uk>
> Subject: Re: panic: APIC: Previous IPI is stuck
> To: Andy Farkas <andy@bradfieldprichard.com.au>
> Cc: stable@freebsd.org
> Message-ID: <20041115082235.A82851@titus.hanley.stade.co.uk>
> Content-Type: text/plain; charset=us-ascii
>
> On Mon, Nov 15, 2004 at 04:49:56PM +1100, Andy Farkas wrote:
> > [freebsd.org is rejecting my email (cant find hostname)
> > so please feel free to copy this to the list]
>
> So quoted in full.
>
> > On Mon, 15 Nov 2004, Adrian Wontroba wrote:
> > ...
> > > The practice is that it it has now crashed three times in a
couple of
> > > days with "panic: APIC: Previous IPI is stuck", the
most recent one
> > > dragging me out from home early in a Monday morning.
> >
> > /me raises hand
> >
> > I still get panics too (5.3-STABLE cvsup'd last thursday).
> > At one stage I thought it was fixed, but I was wrong.
> > My box does not reboot itself either.
> >
> > > Over in current there are a couple of threads starting in late
September
> > > where a few people are suffering this problem. Like them,
I'm using an
> > > old (1997) Pentium Pro multiprocessor, in my case a 4 way Fujitsu
M700.
> > >
> > > The machine is running with the SMP kernel (ie GENERIC + SMP),
4BSD
> > > scheduler, without preemption.
> >
> > Robert Watson has said it happens on his 4-way xeon box,
> > so its not the "old hardware" thats to blame. (My box is
> > an old Dell quad-ppro too). Something changed in the code
> > around the end of August this year.
> >
> > > I've set kern.sched.ipiwakeup.enabled=0 and crossed my
fingers.
> >
> > Doesn't help. I already tried. Panic will still happen.
>
> Ah. Will it last the day I wonder?
>
> > > I'm a SMP novice. Would the machine become stable if I
switched to a
> > > non-SMP kernel? Reliability is more important than speed in this
case,
> > > and the opportunity for experimentation close to zero.
Creditability
> > > has already been damaged by the gvinum RAID5 experience (8-(
> >
> > A UP kernel will probably run forever. The IPI panic can
> > only happen on SMP kernels.
>
> Thanks. I'll switch back to GENERIC.
>
> > > I'm not knocking 5.3 - in all other respects it seems
wonderful.
> >
> > I'm not knocking 5.3 either, but it seems to its not quite
> > stable. Its more of ".0" release, where things are still
> > getting ironed out (like gvinum, which I also have problems
> > with).
>
> "RELENG_4: Time to die" - for all kinds of good reasons. It was
time
> for 5-STABLE. The future release plan looks promising, but there
> is still the age old problem - how do you get the more of the user
> population to try out and find the problems in new versions before they
> acquire -RELEASE status?
>
> "Mea culpa" - I no longer have a "crash box". Time to
get my mail
> off my own PPro (uniprocessor) box to free it up as such. If I had
> done this, I would have run into the vinum / gvinum issues in a less
> embarrassing fashion.
>
> > Stephan, you mentioned that the IPI code needs rewriting in order to
> > fix this problem... how's it going?
> >
> > - andyf
>
> --
> Adrian Wontroba
>
> ------------------------------
>
> Message: 28
> Date: Mon, 15 Nov 2004 10:49:56 +0200
> From: Andrei Grudiy <gruand@interexc.com>
> Subject: 100.chksetuid in /etc/periodic/security resets the mashine
> To: freebsd-security@freebsd.org, freebsd-stable@freebsd.org
> Cc: freebsd-questions@freebsd.org
> Message-ID: <20041115084956.GA24138@interexc.com>
> Content-Type: text/plain; charset=us-ascii
>
> Hello, kolleages!
> I have a problem.
> When I (or system) start the script 100.chksetuid in
> /etc/periodic/security my machine resets.
> The machine:
> Timecounter "i8254" frequency 1193182 Hz
> CPU: Intel(R) Xeon(TM) CPU 3.06GHz (3056.82-MHz 686-class CPU)
> System version:
> FreeBSD 4.10-STABLE #0: Mon Nov 8 06:50:54 PST 2004
>
> I will glad to have help.
> Thank you in advance.
> --
> Andrei Grudiy.
> Ukraine.
>
> ------------------------------
>
> _______________________________________________
> freebsd-stable@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-stable
> To unsubscribe, send any mail to
"freebsd-stable-unsubscribe@freebsd.org"
>
> End of freebsd-stable Digest, Vol 87, Issue 1
> *********************************************
>