Re: Patch for rc.d/devd on FreeBSD 9-current
"M. Warner Losh" writes:
> + /*
> + * Close the PID file, and all other open descriptors.
> + * Inherit std{in,out,err} only.
> + */
> + cfg.close_pidfile();
> + ::closefrom(3);
Actually, closefrom() is sufficient, since the only resource held by the
pidfile that would persist across execve() is the file descriptor (and
hence the lock).
DES
--
Dag-Erling Smørgrav - d...@des.no
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: r209240 ia64 -> buildworld -> undefined reference to `lzma_physmem'
On Mon, Jun 28, 2010 at 06:39:29PM +0200, Dag-Erling Smørgrav wrote: > Anton Shterenlikht writes: > > I think this only happens when I copy from one xterm to another, > > to paste into the mailer. I've checked the command which > > I put in a file, and all seems fine. Also, the latest > > error message suggests that the command is fine: > > OK, can you do it again with -Wl,--verbose in addition to -v? Like > this: cc -static -v -Wl,--verbose -o rescue ... it generated quite a lot of output, so I put it here: http://seis.bris.ac.uk/~mexas/ia64-lzma-problem.txt Please let me know if you prefer all output in the body of email. many thanks for your continuing help, much appreciated anton -- Anton Shterenlikht Room 2.6, Queen's Building Mech Eng Dept Bristol University University Walk, Bristol BS8 1TR, UK Tel: +44 (0)117 331 5944 Fax: +44 (0)117 929 4423 ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: r209240 ia64 -> buildworld -> undefined reference to `lzma_physmem'
Anton Shterenlikht writes: > http://seis.bris.ac.uk/~mexas/ia64-lzma-problem.txt This confirms my suspicion that ld is picking up the wrong liblzma: > attempt to open /usr/local/lib/liblzma.a succeeded but I still can't figure out why. Can you do the following: % make buildenv % env and also show us your make.conf and src.conf? Do you have any gcc ports installed? DES -- Dag-Erling Smørgrav - d...@des.no ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: r209240 ia64 -> buildworld -> undefined reference to `lzma_physmem'
On 2010-06-29 11:25, Dag-Erling Smørgrav wrote: > Anton Shterenlikht writes: >> http://seis.bris.ac.uk/~mexas/ia64-lzma-problem.txt > > This confirms my suspicion that ld is picking up the wrong liblzma: > >> attempt to open /usr/local/lib/liblzma.a succeeded > > but I still can't figure out why. Can you do the following: Because the ld command line includes /usr/local/lib twice, and *before* /usr/obj/usr/src/tmp/usr/lib: -L/usr/local/lib -L/usr/local/lib -L/usr/obj/usr/src/tmp/usr/lib -L/usr/obj/usr/src/tmp/usr/lib The question is, where do those -L/usr/local/lib's come from. :) Maybe because Anton is calling /usr/bin/cc instead of /usr/obj/usr/src/tmp/usr/bin/cc ? ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: r209240 ia64 -> buildworld -> undefined reference to `lzma_physmem'
On Tue, Jun 29, 2010 at 11:25:40AM +0200, Dag-Erling Smørgrav wrote: > Anton Shterenlikht writes: > > http://seis.bris.ac.uk/~mexas/ia64-lzma-problem.txt > > This confirms my suspicion that ld is picking up the wrong liblzma: > > > attempt to open /usr/local/lib/liblzma.a succeeded > > but I still can't figure out why. Can you do the following: > > % make buildenv > % env # make buildenv Entering world for ia64:ia64 # env LIBRARY_PATH=/usr/local/lib USER=mexas MACHTYPE=unknown MAIL=/var/mail/mexas MAKEOBJDIRPREFIX=/usr/obj VENDOR=unknown SHLVL=4 HOME=/root OLDPWD=/usr/obj/usr/src LSCOLORS=ExFxCxDxBxegedabagacad MACHINE_ARCH=ia64 PAGER=more GROFF_FONT_PATH=/usr/obj/usr/src/tmp/legacy/usr/share/groff_font MAKEFLAGS= -m /usr/src/share/mk GROUP=mexas SGML_CATALOG_FILES=/usr/doc/en_US.ISO8859-1/share/sgml/catalog:/usr/doc/share/sgml/catalog:/usr/local/share/sgml/iso8879/catalog:/usr/local/share/sgml/html/catalog:/usr/local/share/sgml/docbook/4.1/catalog:/usr/local/share/sgml/jade/catalog LOGNAME=mexas VERSION=FreeBSD 9.0-CURRENT ia64 900014 WINDOWID=16777229 LYNX_CFG=/home/mexas/.lynx.cfg XTERM_SHELL=/bin/tcsh MACHINE=ia64 BLOCKSIZE=K TERM=xterm _SHLIBDIRPREFIX=/usr/obj/usr/src/tmp SYSTEM=TZAV WINDOWPATH=11 PATH=/usr/obj/usr/src/tmp/legacy/usr/sbin:/usr/obj/usr/src/tmp/legacy/usr/bin:/usr/obj/usr/src/tmp/legacy/usr/games:/usr/obj/usr/src/tmp/usr/sbin:/usr/obj/usr/src/tmp/usr/bin:/usr/obj/usr/src/tmp/usr/games:/sbin:/bin:/usr/sbin:/usr/bin DISPLAY=mech-anton240:0.0 REMOTEHOST=mech-anton240.men.bris.ac.uk LANG=en_GB.ISO8859-15 SGML_ROOT=/usr/local/share/sgml INSTALL=sh /usr/src/tools/install.sh SHELL=/bin/sh HOST=mech-cluster241.men.bris.ac.uk CPUTYPE= __MKLVL__=2 GROFF_TMAC_PATH=/usr/obj/usr/src/tmp/legacy/usr/share/tmac OSTYPE=FreeBSD GROFF_BIN_PATH=/usr/obj/usr/src/tmp/legacy/usr/bin PWD=/usr/src XTERM_LOCALE=en_GB.ISO8859-15 XTERM_VERSION=XTerm(258) TERMCAP=xterm|X11 terminal emulator:@7=\EOF:@8=\EOM:F1=\E[23~:F2=\E[24~:K2=\EOE:Km=\E[M:k1=\EOP:k2=\EOQ:k3=\EOR:k4=\EOS:k5=\E[15~:k6=\E[17~:k7=\E[18~:k8=\E[19~:k9=\E[20~:k;=\E[21~:kI=\E[2~:kN=\E[6~:kP=\E[5~:kd=\EOB:kh=\EOH:kl=\EOD:kr=\EOC:ku=\EOA:am:bs:km:mi:ms:ut:xn:AX:Co#8:co#205:kn#12:li#50:pa#64:AB=\E[4%dm:AF=\E[3%dm:AL=\E[%dL:DC=\E[%dP:DL=\E[%dM:DO=\E[%dB:LE=\E[%dD:RI=\E[%dC:UP=\E[%dA:ae=\E(B:al=\E[L:as=\E(0:bl=^G:cd=\E[J:ce=\E[K:cl=\E[H\E[2J:cm=\E[%i%d;%dH:cs=\E[%i%d;%dr:ct=\E[3g:dc=\E[P:dl=\E[M:ei=\E[4l:ho=\E[H:im=\E[4h:is=\E[!p\E[?3;4l\E[4l\E>:kD=\E[3~:ke=\E[?1l\E>:ks=\E[?1h\E=:le=^H:md=\E[1m:me=\E[m:ml=\El:mr=\E[7m:mu=\Em:nd=\E[C:op=\E[39;49m:rc=\E8:rs=\E[!p\E[?3;4l\E[4l\E>:sc=\E7:se=\E[27m:sf=^J:so=\E[7m:sr=\EM:st=\EH:ue=\E[24m:up=\E[A:us=\E[4m:ve=\E[?12l\E[?25h:vi=\E[?25l:vs=\E[?12;25h:kb=\010: FTP_PASSIVE_MODE=YES HOSTTYPE=FreeBSD EDITOR=vi # > > and also show us your make.conf and src.conf? > # cat /etc/make.conf SENDMAIL_CFLAGS=-I/usr/local/include/sasl -DSASL SENDMAIL_LDFLAGS=-L/usr/local/lib SENDMAIL_LDADD=-lsasl2 CFLAGS= -O1 COPTFLAGS= -O1 # added by use.perl 2010-05-12 12:40:35 PERL_VERSION=5.10.1 # I haven't got src.conf on any of my ia64 boxes: # cat /etc/src.conf cat: /etc/src.conf: No such file or directory # > Do you have any gcc ports installed? I don't thik so: # pkg_info -xo gcc pkg_info: no packages match pattern(s) # Just in case, here's a complete list of my ports (sorry to waste the space, if it's irrelevant): # portmaster -l ===>>> Root ports (No dependencies, not depended on) ===>>> bigreqsproto-1.1.0 ===>>> boost-jam-1.43.0 ===>>> calc-2.12.4.0 ===>>> cmake-2.8.1_1 ===>>> cyrus-sasl-2.1.23 ===>>> evieext-1.1.0 ===>>> g95-0.92.20090624 ===>>> glproto-1.4.11 ===>>> gmp-5.0.1 ===>>> gperf-3.0.3 ===>>> iw-hspell-1.0 ===>>> lemon-1.69 ===>>> libtool-2.2.6b ===>>> links-0.98,1 ===>>> portmaster-2.32 ===>>> qt4-qmake-4.6.3 ===>>> qt4-rcc-4.6.3 ===>>> qt4-uic-4.6.3 ===>>> re2c-0.13.5 ===>>> resourceproto-1.0.2 ===>>> scr2txt-1.2 ===>>> tidy-2804_2 ===>>> unrar-3.93,5 ===>>> unzip-6.0 ===>>> urlview-0.9_6 ===>>> v4l_compat-1.0.20100403_1 ===>>> xcmiscproto-1.2.0 ===>>> xf86bigfontproto-1.2.0 ===>>> xorg-macros-1.6.0 ===>>> 29 root ports ===>>> Trunk ports (No dependencies, are depended on) ===>>> amspsfnt-1.0_5 ===>>> autoconf-wrapper-20071109 ===>>> automake-wrapper-20071109 ===>>> ca_root_nss-3.12.4 ===>>> clucene-0.9.21 ===>>> cmpsfont-1.0_6 ===>>> compositeproto-0.4.1 ===>>> damageproto-1.2.0 ===>>> db41-4.1.25_4 ===>>> dmidecode-2.10 ===>>> dmxproto-2.3 ===>>> dri2proto-2.2 ===>>> expat-2.0.1_1 ===>>> fixesproto-4.1.1 ===>>> font-util-1.0.2 ===>>> fontcacheproto-0.1.3 ===>>> fontsproto-2.1.0 ===>>> gdbm-1.8.3_3 ===>>> gnome_subr-1.0 ===>>> gnomehier-2.3_12 ===>>> gsfonts-8.11_5 ===>>> hicolor-icon-theme-0.12 ===>>> icu-3.8.1_3 ===>>> inputproto-2.0 ===>>> jbigkit-1.6 ===>>> jpeg-8_3 ===>>> kbproto-1.0.4 ===>>> kdehier4-1.0.4 ===>>> libcheck-0.9.8 ===>>> libdaemon-0.14 ===>>> libexecinfo-1.1_3 ===>>> libfpx-1.2.0.12_1 ===>>> libiconv-1.13.1_1 ===>>> libltdl-2.2.6b ===>>> libmspack-0.0.20060920 =
Re: r209240 ia64 -> buildworld -> undefined reference to `lzma_physmem'
Dag-Erling Smørgrav writes: > This confirms my suspicion that ld is picking up the wrong liblzma: > > attempt to open /usr/local/lib/liblzma.a succeeded > but I still can't figure out why. Uh, I must be blind. It uses /usr/local/lib/liblzma.a because -L/usr/local/lib was specified on the command line. This is most likely caused by your environment or make.conf / src.conf. DES -- Dag-Erling Smørgrav - d...@des.no ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: r209240 ia64 -> buildworld -> undefined reference to `lzma_physmem'
Anton Shterenlikht writes: > # make buildenv > Entering world for ia64:ia64 > # env > LIBRARY_PATH=/usr/local/lib where does this come from? Your .bashrc or something? % make buildenv % unset LIBRARY_PATH then run the cc command again. DES -- Dag-Erling Smørgrav - d...@des.no ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: r209240 ia64 -> buildworld -> undefined reference to `lzma_physmem'
On 2010-06-29 11:59, Anton Shterenlikht wrote: > LIBRARY_PATH=/usr/local/lib There's your problem. Remove this environment variable, and try buildworld again. :) ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: r209240 ia64 -> buildworld -> undefined reference to `lzma_physmem'
On Tue, Jun 29, 2010 at 12:03:39PM +0200, Dag-Erling Smørgrav wrote: > Anton Shterenlikht writes: > > # make buildenv > > Entering world for ia64:ia64 > > # env > > LIBRARY_PATH=/usr/local/lib > > where does this come from? Your .bashrc or something? I've this set in $HOME/.tcsh. I don't remember why now. I probably fucked up.. However, I've got this set on 3 ia64 boxes. On two of them I don't have this lzma problem. mech-as28# uname -srm FreeBSD 9.0-CURRENT ia64 mech-as28# setenv | grep LIB LIBRARY_PATH=/usr/local/lib mech-as28# mech-as221# uname -srm FreeBSD 9.0-CURRENT ia64 mech-as221# setenv | grep LIB LIBRARY_PATH=/usr/local/lib mech-as221# mech-cluster241# uname -srm FreeBSD 9.0-CURRENT ia64 mech-cluster241# setenv |grep LIB LIBRARY_PATH=/usr/local/lib mech-cluster241# I'm going to repeat buildworld on all 3 boxes now, just to be sure that it still works on the other two boxes. > > % make buildenv > % unset LIBRARY_PATH > I'll then repeat buildworld with LIBRARY_PATH unset. many thanks for your help anton -- Anton Shterenlikht Room 2.6, Queen's Building Mech Eng Dept Bristol University University Walk, Bristol BS8 1TR, UK Tel: +44 (0)117 331 5944 Fax: +44 (0)117 929 4423 ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: r209240 ia64 -> buildworld -> undefined reference to `lzma_physmem'
2010/6/29 Anton Shterenlikht : > On Tue, Jun 29, 2010 at 12:03:39PM +0200, Dag-Erling Smørgrav wrote: >> Anton Shterenlikht writes: >> > # make buildenv >> > Entering world for ia64:ia64 >> > # env >> > LIBRARY_PATH=/usr/local/lib >> >> where does this come from? Your .bashrc or something? > > I've this set in $HOME/.tcsh. I don't remember why now. > I probably fucked up.. > > However, I've got this set on 3 ia64 boxes. > On two of them I don't have this lzma problem. Didn't you mention (about 70 emails previously) that you only had /usr/local/lib/libzma.a on one of your ia64 boxes, and the other two built world just fine? Does that explain why you dont have this problem on those boxes, with the same setting? Cheers Tom ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: r209240 ia64 -> buildworld -> undefined reference to `lzma_physmem'
Anton Shterenlikht writes: > However, I've got this set on 3 ia64 boxes. > On two of them I don't have this lzma problem. Because they either don't have liblzma installed from ports, or they have a different version that works. DES -- Dag-Erling Smørgrav - d...@des.no ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
SOLVED: Re: r209240 ia64 -> buildworld -> undefined reference to `lzma_physmem'
On Tue, Jun 29, 2010 at 01:26:23PM +0200, Dag-Erling Smørgrav wrote: > Anton Shterenlikht writes: > > However, I've got this set on 3 ia64 boxes. > > On two of them I don't have this lzma problem. > > Because they either don't have liblzma installed from ports, or they > have a different version that works. too right.. # pkg_info -W /usr/local/lib/liblzma.a /usr/local/lib/liblzma.a was installed by package xz-4.999.9_1 DES, my apologies for wasting your, and everybody else's time. My fault entirely. -- Anton Shterenlikht Room 2.6, Queen's Building Mech Eng Dept Bristol University University Walk, Bristol BS8 1TR, UK Tel: +44 (0)117 331 5944 Fax: +44 (0)117 929 4423 ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: lock recursion panic in cam_xpt.c
On 6/28/2010 11:13 PM, Giorgos Keramidas wrote: A recent CURRENT build from /head @ 209581 panics when I run "cdrecord -scanbus" with the attached backtrace. The culprit seems to be the extra call fo xpt_lock_buses() added in head rev 208752, but I'm not sure if this is the real cause yet. Thanks I'm already on it and working it. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: lock recursion panic in cam_xpt.c
On 6/28/2010 11:13 PM, Giorgos Keramidas wrote: A recent CURRENT build from /head @ 209581 panics when I run "cdrecord -scanbus" with the attached backtrace. The culprit seems to be the extra call fo xpt_lock_buses() added in head rev 208752, but I'm not sure if this is the real cause yet. Fixed, thanks. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Patch for rc.d/devd on FreeBSD 9-current
In message: <86r5jqdz9w@ds4.des.no>
Dag-Erling Smørgrav writes:
: "M. Warner Losh" writes:
: > + /*
: > +* Close the PID file, and all other open descriptors.
: > +* Inherit std{in,out,err} only.
: > +*/
: > + cfg.close_pidfile();
: > + ::closefrom(3);
:
: Actually, closefrom() is sufficient, since the only resource held by the
: pidfile that would persist across execve() is the file descriptor (and
: hence the lock).
I went ahead and used pidfile_close in this context because that's
what's recommended in the man page. I know it is likely redundant,
but I thought better safe than sorry...
Warner
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Patch for rc.d/devd on FreeBSD 9-current
"M. Warner Losh" writes: > I went ahead and used pidfile_close in this context because that's > what's recommended in the man page. I know it is likely redundant, > but I thought better safe than sorry... agreed... DES -- Dag-Erling Smørgrav - d...@des.no ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [sparc64] [panic] cheetah_ipi_selected: CPU can't IPI itself
On Mon, Jun 28, 2010 at 10:25:15AM -0400, Nathaniel W Filardo wrote: > Well, I'm back in the same town as my sparc64 and so csup'd, built, and > rebooted, trying to get more information about the "vm object not owned" > panic I reported a while ago. To my dismay, I now get this panic, also late > enough in the boot process to be starting up jails: > > panic: cheetah_ipi_selected: CPU can't IPI itself > cpuid = 0 > KDB: stack backtrace: > panic() at panic+0x1c8 > cheetah_ipi_selected() at cheetah_ipi_selected+0x48 > tlb_page_demap() at tlb_page_demap+0xdc > pmap_copy_page() at pmap_copy_page+0x4c4 > vm_fault() at vm_fault+0x13ec > trap_pfault() at trap_pfault+0x190 > trap() at trap+0xd0 > -- data access protection tar=0x224b93 sfar=0x224550 sfsr=0x85 > %o7=0x4063398c -- > userland() at 0x40633830 > user trace: trap %o7=0x4063398c > ... > > And the system hangs; I had to use the ALOM to reboot it. > Sorry to not have more useful news. Could please give the following patch a try? http://people.freebsd.org/~marius/sparc64_pin_ipis.diff If that doesn't fix the above panic I have no clue how this can happen apart from the per-CPU pages getting corrupted. Marius ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
