Re: Upgrading 5.3 6.0 buildworld failure in libkrb5
On Mon, Dec 05, 2005 at 03:18:43PM -0800, Vizion wrote: I have tried repeatedly to get make buildworld for upgrading from freebsd 5.3 to 6.0 but get repeated failure in libkrb5. Maybe you should update to the latest 5-STABLE before uprading to 6-STABLE. I have tried with very helpful advice from freebsd-questions contributors: with and without ccache 3x make cleandir prior to build additional cvsup of source tree I always build with an empty /usr/obj. /usr/src/kerberos5/lib/libkrb5/../../../crypto/heimdal/lib/krb5/changepw.c:170: error: syntax error before chpw Dou you need kerberos? I disabeled it through a knob in /etc/make.conf. Check /usr/share/examples/etc/make.conf for details. Last weekend I upgraded my 5-STABLE installation to 6-STABLE and all went smoothly. First I built 6-STABLE from 5-STABLE, activated it and then I built 6-STABLE again. Gunther ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
[PR] The csh core dump on FreeBSD-6.0-STABLE
Hi,
Today, I want to copy a file to a msdosfs mounted on my
FreeBSD-6.0-STABLE. I typed cp /data1/books, then I hit the TAB. It
doesn't response. After a few seconds, the login: appears. The csh core
dump.
In the /var/log/message, says dos2unixtime(): month value out of range
(15) and pid 551 (csh), uid 0: exited on signal 8. Then I gdb the
csh.core, then where says:
#0 0x0806a1e6 in globfree ()
#1 0x0806ab66 in globfree ()
#2 0x0806b440 in globfree ()
#3 0x080747c4 in globfree ()
#4 0x0805c552 in ?? ()
#5 0x in ?? ()
.
.
.
#20 0x08080446 in realloc ()
#21 0x0805e117 in ?? ()
#22 0x in ?? ()
.
.
.
.
#325 0x281b6931 in _none_init () from /lib/libc.so.6
#326 0x0813000d in ?? ()
#327 0x281cc4e4 in ?? () from /lib/libc.so.6
#328 0xbfbeeb58 in ?? ()
#329 0x2813afb4 in wctomb () from /lib/libc.so.6
#330 0x0804a6ce in ?? ()
#331 0x080d1fbc in environ ()
#332 0x in ?? ()
#333 0xbfbf6c38 in ?? ()
#334 0x in ?? ()
.
.
.
.
#642 0x28149ffe in sigsetmask () from /lib/libc.so.6
#xxx 0x in ?? ()
.
.
.
.
#8599 0x28090d9a in malloc () from /libexec/ld-elf.so.1
.
.
.
.
#8605 0x08081a18 in __divdi3 ()
#8606 0x0001 in ?? ()
Then, I test how can reproduce the problem. Here's the details.
fstab: /dev/ad0s5/data1 msdosfs rw,
-L=zh_CN.eucCN 2 2
In the /data1/books, there are some files have a Chinese filename.
If I setenv LANG zh_CN.eucCN and LC_CTYPE zh_CN.eucCN, the problem will
not happen. If I remove these env variables, the problem reproduces.
csh: --version
tcsh 6.14.00 (Astron) 2005-03-25 (i386-intel-FreeBSD) options
wide, nls, dl, al, kan, rh, color, filec
And my /etc/csh.cshrc:
# $FreeBSD: src/etc/csh.cshrc,v 1.3 1999/08/27 23:23:40 peter
Exp $
#
# System-wide .cshrc file for csh(1).
set ostype = `uname -s`# sad, no?
# pretty path
set path = ( ~/bin /bin /usr/local/bin /usr/local/sbin /usr/bin
/sbin \
/usr/sbin /usr/X11R6/bin /usr/local/jdk1.3.1/bin \
)
if ( -d /usr/games ) set path = ( $path /usr/games )
if ( -d /usr/ports ) set path = ( $path
/usr/ports/Tools/scripts )
if ( -d /var/qmail ) set path = ( $path /var/qmail/bin )
if ( -d /home/des/bin ) set path = ( $path /home/des/bin )
# settings
set autocorrect# fix my mistakes.
set autolist = ambiguous #
set cdpath = ( ~ )# lazy
set complete = enhance# vi f.b completes to foo.bar!
set correct = cmd# correct what i type.
set filec# file completion
set prompt = '[EMAIL PROTECTED] %B%~%b%# '
set history = 100# history buffer
set notify# don't wait for activity; instant job
status
set watch=(0 any any)# who's here?
unset autologout# idle.
unset noglob#
# environment setup
setenv EXINITset ai
setenv IRCNAMEXin LI [EMAIL PROTECTED]
setenv PAGERless
setenv LSCOLORS ExGxFxdxCxegedabagExEx
if ( -d ~/tmp ) setenv TMPDIR $HOME/tmp# secure.
if (! $?term) exit# if we don't have a terminal, bail.
# nifty prompt. xterm title if we're in an xterm...
switch ($term)
case aterm:
case rxvt:
case screen:
case xterm:
case xterm-color:
setenv TERM xterm
set xterm=%{\033]2;[EMAIL PROTECTED]:%~\007%}%{\033]1;%m\007%}
breaksw
default:
set xterm=
endsw
unset xterm
Re: [PR] The csh core dump on FreeBSD-6.0-STABLE
Sorry, fotget my hardware configuration. It's a IBM ThinkPad T23 2647-4NC. Piii 1.13, 512M SDR, 40G(HITACHI 5k80), 10/100M Ethernet modem combo card, wifi card original. 2005/12/6, Z R [EMAIL PROTECTED]: Hi, Today, I want to copy a file to a msdosfs mounted on my FreeBSD-6.0-STABLE. I typed cp /data1/books, then I hit the TAB. It doesn't response. After a few seconds, the login: appears. The csh core dump. In the /var/log/message, says dos2unixtime(): month value out of range (15) and pid 551 (csh), uid 0: exited on signal 8. Then I gdb the csh.core, then where says: #0 0x0806a1e6 in globfree () #1 0x0806ab66 in globfree () #2 0x0806b440 in globfree () #3 0x080747c4 in globfree () #4 0x0805c552 in ?? () #5 0x in ?? () . . . #20 0x08080446 in realloc () #21 0x0805e117 in ?? () #22 0x in ?? () . . . . #325 0x281b6931 in _none_init () from /lib/libc.so.6 #326 0x0813000d in ?? () #327 0x281cc4e4 in ?? () from /lib/libc.so.6 #328 0xbfbeeb58 in ?? () #329 0x2813afb4 in wctomb () from /lib/libc.so.6 #330 0x0804a6ce in ?? () #331 0x080d1fbc in environ () #332 0x in ?? () #333 0xbfbf6c38 in ?? () #334 0x in ?? () . . . . #642 0x28149ffe in sigsetmask () from /lib/libc.so.6 #xxx 0x in ?? () . . . . #8599 0x28090d9a in malloc () from /libexec/ld-elf.so.1 . . . . #8605 0x08081a18 in __divdi3 () #8606 0x0001 in ?? () Then, I test how can reproduce the problem. Here's the details. fstab: /dev/ad0s5/data1 msdosfs rw, -L=zh_CN.eucCN 2 2 In the /data1/books, there are some files have a Chinese filename. If I setenv LANG zh_CN.eucCN and LC_CTYPE zh_CN.eucCN, the problem will not happen. If I remove these env variables, the problem reproduces. csh: --version tcsh 6.14.00 (Astron) 2005-03-25 (i386-intel-FreeBSD) options wide, nls, dl, al, kan, rh, color, filec And my /etc/csh.cshrc: # $FreeBSD: src/etc/csh.cshrc,v 1.3 1999/08/27 23:23:40 peter Exp $ # # System-wide .cshrc file for csh(1). set ostype = `uname -s`# sad, no? # pretty path set path = ( ~/bin /bin /usr/local/bin /usr/local/sbin /usr/bin /sbin \ /usr/sbin /usr/X11R6/bin /usr/local/jdk1.3.1/bin \ ) if ( -d /usr/games ) set path = ( $path /usr/games ) if ( -d /usr/ports ) set path = ( $path /usr/ports/Tools/scripts ) if ( -d /var/qmail ) set path = ( $path /var/qmail/bin ) if ( -d /home/des/bin ) set path = ( $path /home/des/bin ) # settings set autocorrect# fix my mistakes. set autolist = ambiguous # set cdpath = ( ~ )# lazy set complete = enhance# vi f.b completes to foo.bar! set correct = cmd# correct what i type. set filec# file completion set prompt = '[EMAIL PROTECTED] %B%~%b%# ' set history = 100# history buffer set notify# don't wait for activity; instant job status set watch=(0 any any)# who's here? unset autologout# idle. unset noglob# # environment setup setenv EXINITset ai setenv IRCNAMEXin LI [EMAIL PROTECTED] setenv PAGERless setenv LSCOLORS ExGxFxdxCxegedabagExEx if ( -d ~/tmp ) setenv TMPDIR $HOME/tmp# secure. if (! $?term) exit# if we don't have a terminal, bail. # nifty prompt. xterm title if we're in an xterm... switch ($term) case aterm: case
Re: [PR] The csh core dump on FreeBSD-6.0-STABLE
On Tue, Dec 06, 2005 at 05:04:48PM +0800, Z R wrote: Hi, Today, I want to copy a file to a msdosfs mounted on my FreeBSD-6.0-STABLE. I typed cp /data1/books, then I hit the TAB. It doesn't response. After a few seconds, the login: appears. The csh core dump. csh is maintained separately from FreeBSD - you should report this csh bug to the authors (see the manpage). Kris pgpQ7Hd5KKKGC.pgp Description: PGP signature
Re: USB Devices not appearing in /dev
On Mon, Dec 05, 2005 at 09:12:44PM +0100, Ronald Klop wrote: On Mon, 05 Dec 2005 07:04:24 +0100, Igor Robul [EMAIL PROTECTED] wrote: On Sun, Dec 04, 2005 at 12:59:14AM +1300, Jonathan Chen wrote: However, if I look in /dev, I only see the generic usb[0-3] devices. When I used to run 5.4-STABLE, the device entries did appear in /dev. I have a similar problem with Palm devices and ucom0 not appearing. In many cases, you need press Sync button on cable to make ucom appear. I think he needs /dev/cuaU0 as mentioned in the FILES section of 'man ucom'. Bingo! I did not realise that the behaviour had changed from 5-STABLE. My bad. Thank you again for solving this problem for me. Cheers. -- Jonathan Chen [EMAIL PROTECTED] -- Opportunities are seldom labeled ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
QUARANTINED: Freebsd-stable@freebsd.org
The message Freebsd-stable@freebsd.org from Bounced mail, sent on 12/6/2005 13:45 was quarantined because it contained either an executable file, a batch file or a screen saver file. All of these types of attachments are considered security risks. Please consult your mail administrator who can release the message. This message was checked by MailScan for WorkgroupMail. www.workgroupmail.com ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Upgrading 5.3 6.0 buildworld failure in libkrb5
On Mon, Dec 05, 2005 at 03:18:43PM -0800, Vizion wrote:
Hi
I have tried repeatedly to get make buildworld for upgrading from freebsd 5.3
to 6.0 but get repeated failure in libkrb5.
FreeBSD 5.3-RELEASE #0: Fri Nov 5 04:19:18 UTC 2004
[EMAIL PROTECTED]:/usr/obj/usr/src/sys/GENERIC
Timecounter i8254 frequency 1193182 Hz quality 0
CPU: AMD Athlon(tm) (1593.54-MHz 686-class CPU)
Origin = AuthenticAMD Id = 0x6a0 Stepping = 0
Features=0x383fbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,MMX,FXSR,SSE
AMD Features=0xc048MP,AMIE,DSP,3DNow!
real memory = 2080309248 (1983 MB)
avail memory = 2030002176 (1935 MB)
ACPI APIC Table: KM400A AWRDACPI
I have tried with very helpful advice from freebsd-questions contributors:
with and without ccache
3x make cleandir prior to build
additional cvsup of source tree
but the problem still remains .
Hopefully someone on stable may have the answer.
Here is my make.conf
SENDMAIL_CF_DIR=/usr/local/share/sendmail/cf
# added by use.perl 2005-11-18 10:51:36
PERL_VER=5.8.7
PERL_VERSION=5.8.7
.if !defined(NOCCACHE)
.if ${.CURDIR:M/usr/src*}
CC=/usr/local/libexec/ccache/cc
CXX=/usr/local/libexec/ccache/c++
.else
CC=cc
CXX=c++
.endif
.else
CC=/usr/bin/cc
CXX=/usr/bin/c++
.endif
The example of setting up ccache in /etc/make.conf is just plain
wrong. It shouldn't be hardcoding CC to /usr/bin/cc, similarly
for CXX. Comment out the ccache stuff completely in /etc/make.conf
(or at least the last else part), make sure your PATH doesn't
include the ccache path, and try again with an empty /usr/obj.
Please report back if it succeeded (it should). Please send your
complaints to the ccache port MAINTAINER as he did not respond to
my email explaining the problem, and I'm getting really tired of
explaining this for the Nth time.
Cheers,
--
Ruslan Ermilov
[EMAIL PROTECTED]
FreeBSD committer
pgpA7r82scSj2.pgp
Description: PGP signature
Re: ZERO_COPY_SOCKETS
Igor Robul [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] On Mon, Dec 05, 2005 at 09:20:28PM -0500, Joshua Coombs wrote: #optionsZERO_COPY_SOCKETS What's the status of this in 6.0-R and 6-stable? The idea of avoiding memory copies when possible seems really appealing for my 386, on which any little boost is significant. : ) http://www.freebsd.org/releases/6.0R/relnotes-i386.html#KERNEL So you can't use FreeBSD-6.0 and greater on 80386 anymore. Ok, lemmie just point out that I'm already running 6.0, just to eliminate that issue. What I'm curious about is weather or not 6.0R's zero copy sockets are considered stable or not. Joshua Coombs ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
buildworld fails
Gcc segfaults for me during a buildworld. In my make.conf: CPUTYPE?= pentium-m CFLAGS= -O2 -pipe My last successful build was: FreeBSD 6.0-STABLE (TPR40-6) #0: Sat Nov 26 23:13:30 CET 2005 # make update was run right before building. Here's a tail of the buildworld log. building profiled panel library ranlib libpanel_p.a cat /usr/src/lib/libpanel/../../contrib/ncurses/man/panel.3x panel.3 gzip -cn panel.3 panel.3.gz === lib/libpcap (all) cc -pg -O2 -pipe -march=pentium-m -DHAVE_CONFIG_H -Dyylval=pcapyylval -I/usr/src/lib/libpcap -I. -D_U_=__attribute__((unused)) -DHAVE_SNPRINTF -DHAVE_VSNPRINTF -DINET6 -I/usr/src/lib/libpcap/../../contrib/libpcap -c grammar.c -o grammar.po cc -pg -O2 -pipe -march=pentium-m -DHAVE_CONFIG_H -Dyylval=pcapyylval -I/usr/src/lib/libpcap -I. -D_U_=__attribute__((unused)) -DHAVE_SNPRINTF -DHAVE_VSNPRINTF -DINET6 -I/usr/src/lib/libpcap/../../contrib/libpcap -c /usr/src/lib/libpcap/../../contrib/libpcap/pcap-bpf.c -o pcap-bpf.po cc -pg -O2 -pipe -march=pentium-m -DHAVE_CONFIG_H -Dyylval=pcapyylval -I/usr/src/lib/libpcap -I. -D_U_=__attribute__((unused)) -DHAVE_SNPRINTF -DHAVE_VSNPRINTF -DINET6 -I/usr/src/lib/libpcap/../../contrib/libpcap -c /usr/src/lib/libpcap/../../contrib/libpcap/pcap.c -o pcap.po cc -pg -O2 -pipe -march=pentium-m -DHAVE_CONFIG_H -Dyylval=pcapyylval -I/usr/src/lib/libpcap -I. -D_U_=__attribute__((unused)) -DHAVE_SNPRINTF -DHAVE_VSNPRINTF -DINET6 -I/usr/src/lib/libpcap/../../contrib/libpcap -c /usr/src/lib/libpcap/../../contrib/libpcap/inet.c -o inet.po cc -pg -O2 -pipe -march=pentium-m -DHAVE_CONFIG_H -Dyylval=pcapyylval -I/usr/src/lib/libpcap -I. -D_U_=__attribute__((unused)) -DHAVE_SNPRINTF -DHAVE_VSNPRINTF -DINET6 -I/usr/src/lib/libpcap/../../contrib/libpcap -c /usr/src/lib/libpcap/../../contrib/libpcap/fad-getad.c -o fad-getad.po cc -pg -O2 -pipe -march=pentium-m -DHAVE_CONFIG_H -Dyylval=pcapyylval -I/usr/src/lib/libpcap -I. -D_U_=__attribute__((unused)) -DHAVE_SNPRINTF -DHAVE_VSNPRINTF -DINET6 -I/usr/src/lib/libpcap/../../contrib/libpcap -c /usr/src/lib/libpcap/../../contrib/libpcap/gencode.c -o gencode.po cc -pg -O2 -pipe -march=pentium-m -DHAVE_CONFIG_H -Dyylval=pcapyylval -I/usr/src/lib/libpcap -I. -D_U_=__attribute__((unused)) -DHAVE_SNPRINTF -DHAVE_VSNPRINTF -DINET6 -I/usr/src/lib/libpcap/../../contrib/libpcap -c /usr/src/lib/libpcap/../../contrib/libpcap/optimize.c -o optimize.po /usr/src/lib/libpcap/../../contrib/libpcap/optimize.c: In function `convert_code_r': /usr/src/lib/libpcap/../../contrib/libpcap/optimize.c:2213: internal compiler error: Segmentation fault: 11 Please submit a full bug report, with preprocessed source if appropriate. See URL:http://gcc.gnu.org/bugs.html for instructions. *** Error code 1 Stop in /usr/src/lib/libpcap. *** Error code 1 Stop in /usr/src/lib. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: make buildworld fails:: cmap.h: No such file or directory
On Sun, Dec 04, 2005 at 01:14:01PM -0600, Michael Bowerman wrote:
The poblem ended up being that I had in my make.conf:
CFLAGS= -O2 -pipe
CXXFLAGS= -O2 -pipe
I ended up just removing the CXXFLAGS line. I probably cold have used
CXXFLAGS+=... But, I don't think I have any needs for specific C++ flags.
Yes, CXXFLAGS is an addition to CFLAGS:
CXXFLAGS?= ${CFLAGS:N-std=*:N-Wnested-externs:N-W*-prototypes}
That is, anything added to CFLAGS is also added to CXXFLAGS with
some exceptions.
Cheers,
--
Ruslan Ermilov
[EMAIL PROTECTED]
FreeBSD committer
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ZERO_COPY_SOCKETS
On Dec 6, 2005, at 7:37 AM, Joshua Coombs wrote: Ok, lemmie just point out that I'm already running 6.0, just to eliminate that issue. So you were not truthful about running a 386... What I'm curious about is weather or not 6.0R's zero copy sockets are considered stable or not. Works for me[tm]. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ZERO_COPY_SOCKETS
Vivek Khera [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] On Dec 6, 2005, at 7:37 AM, Joshua Coombs wrote: Ok, lemmie just point out that I'm already running 6.0, just to eliminate that issue. So you were not truthful about running a 386... No, I'm running on a 386. It's a bodged, banged up pile, but it's a 386. FreeBSD 6 can infact run on a subset of 386 hardware with the right massaging. What I'm curious about is weather or not 6.0R's zero copy sockets are considered stable or not. Works for me[tm]. Cool, I'll have to give it a go then. Joshua Coombs ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Upgrading 5.3 6.0 buildworld failure in libkrb5
On Tuesday 06 December 2005 04:00, the author Ruslan Ermilov contributed to
the dialogue on-
Re: Upgrading 5.3 6.0 buildworld failure in libkrb5:
On Mon, Dec 05, 2005 at 03:18:43PM -0800, Vizion wrote:
Hi
I have tried repeatedly to get make buildworld for upgrading from freebsd
5.3 to 6.0 but get repeated failure in libkrb5.
FreeBSD 5.3-RELEASE #0: Fri Nov 5 04:19:18 UTC 2004
[EMAIL PROTECTED]:/usr/obj/usr/src/sys/GENERIC
Timecounter i8254 frequency 1193182 Hz quality 0
CPU: AMD Athlon(tm) (1593.54-MHz 686-class CPU)
Origin = AuthenticAMD Id = 0x6a0 Stepping = 0
Features=0x383fbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MC
A,CMOV,PAT,PSE36,MMX,FXSR,SSE AMD Features=0xc048MP,AMIE,DSP,3DNow!
real memory = 2080309248 (1983 MB)
avail memory = 2030002176 (1935 MB)
ACPI APIC Table: KM400A AWRDACPI
I have tried with very helpful advice from freebsd-questions contributors:
with and without ccache
3x make cleandir prior to build
additional cvsup of source tree
but the problem still remains .
Hopefully someone on stable may have the answer.
Here is my make.conf
SENDMAIL_CF_DIR=/usr/local/share/sendmail/cf
# added by use.perl 2005-11-18 10:51:36
PERL_VER=5.8.7
PERL_VERSION=5.8.7
.if !defined(NOCCACHE)
.if ${.CURDIR:M/usr/src*}
CC=/usr/local/libexec/ccache/cc
CXX=/usr/local/libexec/ccache/c++
.else
CC=cc
CXX=c++
.endif
.else
CC=/usr/bin/cc
CXX=/usr/bin/c++
.endif
The example of setting up ccache in /etc/make.conf is just plain
wrong. It shouldn't be hardcoding CC to /usr/bin/cc, similarly
for CXX. Comment out the ccache stuff completely in /etc/make.conf
(or at least the last else part), make sure your PATH doesn't
include the ccache path, and try again with an empty /usr/obj.
Please report back if it succeeded (it should). Please send your
complaints to the ccache port MAINTAINER as he did not respond to
my email explaining the problem, and I'm getting really tired of
explaining this for the Nth time.
Thanks very much - I am building right now --after deinstalling ccache, make
cleandir x3 and an empty /usr/obj. I will post the results here
Thanks again for taking the time to reply
david
--
40 yrs navigating and computing in blue waters.
English Owner Captain of British Registered 60' bluewater Ketch S/V Taurus.
Currently in San Diego, CA. Sailing bound for Europe via Panama Canal after
completing engineroom refit.
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ZERO_COPY_SOCKETS
On Tue, Dec 06, 2005 at 07:37:59AM -0500, Joshua Coombs wrote: Igor Robul [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] On Mon, Dec 05, 2005 at 09:20:28PM -0500, Joshua Coombs wrote: #optionsZERO_COPY_SOCKETS What's the status of this in 6.0-R and 6-stable? The idea of avoiding memory copies when possible seems really appealing for my 386, on which any little boost is significant. : ) http://www.freebsd.org/releases/6.0R/relnotes-i386.html#KERNEL So you can't use FreeBSD-6.0 and greater on 80386 anymore. Ok, lemmie just point out that I'm already running 6.0, just to eliminate that issue. What I'm curious about is weather or not 6.0R's zero copy sockets are considered stable or not. Yes. Kris pgpqu12iIuX1R.pgp Description: PGP signature
Re: buildworld fails
On Mar 6 décembre 2005 15:48, [LoN]Kamikaze wrote: Gcc segfaults for me during a buildworld. it shouldn't happend. you know that. cc -pg -O2 -pipe -march=pentium-m -DHAVE_CONFIG_H -Dyylval=pcapyylval -I/usr/src/lib/libpcap -I. -D_U_=__attribute__((unused)) -DHAVE_SNPRINTF -DHAVE_VSNPRINTF -DINET6 -I/usr/src/lib/libpcap/../../contrib/libpcap -c /usr/src/lib/libpcap/../../contrib/libpcap/optimize.c -o optimize.po /usr/src/lib/libpcap/../../contrib/libpcap/optimize.c: In function `convert_code_r': /usr/src/lib/libpcap/../../contrib/libpcap/optimize.c:2213: internal compiler error: Segmentation fault: 11 Please submit a full bug report, with preprocessed source if appropriate. See URL:http://gcc.gnu.org/bugs.html for instructions. please do if you already didn't, it will help to improve gcc and/or freebsd depending on what caused the bug. you can also post the preprocessed source for other freebsd users to test. -- Matthieu Michaud - EPITA 2007 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Upgrading 5.3 6.0 buildworld failure now in libmagic
On Tuesday 06 December 2005 11:47, the author Vizion contributed to the dialogue which was on- Re: Upgrading 5.3 6.0 buildworld failure in libkrb5 but is currently: Upgrading 5.3 6.0 buildworld failure now in libmagic On Tuesday 06 December 2005 04:00, the author Ruslan Ermilov contributed to the dialogue on- snip The example of setting up ccache in /etc/make.conf is just plain wrong. It shouldn't be hardcoding CC to /usr/bin/cc, similarly for CXX. Comment out the ccache stuff completely in /etc/make.conf (or at least the last else part), make sure your PATH doesn't include the ccache path, and try again with an empty /usr/obj. Please report back if it succeeded (it should). Please send your complaints to the ccache port MAINTAINER as he did not respond to my email explaining the problem, and I'm getting really tired of explaining this for the Nth time. Thanks very much - I am building right now --after deinstalling ccache, make cleandir x3 and an empty /usr/obj. I will post the results here Well certainly made a difference but now it fails in magic building static magic library ranlib libmagic.a cc -fpic -DPIC -O2 -fno-strict-aliasing -pipe -DMAGIC='/usr/share/misc/magic' -DBUILTIN_ELF -DELFCORE -DHAVE_CONFIG_H -I/usr/src/lib/libmagic -I/usr/src/lib/libmagic/../../contrib/file -c /usr/src/lib/libmagic/../../contrib/file/apprentice.c -o apprentice.So cc -fpic -DPIC -O2 -fno-strict-aliasing -pipe -DMAGIC='/usr/share/misc/magic' -DBUILTIN_ELF -DELFCORE -DHAVE_CONFIG_H -I/usr/src/lib/libmagic -I/usr/src/lib/libmagic/../../contrib/file -c /usr/src/lib/libmagic/../../contrib/file/apptype.c -o apptype.So cc -fpic -DPIC -O2 -fno-strict-aliasing -pipe -DMAGIC='/usr/share/misc/magic' -DBUILTIN_ELF -DELFCORE -DHAVE_CONFIG_H -I/usr/src/lib/libmagic -I/usr/src/lib/libmagic/../../contrib/file -c /usr/src/lib/libmagic/../../contrib/file/ascmagic.c -o ascmagic.So cc -fpic -DPIC -O2 -fno-strict-aliasing -pipe -DMAGIC='/usr/share/misc/magic' -DBUILTIN_ELF -DELFCORE -DHAVE_CONFIG_H -I/usr/src/lib/libmagic -I/usr/src/lib/libmagic/../../contrib/file -c /usr/src/lib/libmagic/../../contrib/file/compress.c -o compress.So cc -fpic -DPIC -O2 -fno-strict-aliasing -pipe -DMAGIC='/usr/share/misc/magic' -DBUILTIN_ELF -DELFCORE -DHAVE_CONFIG_H -I/usr/src/lib/libmagic -I/usr/src/lib/libmagic/../../contrib/file -c /usr/src/lib/libmagic/../../contrib/file/fsmagic.c -o fsmagic.So cc -fpic -DPIC -O2 -fno-strict-aliasing -pipe -DMAGIC='/usr/share/misc/magic' -DBUILTIN_ELF -DELFCORE -DHAVE_CONFIG_H -I/usr/src/lib/libmagic -I/usr/src/lib/libmagic/../../contrib/file -c /usr/src/lib/libmagic/../../contrib/file/funcs.c -o funcs.So cc -fpic -DPIC -O2 -fno-strict-aliasing -pipe -DMAGIC='/usr/share/misc/magic' -DBUILTIN_ELF -DELFCORE -DHAVE_CONFIG_H -I/usr/src/lib/libmagic -I/usr/src/lib/libmagic/../../contrib/file -c /usr/src/lib/libmagic/../../contrib/file/is_tar.c -o is_tar.So cc -fpic -DPIC -O2 -fno-strict-aliasing -pipe -DMAGIC='/usr/share/misc/magic' -DBUILTIN_ELF -DELFCORE -DHAVE_CONFIG_H -I/usr/src/lib/libmagic -I/usr/src/lib/libmagic/../../contrib/file -c /usr/src/lib/libmagic/../../contrib/file/magic.c -o magic.So cc -fpic -DPIC -O2 -fno-strict-aliasing -pipe -DMAGIC='/usr/share/misc/magic' -DBUILTIN_ELF -DELFCORE -DHAVE_CONFIG_H -I/usr/src/lib/libmagic -I/usr/src/lib/libmagic/../../contrib/file -c /usr/src/lib/libmagic/../../contrib/file/print.c -o print.So cc -fpic -DPIC -O2 -fno-strict-aliasing -pipe -DMAGIC='/usr/share/misc/magic' -DBUILTIN_ELF -DELFCORE -DHAVE_CONFIG_H -I/usr/src/lib/libmagic -I/usr/src/lib/libmagic/../../contrib/file -c /usr/src/lib/libmagic/../../contrib/file/readelf.c -o readelf.So cc -fpic -DPIC -O2 -fno-strict-aliasing -pipe -DMAGIC='/usr/share/misc/magic' -DBUILTIN_ELF -DELFCORE -DHAVE_CONFIG_H -I/usr/src/lib/libmagic -I/usr/src/lib/libmagic/../../contrib/file -c /usr/src/lib/libmagic/../../contrib/file/softmagic.c -o softmagic.So building shared library libmagic.so.2 cat /usr/src/lib/libmagic/../../contrib/file/Header /usr/src/lib/libmagic/../../contrib/file/Localstuff /usr/src/lib/libmagic/../../contrib/file/Magdir/xo65,v /usr/src/lib/libmagic/../../contrib/file/Magdir/virtutech,v /usr/src/lib/libmagic/../../contrib/file/Magdir/uuencode,v /usr/src/lib/libmagic/../../contrib/file/Magdir/netbsd,v /usr/src/lib/libmagic/../../contrib/file/Magdir/allegro /usr/src/lib/libmagic/../../contrib/file/Magdir/sccs /usr/src/lib/libmagic/../../contrib/file/Magdir/sysex /usr/src/lib/libmagic/../../contrib/file/Magdir/xdelta /usr/src/lib/libmagic/../../contrib/file/Magdir/zyxel /usr/src/lib/libmagic/../../contrib/file/Magdir/riff,v /usr/src/lib/libmagic/../../contrib/file/Magdir/games /usr/src/lib/libmagic/../../contrib/file/Magdir/vicar /usr/src/lib/libmagic/../../contrib/file/Magdir/mlssa /usr/src/lib/libmagic/../../contrib/file/Magdir/geos /usr/src/lib/libmagic/../../contrib/file/Magdir/fsav
Re: Upgrading 5.3 6.0 buildworld failure now in libmagic
On Tue, Dec 06, 2005 at 01:20:44PM -0800, Vizion wrote: On Tuesday 06 December 2005 11:47, the author Vizion contributed to the dialogue which was on- Re: Upgrading 5.3 6.0 buildworld failure in libkrb5 but is currently: Upgrading 5.3 6.0 buildworld failure now in libmagic On Tuesday 06 December 2005 04:00, the author Ruslan Ermilov contributed to the dialogue on- snip The example of setting up ccache in /etc/make.conf is just plain wrong. It shouldn't be hardcoding CC to /usr/bin/cc, similarly for CXX. Comment out the ccache stuff completely in /etc/make.conf (or at least the last else part), make sure your PATH doesn't include the ccache path, and try again with an empty /usr/obj. Please report back if it succeeded (it should). Please send your complaints to the ccache port MAINTAINER as he did not respond to my email explaining the problem, and I'm getting really tired of explaining this for the Nth time. Thanks very much - I am building right now --after deinstalling ccache, make cleandir x3 and an empty /usr/obj. I will post the results here Well certainly made a difference but now it fails in magic Update to 5.4 before trying to update to 6.0. Kris pgpf2p3434d7o.pgp Description: PGP signature
Re: Upgrading 5.3 6.0 buildworld failure now in libmagic
Kris Kennaway wrote: On Tue, Dec 06, 2005 at 01:20:44PM -0800, Vizion wrote: On Tuesday 06 December 2005 11:47, the author Vizion contributed to the dialogue which was on- Re: Upgrading 5.3 6.0 buildworld failure in libkrb5 but is currently: Upgrading 5.3 6.0 buildworld failure now in libmagic On Tuesday 06 December 2005 04:00, the author Ruslan Ermilov contributed to the dialogue on- snip The example of setting up ccache in /etc/make.conf is just plain wrong. It shouldn't be hardcoding CC to /usr/bin/cc, similarly for CXX. Comment out the ccache stuff completely in /etc/make.conf (or at least the last else part), make sure your PATH doesn't include the ccache path, and try again with an empty /usr/obj. Please report back if it succeeded (it should). Please send your complaints to the ccache port MAINTAINER as he did not respond to my email explaining the problem, and I'm getting really tired of explaining this for the Nth time. Thanks very much - I am building right now --after deinstalling ccache, make cleandir x3 and an empty /usr/obj. I will post the results here Well certainly made a difference but now it fails in magic Update to 5.4 before trying to update to 6.0. Kris So is there any supported direct 5.3-6.0 upgrade path, or is a stop in 5.4 ville manditory now.? jim ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Upgrading 5.3 6.0 buildworld failure now in libmagic
On Tue, Dec 06, 2005 at 02:36:05PM -0700, secmgr wrote: Update to 5.4 before trying to update to 6.0. Kris So is there any supported direct 5.3-6.0 upgrade path, or is a stop in 5.4 ville manditory now.? I tried to say that you have to update to 5.4 before you can update to 6.0, i.e. updates from older versions are not supported. It may be easier to do a binary upgrade (i.e. download release media and use the upgrade option). Kris pgphYPjbZzGAM.pgp Description: PGP signature
Re: buildworld fails
The error also appeared without optimizations. So far compiling with optimizations has never caused any trouble for me. Now it is working without problems. I suspect that it was a cooling problem of my RAM. Adi Pircalabu wrote: On Tue, 06 Dec 2005 15:48:30 +0100 [LoN]Kamikaze [EMAIL PROTECTED] wrote: Gcc segfaults for me during a buildworld. In my make.conf: CPUTYPE?= pentium-m CFLAGS= -O2 -pipe Hi, you probably know it's not recommended to use optimization flags when building the base system. Please comment CFLAGS in /etc/make.conf and retry with the same source tree. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Upgrading 5.3 6.0 buildworld failure now in libmagic
On Tuesday 06 December 2005 23:46, Kris Kennaway wrote: On Tue, Dec 06, 2005 at 02:36:05PM -0700, secmgr wrote: Update to 5.4 before trying to update to 6.0. Kris So is there any supported direct 5.3-6.0 upgrade path, or is a stop in 5.4 ville manditory now.? I tried to say that you have to update to 5.4 before you can update to 6.0, i.e. updates from older versions are not supported. It may be easier to do a binary upgrade (i.e. download release media and use the upgrade option). At least with a vanilla install of 5.3, I had no problem going directly to 6.0. This was an extremely basic install, and I only did it because I lost my 6.0-R cd :) A. -- Andy Fawcett | [EMAIL PROTECTED] | [EMAIL PROTECTED] In an open world without walls and fences, | [EMAIL PROTECTED] we wouldn't need Windows and Gates. -- anon | [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Upgrading 5.3 6.0 buildworld failure now in libmagic
On Tuesday 06 December 2005 13:28, the author Kris Kennaway contributed to the dialogue on- Re: Upgrading 5.3 6.0 buildworld failure now in libmagic: On Tue, Dec 06, 2005 at 01:20:44PM -0800, Vizion wrote: On Tuesday 06 December 2005 11:47, the author Vizion contributed to the dialogue which was on- Re: Upgrading 5.3 6.0 buildworld failure in libkrb5 but is currently: Upgrading 5.3 6.0 buildworld failure now in libmagic On Tuesday 06 December 2005 04:00, the author Ruslan Ermilov contributed to the dialogue on- snip The example of setting up ccache in /etc/make.conf is just plain wrong. It shouldn't be hardcoding CC to /usr/bin/cc, similarly for CXX. Comment out the ccache stuff completely in /etc/make.conf (or at least the last else part), make sure your PATH doesn't include the ccache path, and try again with an empty /usr/obj. Please report back if it succeeded (it should). Please send your complaints to the ccache port MAINTAINER as he did not respond to my email explaining the problem, and I'm getting really tired of explaining this for the Nth time. Thanks very much - I am building right now --after deinstalling ccache, make cleandir x3 and an empty /usr/obj. I will post the results here Well certainly made a difference but now it fails in magic Update to 5.4 before trying to update to 6.0. Thank you Kris You are a mine of information as always. I do wish there was some consistency in updating about this.. I asked on this list whether I needed to upgrade to 5.4 before mocing to 6 and the advice suggested that I could go straight from 5.3 to 6 but there we are -- guess that's life chuckles Presumably it would be safest to delete /usr/src/* and cvsup with tag=RELENG_5 Thanks again david -- 40 yrs navigating and computing in blue waters. English Owner Captain of British Registered 60' bluewater Ketch S/V Taurus. Currently in San Diego, CA. Sailing bound for Europe via Panama Canal after completing engineroom refit. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Upgrading 5.3 6.0 buildworld failure now in libmagic
On Tuesday 06 December 2005 14:15, the author Vizion contributed to the dialogue on- Re: Upgrading 5.3 6.0 buildworld failure now in libmagic: On Tuesday 06 December 2005 13:28, the author Kris Kennaway contributed to the dialogue on- Re: Upgrading 5.3 6.0 buildworld failure now in libmagic: On Tue, Dec 06, 2005 at 01:20:44PM -0800, Vizion wrote: On Tuesday 06 December 2005 11:47, the author Vizion contributed to the dialogue which was on- Re: Upgrading 5.3 6.0 buildworld failure in libkrb5 but is currently: Upgrading 5.3 6.0 buildworld failure now in libmagic On Tuesday 06 December 2005 04:00, the author Ruslan Ermilov contributed to the dialogue on- snip The example of setting up ccache in /etc/make.conf is just plain wrong. It shouldn't be hardcoding CC to /usr/bin/cc, similarly for CXX. Comment out the ccache stuff completely in /etc/make.conf (or at least the last else part), make sure your PATH doesn't include the ccache path, and try again with an empty /usr/obj. Please report back if it succeeded (it should). Please send your complaints to the ccache port MAINTAINER as he did not respond to my email explaining the problem, and I'm getting really tired of explaining this for the Nth time. Thanks very much - I am building right now --after deinstalling ccache, make cleandir x3 and an empty /usr/obj. I will post the results here Well certainly made a difference but now it fails in magic Update to 5.4 before trying to update to 6.0. Thank you Kris You are a mine of information as always. I do wish there was some consistency in updating about this.. I asked on this list whether I needed to upgrade to 5.4 before mocing to 6 and the advice suggested that I could go straight from 5.3 to 6 but there we are -- guess that's life chuckles Presumably it would be safest to delete /usr/src/* and cvsup with tag=RELENG_5 Thanks again david Just an additional question if some one has time to answer. Should I upgrade my ports from 5.4 as well prior to moving to 6? I have a large ports installation on the system I am upgrading. david -- 40 yrs navigating and computing in blue waters. English Owner Captain of British Registered 60' bluewater Ketch S/V Taurus. Currently in San Diego, CA. Sailing bound for Europe via Panama Canal after completing engineroom refit. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Upgrading 5.3 6.0 buildworld failure now in libmagic
On Tue, 6 Dec 2005, Vizion wrote: Re: Upgrading 5.3 6.0 buildworld failure in libkrb5 but is currently: Upgrading 5.3 6.0 buildworld failure now in libmagic You should first upgrade to the latest 5-STABLE (cvs tag RELENG_5), then you should be able to upgrade to 6-STABLE (cvs tag RELENG_6). hth, Doug -- This .signature sanitized for your protection ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Upgrading 5.3 6.0 buildworld failure now in libmagic
On Tue, 6 Dec 2005, Vizion wrote: Just an additional question if some one has time to answer. Should I upgrade my ports from 5.4 as well prior to moving to 6? No, that's not needed. hth, Doug -- This .signature sanitized for your protection ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Upgrading 5.3 6.0 buildworld failure now in libmagic
On Tuesday 06 December 2005 14:36, the author Doug Barton contributed to the dialogue on- Re: Upgrading 5.3 6.0 buildworld failure now in libmagic: On Tue, 6 Dec 2005, Vizion wrote: Just an additional question if some one has time to answer. Should I upgrade my ports from 5.4 as well prior to moving to 6? No, that's not needed. Thanks again david -- 40 yrs navigating and computing in blue waters. English Owner Captain of British Registered 60' bluewater Ketch S/V Taurus. Currently in San Diego, CA. Sailing bound for Europe via Panama Canal after completing engineroom refit. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Upgrading 5.3 6.0 buildworld failure now in libmagic
Kris Kennaway wrote: On Tue, Dec 06, 2005 at 02:36:05PM -0700, secmgr wrote: Update to 5.4 before trying to update to 6.0. Kris So is there any supported direct 5.3-6.0 upgrade path, or is a stop in 5.4 ville manditory now.? I tried to say that you have to update to 5.4 before you can update to 6.0, i.e. updates from older versions are not supported. It may be easier to do a binary upgrade (i.e. download release media and use the upgrade option). Kris Not to belabour this, but the 6.0 release notes do specificly say 5.3 RELEASE and newer. Source upgrades to FreeBSD 6.0-RELEASE are only supported from FreeBSD 5.3-RELEASE or later. Users of older systems wanting to upgrade 6.0-RELEASE will need to update to FreeBSD 5.3 or newer first, then to FreeBSD 6.0-RELEASE. This is one of my pet peeves with FreeBSD. You can read the Release Notes, the UPDATING, the ERRATA, the HARDWARE, thinking you've prepped yourself for the upgrade, and still be screwed. If RE wants to change the requirements for upgrading, then how bleeping hard would it be to update either release notes or errata. It's not so much that I now need to do multiple upgrades (ok, that IS pretty annoying), it's that I'd never of known unless I followed this thread. I've run into this while installing since 4.4, and it's gotten really bad since the whole 5.3 mess. Now it's deja vu all over again. jim ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Upgrading 5.3 6.0 buildworld failure now in libmagic
On Tue, Dec 06, 2005 at 05:23:42PM -0700, secmgr wrote: Update to 5.4 before trying to update to 6.0. Kris So is there any supported direct 5.3-6.0 upgrade path, or is a stop in 5.4 ville manditory now.? I tried to say that you have to update to 5.4 before you can update to 6.0, i.e. updates from older versions are not supported. It may be easier to do a binary upgrade (i.e. download release media and use the upgrade option). Kris Not to belabour this, but the 6.0 release notes do specificly say 5.3 RELEASE and newer. You're right, as others have also pointed out. Source upgrades to FreeBSD 6.0-RELEASE are only supported from FreeBSD 5.3-RELEASE or later. Users of older systems wanting to upgrade 6.0-RELEASE will need to update to FreeBSD 5.3 or newer first, then to FreeBSD 6.0-RELEASE. This is one of my pet peeves with FreeBSD. You can read the Release Notes, the UPDATING, the ERRATA, the HARDWARE, thinking you've prepped yourself for the upgrade, and still be screwed. If RE wants to change the requirements for upgrading, then how bleeping hard would it be to update either release notes or errata. This didn't happen here, so you don't need to be upset at RE. Kris pgpdXD8SIxbxN.pgp Description: PGP signature
Re: Upgrading 5.3 6.0 buildworld failure now in libmagic
On Tue, 6 Dec 2005, secmgr wrote: Not to belabour this, but the 6.0 release notes do specificly say 5.3 RELEASE and newer. 5.4-STABLE is newer. :) Source upgrades to FreeBSD 6.0-RELEASE are only supported from FreeBSD 5.3-RELEASE or later. Users of older systems wanting to upgrade 6.0-RELEASE will need to update to FreeBSD 5.3 or newer first, then to FreeBSD 6.0-RELEASE. How does this change to UPDATING in RELENG_6 look to you: Index: UPDATING === RCS file: /home/ncvs/src/UPDATING,v retrieving revision 1.416.2.7 diff -u -r1.416.2.7 UPDATING --- UPDATING1 Nov 2005 23:44:40 - 1.416.2.7 +++ UPDATING7 Dec 2005 00:42:04 - @@ -229,7 +229,13 @@ page for more details. Due to several updates to the build infrastructure, source - upgrades from versions prior to 5.3 no longer supported. + upgrades from versions prior to 5.4-STABLE are not likely + to succeed. + + When upgrading from one major version to another, it is + generally best to upgrade to the latest code in the branch + currently installed first, then do another upgrade to the + new branch. This is one of my pet peeves with FreeBSD. You can read the Release Notes, the UPDATING, the ERRATA, the HARDWARE, thinking you've prepped yourself for the upgrade, and still be screwed. This is an open source project. The only way that things improve is if people help make it better. It's also worth pointing out that this issue of upgrading to the latest version of the branch you're in has been common knowledge for, basically, always; so if the folks that wrote the release notes neglected to include it, it's understandable. (Although, as you point out, potentially frustrating for new(er) users.) If RE wants to change the requirements for upgrading, then how bleeping hard would it be to update either release notes or errata. It's not so much that I now need to do multiple upgrades (ok, that IS pretty annoying), it's that I'd never of known unless I followed this thread. Ok, so, after you calm down a bit, why don't you write a message to [EMAIL PROTECTED] and mention this issue. hth, Doug -- This .signature sanitized for your protection ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Upgrading 5.3 6.0 buildworld failure now in libmagic
On Tue, December 6, 2005 19:44, Doug Barton wrote: On Tue, 6 Dec 2005, secmgr wrote: Not to belabour this, but the 6.0 release notes do specificly say 5.3 RELEASE and newer. 5.4-STABLE is newer. :) Source upgrades to FreeBSD 6.0-RELEASE are only supported from FreeBSD 5.3-RELEASE or later. Users of older systems wanting to upgrade 6.0-RELEASE will need to update to FreeBSD 5.3 or newer first, then to FreeBSD 6.0-RELEASE. How does this change to UPDATING in RELENG_6 look to you: Index: UPDATING === RCS file: /home/ncvs/src/UPDATING,v retrieving revision 1.416.2.7 diff -u -r1.416.2.7 UPDATING --- UPDATING1 Nov 2005 23:44:40 - 1.416.2.7 +++ UPDATING7 Dec 2005 00:42:04 - @@ -229,7 +229,13 @@ page for more details. Due to several updates to the build infrastructure, source - upgrades from versions prior to 5.3 no longer supported. + upgrades from versions prior to 5.4-STABLE are not likely + to succeed. Sorry to butt in but.. Doesn't the definition of -STABLE change, for all intents and purposes, by the minute? What next, versions prior to 5.4-STABLE as of MMDD ? + + When upgrading from one major version to another, it is + generally best to upgrade to the latest code in the branch + currently installed first, then do another upgrade to the + new branch. This is getting closer to the truth. Why don't you just say update to the most recent RELENG_5 before attempting. Future proof, no room for confusion. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
6.0-stable panic in ohci_softintr when using ucom/uftdi
My setup is:
ASUS Pundant Booksize PC Celeron 2.66Ghz, 512M ram, 4 USB ports.
Attached is one Netcomm USB modem which uses the ucom / uftdi
drivers, and is configured for auto answer.
Source is 6.0 stable as of today 7th Dec 2005.
Devices in /dev that get created are:
cuaU0
cuaU0.init
cuaU0.lock
ttyU0.init
ttyU0.lock
ttyd0
I have added the following to /etc/ttys:
ttyU0 /usr/libexec/getty modem.230400 dialup on insecure
and this to /etc/gettytab:
modem.230400|modems-230k:\
:hw:np:sp#230400:
As soon at the modem rings, the machine panics. I don't think the
modem even gets time to pick up the line. This doesn't happen on
a 5.4-stable box with 6 modems connected, but 5.4-stable appears
to have other hanging issues, thus why I am trying out 6.0-stable.
Recent changes to ohci.c (1.154.2.1) in this area (2 days ago) ??
Should I raise a PR ?
Paul.
# kgdb kernel.debug /var/crash/vmcore.2
kgdb: core file: /var/crash/vmcore.2
kgdb: kernel image: kernel.debug
[GDB will not be able to debug user-mode
threads: /usr/lib/libthread_db.so: Undefined sym
bol ps_pglobal_lookup]
GNU gdb 6.1.1 [FreeBSD]
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you
are
welcome to change it and/or distribute copies of it under certain
conditions.
Type show copying to see the conditions.
There is absolutely no warranty for GDB. Type show warranty for
details.
This GDB was configured as i386-marcel-freebsd.
Unread portion of the kernel message buffer:
ucom0: open bulk out error (addr 2): IN_USE
Fatal trap 12: page fault while in kernel mode
fault virtual address = 0x24
fault code = supervisor read, page not present
instruction pointer = 0x20:0xc0474c36
stack pointer = 0x28:0xd3133c7c
frame pointer = 0x28:0xd3133cac
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, def32 1, gran 1
processor eflags= interrupt enabled, resume, IOPL = 0
current process = 29 (irq19: ohci0 ohci1+)
trap number = 12
panic: page fault
Uptime: 47s
Dumping 446 MB (2 chunks)
chunk 0: 1MB (159 pages) ... ok
chunk 1: 447MB (114240 pages) 431 415 399 383 367 351 335 319 303 287
271 255 239 223 2
07 191 175 159 143 127 111 95 79 63 47 31 15
#0 doadump () at pcpu.h:165
165 __asm __volatile(movl %%fs:0,%0 : =r (td));
(kgdb) backtrace
#0 doadump () at pcpu.h:165
#1 0xc04c8a42 in boot (howto=260)
at /usr/src/sys/kern/kern_shutdown.c:399
#2 0xc04c8cd8 in panic (fmt=0xc05f6b91 %s)
at /usr/src/sys/kern/kern_shutdown.c:555
#3 0xc05d7e34 in trap_fatal (frame=0xd3133c3c, eva=36)
at /usr/src/sys/i386/i386/trap.c:836
#4 0xc05d7b9b in trap_pfault (frame=0xd3133c3c, usermode=0, eva=36)
at /usr/src/sys/i386/i386/trap.c:744
#5 0xc05d77f9 in trap (frame=
{tf_fs = -1027342328, tf_es = -1027342296, tf_ds = -1028849624,
tf_edi = -1028264960, tf_esi = -1028043056, tf_ebp = -753714004, tf_isp
= -753714072, tf_ebx = 2, tf_edx = -1028786304, tf_ecx = 0, tf_eax =
-1027196800, tf_trapno = 12, tf_err = 0, tf_eip = -1069069258, tf_cs =
32, tf_eflags = 590466, tf_esp = -1068655605, tf_ss = -1028786304})
at /usr/src/sys/i386/i386/trap.c:434
#6 0xc05c7f3a in calltrap () at /usr/src/sys/i386/i386/exception.s:139
#7 0xc0474c36 in ohci_softintr (v=0xc2b8b000)
at /usr/src/sys/dev/usb/ohci.c:1469
#8 0xc04887ab in usb_schedsoftintr (bus=0xc2b8b000)
at /usr/src/sys/dev/usb/usb.c:871
#9 0xc0474762 in ohci_intr1 (sc=0xc2b8b000)
at /usr/src/sys/dev/usb/ohci.c:1233
#10 0xc04745b4 in ohci_intr (p=0xc2b8b000)
at /usr/src/sys/dev/usb/ohci.c:1162
#11 0xc04b45d9 in ithread_loop (arg=0xc2a8b400)
at /usr/src/sys/kern/kern_intr.c:547
#12 0xc04b3860 in fork_exit (callout=0xc04b4480 ithread_loop,
arg=0xc2a8b400,
frame=0xd3133d38) at /usr/src/sys/kern/kern_fork.c:789
#13 0xc05c7f9c in fork_trampoline ()
at /usr/src/sys/i386/i386/exception.s:208
(kgdb)
Kernel Config:
machine i386
cpu I686_CPU
ident TERMITE6X
makeoptions DEBUG=-g
options SCHED_4BSD
options PREEMPTION
options INET
options FFS
options SOFTUPDATES
options UFS_ACL
options UFS_DIRHASH
options MD_ROOT
options GEOM_GPT
options COMPAT_43
options KTRACE
options SYSVSHM
options SYSVMSG
options SYSVSEM
options _KPOSIX_PRIORITY_SCHEDULING
options KBD_INSTALL_CDEV
options ADAPTIVE_GIANT
device apic
device pci
device agp
device ata
device atadisk
device atapicd
options ATA_STATIC_ID
device scbus
device da
device cd
device pass
device atkbdc
device atkbd
device psm
device vga
device splash
device sc
device pmtimer
device sio
device
Re: Upgrading 5.3 6.0 buildworld failure now in libmagic
On Tuesday 06 December 2005 16:50, the author Allen contributed to the dialogue on- Re: Upgrading 5.3 6.0 buildworld failure now in libmagic: On Tue, December 6, 2005 19:44, Doug Barton wrote: On Tue, 6 Dec 2005, secmgr wrote: Not to belabour this, but the 6.0 release notes do specificly say 5.3 RELEASE and newer. 5.4-STABLE is newer. :) Source upgrades to FreeBSD 6.0-RELEASE are only supported from FreeBSD 5.3-RELEASE or later. Users of older systems wanting to upgrade 6.0-RELEASE will need to update to FreeBSD 5.3 or newer first, then to FreeBSD 6.0-RELEASE. How does this change to UPDATING in RELENG_6 look to you: Index: UPDATING === RCS file: /home/ncvs/src/UPDATING,v retrieving revision 1.416.2.7 diff -u -r1.416.2.7 UPDATING --- UPDATING1 Nov 2005 23:44:40 - 1.416.2.7 +++ UPDATING7 Dec 2005 00:42:04 - @@ -229,7 +229,13 @@ page for more details. Due to several updates to the build infrastructure, source - upgrades from versions prior to 5.3 no longer supported. + upgrades from versions prior to 5.4-STABLE are not likely + to succeed. Sorry to butt in but.. Doesn't the definition of -STABLE change, for all intents and purposes, by the minute? What next, versions prior to 5.4-STABLE as of MMDD ? + + When upgrading from one major version to another, it is + generally best to upgrade to the latest code in the branch + currently installed first, then do another upgrade to the + new branch. This is getting closer to the truth. Why don't you just say update to the most recent RELENG_5 before attempting. Future proof, no room for confusion. Well I do not want to not thank those who have made the upgrades viable. The value of their work should not be underrated. There is however a perennial problem that freebsd documentation has always been seen as behind and seperate from the development process rather than an integral part of that process. I do not know whether that historical habit is changeable. I suspect it is the only major disadvantage from what I would personally describe as a somewhat technologically centred meritocratic school of governance for the freebsd project. Some improved cohesion between the desire to meet the developmental needs and a desirable objective to provide an end user-centric operation is, to my mind desirable. On the other hand freebsd has prospered in the past by devotion to reliance upon idiosyncratic individual initiatives and that does not blend well with co-operatively integrated plans to similtaneously meet the twin goals I identify. On the whole the result is a A for freebsd when we all want an A++ chuckles Certainly better documentation for the upgrade path between 5.3 and 6.0 would have saved me a h*** of a lot of time.. but there it is.. live does not hand out many A++s Thank you top everyone who helped. I have now successfully upgarded to 5.4 and am about to begin the last leg of this journey towards 6.0. my two pennorth david -- 40 yrs navigating and computing in blue waters. English Owner Captain of British Registered 60' bluewater Ketch S/V Taurus. Currently in San Diego, CA. Sailing bound for Europe via Panama Canal after completing engineroom refit. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Upgrading 5.3 6.0 buildworld failure now in libmagic
From: Vizion [EMAIL PROTECTED] To: freebsd-stable@freebsd.org, [EMAIL PROTECTED] Date: Tue, 6 Dec 2005 19:41:30 -0800 Cc: Doug Barton [EMAIL PROTECTED], Kris Kennaway [EMAIL PROTECTED] Subject: Re: Upgrading 5.3 6.0 buildworld failure now in libmagic On Tuesday 06 December 2005 16:50, the author Allen contributed to the dialogue on- Re: Upgrading 5.3 6.0 buildworld failure now in libmagic: On Tue, December 6, 2005 19:44, Doug Barton wrote: On Tue, 6 Dec 2005, secmgr wrote: Not to belabour this, but the 6.0 release notes do specificly say 5.3 RELEASE and newer. 5.4-STABLE is newer. :) Source upgrades to FreeBSD 6.0-RELEASE are only supported from FreeBSD 5.3-RELEASE or later. Users of older systems wanting to upgrade 6.0-RELEASE will need to update to FreeBSD 5.3 or newer first, then to FreeBSD 6.0-RELEASE. How does this change to UPDATING in RELENG_6 look to you: Index: UPDATING === RCS file: /home/ncvs/src/UPDATING,v retrieving revision 1.416.2.7 diff -u -r1.416.2.7 UPDATING --- UPDATING1 Nov 2005 23:44:40 - 1.416.2.7 +++ UPDATING7 Dec 2005 00:42:04 - @@ -229,7 +229,13 @@ page for more details. Due to several updates to the build infrastructure, source - upgrades from versions prior to 5.3 no longer supported. + upgrades from versions prior to 5.4-STABLE are not likely + to succeed. Sorry to butt in but.. Doesn't the definition of -STABLE change, for all intents and purposes, by the minute? What next, versions prior to 5.4-STABLE as of MMDD ? I believe I've seen exactly this type of notation in UPDATING over the years, in both 4.x 5.x. + + When upgrading from one major version to another, it is + generally best to upgrade to the latest code in the branch + currently installed first, then do another upgrade to the + new branch. This is getting closer to the truth. Why don't you just say update to the most recent RELENG_5 before attempting. Future proof, no room for confusion. [...snip...] There is however a perennial problem that freebsd documentation has always been seen as behind and seperate from the development process rather than an Maybe (hmm, even probably :) but I've found documentation, announcements, errata, etc. (*manpages*) for FreeBSD to be *much* better, more relevant up to date than, umm, other opensource systems. Compared to FreeBSD, other systems' documentation/manpages seem haphazard in some cases even nonexistent. integral part of that process. [...snip...] Certainly better documentation for the upgrade path between 5.3 and 6.0 would have saved me a h*** of a lot of time.. but there it is.. live does not hand out many A++s I would guess that it says 5.3 instead of 5.4 due to oversight, e.g. it was written/documented/recommended before 5.4 was out. Maybe that's (part of) the basis for the Handbook's recommendation of reading the -stable list if you indeed want to track past -RELEASE. :) Thank you top everyone who helped. I have now successfully upgarded to 5.4 and am about to begin the last leg of this journey towards 6.0. my two pennorth david -- Mine too I guess :) -kc ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: cpu-timer rate
On Friday, 2 December 2005 at 14:32:58 +0100, kama wrote:
Hi,
I am just wondering why the cpu-timer is doubled from what I set in
kern.hz?
# vmstat -i
...
cpu0: timer 14314031 1999
# sysctl -a | grep hz
kern.clockrate: { hz = 1000, tick = 1000, profhz = 666, stathz = 133 }
Interesting question. So far I haven't seen an answer that comes
close to explaining it. My guess is that it's because of the specific
timer you're using; which is it? Is there anything else of interest
in your setup?
FWIW, I get (without ACPI) on two different machines essentially the
same:
$ vmstat -i
interrupt total rate
irq0: clk 55250411 1000
irq1: atkbd0 47365 0
irq5: ohci197516 1
irq8: rtc7069645127
irq10: ehci0 1 0
irq11: nve0 xl0+ 1022991 18
irq14: ata0 425652 7
irq15: ata1 4777 0
Total 63918358 1157
$ sysctl -a | grep hz
kern.clockrate: { hz = 1000, tick = 1000, profhz = 1024, stathz = 128 }
debug.psm.hz: 20
Greg
--
See complete headers for address and phone numbers.
pgpYkTQ7P7I12.pgp
Description: PGP signature
Re: Upgrading 5.3 6.0 buildworld failure now in libmagic
On Tue, Dec 06, 2005 at 11:24:31PM -0500, Kenneth W Cochran wrote: Certainly better documentation for the upgrade path between 5.3 and 6.0 would have saved me a h*** of a lot of time.. but there it is.. live does not hand out many A++s I would guess that it says 5.3 instead of 5.4 due to oversight, e.g. it was written/documented/recommended before 5.4 was out. Maybe that's (part of) the basis for the Handbook's recommendation of reading the -stable list if you indeed want to track past -RELEASE. :) I've corrected myself already in previous replies, but to try and put this to rest, I was mistaken when I said that 5.4 was required. Others have already confirmed that clean 5.3 installations may be directly upgraded to 6.0. The problem experienced by the OP must have had another cause. The upgrade to 5.4 may have corrected it for him. Kris pgpbOFo0MhqI7.pgp Description: PGP signature
Help - vr0: rx packet loss on new 6.0 kernel
Just upgraded from 5.4 6.0 and am getting vr0: rx packet loss even on single user mode can anyone please help me to fix the problem Thanks ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Help - vr0: rx packet loss on new 6.0 kernel
Just upgraded from 5.4 6.0 and am getting vr0: rx packet loss even on single user mode can anyone please help me to fix the problem Thanks ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Adventurous fix for wheel mouse not working in FreeBSD 6.0
After installing FreeBSD 6.0, I was no longer able to scroll using the wheel on my Logitech Optical Mouse. I ran moused with the -fd flags and confirmed that the mouse daemon was catching the z-axis events. My xorg.conf looked OK to me: Section InputDevice Identifier Mouse0 Driver mouse Option Device /dev/sysmouse Option CorePointer Option AlwaysCore Option Protocol Auto Option Buttons 5 Option ZAxisMapping 4 5 Option Emulate3Buttons no EndSection I struggled for days and tried dozens of things. I came to suspect that the problem was related to changes in the way ZAxisMapping is handled by Xorg. Based on stuff in an Xorg mailing list, I suspect further changes, likely to be corrective, will be in future versions of the FreeBSD xorg-server port. However, for the adventurous and impatient, this is what I did to fix my problem: 1. Edit /usr/ports/x11-servers/xorg-server/work/xc/programs/Xserver/hw/xfree86/input/mouse/mouse.c and change from NULL to 4 5 in the following line: 530c530 s = xf86SetStrOption(pInfo-options, ZAxisMapping, 4 5); --- s = xf86SetStrOption(pInfo-options, ZAxisMapping, NULL); 2. portupgrade -Wwf xorg-server 3. Restart the X server with CTRL-ALT-Backspace. I don't really know why it works, so I recommend it only for daredevils, unless someone wiser can say it is sound. Cheers, John ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Help - vr0: rx packet loss on new 6.0 kernel
From: [EMAIL PROTECTED] Date: 2005/12/06 Tue PM 10:57:44 PST To: freebsd-stable@freebsd.org Subject: Help - vr0: rx packet loss on new 6.0 kernel Just upgraded from 5.4 6.0 and am getting vr0: rx packet loss even on single user mode can anyone please help me to fix the problem Thanks cANNOT GET CONTROL OF SYSTEM EVEN VIA ALTERNATIVE TTY ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: cpu-timer rate
On Mon, 2005-Dec-05 10:15:52 -0800, Kevin Oberman wrote: On Mon, Dec 05, 2005 at 09:42:08AM +0100 I heard the voice of kama, and lo! it spake thus: I appreciate that you took time to answer about the different clocks. But that does not answer why vmstat -i shows a rate of 2000 when I have set the hz to 1000. Because the rate is always twice hz. While I will concede that I have no explanation, but on all of my systems rate = HZ +/-1. I have never seen a case where rate/2 = HZ. Basically, it depends on what clock(s) your kernel is using. Traditionally, FreeBSD/i386 uses the one of the i8254 counters to generate hz (on irq0) and the RTC to generate profhz/stathz (on irq8). In this case, the rate on those interrupts should match the values reported by kern.clockrate. On SMP machines, this approach is fairly expensive because the interrupts need to be forwarded to all CPUs using IPIs. In early February, jhb implemented an alternative approach using the local APIC clock (sys/i386/i386/local_apic.c v1.13 and other files). Since every CPU has a LAPIC, every CPU gets its own clock interrupts without needing IPIs. The downside is that there's only a single LAPIC so a single hardware clock interrupt needs to generate separate (and independent) hz/tick and stathz/profhz clocks. Since the clocks need to be independent (to make process statistics meaningful), this implies that the hardware (LAPIC) clock (cpu0) needs to be faster than hz. The original commit ran LAPIC at hz*3 but this was later changed to hz*2 to reduce overheads. -- Peter Jeremy ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Re: Help - vr0: rx packet loss on new 6.0 kernel
From: [EMAIL PROTECTED] Date: 2005/12/06 Tue PM 11:13:31 PST To: [EMAIL PROTECTED], freebsd-stable@freebsd.org Subject: Re: Help - vr0: rx packet loss on new 6.0 kernel From: [EMAIL PROTECTED] Date: 2005/12/06 Tue PM 10:57:44 PST To: freebsd-stable@freebsd.org Subject: Help - vr0: rx packet loss on new 6.0 kernel Just upgraded from 5.4 6.0 and am getting vr0: rx packet loss even on single user mode can anyone please help me to fix the problem Thanks cANNOT GET CONTROL OF SYSTEM EVEN VIA ALTERNATIVE TTY Just managed to get a ps -aux - does anyone know what process I need to kill? Thanks ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Re: Help - vr0: rx packet loss on new 6.0 kernel
From: [EMAIL PROTECTED] Date: 2005/12/06 Tue PM 11:23:18 PST To: [EMAIL PROTECTED], freebsd-stable@freebsd.org Subject: Re: Re: Help - vr0: rx packet loss on new 6.0 kernel OK booted on the old kernel back to 5.4 Does anyone have any idea what may have caused the problem? Thanks From: [EMAIL PROTECTED] Date: 2005/12/06 Tue PM 11:13:31 PST To: [EMAIL PROTECTED], freebsd-stable@freebsd.org Subject: Re: Help - vr0: rx packet loss on new 6.0 kernel From: [EMAIL PROTECTED] Date: 2005/12/06 Tue PM 10:57:44 PST To: freebsd-stable@freebsd.org Subject: Help - vr0: rx packet loss on new 6.0 kernel Just upgraded from 5.4 6.0 and am getting vr0: rx packet loss even on single user mode can anyone please help me to fix the problem Thanks cANNOT GET CONTROL OF SYSTEM EVEN VIA ALTERNATIVE TTY Just managed to get a ps -aux - does anyone know what process I need to kill? Thanks ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Fatal trap 12: page fault while in kernel mode
On Friday 02 December 2005 14.54, John Baldwin wrote:
On Friday 02 December 2005 05:00 am, Yuri Khotyaintsev wrote:
I have the following panic occurring several times a week. The machine is
an NFS server, and it usually panics early in the morning, when first
people try to access it. After reboot it may work OK for 1-2 days, and
then panics again. I have tried changing memory and replacing disk which
was exported via NFS, but nothing helped :(
Any suggestion on how to fix this panic will be very much appreciated !
This panic (in propagate_priority) is usually caused when a thread goes to
sleep while holding a mutex (which is forbidden). If you enable INVARIANTS
and/or WITNESS you should get a better panic, and with WITNESS you will
even be warned when a thread goes to sleep while holding a mutex. However,
these options do introduce considerable execution overhead, and sometimes
that overhead changes the timing enough to hide the race. :(
Here are the two panics which I got with INVARIANTS and WITNESS enabled.
# kgdb /usr/obj/usr/src/sys/HEM.DEBUG/kernel.debug vmcore.8
[GDB will not be able to debug user-mode threads: /usr/lib/libthread_db.so:
Undefined symbol ps_pglobal_lookup]
GNU gdb 6.1.1 [FreeBSD]
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type show copying to see the conditions.
There is absolutely no warranty for GDB. Type show warranty for details.
This GDB was configured as i386-marcel-freebsd.
Unread portion of the kernel message buffer:
Memory modified after free 0xc4759e00(508) val=0 @ 0xc4759e00
panic: Most recently used by UFS dirhash
Uptime: 11h8m36s
Dumping 511 MB (2 chunks)
chunk 0: 1MB (160 pages) ... ok
chunk 1: 511MB (130800 pages) 495 479 463 447 431 415 399 383 367 351 335
319 303 287 271 255 239 223 207 191 175 159 143 127 111 95 79 63 47 31 15
#0 doadump () at pcpu.h:165
165 pcpu.h: No such file or directory.
in pcpu.h
(kgdb) where
#0 doadump () at pcpu.h:165
#1 0xc050fd4f in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:399
#2 0xc0510043 in panic (fmt=0xc06dccbb Most recently used by %s\n)
at /usr/src/sys/kern/kern_shutdown.c:555
#3 0xc0648ccf in mtrash_ctor (mem=0xc4759e00, size=0, arg=0x0, flags=2)
at /usr/src/sys/vm/uma_dbg.c:137
#4 0xc06469c1 in uma_zalloc_arg (zone=0xc104d980, udata=0x0, flags=2)
at /usr/src/sys/vm/uma_core.c:1850
#5 0xc05043cd in malloc (size=400, mtp=0xc06fb700, flags=2) at uma.h:275
#6 0xc063fba9 in ufs_readdir (ap=0xd56eaaec)
at /usr/src/sys/ufs/ufs/ufs_vnops.c:1846
#7 0xc06a61cc in VOP_READDIR_APV (vop=0x0, a=0xd56eaaec) at vnode_if.c:1427
#8 0xc0607716 in nfsrv_readdir (nfsd=0xc4368c00, slp=0x0, td=0xc3326780,
mrq=0xd56eac80) at vnode_if.h:746
#9 0xc060fa5b in nfssvc_nfsd (td=0x0)
at /usr/src/sys/nfsserver/nfs_syscalls.c:472
#10 0xc060f280 in nfssvc (td=0xc3326780, uap=0xd56ead04)
at /usr/src/sys/nfsserver/nfs_syscalls.c:181
#11 0xc069b6b0 in syscall (frame=
---Type return to continue, or q return to quit---
{tf_fs = 59, tf_es = 59, tf_ds = 59, tf_edi = 0, tf_esi = 0, tf_ebp =
-1077941464, tf_isp = -714166940, tf_ebx = 0, tf_edx = -1077936144, tf_ecx =
1, tf_eax = 155, tf_trapno = 12, tf_err = 2, tf_eip = 671852067, tf_cs = 51,
tf_eflags = 582, tf_esp = -1077941492, tf_ss = 59})
at /usr/src/sys/i386/i386/trap.c:981
#12 0xc068947f in Xint0x80_syscall ()
at /usr/src/sys/i386/i386/exception.s:200
#13 0x0033 in ?? ()
Previous frame inner to this frame (corrupt stack?)
(kgdb) quit
# kgdb /usr/obj/usr/src/sys/HEM.DEBUG/kernel.debug vmcore.9
[GDB will not be able to debug user-mode threads: /usr/lib/libthread_db.so:
Undefined symbol ps_pglobal_lookup]
GNU gdb 6.1.1 [FreeBSD]
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type show copying to see the conditions.
There is absolutely no warranty for GDB. Type show warranty for details.
This GDB was configured as i386-marcel-freebsd.
Unread portion of the kernel message buffer:
Memory modified after free 0xc5172800(508) val=0 @ 0xc5172800
panic: Most recently used by UFS dirhash
Uptime: 1d1h7m17s
Dumping 511 MB (2 chunks)
chunk 0: 1MB (160 pages) ... ok
chunk 1: 511MB (130800 pages) 495 479 463 447 431 415 399 383 367 351 335
319 303 287 271 255 239 223 207 191 175 159 143 127 111 95 79 63 47 31 15
#0 doadump () at pcpu.h:165
165 pcpu.h: No such file or directory.
in pcpu.h
(kgdb) where
#0 doadump () at pcpu.h:165
#1 0xc050fd4f in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:399
#2 0xc0510043 in panic (fmt=0xc06dccbb Most recently used by %s\n)
at /usr/src/sys/kern/kern_shutdown.c:555
#3 0xc0648ccf in mtrash_ctor (mem=0xc5172800, size=0, arg=0x0, flags=257)
