Re: Please test the UFS2 patch!
On Sat, Jun 08, 2002 at 03:06:25AM +0200, Dag-Erling Smorgrav wrote: Brooks Davis [EMAIL PROTECTED] writes: In addition to the dump problem I've reported, I'm also seeing issues with df output. The following is obviously wrong: Filesystem 1K-blocks Used Avail Capacity Mounted on /dev/ad0s2a254063 -246047 479785 -105%/ Does the attached patch fix the problem? Unfortunatly, no. With that patch I see: Filesystem 1K-blocks Used Avail Capacity Mounted on /dev/ad0s2a254063 -246046 479784 -105%/ devfs 11 0 100%/dev /dev/ad0s2f 16633298 12518566 278406982%/usr /dev/ad0s2e 1524407 573287 82916841%/var procfs 44 0 100%/proc linprocfs 44 0 100%/usr/compat/linux/proc -- Brooks -- Any statement of the form X is the one, true Y is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 msg39360/pgp0.pgp Description: PGP signature
perl wrapper and PATH
I know that the specific mergemaster issues have been addressed, but I thought this experience pointed out something subtly astonishing, so I figured I'd point it out. I ran mergemaster, and the perl wrapper started complaining that I needed to install perl, so I did pkg_add -r perl. The port talked all about use.perl port or use.perl system, but I figured system was wrapper so I didn't bother running use.perl . I tried perl -de 0, and voila, I had perl. So I ran mergemaster again, and the wrapper started complaining again that I needed to install perl. Turns out that mergemaster sets a restrictive PATH, and the wrapper (apparently) looks for the real perl in the PATH. This can be awfully confusing -- /usr/bin/perl works, but env PATH=/usr/bin perl doesn't work. I ran use.perl port, and that gave me a working perl for mergemaster. Interestingly, use.perl system didn't give me back the perl wrapper; I'm not sure what I got. Sigh. Bill To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: dump (via amanda) causing panics
On Sat, Jun 08, 2002 at 02:45:06PM +1000, Bruce Evans wrote: On Fri, 7 Jun 2002, Brooks Davis wrote: On Fri, Jun 07, 2002 at 02:16:45PM -0700, Brooks Davis wrote: On Fri, Jun 07, 2002 at 01:30:37PM -0700, David O'Brien wrote: On Fri, Jun 07, 2002 at 12:59:55PM -0700, Brooks Davis wrote: Applying phk's patch seems to have fixed it. It's a bit overkill for fixing dump, but it did work and I guess this way I can do some limited testing of the ufs2 patch. Is that the full ufs2 patch? phk also committed a quick fix for dump. That's with the full ufs2 patch. Here's a sample of the errors I'm seeing: DUMP: read error from /dev/ad0s2f: Invalid argument: [sector -1980991191]: count=-1 DUMP: read error from /dev/ad0s2f: Invalid argument: [sector -1980991190]: count=-1 ... I saw similarly bogus sector (block) numbers when I first debugged this problem. They were caused by missing prototypes. 32-bit block numbers were passed to unprototyped functions that expected daddr_t block numbers. When daddr_t was changed to 64 bits, there was garbage in the top 32 bits. dump doesn't compile cleanly at a high WARNS level, so now would be a good time to WARNSify it. That sounds like a good idea. If someone else doesn't get there first, I'll take a look at that soon. If nothing else, there's the plane trip down to SFO for USENIX. -- Brooks -- Any statement of the form X is the one, true Y is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 msg39362/pgp0.pgp Description: PGP signature
Perl wrapper bad
... when I say bad I don't mean in execution. I mean that the idea of a redirecting wrapper for one special program seems to me an architectural wart that shouldn't be pushed on the userbase. Not only does it conflict in style with the existing mailwrapper, but it introduces a DWIM feature without precedent. Using PATH is simply wrong in restricted-path cases. The idea that manually creating a symlink is an insufficient solution is an underestimation of the intelligence of the FreeBSD userbase. Those who think that a generalisation of mailwrapper would be a cleaner solution can try the following *proof-of-concept*: echo 'myperl /usr/local/bin/perl' /etc/mail/mailer.conf ln -s /usr/sbin/mailwrapper /usr/bin/myperl /usr/bin/myperl -v This also works for suidperl. Joshua To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Perl wrapper bad
* From Joshua Goodall [EMAIL PROTECTED] ... when I say bad I don't mean in execution. I mean that the idea of a redirecting wrapper for one special program seems to me an architectural wart that shouldn't be pushed on the userbase. With no gain except supporting improperly-shebanged scripts. We can use s/// in ports to fix shebangs, so there's not much excuse there, and I'd rather have a tool using autoconf find the Real perl than the wrapper, but to do this I have to deviate from the path I normally use to prefer system utilities over local ones: /bin:/usr/bin:/usr/ucb:/usr/gnu/bin:/usr/local/bin:/a/pkg/bin: \ /sbin:/usr/sbin:/usr/etc:/usr/gnu/sbin:/usr/local/sbin:/a/pkg/sbin Can you spot all the places Perl might be there? Can you now tell me which one a ``wrapper'' for the 'real' Perl should look? And what about where autoconf scripts should find perl? -- J. Mallett [EMAIL PROTECTED]FreeBSD: The Power To Serve I've coined new words, like, misunderstanding and Hispanically. -- George W. Bush, Radio-Television Correspondents Association dinner, Washington, D.C., March 29, 2001 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: GCC3.1 internal compiler error when compilingXFree86-4-libraries
I have the following error when I try to install it. Is it unique only to me? === Installing for XFree86-libraries-4.2.0_1 === XFree86-libraries-4.2.0_1 depends on executable: mkhtmlindex - found === XFree86-libraries-4.2.0_1 depends on shared library: freetype.9 - found : : : (snip) install in lib/GL/GL done installing in lib/GL/mesa/src/OSmesa... /usr/bin/install -c -m 0644 libOSMesa.a /usr/X11R6/lib ranlib /usr/X11R6/lib/libOSMesa.a rm -f ../../../../../lib/GL/mesa/src/translate.o unshared/../../../../../lib/GL/mesa/src/translate.o LD_LIBRARY_PATH=../../../../../exports/lib cc -c -ansi -pedantic -Dasm=__asm -Wall -Wpointer-arith -I../../../../../exports/include/X11 -I../../../../../include/extensions -I../../../../../extras/Mesa/src/OSmesa -I../../../../../extras/Mesa/src -I../../../../../extras/Mesa/include -I../../../../.. -I../../../../../exports/include -DCSRG_BASED -DFUNCPROTO=15 -DNARROWPROTO -DXTHREADS -DXUSE_MTSAFE_API -DXNO_MTSAFE_PWDAPI -DMALLOC_0_RETURNS_NULL ../../../../../lib/GL/mesa/src/translate.c -o unshared/../../../../../lib/GL/mesa/src/translate.o Assembler messages: FATAL: can't create unshared/../../../../../lib/GL/mesa/src/translate.o: No such file or directory *** Error code 1 Stop in /home/ports/x11/XFree86-4-libraries/work/xc/lib/GL/mesa/src/OSmesa. *** Error code 1 Stop in /home/ports/x11/XFree86-4-libraries/work/xc/lib/GL. *** Error code 1 Stop in /home/ports/x11/XFree86-4-libraries/work/xc/lib. *** Error code 1 Stop in /home/ports/x11/XFree86-4-libraries/work/xc. *** Error code 1 Stop in /home/ports/x11/XFree86-4-libraries/work/xc. *** Error code 1 Stop in /home/ports/x11/XFree86-4-libraries. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: perl wrapper and PATH
On Fri, Jun 07, 2002 at 11:26:18PM -0700, Bill Fenner wrote: I ran use.perl port, and that gave me a working perl for mergemaster. Interestingly, use.perl system didn't give me back the perl wrapper; I'm not sure what I got. Sigh. That script predates the removal of perl from the base system, and was supposed to facilitate the switching between various perl versions. It still has its justification of existence on -STABLE, but on -CURRENT, it does not work well any more. What you got is likely links to nowhere, your perl wrapper binary was clobbered. Bottom line: if at all, it should only be used for use.perl port, for the cases where the wrapper does not work as desired. -- Regards: Szilveszter ADAM Szombathely Hungary To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: GCC3.1 internal compiler error when compiling XFree86-4-libraries
On Sat, Jun 08, 2002 at 05:13:12PM +0900, Yamada Ken Takeshi wrote: I have the following error when I try to install it. Is it unique only to me? I didn't get that when I built it on ref5. That's the only place I've tried it. Kris msg39367/pgp0.pgp Description: PGP signature
Re: Re: GCC3.1 internal compiler error when compiling XFree86-4-libraries
On 2002-06-08 01:39 -0700, Kris Kennaway [EMAIL PROTECTED] wrote: On Sat, Jun 08, 2002 at 05:13:12PM +0900, Yamada Ken Takeshi wrote: I have the following error when I try to install it. Is it unique only to me? I didn't get that when I built it on ref5. That's the only place I've tried it. I got around this problem by (indirectly) fixing the .c.o rule in the Imakefile. This patch was part of my previous mail to you regarding the XFree86 library build process (new version of patch-z32). The problem is that unshared is meant to be a prefix to a file name, but $@ happens to be a path name including directory components. E.g. $@ = dir/file.o = unshared/dir/file.o The correct path is dir/unshared/file.o and the modified definition of LibObjCompile uses that filename: File: /usr/ports/x11/XFree86-4-libraries/files/patch-z32 --- lib/GL/mesa/src/OSmesa/Imakefile.orig Tue Apr 3 11:29:33 2001 +++ lib/GL/mesa/src/OSmesa/ImakefileWed Jun 5 12:28:26 2002 @@ -8,6 +8,16 @@ #define DoDebugLib DebugLibGlx #define DoProfileLib ProfileLibGlx +#define LibObjCompile(dir,options) RemoveFiles($@ $(@:C!([^/]+)$!dir/\1!)) @@\ + ClearmakeOSName \ + $(CC) -c $(CCOPTIONS) $(THREADS_CFLAGS) $(ALLDEFINES) \ + options $*.c -o $(@:C!([^/]+)$!dir/\1!) + +#define ObjectCompile(options) RemoveFile($@) @@\ + ClearmakeOSName \ + $(CC) -c $(CFLAGS) options -O0 $*.c -o $@ + + #include ../Imakefile.inc #ifdef i386Architecture #include ../X86/Imakefile.inc @@ -58,7 +68,7 @@ LIBNAME = OSMesa SOREV = 3.3 - +#if !defined(LibInstall) || LibInstall || (!defined(ModInstall) || ModInstall) #if DoNormalLib NormalLibraryTarget($(LIBNAME), $(UOBJS)) InstallLibrary($(LIBNAME),$(USRLIBDIR)) @@ -77,6 +87,7 @@ #if DoProfileLib ProfiledLibraryTarget($(LIBNAME), $(POBJS)) InstallLibrary($(LIBNAME)_p,$(USRLIBDIR)) +#endif #endif DependTarget() (The redefinition of ObjectCompile() disables optimization because it triggers an internal bug in gcc-3.1 in the case of the PCI object.) Regards, STefan To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: perl wrapper and PATH
On Fri, Jun 07, 2002 at 11:26:18PM -0700, Bill Fenner wrote: I ran use.perl port, and that gave me a working perl for mergemaster. Interestingly, use.perl system didn't give me back the perl wrapper; I'm not sure what I got. Sigh. That script predates the removal of perl from the base system, and was supposed to facilitate the switching between various perl versions. It still has its justification of existence on -STABLE, but on -CURRENT, it does not work well any more. What you got is likely links to nowhere, your perl wrapper binary was clobbered. Bottom line: if at all, it should only be used for use.perl port, for the cases where the wrapper does not work as desired. Or maybe we should get rid of the wrapper and change the perl port/package to run use.perl port by default on current? John -- John Hay -- [EMAIL PROTECTED] / [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
HEADS UP: New GNU sort committed and activated
Please report me any problems with new GNU sort, in case you have them. -- Andrey A. Chernov http://ache.pp.ru/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
../../../vm/uma_core.c:1327: could sleep with pcm0:play:0 locked from
Hello: A couple of days ago (I dont remember the exact day) I've recompiled the kernel to add this features: options EXT2FS device pcm device sbc device gif 4 device stf Every time I boot, I see this messages (a lot of them): (I dont copy here all of them, only a representative subset :) By the way, I have experienced some spontaneous reboot after 16-20 hours of continuous compilation (my MMX-200 takes 16 hours to recompile the distribution). But Im not sure that the problem cames from FreeBSD, because after the reboot, my BIOS didn't recognize the hard disk :) ../vm/uma_core.c:1160 ../../../vm/uma_core.c:1327: could sleep with process lock locked from ../../../kern/kern_prot.c:511 ../../../vm/uma_core.c:1327: could sleep with process lock locked from ../../../kern/kern_prot.c:511 ../../../vm/uma_core.c:1327: could sleep with process lock locked from ../../../kern/kern_prot.c:613 ../../../vm/uma_core.c:1327: could sleep with UMA lock locked from ../../../vm/uma_core.c:1160 ../../../vm/uma_core.c:1327: could sleep with pcm0:play:0 locked from ../../../dev/sound/pcm/sound.c:191 ../../../vm/uma_core.c:1327: could sleep with pcm0:play:0 locked from ../../../dev/sound/pcm/dsp.c:765 ../../../vm/uma_core.c:1327: could sleep with pcm0:play:0 locked from ../../../dev/sound/pcm/dsp.c:713 Hope this help. Do you think these errors are alarming ? I mean, do you recommend me to recopile my kernel again ? (please noo, it takes me a lot of time to recompile whatever thing :) * Juan F. Rodriguez Hervella Universidad Carlos III de Madrid * To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: ../../../vm/uma_core.c:1327: could sleep with pcm0:play:0 locked from
--- Juan Francisco Rodriguez Hervella [EMAIL PROTECTED] wrote: ../vm/uma_core.c:1160 ../../../vm/uma_core.c:1327: could sleep with process lock locked from ../../../kern/kern_prot.c:511 ../../../vm/uma_core.c:1327: could sleep with process lock locked from Hope this help. Do you think these errors are alarming ? I mean, do you recommend me to recopile my kernel again ? (please noo, it takes me a lot of time to recompile whatever thing :) Hi. I am not sure if they are alarming or not, but recently (infact yesterday) I made a post to this mailing list with all the lock problems which I found when using a SoundBlaster 1024 Live! card which uses the pcm driver. Afaik. This problems are well known, and the developers are working on resolving the issues, though I maybe wrong. Thanks. Regards -- Hiten __ Do You Yahoo!? Yahoo! - Official partner of 2002 FIFA World Cup http://fifaworldcup.yahoo.com To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Fixing could sleeep... was (Re: ../../../vm/uma_core.c:1327: couldsleep with pcm0:play:0 locked from)
On Sat, 08 Jun 2002 04:03:40 -0700 (PDT)
Hiten Pandya [EMAIL PROTECTED] wrote:
--- Juan Francisco Rodriguez Hervella [EMAIL PROTECTED] wrote:
../vm/uma_core.c:1160
../../../vm/uma_core.c:1327: could sleep with process lock locked
from ../../../kern/kern_prot.c:511
../../../vm/uma_core.c:1327: could sleep with process lock locked
from
Hope this help. Do you think these errors are alarming ?
I mean, do you recommend me to recopile my kernel again ?
(please noo, it takes me a lot of time to recompile whatever
thing :)
I also get these and I figured they're as good an excuse as any to jump
into the kernel code :-} This particular one (and others related to the
setuid/gid family of functions) occur because some time after PROC_LOCK
is called in set{uid,euid} and further down the call stack uidfind()
allocates some memory specifying the M_WAITOK flag.
Is the solution to this to use M_NOWAIT and continue re-trying untill it
succeeds? Is there on-going smp work in locking down struct proc that
will eliminate this problem?
Cheers,
Mike Makonnen
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Weekly run output: makewhatis
I started getting these recently in my weekly run outputs. Cleaning up kernel database files: Rebuilding locate database: Rebuilding whatis database: makewhatis: /usr/local/man/man1/etags.1.gz: No such file or directory makewhatis: /usr/local/man/man3/ldap_8859_to_t61.3.gz: No such file or directory makewhatis: /usr/local/man/man3/ldap_enable_translation.3.gz: No such file or directory makewhatis: /usr/local/man/man3/ldap_set_string_translators.3.gz: No such file or directory makewhatis: /usr/local/man/man3/ldap_t61_to_8859.3.gz: No such file or directory makewhatis: /usr/local/man/man3/ldap_translate_from_t61.3.gz: No such file or directory makewhatis: /usr/local/man/man3/ldap_translate_to_t61.3.gz: No such file or directory makewhatis: /usr/local/man/man8/ldif2id2children.8.gz: No such file or directory makewhatis: /usr/local/man/man8/ldif2id2entry.8.gz: No such file or directory makewhatis: /usr/local/man/man8/ldif2index.8.gz: No such file or directory -- End of weekly output -- I know the etags line has been happening for at least a couple of months, but all the rest are new. Is this a result of the recent de-perlifying of makewhatis? I'm assuming there's probably a missing 2/dev/null somewhere. Cheers, Mike Makonnen To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
f77 broken on -current
f77 cannot compile any programs on -current: %f77 test.f /usr/libexec/elf/ld: cannot find -lfrtbegin Creating src/gnu/lib/libfrtbegin and placing this Makefile in it fixes it (after editing the parent directory's makefile to hook it in): .PATH: ../../../contrib/libf2c/libF77 LIB=frtbegin SRCS= main.c .include bsd.lib.mk There may be a more elegant way to fix this - I don't know much about GCC or how it was solved w/ gcc 2.x. Tim To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: GCC3.1 internal compiler error when compilingXFree86-4-libraries
Thank you! Your patch-z32 made me happy a little.
When can I compile XFree86-4-Server-4.2.0_2 with -current?
It gives me internal compiler error, too as below. I had
thought it uses XFree86-4-libraries port which was wrong.
=== Building for XFree86-Server-4.2.0_2
Building Release 6.6 of the X Window System: -
Sat Jun 8 21:40:08 JST 2002
::: (snip)
rm -f translate.o
LD_LIBRARY_PATH=../../../../exports/lib cc -c -O -pipe-ansi -pedantic -Dasm=__asm
-Wall -Wpointer-arith -I../../../../exports/include
-I../../../../exports/include/X11 -I../../../../include/extensions
-I../../../../extras/Mesa/src -I../../../../lib/GL/dri -I../../../..
-I../../../../exports/include -DCSRG_BASED -DFUNCPROTO=15 -DNARROWPROTO -DXTHREADS
-DXUSE_MTSAFE_API -DXNO_MTSAFE_PWDAPI-DMALLOC_0_RETURNS_NULL -DGLXEXT -DXF86DRI
-DGLX_DIRECT_RENDERING -DGLX_USE_DLOPEN -DGLX_USE_MESA-DUSE_X86_ASM
-DUSE_MMX_ASM -ansi -pedantic -Dasm=__asm -Wall -Wpointer-arith
-I../../../../exports/include -I../../../../exports/include/X11
-I../../../../include/extensions -I../../../../extras/Mesa/src
-I../../../../lib/GL/dri -I../../../.. -I../../../../exports/include -DCSRG_BASED
-DFUNCPROTO=15 -DNARROWPROTO -DXTHREADS -DXUSE_MTSAFE_API -DXNO_MTSAFE_PWDAPI
-DMALLOC_0_RETURNS_NULL -DGLXEXT -DXF86DRI -DGLX_DIRECT_RENDERING -DGLX_USE_DLOPEN
-DGLX_USE_MES!
A -DUSE_X86_ASM -DUSE_MMX_ASM-fPIC translate.c
In file included from translate.c:779:
../../../../extras/Mesa/src/trans_tmp.h: In function `trans_1_GLdouble_1ub_elt':
../../../../extras/Mesa/src/trans_tmp.h:124: could not find a spill register
(insn 96 94 97 (set (subreg:SF (reg:QI 75) 0)
(plus:SF (reg:SF 8 st(0) [76])
(reg:SF 9 st(1) [80]))) 525 {*fop_sf_comm_nosse} (insn_list 87 (nil))
(expr_list:REG_DEAD (reg:SF 8 st(0) [76])
(nil)))
../../../../extras/Mesa/src/trans_tmp.h:124: Internal compiler error in failed_reload,
at reload1.c:5050
Please submit a full bug report,
with preprocessed source if appropriate.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: perl wrapper and PATH
On Sat, 8 Jun 2002, John Hay wrote: On Fri, Jun 07, 2002 at 11:26:18PM -0700, Bill Fenner wrote: I ran use.perl port, and that gave me a working perl for mergemaster. Interestingly, use.perl system didn't give me back the perl wrapper; I'm not sure what I got. Sigh. That script predates the removal of perl from the base system, and was supposed to facilitate the switching between various perl versions. It still has its justification of existence on -STABLE, but on -CURRENT, it does not work well any more. What you got is likely links to nowhere, your perl wrapper binary was clobbered. Bottom line: if at all, it should only be used for use.perl port, for the cases where the wrapper does not work as desired. Or maybe we should get rid of the wrapper and change the perl port/package to run use.perl port by default on current? John -- John Hay -- [EMAIL PROTECTED] / [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message The wrapper is there so that there are no suprises to people that *expect* perl in the system. What would possibly be a good idea is that the wrapper is there, but it doesn;t actually redirect to the new perl. Then use.perl is run from the port. The case for system should be removed or some way of relinking to the wrapper instead should be provided? The problem is that use.perl is needed on -STABLE systems, so... a different behaviour when the OS version is =5 might be needed? I Cc:ed this to the ports maintainer just in case... If they would like I can fix use.perl to have a different behaviour on -current and thereafter, but I don;t want to step on anybody's toes. -Trish -- Trish Lynch [EMAIL PROTECTED] FreeBSD The Power to Serve Ecartis Core Team [EMAIL PROTECTED] http://www.freebsd.org To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: dump (via amanda) causing panics
In message [EMAIL PROTECTED], David O'Brien writes: Can you reduce PHK's ufs2 patch down to the minium required to fix dump? That could then be committed now. Hopefully I already committed the fix to dump(8) ? -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: dump (via amanda) causing panics
In message [EMAIL PROTECTED], Brooks Davis writes: I saw similarly bogus sector (block) numbers when I first debugged this problem. They were caused by missing prototypes. 32-bit block numbers were passed to unprototyped functions that expected daddr_t block numbers. When daddr_t was changed to 64 bits, there was garbage in the top 32 bits. =20 dump doesn't compile cleanly at a high WARNS level, so now would be a good time to WARNSify it. That sounds like a good idea. If someone else doesn't get there first, I'll take a look at that soon. If nothing else, there's the plane trip down to SFO for USENIX. Please, if you do so, do it relative to the UFS2 patch, there is little point in making it harder for both yourself and Kirk than absolutely necessary... -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
RE: Fixing could sleeep... was (Re: ../../../vm/uma_core.c:132
On 08-Jun-2002 Mike Makonnen wrote:
On Sat, 08 Jun 2002 04:03:40 -0700 (PDT)
Hiten Pandya [EMAIL PROTECTED] wrote:
--- Juan Francisco Rodriguez Hervella [EMAIL PROTECTED] wrote:
../vm/uma_core.c:1160
../../../vm/uma_core.c:1327: could sleep with process lock locked
from ../../../kern/kern_prot.c:511
../../../vm/uma_core.c:1327: could sleep with process lock locked
from
Hope this help. Do you think these errors are alarming ?
I mean, do you recommend me to recopile my kernel again ?
(please noo, it takes me a lot of time to recompile whatever
thing :)
I also get these and I figured they're as good an excuse as any to jump
into the kernel code :-} This particular one (and others related to the
setuid/gid family of functions) occur because some time after PROC_LOCK
is called in set{uid,euid} and further down the call stack uidfind()
allocates some memory specifying the M_WAITOK flag.
Is the solution to this to use M_NOWAIT and continue re-trying untill it
succeeds? Is there on-going smp work in locking down struct proc that
will eliminate this problem?
Well, the real solution probably involves changing where we dink with
uidinfo structs so we bump the reference count on teh new one before we
grab the proc lock, change over to the new one while holding the proc lock,
then release the reference to the old one after we are done.
Cheers,
Mike Makonnen
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
--
John Baldwin [EMAIL PROTECTED]http://www.FreeBSD.org/~jhb/
Power Users Use the Power to Serve! - http://www.FreeBSD.org/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: perl wrapper and PATH
On Sat, Jun 08, 2002 at 09:48:05AM -0400, Trish Lynch wrote: The wrapper is there so that there are no suprises to people that *expect* perl in the system. What would possibly be a good idea is that the wrapper is there, but it doesn;t actually redirect to the new perl. Then use.perl is run from the port. The case for system should be removed or some way of relinking to the wrapper instead should be provided? It sounds reasonable, but what's the point of having a wrapper at all then? The problem is that use.perl is needed on -STABLE systems, so... a different behaviour when the OS version is =5 might be needed? I don't like that but I am afraid it has to be done. I Cc:ed this to the ports maintainer just in case... If they would like I can fix use.perl to have a different behaviour on -current and thereafter, but I don;t want to step on anybody's toes. Thanks, but I think I'll try to hack something up during weekend. I am of the opinion that we don't need the wrapper and that use.perl can easily do some symlink magic to solve all outstanding issues with perl in -current. Cheers, \Anton. -- | Anton Berezin| FreeBSD: The power to serve | | catpipe Systems ApS _ _ |_ | http://www.FreeBSD.org | | [EMAIL PROTECTED](_(_|| |[EMAIL PROTECTED] | | +45 7021 0050| Private: [EMAIL PROTECTED] | To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: f77 broken on -current
On Sat, Jun 08, 2002 at 09:29:30PM +1000, Tim J. Robbins wrote: f77 cannot compile any programs on -current: %f77 test.f /usr/libexec/elf/ld: cannot find -lfrtbegin Creating src/gnu/lib/libfrtbegin and placing this Makefile in it fixes it (after editing the parent directory's makefile to hook it in): .PATH: ../../../contrib/libf2c/libF77 LIB= frtbegin SRCS= main.c .include bsd.lib.mk There may be a more elegant way to fix this - I don't know much about GCC or how it was solved w/ gcc 2.x. I filed a PR with patches 14 days ago. Unfortunately, I misspelled Fortran in the subject line. David O'Brien is aware of the patches, but he has/had more important compiler/library issues to address. [2002/05/26] gnu/38594 Fortan program don't link post gcc-3.1 -- Steve To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: GCC3.1 internal compiler error when compiling XFree86-4-libraries
On Sat, Jun 08, 2002 at 10:11:13PM +0900, Yamada Ken Takeshi wrote: snip/ (expr_list:REG_DEAD (reg:SF 8 st(0) [76]) (nil))) ../../../../extras/Mesa/src/trans_tmp.h:124: Internal compiler error in failed_reload, at reload1.c:5050 Please submit a full bug report, with preprocessed source if appropriate. interesting enough, if you compile that file WITHOUT optimizations, everything works fine. -tacho To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
More X breakage in XFree86-4-Servers ...
BRARY_PATH=../../../../exports/lib cc -c -O -pipe -D_OLD_STDIO -ansi -pedantic
-Dasm=__asm -Wall -Wpointer-arith -I../../../../exports/include
-I../../../../exports/include/X11 -I../../../../include/extensions
-I../../../../extras/Mesa/src -I../../../../lib/GL/dri -I../../../..
-I../../../../exports/include -DCSRG_BASED -DFUNCPROTO=15 -DNARROWPROTO -DXTHREADS
-DXUSE_MTSAFE_API -DXNO_MTSAFE_PWDAPI-DMALLOC_0_RETURNS_NULL -DGLXEXT -DXF86DRI
-DGLX_DIRECT_RENDERING -DGLX_USE_DLOPEN -DGLX_USE_MESA-DUSE_X86_ASM
-DUSE_MMX_ASM -ansi -pedantic -Dasm=__asm -Wall -Wpointer-arith
-I../../../../exports/include -I../../../../exports/include/X11
-I../../../../include/extensions -I../../../../extras/Mesa/src
-I../../../../lib/GL/dri -I../../../.. -I../../../../exports/include -DCSRG_BASED
-DFUNCPROTO=15 -DNARROWPROTO -DXTHREADS -DXUSE_MTSAFE_API -DXNO_MTSAFE_PWDAPI
-DMALLOC_0_RETURNS_NULL -DGLXEXT -DXF86DRI -DGLX_DIRECT_REND
ERING -DGLX_USE_DLOPEN -DGLX_USE_MESA -DUSE_X86_ASM -DUSE_MMX_ASM-fPIC
translate.c
In file included from translate.c:779:
../../../../extras/Mesa/src/trans_tmp.h: In function `trans_1_GLdouble_1ub_elt':
../../../../extras/Mesa/src/trans_tmp.h:124: could not find a spill register
(insn 96 94 97 (set (subreg:SF (reg:QI 75) 0)
(plus:SF (reg:SF 8 st(0) [76])
(reg:SF 9 st(1) [80]))) 525 {*fop_sf_comm_nosse} (insn_list 87 (nil))
(expr_list:REG_DEAD (reg:SF 8 st(0) [76])
(nil)))
../../../../extras/Mesa/src/trans_tmp.h:124: Internal compiler error in failed_reload,
at reload1.c:5050
Please submit a full bug report,
with preprocessed source if appropriate.
See URL:http://www.gnu.org/software/gcc/bugs.html for instructions.
*** Error code 1
Stop in
/usr/local/ports/usr/ports/x11-servers/XFree86-4-Server/work/xc/lib/GL/mesa/src.
*** Error code 1
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: perl wrapper and PATH
On Sat, Jun 08, 2002 at 05:07:39PM +0200, Anton Berezin wrote: It sounds reasonable, but what's the point of having a wrapper at all then? One way or the other we need to have /usr/bin/perl exist and be usable. Many have perl scripts in ~/bin that they expect to run on all modern OS's -- which means they have /usr/bin/perl. I am of the opinion that we don't need the wrapper and that use.perl can easily do some symlink magic to solve all outstanding issues with perl in -current. With the limitations in the exiting wrapper, either use.perl or using mailwrapper is probably what we should do. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: perl wrapper and PATH
On Sat, 8 Jun 2002, David O'Brien wrote: On Sat, Jun 08, 2002 at 05:07:39PM +0200, Anton Berezin wrote: It sounds reasonable, but what's the point of having a wrapper at all then? One way or the other we need to have /usr/bin/perl exist and be usable. Many have perl scripts in ~/bin that they expect to run on all modern OS's -- which means they have /usr/bin/perl. Exactly, the reason for the wrapper even if its not a wrapper, but a placeholder, is to notify people that there has been a change, and you now need to install the perl port for perl. The optimum behaviour would be to use.perl port when its installed, and if the port is removed, have the placeholder still in place. (a -current version of use.perl system) I am of the opinion that we don't need the wrapper and that use.perl can easily do some symlink magic to solve all outstanding issues with perl in -current. With the limitations in the exiting wrapper, either use.perl or using mailwrapper is probably what we should do. *nod* Anton, if you don;t get around to it this weekend, mind if I take a stab at it? -Trish -- Trish Lynch [EMAIL PROTECTED] FreeBSD The Power to Serve Ecartis Core Team [EMAIL PROTECTED] http://www.freebsd.org To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
[Winston's List] Get Caught Up! - The HOT STEAMY Black-Novel
A projected ESSENCE Best-Seller!!! To CHECK OUT the HOT Black-Novel, Caught Up! CLICK ON LINK BELOW!!! http://winstonchapman.netfirms.com READ 2-Chapters ON-LINE and you'll be Caught Up, too!!! Special Offer: TODAY ONLY!!! Nubonyx.com - Getting People of Color Online Unlimited Internet Access - www.nubonyx.com To Unsubscribe from the list, Click link, then send email. mailto:[EMAIL PROTECTED]?[EMAIL PROTECTED] Or send an email with remove in subject to [EMAIL PROTECTED] Winston Chapman, 4129 Kings Causeway, Atlanta, GA 30294
New ipfw code available
[Bcc to -current because it is relevant there as well -- sorry for the crosspost] Hi, over the past 2-3 weeks I have done an extensive rewrite of the ipfw code (userland + kernel) in an attempt to make it faster and more flexible. The idea (which I discussed a few times on the mailing lists) was to replace the current ipfw rules (macroinstructions) with a set of microinstructions, each of them performing a single operation such as matching an address, or a port range, or a protocol flag, etc. -- much in the spirit of BPF and derivatives -- and to let the userland front-end compile ipfw(8) commands into an appropriate set of microinstructions. There are several advantages in using this technique: first of all, instructions are typically shorter and faster, because the former code had to check for the presence of all the possible options in a rule, whereas the new one can simply do just the things that are required -- e.g. an instruction like allow ip from 1.2.3.0/24 to any translates to a couple of microinstructions (whose complete implementation is below the instructions themselves): O_IP_DST if (((ipfw_insn_ip *)cmd)-addr.s_addr == (dst_ip.s_addr ((ipfw_insn_ip *)cmd)-mask.s_addr)) goto cmd_match; goto cmd_fail; O_ACCEPT: retval = 0; /* accept */ goto accept; But there is a lot more -- the instruction set is easily extensible, and without backward compatibility problems. Furthermore, you can build (and I have already implemented them) more complex rules by assembling microinstructions with OR and NOT operands. I.e. you can write something like: pipe 10 tcp from 1.2.3.4 or 1.2.3.7 or not 1.2.3.0/28 21-25,1024-4095 \ to any in recv ed0 or recv fxp1 or recv dc0 uid 35 or uid 50 You get the idea... I have a fairly complete version of the above code at the moment, which is only missing a small set of functionalities (ip/tcp flags matching, log and fixing hooks to the stateful code). However the glue to implement all the missing pieces is already there, it is just a matter of adding a few lines of code and testing things. Other than that, the code is meant to be fully compatible with the old syntax so you will not have to rewrite your existing rulesets. I have put a preliminary snapshot of this code (for CURRENT) at http://info.iet.unipi.it/~luigi/ipfw5.20020609.tgz It replaces the following files from a recent (2002/05/14) version of -current. sys/netinet/ip_dummynet.c sys/netinet/ip_fw.c sys/netinet/ip_fw.h sbin/ipfw/ipfw.c I would be very grateful if someone could have a look at the code, maybe give it a try, and see e.g. how it compiles your typical ruleset and whether the new extensions can make your ipfw rulesets simpler. Feedback welcome, both on the architecture and on the implementation. NOTE: if people wonder why I did not use BPF and reinvented the wheel: the keyword is backward compatiblity -- i thought it was a bit too complex to compile the existent ipfw syntax into BPF, especially because BPF at least as far as i know does not handle UIDs, and GIDs and interface matches and different actions than match or not match, so i would have had to extend the code anyways, at which point i thought I could as well write my own microinstruction set... cheers luigi ---+- Luigi RIZZO, [EMAIL PROTECTED] . Dip. di Ing. dell'Informazione http://www.iet.unipi.it/~luigi/ . Universita` di Pisa TEL/FAX: +39-050-568.533/522 . via Diotisalvi 2, 56126 PISA (Italy) Mobile +39-347-0373137 ---+- to thanks luigi To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: cvs commit: src/sys/kern subr_witness.c
On Sat, 08 Jun 2002 10:57:31 -0400 (EDT) John Baldwin [EMAIL PROTECTED] wrote: Heh, that's fine. Let me know if it works. :) Ok, no more exhausted messages. Before I applied it I had a bunch of dead witnesses when I did a show witness in ddb (i.e. - only about 1 out of 10 witnesses were _not_ dead). I didn't see any after the patch (I assume I'll probably see more as my uptime increases?). Before which patch? The one in CVS or the one I haven't committed yet. (The one I posted that's not in CVS has a bug btw). The one in CVS. Cheers. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
