Re: nroff -man broken?
On Tue, Apr 24, 2001 at 10:25:47PM +0200, Riccardo Torrini wrote: # man man Formatting page, please wait...mdoc error: end-macro (.em) respecification is not allowed. (#20) Should this have been `.Em ...'? User Abort. Done. This happens over last week. World of this night (after cvsup with also make kernel and mergemaster, for 4 times). I have also tryed to remove all */man/cat*/*gz compiled manuals with but luck :( Any hints? Thanks. There was a problem caused by broken `make cleandir' behavior. Make sure you have src/share/mk/bsd.obj.mk, revision 1.35. Cheers, -- Ruslan Ermilov Oracle Developer/DBA, [EMAIL PROTECTED] Sunbay Software AG, [EMAIL PROTECTED] FreeBSD committer, +380.652.512.251Simferopol, Ukraine http://www.FreeBSD.org The Power To Serve http://www.oracle.com Enabling The Information Age To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: nroff -man broken?
On Tue, 24 Apr 2001 22:25:47 +0200, Riccardo Torrini wrote: This happens over last week. World of this night (after cvsup with also make kernel and mergemaster, for 4 times). I have also tryed to remove all */man/cat*/*gz compiled manuals with but luck :( Any hints? Thanks. Check for catpages in */man/en.ISO_8859-1/cat* as well, using your own locale-dependent directory, of course. Ciao, Sheldon. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: [RFC] RELNOTESng for 5-CURRENT
On Tue, 24 Apr 2001, Bruce A. Mah wrote: [...] There are two disadvantages to going this route. I think they're fairly minor: 1. Generating a set of release notes requires the DocBook toolchain to be built, as well as the doc/ subtree. Note that RELNOTESng will have absolutely no effect on the buildworld/installworld procedure. [...] defaulting to off. Once the bugs have been shaken out, I'll make RELNOTESng the default and stop maintaining the *.TXT files. Eventually, the *.TXT files will get removed. Perhaps the *.TXT files could be periodically regenerated to their current location to 1) avoid a POLA violation and 2) allow for at least some RELNOTES without needing DocBook and doc/ (even if they may be slightly out of date). Just an idea.. Tony. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Updated: cp -t patch (w/ commentary)
On Mon, Apr 23, 2001 at 11:33:24AM -0700, John W. De Boskey wrote: After some feedback, I have changed the patch slightly. Rename -d to -t and remove the requirement for the option to have a value. I thought people generally agreed the right fix was to add functionality to `xargs', not `cp' as you aren't scratching the general itch. -- -- David ([EMAIL PROTECTED]) To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Boot messages
On 25-Apr-01 (01:31:59/GMT) Garrett Wollman wrote: The ``can't assign resources'' messages indicate that the devices are legacy ISA devices for which a non-PnP-aware driver is compiled into the kernel. These include devices such as keyboard... This means that I can remove this lines? Sure? -8-[ /usr/src/sys/i386/conf/TRUDY ]-8- # atkbdc0 controls both the keyboard and the PS/2 mouse device atkbdc 1 device atkbd device psm # Floppy drives device fdc # Serial (COM) ports device sio 1 # pca: PCM audio through your PC speaker device pca AIUI such messages are currently disabled unless one boots in verbose mode. Under -CURRENT boot is supposed to be 'extra_verbose' (IMHO). Ciao, Riccardo. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: nroff -man broken?
On 25-Apr-01 (07:55:22/GMT) Sheldon Hearn wrote: Check for catpages in */man/en.ISO_8859-1/cat* as well, using your own locale-dependent directory, of course. Only have /usr/share/man/en.ISO_8859-1/ but all dirs under this path (cat[1-9n] and cat1aout) are empty :-( # gzip -l cat1/man.1.gz compressed uncompr. ratio uncompressed_name 67 115 57.3% cat1/man.1 # gzip -cd cat1/man.1.gz|hd 00 4d414e28 31290909 09467265 65425344 |MAN(1)...FreeBSD| 10 2047656e 6572616c 20436f6d 6d616e64 | General Command| 20 73204d61 6e75616c 2009094d 414e2831 |s Manual ..MAN(1| 30 290a0a0a 0a0a0a0a 0a0a0a0a 0a0a0a0a |)...| 40 0a0a0a0a 0a0a0a0a 0a0a0a0a 0a0a0a0a || * 70 Even removing cat1/man.1.gz man re-create same empty file. Also making man formatting by hand show same error: # gzip -cd /usr/share/man/man1/man.1.gz | nroff -man mdoc error: end-macro (.em) respecification is not allowed. (#20) Should this have been `.Em ...'? User Abort. Ciao, Riccardo. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: nroff -man broken?
On 25-Apr-01 (07:18:57/GMT) Ruslan Ermilov wrote: There was a problem caused by broken `make cleandir' behavior. Make sure you have src/share/mk/bsd.obj.mk, revision 1.35. # $FreeBSD: src/share/mk/bsd.obj.mk,v 1.35 2001/04/23 14:47:40 ru Exp $ Going to make another world this night :( Ciao, Riccardo. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: nroff -man broken?
On Wed, 25 Apr 2001 10:17:22 +0200, Riccardo Torrini wrote: Even removing cat1/man.1.gz man re-create same empty file. Also making man formatting by hand show same error: Then Ruslan's comments stand. I built and installed world from the updated sources that Ruslan's suggesting and still had problems because of stale catpages in my locale-dependent directories. Ciao, Sheldon. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Updated: cp -t patch (w/ commentary)
On Mon, Apr 23, 2001 at 11:33:24AM -0700, John W. De Boskey wrote: After some feedback, I have changed the patch slightly. Rename -d to -t and remove the requirement for the option to have a value. I thought people generally agreed the right fix was to add functionality to `xargs', not `cp' as you aren't scratching the general itch. In fact, I think enough people disagreed that xargs(1) should be modified as it can be done with scripts. Personally, I'd prefer Dima's xargs(1) fix. -- -- David ([EMAIL PROTECTED]) -- Brian [EMAIL PROTECTED]brian@[uk.]FreeBSD.org http://www.Awfulhak.org brian@[uk.]OpenBSD.org Don't _EVER_ lose your sense of humour ! To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: [RFC] RELNOTESng for 5-CURRENT
takhus Perhaps the *.TXT files could be periodically regenerated to their takhus current location to 1) avoid a POLA violation and 2) allow for at takhus least some RELNOTES without needing DocBook and doc/ (even if they takhus may be slightly out of date). I second this. It is true that current.freebsd.org and much of do-it-yourself distributions are generated with 'NODOC=YES', since it needs much time and disk spaces to process doc.1 target (especially setting up a DocBook environment). Removing *.TXT files also makes some difficulties when ordinally make buildworld/installworld users want to know what changes are made (they should change their CVSup configulation file, checkout doc if the repository is CVSuped, install DocBook via ports, and run make(1) to get a plaintext of release notes). Just like current 'doc' distribution of 'NODOC=YES', it would be helpful that *.TXT files are in src/release. -- - Makoto `MAR' MATSUSHITA To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Updated: cp -t patch (w/ commentary)
On Wed, 25 Apr 2001 10:01:18 -0400, John W. De Boskey wrote: I am dealing with a production process that currently runs approximately 10 hours. (on 28 866Mhz processors, 2 Netapps). This process fell into my lap about 2 months ago. Something to consider is that you're trying to solve a fairly specific problem. What everyone's asking for is a general solution. Perhaps there is no general solution to your specific problem. Perhaps shell magic or a perl script is your answer. However, a specific hack to cp(1) is what a lot of people don't like. If FreeBSD contained every little hack every committer had used to address specific problems, it'd be a mess. Ciao, Sheldon. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Updated: cp -t patch (w/ commentary)
Hi David, Brian, Thank you for taking the time to reply. I hope you were able to review the patch also. I am dealing with a production process that currently runs approximately 10 hours. (on 28 866Mhz processors, 2 Netapps). This process fell into my lap about 2 months ago. After studying the process, the 1st item that came to the fore-front was the number of fork/exec pairs occuring for the file copy process. Please note, as written in previous emails, the copy process copies files from multiple directories to a singular directory. I have reduced the runtime of the process so far by a solid hour. My change to cp is the lowest level/minimal change fix which allows me to maintain a O(1) time constraint. I've played with (non-freebsd) versions of xargs already, and found them (the various algorithms in xargs) to be more expensive than the patch to cp. I realize you folks are not here, and cannot examine the processes I have to deal with first hand. I can only simply ask you to trust that the work I and others have done while coming to the conclusion that the cp patch is the best alternative is correct. On a different note, I have spoken with my mentor (seems funny calling him that these days) Jordan, and his response to my email was: I think you should just commit the cp changes and let the xargs weenies debate themselves silly if the want to. :) The two issues are not really related. -Jordan I must say at this point, I tend to agree with him. Basically, my review request was skipped over and folks simply went on to discuss/argue the merits/demerits of various patchs to xargs. The question of whether xargs is appropriate and maintains adequate performance for my particular process seems to have been left on the roadside... I hope I haven't rambled to much. And again, thanks for taking the time to respond. -John - Current List's Original Message - On Mon, Apr 23, 2001 at 11:33:24AM -0700, John W. De Boskey wrote: After some feedback, I have changed the patch slightly. Rename -d to -t and remove the requirement for the option to have a value. I thought people generally agreed the right fix was to add functionality to `xargs', not `cp' as you aren't scratching the general itch. -- -- David ([EMAIL PROTECTED]) To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Updated: cp -t patch (w/ commentary)
John W. De Boskey wrote: Hi David, Brian, Thank you for taking the time to reply. I hope you were able to review the patch also. I am dealing with a production process that currently runs approximately 10 hours. (on 28 866Mhz processors, 2 Netapps). This process fell into my lap about 2 months ago. After studying the process, the 1st item that came to the fore-front was the number of fork/exec pairs occuring for the file copy process. Please note, as written in previous emails, the copy process copies files from multiple directories to a singular directory. I have reduced the runtime of the process so far by a solid hour. My change to cp is the lowest level/minimal change fix which allows me to maintain a O(1) time constraint. I've played with (non-freebsd) versions of xargs already, and found them (the various algorithms in xargs) to be more expensive than the patch to cp. I realize you folks are not here, and cannot examine the processes I have to deal with first hand. I can only simply ask you to trust that the work I and others have done while coming to the conclusion that the cp patch is the best alternative is correct. On a different note, I have spoken with my mentor (seems funny calling him that these days) Jordan, and his response to my email was: I think you should just commit the cp changes and let the xargs weenies debate themselves silly if the want to. :) The two issues are not really related. -Jordan I must say at this point, I tend to agree with him. Basically, my review request was skipped over and folks simply went on to discuss/argue the merits/demerits of various patchs to xargs. The question of whether xargs is appropriate and maintains adequate performance for my particular process seems to have been left on the roadside... I hope I haven't rambled to much. And again, thanks for taking the time to respond. The only thing that I can't understand is why you want this incompatible featute to go into cvs repo. Why you can't make this very specific modification locally and use it on your own, or just make a port of it if you really think that it might be useful to somebody else? -Maxim To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
-current world can't be built on 4-STABLE (broke in lint)
Hi, It seems that recent lint modifications made impossible to build the -current world on 4-stable system, thus breaking source upgrade path from -stable to -current. Please fix. -Maxim === usr.bin/xlint === usr.bin/xlint/lint1 cc -pipe -mpreferred-stack-boundary=2 -O -march=k6 -I. -I/usr/src/usr.bin/xlint/ lint1 -DXXX_BROKEN_GCC -I/shares/UF/obj/usr/src/i386/usr/include -o lint1 cgr am.o scan.o mem1.o mem.o err.o main1.o decl.o tree.o func.o init.o emit.o emit1. o -ll === usr.bin/xlint/lint2 cc -pipe -mpreferred-stack-boundary=2 -O -march=k6 -I/usr/src/usr.bin/xlint/lint 2/../lint1 -I/shares/UF/obj/usr/src/i386/usr/include -o lint2 main2.o hash.o read.o mem.o mem2.o chk.o msg.o emit.o emit2.o === usr.bin/xlint/xlint cc -pipe -mpreferred-stack-boundary=2 -O -march=k6 -I/usr/src/usr.bin/xlint/xlin t/../lint1 -I/shares/UF/obj/usr/src/i386/usr/include -o xlint xlint.o mem.o === usr.bin/xlint/llib /shares/UF/obj/usr/src/usr.bin/xlint/llib/../xlint/xlint -Cposix /usr/src/usr.bi n/xlint/llib/llib-lposix /shares/UF/obj/usr/src/usr.bin/xlint/llib/../xlint/xlint -Cstdc /usr/src/usr.bin /xlint/llib/llib-lstdc /usr/libexec/ld-elf.so.1: Shared object libc.so.5 not found /usr/libexec/ld-elf.so.1: Shared object libc.so.5 not found *** Error code 1 *** Error code 1 (FreeBSD vic.sabbo.net 4.3-RC FreeBSD 4.3-RC #7: Mon Mar 26 21:37:09 EEST 2001 [EMAIL PROTECTED]:/usr/src/sys/compile/VEGA i386) To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: [RFC] RELNOTESng for 5-CURRENT
[Please keep me as one of the explicit recipients of this email. Thanks.] If memory serves me right, Makoto MATSUSHITA wrote: takhus Perhaps the *.TXT files could be periodically regenerated to their takhus current location to 1) avoid a POLA violation and 2) allow for at takhus least some RELNOTES without needing DocBook and doc/ (even if they takhus may be slightly out of date). [snip] It is true that current.freebsd.org and much of do-it-yourself distributions are generated with 'NODOC=YES', since it needs much time and disk spaces to process doc.1 target (especially setting up a DocBook environment). My first reaction is, is doing doc.1 *that* much of a problem? When I was testing, it didn't seem like building this consumed much time or disk space compared to the rest of the make release process (i.e. building world and several kernels). A checked-out doc/ is 37 MB. Removing *.TXT files also makes some difficulties when ordinally make buildworld/installworld users want to know what changes are made (they should change their CVSup configulation file, checkout doc if the repository is CVSuped, install DocBook via ports, and run make(1) to get a plaintext of release notes). I think the only recurring cost that people are going to have to do is to keep a reasonably current copy of doc/. Building the docproj port is a one-time operation. After that, it takes about 15 seconds of wallclock time on my workstation to build the TXT version of the release notes (note that you'll get the SGML sources automatically under src/ release/doc). Just like current 'doc' distribution of 'NODOC=YES', it would be helpful that *.TXT files are in src/release. Umm, no, it's not just like the current doc distribution. If you build a release with NODOC=YES, you don't get any rendition of the FAQ, Handbook, etc. There's no *.TXT files to fall back on. Here's my thoughts...for the record, I'm weakly opposed to regen-ing *.TXT versions: First, I don't want to bloat the repository with oodles of builds to the *.TXT files. If we do this, it ought to be be fairly infrequently, like maybe once or twice a month. Second, regen-ing needs to be done automatically. I'm not going to do it by hand. Third, let's assume that there's some interest in actually having different localized versions of the release notes (note that the infrastructure supports it). What language do we build for the *.TXT fallback files? Finally, there needs to be some boilerplate text on the fallback files to indicate the generation date of the fallback versions, and a pseudo-disclaimer that they may be out of date with respect to the actual state of the code. If we get the automatic generation problem solved, this one should be easy. Like I said, I'm weakly opposed to doing this, but I'm also quite willing to be swayed. Cheers, Bruce. PGP signature
Re: [RFC] RELNOTESng for 5-CURRENT
On Wed, Apr 25, 2001 at 09:58:40AM -0700, Bruce A. Mah wrote: [Please keep me as one of the explicit recipients of this email. Removing *.TXT files also makes some difficulties when ordinally make buildworld/installworld users want to know what changes are made (they should change their CVSup configulation file, checkout doc if the repository is CVSuped, install DocBook via ports, and run make(1) to get a plaintext of release notes). I think the only recurring cost that people are going to have to do is to keep a reasonably current copy of doc/. Building the docproj port is Reasonably current effectively means not current . Aka out of date. Umm, no, it's not just like the current doc distribution. If you build a release with NODOC=YES, you don't get any rendition of the FAQ, Handbook, etc. There's no *.TXT files to fall back on. Here's my thoughts...for the record, I'm weakly opposed to regen-ing *.TXT versions: First, I don't want to bloat the repository with oodles of builds to the *.TXT files. If we do this, it ought to be be fairly infrequently, like maybe once or twice a month. Bad idea.. RELNOTES, HARDWARE etc are things that should be up to date. Not 'a bit uptodate' or 'slightly outdated'. I really would not like to see the idea being bloated by going this route. If people think getting the Docbook infrastructure in place is too much work/time they should accustom themselves to reading the raw Docboot source files. Like I said, I'm weakly opposed to doing this, but I'm also quite willing to be swayed. Please don't be swayed.. ;) W/ -- | / o / / _ Arnhem, The Netherlandsemail: [EMAIL PROTECTED] |/|/ / / /( (_) BultePowered by FreeBSD/alpha http://www.freebsd.org To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Boot messages
On Wed, 25 Apr 2001 09:57:14 +0200 (CEST), Riccardo Torrini [EMAIL PROTECTED] said: This means that I can remove this lines? Sure? device atkbdc 1 No, I said nothing of the sort. -GAWollman To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Updated: cp -t patch (w/ commentary)
At 10:01 AM -0400 4/25/01, John W. De Boskey wrote: Hi David, Brian, Thank you for taking the time to reply. I hope you were able to review the patch also. Every time you have asked for people's opinions, they have said that it seems wrong to made add a specific option to the 'cp' command to address a generic problem with the 'xargs' command. You continue to pretend that this is not a valid comment on your proposed change. If you do not want our opinions, then stop asking for them. You then offer to do a similar update to 'mv', again to fix the problem when using 'mv' with 'xargs'. Will you also do updates for 'scp'? How about 'fs setacl'? (an AFS command). Other commands? Why should we fix all these commands to address a problem caused by using them with xargs? Why not fix 'xargs', at which point we don't have to care about any list of commands (even weird ones like 'fs setacl') which have this same problem. I have reduced the runtime of the process so far by a solid hour. My change to cp is the lowest level/minimal change fix which allows me to maintain a O(1) time constraint. I've played with (non-freebsd) versions of xargs already, and found them (the various algorithms in xargs) to be more expensive than the patch to cp. It is inconceivable that the proposed patch to 'xargs' would increase your running time. I don't mean the standard '-I' change, which would certainly destroy performance, but the proposed patch to 'xargs' which solves your specific problem in a general way. I'm still curious as to why you think the proposed change to xargs will cause you ANY performance problem. I simply can not imagine where you would get a performance problem from the -Y idea (though I'm still tempted to change the letter for that proposed option). Dimi has written one or two different patches to xargs. Did you try any of them? (ignore the fact that he used '-I' as the letter for what was supposed to be the NEW option, *that* was a mistake!). How DID that patch effect your running time? I realize you folks are not here, and cannot examine the processes I have to deal with first hand. I can only simply ask you to trust that the work I and others have done while coming to the conclusion that the cp patch is the best alternative is correct. It isn't so much that we don't trust you, we're just wondering why the patch to 'xargs' does not solve the same problem you're trying to solve. We could also ask you to trust us, in that we already know the exact problem you are describing, and we *are* trying to address it. I've hit the exact same problem in the past, it's just that I've always solved it by writing a short script. If we are going to open the floor to adding non-standard options to standard unix commands, then it seems much better to add one option to one command, instead of adding options to a list of commands. On a different note, I have spoken with my mentor (seems funny calling him that these days) Jordan, and his response to my email was: I think you should just commit the cp changes and let the xargs weenies debate themselves silly if they want to. :) The two issues are not really related. -Jordan I must say at this point, I tend to agree with him. I think the problem is that this *discussion* has rambled off in several different directions, many of which have no bearing to your situation. That doesn't mean we aren't honestly trying to come up with a good general solution which *is* directly related to your problem. It just means that we're tossing in a few extra things in addition to the solution for your situation. We should probably fix your problem first, and discuss the rest of it later. The xargs weenies have also offered an explicit patch that could be tried, but that patch is being ignored by you. It is not a matter of talking ourselves to death, it's a matter that we're looking for feedback from anyone who wants to respond to the proposed xargs changes. If you need an immediate fix, I'll be happy to change Dimi's patch to use a different letter, and commit the change later tonight. We'll forget this ask for input stage, if Jordan really finds it so bothersome. -- Garance Alistair Drosehn= [EMAIL PROTECTED] Senior Systems Programmer or [EMAIL PROTECTED] Rensselaer Polytechnic Instituteor [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
problem report: optimization
Hello, i've discovered that now the world cannot be built without any optimization options (-Oxx) due to a 'dirty' code in some places. one of good examples is usr.sbin/rpc.lockd. without -Oxx options kern.c fails compilation: cc -pipe -march=k6 -I. -I/usr/include/rpcsvc -g-o rpc.lockd kern.o nlm_prot_svc.o lockd.o lock_proc.o lockd_lock.o -lrpcsvc -lutil kern.o: In function `test_request': /garbage/src/usr.sbin/rpc.lockd/kern.c(.text+0x504): undefined reference to `from_addr' kern.o: In function `lock_request': /garbage/src/usr.sbin/rpc.lockd/kern.c(.text+0x743): undefined reference to `from_addr' kern.o: In function `unlock_request': /garbage/src/usr.sbin/rpc.lockd/kern.c:387: undefined reference to `from_addr' kern.o: In function `lock_answer': /garbage/src/usr.sbin/rpc.lockd/kern.c:454: undefined reference to `show_4state' /garbage/src/usr.sbin/rpc.lockd/kern.c:454: undefined reference to `show_state' *** Error code 1 Stop in /garbage/src/usr.sbin/rpc.lockd. but with optimizations turned on it compiles well. the problem is in the pieces of code like below: #define d_calls 0 . . if (d_calls) . . from_addr((struct sockaddr_in *)msg-lm_addr)); obvious, that the code inside 'if' statement can't be ever executed, and 'cc' with optimizations enabled doesn't even process it. but without optimizations, all the code is being included into the object file, which, of course, can't be linked because 'from_addr' is really undefined. i understand that -O option is used by default, but i think that unnecesary code should be commented out or deleted from sources because such tricks decrease readability and create problems described above. -- Best regards, Ilya mailto:[EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Updated: cp -t patch (w/ commentary)
However, a specific hack to cp(1) is what a lot of people don't like. If FreeBSD contained every little hack every committer had used to address specific problems, it'd be a mess. I was told that the hack everyone is referring to is already implemented in several other operating systems, but I must confess that my searches so far haven't turned up the expected evidence. I did find a rather useful `-u' flag to cp in Redhat 6.2 which FreeBSD could probably stand to adopt, but other than that... I may have to reverse myself on this one if I can't find at least one other vendor which has adopted -t. - Jordan To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: PATCH to make maxfiles, maxfiles per proc boot-time tunable
It seems to me that these things are not boot-time tunable, and should be (really, they should be runtime tunable, but there $ sysctl -a | grep maxf kern.maxfiles: 360 kern.maxfilesperproc: 360 `maxfiles' and `maxfilesperproc' have been runtime tunable for more than 5 years (but there are still bugs in the implementation of this). are some nasty pageable region allocations for networking that appear to require contiguous regions for no good reason which I can discern). That means that the best we can do right now is boot-time, so here it is: True, things based on stale values of the variables don't work right. IMO, the only useful thing to do with that many file handles is networking. The fact that the networking doesn't work right when these values are turned, because the initial allocations are required to be contiguous for no good reason to make them pageable, is really, really stupid. -- Index: conf/param.c === Don't put anything more in param.c. Almost everything in it can be done better using tunables or sysctls. The only thing that it is now useful for is centralizing the #defines for bogus defaults based on MAXUSERS. This is unnecessary for tunables, since they don't need static initializers. E.g., the tunable for kern.maxfiles can be TUNABLE_INT_DECL(kern.maxfiles, 2 * maxproc, maxfiles); instead of TUNABLE_INT_DECL(kern.maxfiles, MAXFILES, maxfiles); Then maxfiles can be declared in the right place (not here). There would be a problem getting tunables set in the right order if maxproc were tunable. We also have a sysctl for maxproc, but it was made read-only due to allocation problems for exec_map which went away long ago. Apparently the allocation problems for maxfiles and maxfilesperproc aren't so serious, since the sysctls for these have always been read-write. The problems with these sysctls are more with their interactions with setrlimit(). Actually, there is a serious problem with this approach when applied to maxfiles, and I'm not just talking about param.c. The value of maxfiles is used in: Tune at FileFunction B(1)kern/init_main.cproc0_init() R kern/kern_descrip.c falloc() B(2)kern/uipc_socket2.c init_maxsockets() R svr4/svr4_misc.csvr4_sys_sysconfig() R(3)svr4/svr4_resource.csvr4_sys_getrlimit() svr4_sys_getrlimit64() (1) Before SI_SUB_INTRINSIC, SI_ORDER_FIRST (2) Before SI_SUB_TUNABLES, SI_ORDER_ANY; setting kern.ipc.maxsockets in the bootloader does not override this, since the calculation is: maxsockets = imax(maxsockets, imax(maxfiles, nmbclusters)); (3) These should really use the rlimit values from the kernel, instead of accessing maxfiles directly. The major problem is that the value of maxsockets, derived from the value of maxfiles, is used in: kern/uipc_domain.c domaininit() netinet/tcp_subr.c tcp_init() netinet/udp_usrreq.cudp_init() The domaininit() occurs at SI_SUB_PROTO_DOMAIN, SI_ORDER_FIRST; the other two are from dereferences out of inetsw[] in netinet/in_proto.c. ... all during boot, all to get contiguous swappable regions via calls to zinit(). So it's not just rlimit()... Terry Lambert [EMAIL PROTECTED] --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
make.conf INSTALL knob
I originally sent this to freebsd-stable but didn't get any replies. It has been reworded. I ran across this while playing with the INSTALL knob in make.conf. In almost all of the Makefiles in src/ there is either -C or -c hard coded as an argument to install. This means that changes you make to the flags for install via the INSTALL knob in make.conf, specifically -c or -C are not upheld in the acutal Makefiles. /etc/default/make.conf gives the impression that the flags specified when setting INSTALL should acutally be used when install is invoked. This kind of seems like a violation of POLA to me. If you set INSTALL= install -C in make.conf... most people would assume that it will apply the -C flag to every invokation of install, which is not the case. There are certain directories like src/include and src/kerberos* that have -C hardcoded while others like src/etc have -c hardcoded in the Makefile. I was wonder what exactly are the rammifications of removing all -c and -C flags from the Makefile(s) where applicable and making -c the default flag for install in /etc/defaults/make.conf. Is there any specific reason why certain areas of the source need to have -c or -C? Additionally, I believe the INSTALL knob should be used only to allow you to change the path/name of the install binary. A new variable INSTALLFLAGS should be introduced to specify the flags for install. -- Eric Futch New York Connect.Net, Ltd. [EMAIL PROTECTED] Technical Support Staff http://www.nyct.net (212) 293-2620 Bringing New York The Internet Service It Deserves KNYC: 23-Apr-01 23:51 EDT: 59.0 F (15.0 C), clear, humidity 100% To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Updated: cp -t patch (w/ commentary)
[.] The xargs weenies have also offered an explicit patch that could be tried, but that patch is being ignored by you. It is not a matter of talking ourselves to death, it's a matter that we're looking for feedback from anyone who wants to respond to the proposed xargs changes. If you need an immediate fix, I'll be happy to change Dimi's patch to use a different letter, and commit the change later tonight. We'll forget this ask for input stage, if Jordan really finds it so bothersome. To be fair to Jordan, I don't think this is aimed at the individuals, but more at the discussion that was filling his mail box... Let's not take a shouldn't-have-been-quoted email out of context eh ? -- Garance Alistair Drosehn= [EMAIL PROTECTED] Senior Systems Programmer or [EMAIL PROTECTED] Rensselaer Polytechnic Instituteor [EMAIL PROTECTED] -- Brian [EMAIL PROTECTED]brian@[uk.]FreeBSD.org http://www.Awfulhak.org brian@[uk.]OpenBSD.org Don't _EVER_ lose your sense of humour ! To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Updated: cp -t patch (w/ commentary)
It is inconceivable that the proposed patch to 'xargs' would
increase your running time. I don't mean the standard '-I'
change, which would certainly destroy performance, but the
proposed patch to 'xargs' which solves your specific problem
in a general way.
I'm still curious as to why you think the proposed change to
xargs will cause you ANY performance problem. I simply can
not imagine where you would get a performance problem from
the -Y idea (though I'm still tempted to change the letter
for that proposed option).
I suspect that the bulk of the readers of this thread weren't paying
attention.
To summarise, the actual patch that Dima wrote made
blah | xargs -Y {} cp {} somedir
work as expected, replacing {} with as much of stdin as will fit.
It was then suggested that
#! /bin/sh
cmd=$1
last=$2
shift 2
exec $cmd $@ $last
would solve the problem and the only argument against it was that ENV
could corrupt the script and induce an E2BIG. I didn't consider that
argument strong enough, so I stepped out - that's why I'm not writing
this email.
--
Garance Alistair Drosehn= [EMAIL PROTECTED]
Senior Systems Programmer or [EMAIL PROTECTED]
Rensselaer Polytechnic Instituteor [EMAIL PROTECTED]
--
Brian [EMAIL PROTECTED]brian@[uk.]FreeBSD.org
http://www.Awfulhak.org brian@[uk.]OpenBSD.org
Don't _EVER_ lose your sense of humour !
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: [RFC] RELNOTESng for 5-CURRENT
Here's my thoughts...for the record, I'm weakly opposed to regen-ing *.TXT versions: First, I don't want to bloat the repository with oodles of builds to the *.TXT files. If we do this, it ought to be be fairly infrequently, like maybe once or twice a month. Bad idea.. RELNOTES, HARDWARE etc are things that should be up to date. Not 'a bit uptodate' or 'slightly outdated'. I really would not like to see the idea being bloated by going this route. As UPDATING may contain information nessecary to run make world, it can't be built by make world. Chicken and egg, methinks... Leif To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: [RFC] RELNOTESng for 5-CURRENT
Hey whatever. Let's just keep a rendered TXT version where it always (ie. in the src/release... cvs) was but keep the originial as a sgml version in the doc tree. Just like ports/INDEX. Only better. I think it is important to solve the duplication problem we have. It would be very sad to see a release go out with a wrong X.X-RELEASE header in the README.TXT file, has it almost happened, if I'm not mistaken. :) A. Leif Neland wrote: Here's my thoughts...for the record, I'm weakly opposed to regen-ing *.TXT versions: First, I don't want to bloat the repository with oodles of builds to the *.TXT files. If we do this, it ought to be be fairly infrequently, like maybe once or twice a month. Bad idea.. RELNOTES, HARDWARE etc are things that should be up to date. Not 'a bit uptodate' or 'slightly outdated'. I really would not like to see the idea being bloated by going this route. As UPDATING may contain information nessecary to run make world, it can't be built by make world. Chicken and egg, methinks... Leif To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message -- La sémantique est la gravité de l'abstraction. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: [RFC] RELNOTESng for 5-CURRENT
On Wed, Apr 25, 2001 at 09:42:07PM +0200, Leif Neland wrote: Here's my thoughts...for the record, I'm weakly opposed to regen-ing *.TXT versions: First, I don't want to bloat the repository with oodles of builds to the *.TXT files. If we do this, it ought to be be fairly infrequently, like maybe once or twice a month. Bad idea.. RELNOTES, HARDWARE etc are things that should be up to date. Not 'a bit uptodate' or 'slightly outdated'. I really would not like to see the idea being bloated by going this route. As UPDATING may contain information nessecary to run make world, it can't be built by make world. Chicken and egg, methinks... Possibly. But I was not refering to UPDATING. -- | / o / / _ Arnhem, The Netherlandsemail: [EMAIL PROTECTED] |/|/ / / /( (_) BultePowered by FreeBSD/alpha http://www.freebsd.org To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: [RFC] RELNOTESng for 5-CURRENT
If memory serves me right, Wilko Bulte wrote: On Wed, Apr 25, 2001 at 09:42:07PM +0200, Leif Neland wrote: As UPDATING may contain information nessecary to run make world, it can't b e built by make world. Chicken and egg, methinks... Possibly. But I was not refering to UPDATING. Just to clarify, RELNOTESng will not have any effect whatsoever on the way that /usr/src/UPDATING is maintained. Bruce. PGP signature
Re: [RFC] RELNOTESng for 5-CURRENT
On Wed, Apr 25, 2001 at 09:42:07PM +0200, Leif Neland wrote: Here's my thoughts...for the record, I'm weakly opposed to regen-ing *.TXT versions: First, I don't want to bloat the repository with oodles of builds to the *.TXT files. If we do this, it ought to be be fairly infrequently, like maybe once or twice a month. Bad idea.. RELNOTES, HARDWARE etc are things that should be up to date. Not 'a bit uptodate' or 'slightly outdated'. I really would not like to see the idea being bloated by going this route. As UPDATING may contain information nessecary to run make world, it can't be built by make world. Chicken and egg, methinks... Possibly. But I was not refering to UPDATING. Sorry. My parser just made a mistake by expanding etc in RELNOTES, HARDWARE etc Leif To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Boot messages
In message [EMAIL PROTECTED] Dima Dorfman writes: : Riccardo Torrini [EMAIL PROTECTED] writes: :pca1: AT-style speaker sound at port 0x61 on isa0 :WARNING: Driver mistake: repeat make_dev(pcaudio) :WARNING: Driver mistake: repeat make_dev(pcaudioctl) : : As it says, this is a driver mistake. It's a bug. I don't know if : it's new or not since I don't have any computers with a sound card : (and thus have no need for pcaudio*). : :unknown: PNP0f13 can't assign resources :unknown: PNP0501 can't assign resources :unknown: PNP0700 can't assign resources : : This is not a bug. This is an FAQ. So much that it's actually : documented in (*gasp!*) the FAQ: Actually, it is a bug. The drivers in the tree should grok these pnp ids. Also, the bios pnp devices should be probed first rather than last because those are hard wired pnp devices, as opposed to the ISA PNP devices, which have the potential to be moved and can be disabled. Note well: ISA PNP and BIOS PNP are different things. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Updated: cp -t patch (w/ commentary)
aIn message [EMAIL PROTECTED] John W. De Boskey writes: :I must say at this point, I tend to agree with him. Basically, : my review request was skipped over and folks simply went on to : discuss/argue the merits/demerits of various patchs to xargs. The : question of whether xargs is appropriate and maintains adequate : performance for my particular process seems to have been left on : the roadside... : :I hope I haven't rambled to much. And again, thanks for taking : the time to respond. We didn't pass over your patches, but instead pointed out where a more general solution was possible. Often times this ahs happened for features that people suggest. If we just add it to cp, then we'll have to support it forever and it will be yet another difference that we have in our system that will cause problems for other people. So despite what jkh is saying, I'd not commit it. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: -current world can't be built on 4-STABLE (broke in lint)
In message [EMAIL PROTECTED] Maxim Sobolev writes: : It seems that recent lint modifications made impossible to build the : -current world on 4-stable system, thus breaking source upgrade path : from -stable to -current. Agreed! I have a few fixes to -current/-stable so that you can build -stable on -current again. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: [RFC] RELNOTESng for 5-CURRENT
In message [EMAIL PROTECTED] Antoine Beaupre (LMC) writes: : Hey whatever. Let's just keep a rendered TXT version where it always : (ie. in the src/release... cvs) was but keep the originial as a sgml : version in the doc tree. UPDATING will continue to be a flat file, or I will no longer maintain it. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: [RFC] RELNOTESng for 5-CURRENT
In message [EMAIL PROTECTED] Warner Losh writes: : In message [EMAIL PROTECTED] Antoine Beaupre (LMC) writes: : : Hey whatever. Let's just keep a rendered TXT version where it always : : (ie. in the src/release... cvs) was but keep the originial as a sgml : : version in the doc tree. : : UPDATING will continue to be a flat file, or I will no longer maintain : it. I should also add but I don't think this proposal applies to UPDATING to the end of that. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Boot messages
On 25-Apr-01 Warner Losh wrote: In message [EMAIL PROTECTED] Dima Dorfman writes: : Riccardo Torrini [EMAIL PROTECTED] writes: :pca1: AT-style speaker sound at port 0x61 on isa0 :WARNING: Driver mistake: repeat make_dev(pcaudio) :WARNING: Driver mistake: repeat make_dev(pcaudioctl) : : As it says, this is a driver mistake. It's a bug. I don't know if : it's new or not since I don't have any computers with a sound card : (and thus have no need for pcaudio*). : :unknown: PNP0f13 can't assign resources :unknown: PNP0501 can't assign resources :unknown: PNP0700 can't assign resources : : This is not a bug. This is an FAQ. So much that it's actually : documented in (*gasp!*) the FAQ: Actually, it is a bug. The drivers in the tree should grok these pnp ids. Also, the bios pnp devices should be probed first rather than last because those are hard wired pnp devices, as opposed to the ISA PNP devices, which have the potential to be moved and can be disabled. Well, yes, but that breaks console probing atm since we only support hints-based devices for the kernel console. You'll want to fix that first. Note well: ISA PNP and BIOS PNP are different things. Warner -- John Baldwin [EMAIL PROTECTED] -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc 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: Install kernel gets divide overflow
Weird, I installed the April 19 snap here locally on a testbox without any problems. Rgr, I'll try Apr 19th and send another note with some debug info if it is still dying. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Boot messages
In message [EMAIL PROTECTED] John Baldwin writes: : : On 25-Apr-01 Warner Losh wrote: : In message [EMAIL PROTECTED] Dima Dorfman : writes: : : Riccardo Torrini [EMAIL PROTECTED] writes: : :pca1: AT-style speaker sound at port 0x61 on isa0 : :WARNING: Driver mistake: repeat make_dev(pcaudio) : :WARNING: Driver mistake: repeat make_dev(pcaudioctl) : : : : As it says, this is a driver mistake. It's a bug. I don't know if : : it's new or not since I don't have any computers with a sound card : : (and thus have no need for pcaudio*). : : : :unknown: PNP0f13 can't assign resources : :unknown: PNP0501 can't assign resources : :unknown: PNP0700 can't assign resources : : : : This is not a bug. This is an FAQ. So much that it's actually : : documented in (*gasp!*) the FAQ: : : Actually, it is a bug. The drivers in the tree should grok these pnp : ids. Also, the bios pnp devices should be probed first rather than : last because those are hard wired pnp devices, as opposed to the ISA : PNP devices, which have the potential to be moved and can be : disabled. : : Well, yes, but that breaks console probing atm since we only support : hints-based devices for the kernel console. You'll want to fix that first. Right. Last time I tried to push changes like this through, there were some other minor obejctions that I can't recall at the moment as well. I think it was on the par of this one. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: world broken at vnode.h
On Sun, Apr 22, 2001 at 11:24:42AM -0500, Michael Harnois wrote: In file included from ../../dev/bktr/bktr_audio.c:52: ../../sys/vnode.h:571: conflicting types for `vaccess_acl_posix1e' ../../sys/vnode.h:568: previous declaration of `vaccess_acl_posix1e' ../../sys/vnode.h:571: warning: redundant redeclaration of `vaccess_acl_posix1e' in same scope ../../sys/vnode.h:568: warning: previous declaration of `vaccess_acl_posix1e' *** Error code 1 the offending lines in vnode.h are int vaccess_acl_posix1e __P((enum vtype type, struct acl *acl, mode_t acc_mode, struct ucred *cred, int *privused)); int vaccess_acl_posix1e __P((enum vtype type, uid_t file_uid, gid_t file_gid, struct acl *acl, mode_t acc_mode, struct ucred *cred, int *privused)); One suspects only one of those can be correct ... It appears so. I removed the first line and everything compiled fine. I'm not testing huge amounts of code, so YMMV: *** vnode.h Sun Apr 22 10:42:29 2001 --- vnode.h.old Sun Apr 22 10:39:18 2001 *** *** 564,569 --- 564,571 char **retfreebuf)); int vaccess __P((enum vtype type, mode_t file_mode, uid_t uid, gid_t gid, mode_t acc_mode, struct ucred *cred, int *privused)); + int vaccess_acl_posix1e __P((enum vtype type, struct acl *acl, + mode_t acc_mode, struct ucred *cred, int *privused)); int vaccess_acl_posix1e __P((enum vtype type, uid_t file_uid, gid_t file_gid, struct acl *acl, mode_t acc_mode, struct ucred *cred, int *privused)); To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Boot messages
On Tue, 24 Apr 2001 16:19:59 -0700, Dima Dorfman [EMAIL PROTECTED] said: This is not a bug. This is an FAQ. So much that it's actually documented in (*gasp!*) the FAQ: Unfortunately, the A in the FAQ is wrong. The ``can't assign resources'' messages indicate that the devices are legacy ISA devices for which a non-PnP-aware driver is compiled into the kernel. Actually, this isn't true; these drivers are for the most part PnP-aware, the problem is that the hints are processed before the PnP data, so when hints for these drivers are present, the devices instantiated by the PnP data can't get at their resources (because they're already taken). These include devices such as keyboard controllers, the programmable interrupt controller chip, and several other bits of standard infrastructure. The resources can't be assigned because there is already a driver using those addresses. The only devices which can't correctly be handled using PnP data right now are console devices, due to our need to have console support before the device subsystem is initialised. (Keyboard, mouse, video). -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] V I C T O R Y N O T V E N G E A N C E To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: [RFC] RELNOTESng for 5-CURRENT
If memory serves me right, Dima Dorfman wrote: On a slightly related note, do you object, or have plans to, build the release notes with the web site? It would solve this problem very nicely. Hi Dima-- No objections, but no plans right now either. Mostly because I don't know enough about the Web site build. Got any ideas? :-) I'm not sure if it will *solve* the problem, but at least it will allevitate it somewhat. And it's aesthetically more pleasing to me (if that counts for anything). Note that this is a fairly new capability...we currently don't have a link for -CURRENT or 4-STABLE release notes. There might be some issues with this although I can't think of any off-hand. I understand that relnotes will be in src/, so this would have to be an optional part of the build, but at least having them built on www.freebsd.org would suffice. Yeah, it should be optional. The thing-that-generates-the-Web-pages would need the src/release/ module (somewhere in its filesystem, not necessarily in /usr/src/release), plus doc/. RELNOTESng doesn't need a complete src/. Bruce. PGP signature
Re: Updated: cp -t patch (w/ commentary)
Garance A Drosihn [EMAIL PROTECTED] writes: At 10:01 AM -0400 4/25/01, John W. De Boskey wrote: I have reduced the runtime of the process so far by a solid hour. My change to cp is the lowest level/minimal change fix which allows me to maintain a O(1) time constraint. I've played with (non-freebsd) versions of xargs already, and found them (the various algorithms in xargs) to be more expensive than the patch to cp. It is inconceivable that the proposed patch to 'xargs' would increase your running time. I don't mean the standard '-I' change, which would certainly destroy performance, but the proposed patch to 'xargs' which solves your specific problem in a general way. I'm still curious as to why you think the proposed change to xargs will cause you ANY performance problem. I simply can not imagine where you would get a performance problem from the -Y idea (though I'm still tempted to change the letter for that proposed option). I think everything that should have been said in this thread already has been (so I won't repeat it), except for the performace bit. As the author of the patch, I doubt it would hinder performance. All it does is move one part of a loop further down. Instead of doing something once, it does part of that job twice. This job acts on arguments *to xargs* (i.e., argv), and is nothing more than pointer arithmetic and assignment. Unless you give umpteen arguments *to xargs*, you shouldn't notice a difference in execution speed. And as you (gad) said, implementing -I the way SUSv2 defines it would most likely kill performance (most likely it'd also slow down whether you actually use that option or not). Dimi has written one or two different patches to xargs. Did ^^^ -- should be 'a', but that's okay. :-) One patch. Thanks, Dima Dorfman [EMAIL PROTECTED] P.S. obrien: that's a very clever and unintrusive way of avoiding getting two copies of a message; much better than [EMAIL PROTECTED] Those of us (well, at least me) who actually want a copy of the message in our inbox greatly appreciate it. Thanks! To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: PATCH to make maxfiles, maxfiles per proc boot-time tunable
Alfred Perlstein wrote:
* Terry Lambert [EMAIL PROTECTED] [010424 11:59] wrote:
It seems to me that these things are not boot-time tunable, and
should be (really, they should be runtime tunable, but there
are some nasty pageable region allocations for networking that
appear to require contiguous regions for no good reason which I
can discern). That means that the best we can do right now is
boot-time, so here it is:
This looks good except that ncallout is still based on MAXFILES,
without this being fixed I think people might get bitten by
raising the tuneable too high then being unable to allocate
enough callouts. Can you take a look at this and make sure there's
nothing else using MAXFILES like that?
The problem is that param.c is *not* included in gensetdefs scope.
Therefore linker set entries (ie: SYSINIT etc) are not executed. TUNABLE*
entries in param.c are simply not called or used.
SYSTEM_OBJS= locore.o setdef0.o vnode_if.o ${OBJS} ioconf.o param.o config.o \
setdef1.o hack.So
...
setdef0.c setdef1.c setdefs.h: ${OBJS}
@gensetdefs ${OBJS}
param.o is not included in ${OBJS}. I dont see how this patch can work
as-is.
Cheers,
-Peter
--
Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]
All of this is for nothing if we don't go to the stars - JMS/B5
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Recent problems with pmap_remove_pages()
Curious if anyone else has been having problems with pmap_remove_pages() recently? In the past week or so, I've found that heavy load on my dual p3 600 testbox can usually trigger a page fault (prolly a null pointer deref of some kind) in pmap_remove_pages() called from exit1(). Just now I was doing a -j 8 world test on the dual 21164 300 alpha testbox here and it locked up just after printing warning: pmap_remove_pages called with non-current pmap to the console. Anyone else seeing this or have any ideas. Since I've had this on both alpha and x86 now, I'm somewhat inclined to think it is a problem in some MI code somewhere. If I get some more time I'll try and see if I can narrow down the commit that broke this. -- John Baldwin [EMAIL PROTECTED] -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc 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: [RFC] RELNOTESng for 5-CURRENT
Bruce A. Mah [EMAIL PROTECTED] writes: If memory serves me right, Makoto MATSUSHITA wrote: takhus Perhaps the *.TXT files could be periodically regenerated to their takhus current location to 1) avoid a POLA violation and 2) allow for at takhus least some RELNOTES without needing DocBook and doc/ (even if they takhus may be slightly out of date). [snip] Umm, no, it's not just like the current doc distribution. If you build a release with NODOC=YES, you don't get any rendition of the FAQ, Handbook, etc. There's no *.TXT files to fall back on. Here's my thoughts...for the record, I'm weakly opposed to regen-ing *.TXT versions: First, I don't want to bloat the repository with oodles of builds to the *.TXT files. If we do this, it ought to be be fairly infrequently, like maybe once or twice a month. [ snip other good reasons not to regen and commit TXT files ] I agree completely. On a slightly related note, do you object, or have plans to, build the release notes with the web site? It would solve this problem very nicely. I understand that relnotes will be in src/, so this would have to be an optional part of the build, but at least having them built on www.freebsd.org would suffice. Dima Dorfman [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: [RFC] RELNOTESng for 5-CURRENT
Sorry for late reply. bmah My first reaction is, is doing doc.1 *that* much of a problem? When bmah I was testing, it didn't seem like building this consumed much time or bmah disk space compared to the rest of the make release process (i.e. bmah building world and several kernels). A checked-out doc/ is 37 MB. It takes long to fetch all distfiles for docproj ports. Sometimes they are updated. Sometimes they can't fetch. Sometimes text/docproj can't build (we can't build textproc/jade _now_, since PATCHFILES are already outdated, its path is old, and ftp.freesoftware.com is still offline :-) speaking of textproc/jade, it's easy to fix and I've already have a patch but not yet tested). For ordinally make-build/installworld users, how many people understands that they should install textproc/docproj _only_ for making their plaintext relnotes? Most of them don't need SGML-whatever converter for other situations. If installing textproc/docproj is essential for getting all documents in src/, it should not be a port (src/contrib will be their friends); if it's not essential, a port is ok. And in my opinion, relnotes are tightly associated with src/ components just like src/UPDATING. Hmm... Maybe all of my concerns is that getting relnotes (formatting is not a problem; plaintext will be easy, but I don't argue that the only version is PDF) without having some processing/compilation (installing some ports, type 'make' command, etc). If generating relnotes are _optional_ (Makefiles don't _enforce_ us to install textproc/docproj for all machines which run make buildworld or make release), it's ok if somebody's generated version (format is not the matter; plaintext, HTML, PDF, anything) of relnotes are avaliable via ftp, web, or any protocols of the Internet at any time. -- - Makoto `MAR' MATSUSHITA P.S.: I'm totally agree with RENOTESng system. It'll help to improve the project and the quality of document itself. But please keep some rooms for lazy guys (like me) who refuses to change their style :-) To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Boot messages
On Wed, 25 Apr 2001 16:57:56 -0600, Warner Losh [EMAIL PROTECTED] said: Actually, it is a bug. The drivers in the tree should grok these pnp ids. Actually, no, it is not a bug. The FreeBSD drivers for these devices manage their resources differently from the way the Windows drivers do, and the result is not unexpected if you look closely at the dump in verbose mode. -GAWollman To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Boot messages
On Wed, 25 Apr 2001 16:57:56 -0600, Warner Losh [EMAIL PROTECTED] said: Actually, it is a bug. The drivers in the tree should grok these pnp ids. Actually, no, it is not a bug. The FreeBSD drivers for these devices manage their resources differently from the way the Windows drivers do, and the result is not unexpected if you look closely at the dump in verbose mode. I'll say this for the seventeenth time, it is a bug; it's in the way that a) hints are handled, and b) the way that the console code currently works. It's also not really dangerous, so most people ignore it. There are much bigger problems to worry about. 8) -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] V I C T O R Y N O T V E N G E A N C E To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Boot messages
In message [EMAIL PROTECTED] Garrett Wollman writes: : On Wed, 25 Apr 2001 16:57:56 -0600, Warner Losh [EMAIL PROTECTED] said: : : Actually, it is a bug. The drivers in the tree should grok these pnp : ids. : : Actually, no, it is not a bug. The FreeBSD drivers for these devices : manage their resources differently from the way the Windows drivers : do, and the result is not unexpected if you look closely at the dump : in verbose mode. Ummm, I have to disagree here. The PNP ids aren't for keyboards and the like. They are for floppy disks, serial ports and the like. The things that we already have a driver for in the tree. That's why the can't allocate messages happen. Someone else, who doesn't handle PNP stuff, has already grabbed the resource. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
4.3-RELEASE will not boot after install (boot0 ?)
Hi, I have a Dell Optiplex GXi 200Mhz machine which will not boot after installing 4.3-RELEASE. After rebooting, the normal F1 FreeBSD prompt comes up with a beep. Pressing F1 causes the machine to beep again. I believe the following code sequence is the failure location: /usr/src/sys/boot/i386/boot0/boot0.s main.15:movw $LOAD,%bx # Address for read movb $0x2,%ah # Read sector callw intx13# from disk jc main.10 # If error cmpw $MAGIC,0x1fe(%bx) # Bootable? jne main.10 # No where main.10 beeps... maybe we could have it beep twice for a read err, once for a MAGIC error.. How I got here... Sysinstall disk sequence: Expert, delete existing partition, All, Quit, BootMgr, Auto, quit, etc, etc.. The above sequence works fine and produces a bootable system on other machines. Anyways, after doing a expert install but before rebooting, I can then go to the debug shell and get the following: From df Filesystem 512-blocks UsedAvail Capacity Mounted on /dev/md0c 5607 3819 173269%/ /dev/ad0s1a 19836658206 12429232%/mnt /mnt/dev/ad0s1f1676814 1211590 33108079%/mnt/usr /mnt/dev/ad0s1e 39630 23436226 1%/mnt/var /dev/cd0c 1317216 13172160 100%/dist From dislabel -r ad0 # /dev/ad0c: type: ESDI disk: ad0s1 label: flags: bytes/sector: 512 sectors/track: 32 tracks/cylinder: 64 sectors/cylinder: 2048 cylinders: 1032 sectors/unit: 2115552 rpm: 3600 interleave: 1 trackskew: 0 cylinderskew: 0 headswitch: 0 # milliseconds track-to-track seek: 0 # milliseconds drivedata: 0 8 partitions: #size offsetfstype [fsize bsize bps/cpg] a: 20480004.2BSD 1024 819216 # (Cyl.0 - 99) b: 139376 204800 swap# (Cyl. 100 - 168*) c: 21155520unused0 0 # (Cyl.0 - 1032*) e:40960 3441764.2BSD 1024 819216 # (Cyl. 168*- 188) f: 1730416 3851364.2BSD 1024 819216 # (Cyl. 188*- 1032*) I have dumped the 1st 100 blocks of the disk. They are at: http://people.freebsd.org/~jwd/noboot/bblocks.hd (hex dump) http://people.freebsd.org/~jwd/noboot/bblocks (raw data) the output from 'fdisk ad0' is: http://people.freebsd.org/~jwd/noboot/fdisk and the dmesg for the machine: http://people.freebsd.org/~jwd/noboot/dmesg The next thing I will try is a 'dd if=/dev/zero of=/dev/ad0 count=2'. If this fixes the problem, it seems to indicate the install process has a problem with existing fdisk partition information. If someone can provide some pointers I'll try to figure what is going on. Thanks, John To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: make.conf INSTALL knob
On Wed, 25 Apr 2001, Eric D. Futch wrote: I originally sent this to freebsd-stable but didn't get any replies. It has been reworded. I ran across this while playing with the INSTALL knob in make.conf. In almost all of the Makefiles in src/ there is either -C or -c hard coded as an argument to install. This means that changes you make to the flags for install via the INSTALL knob in make.conf, specifically -c or -C are not upheld in the acutal Makefiles. /etc/default/make.conf gives the Yes they are (or should be). Some Makefiles just add more flags, as required for correct operation. impression that the flags specified when setting INSTALL should acutally be used when install is invoked. This kind of seems like a violation of POLA to me. If you set INSTALL= install -C in make.conf... most people would assume that it will apply the -C flag to every invokation of install, which is not the case. It works for me (I use INSTALL= install -C -D -D -p). There are certain directories like src/include and src/kerberos* that have -C hardcoded while others like src/etc have -c hardcoded in the Makefile. I was wonder what exactly are the rammifications of removing all -c and -C flags from the Makefile(s) where applicable and making -c the default flag for install in /etc/defaults/make.conf. Is there any specific reason why certain areas of the source need to have -c or -C? Yes. Removing -c would mainly remove source files at install time (install without -c or -C removes the source files). Removing -C would mainly make everything out of date by changing timestamps on installed headers. Additionally, I believe the INSTALL knob should be used only to allow you to change the path/name of the install binary. A new variable INSTALLFLAGS should be introduced to specify the flags for install. INSTALLFLAGS is an old variable that belongs to individual makefiles, so it can't be used in make.conf. There is little need for yet another variable, since flags can always be added to INSTALL unless they are order-dependent, and install(1) doesn't have [m]any order-dependent flags that could usefully be set in make.conf. Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
