Re: cp -d dir patch for review (or 'xargs'?)
No rain here, it is ARG_MAX - 2048: -s size Set the maximum number of bytes for the command line length pro- vided to utility. The sum of the length of the utility name and the arguments passed to utility (including NULL terminators) will be less than or equal to this number. The current default value for size is ARG_MAX - 2048. 2K would be a pretty big env, root default std is about 367 bytes. Ok, I'll stop arguing. I guess I have to agree that you can script around the problem if you're careful. FWIW, the above is really ARG_MAX - 4k (the documentation is wrong - I recently updated xargs.1 in -current) and this seems to be *exactly* the right threshold. Take a look at the commit message with that xargs.1 commit... -- Rod Grimes - KD7CAX @ CN85sl - (RWG25) [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: upgrading from 3.0 to 4.3
On Mon, Apr 23, 2001 at 01:58:05PM +0200, Mart Norman wrote: Hi! I'm trying to upgrade from 3.0 to 4.3 but make buildworld fails Why are you sending this to freebsd-current? Any hints what should i do to make buildworld successful? Do a binary upgrade; it will be much easier. Kris PGP signature
Re: cp -d dir patch for review (or 'xargs'?)
Rodney W. Grimes [EMAIL PROTECTED] wrote:
Before anyone starts writing scripts, consider that {} will be
replaced by xargs with (roughly) ARG_MAX - 10 characters worth of the
stuff coming off the pipe. If your combined arguments plus
environment exceeds ARG_MAX execve(2) will give you E2BIG.
No rain here, it is ARG_MAX - 2048:
-s size
Set the maximum number of bytes for the command line length pro-
vided to utility. The sum of the length of the utility name and
the arguments passed to utility (including NULL terminators) will
be less than or equal to this number. The current default value
for size is ARG_MAX - 2048.
2K would be a pretty big env, root default std is about 367 bytes.
Yes, that is probably not a portable assumption to make, but it is
far better than using non-standard options to xargs.
If I'm not mistaken, the size of the environment is already
taken into account by the xargs utility (subtracted from
ARG_MAX). So this isn't an issue at all.
Regards
Oliver
--
Oliver Fromme, secnetix GmbH Co KG, Oettingenstr. 2, 80538 München
Any opinions expressed in this message may be personal to the author
and may not necessarily reflect the opinions of secnetix in any way.
All that we see or seem is just a dream within a dream (E. A. Poe)
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
lockd problems
Since client side locking was implemented, I am having much trouble reading mail on an NFS-mounted mail spool. The NFS server is a Solaris 2.6 U250, and I am reading mail using mutt. When lockd is not running, mutt gets EOPNOTSUPP when trying to flock(). When lockd is running, it occasionnally gets EPERM, but not in a deterministic fashion. It also tends to leave the mailbox locked on the server even after quitting. Running lockd with debugging enabled did not show anything that looks like an abnormal condition. Anything I can do to resolve the problem? Or to help finding out what is happening? :) Thomas. -- Thomas Quinot ** Département Informatique Réseaux ** [EMAIL PROTECTED] ENST // 46 rue Barrault // 75634 PARIS CEDEX 13 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
-current kernel is broken?
Hello all, I've just made cvsup to -current and when I try to recompile my kernel I get the following error message: -c -O -pipe -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -W missing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -an si -nostdinc -I- -I. -I../.. -I../../dev -I../../../include -I../../contrib/de v/acpica/Subsystem/Include -D_KERNEL -include opt_global.h -elf -mpreferred-st ack-boundary=2 ../../fs/devfs/devfs_vnops.c In file included from ../../fs/devfs/devfs_vnops.c:45: ../../sys/mount.h:385: field `netc_rnodes' has incomplete type ../../sys/mount.h:395: `AF_MAX' undeclared here (not in a function) ../../sys/mount.h:395: size of array `ne_rtable' has non-integer type *** Error code 1 Stop in /usr/src/sys/compile/ENIA. I think it's connected with the latest kernel patches from today. Thanks, Boris Georgiev To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: -current kernel is broken?
IF you run -current you are expected to follow both this list and the cvs-all list. Your answer is there. User wrote: Hello all, I've just made cvsup to -current and when I try to recompile my kernel I get the following error message: -c -O -pipe -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -W missing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -an si -nostdinc -I- -I. -I../.. -I../../dev -I../../../include -I../../contrib/de v/acpica/Subsystem/Include -D_KERNEL -include opt_global.h -elf -mpreferred-st ack-boundary=2 ../../fs/devfs/devfs_vnops.c In file included from ../../fs/devfs/devfs_vnops.c:45: ../../sys/mount.h:385: field `netc_rnodes' has incomplete type ../../sys/mount.h:395: `AF_MAX' undeclared here (not in a function) ../../sys/mount.h:395: size of array `ne_rtable' has non-integer type *** Error code 1 Stop in /usr/src/sys/compile/ENIA. I think it's connected with the latest kernel patches from today. Thanks, Boris Georgiev To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message -- One thing they don't tell you about doing experimental physics is that sometimes you must work under adverse conditions ... like a state of sheer terror. -- W. K. Hartmann Do YOU Yahoo!? To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: One more typo in src/release/Makefile, rev 1.612? (w/patch)
On 22-Apr-01 David O'Brien wrote: On Mon, Apr 16, 2001 at 08:10:39PM -0700, John Baldwin wrote: Also, Bruce's fix is not entirely correct as it breaks for the non-debug kernel case, but I've already sent you a mail about that, just to let everyone know that it should be fixed shortly. :) I commited your fix for it. IMHO, it is cleaner before my commit and thus what it should be -- the release system should match what is known about the world. If someone has the need to disable debug kernels, they have the knowledge to edit src/release/Makefile... never the less, I committed what you desired. The idea is so that the release doesn't have to know. The same Makefile works in both environments. That way, when we do an actual release, we only have to commit changes to the kernel config files, we don't have to hack the release Makefile as well. -- 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
Updated: cp -t patch (w/ commentary)
Hello, After some feedback, I have changed the patch slightly. Rename -d to -t and remove the requirement for the option to have a value. -t aquire the target from *argv++ instead of argv[argc--] The patch can be found at: http://people.freebsd.org/~jwd/cp-t.patch Some comments: -t was chosen to help match the existing (and be co-existant with) gnu cp option--target-directory=DIRECTORY I have seen many proposals posted with respect to why don't you do it this way? Bascally, they don't do the same thing. cat BigFileList | xargs cp -t targetdir where cat BigFileList is actually a seperate and complex process that I do not own/support. The list of files given to the process spans many subtrees and mount points. The goal is to bring a copy of those files into a single directory. Tar, cpio, and other file copy processes copy hierarchies. Cp is the only program which allows for a simple yet elegant way of transferring files from disparate locations to a single location. cp -s allows for a very simple yet highly effective method of doing what needs to be done. Yes, I am also willing to update mv to work the same way. -John ps: As a humorous aside with respect to standards. I thought FreeBSD set the standard! :-) To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
kernel compile errors
I just received this error in the kernel compile in /usr/home/src/sys/modules/linux. My CVS tree was updated immediately before kernel compile (approx. 2:45pm CST). cc -O -pipe -D_KERNEL -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -ansi -DKLD_MODULE -nostdinc -I- -I. -I@ -I@/dev -I@/../include -mpreferred-stack-boundary=2 -c /usr/home/src/sys/modules/linux/../../compat/linux/linux_file.c In file included from /usr/home/src/sys/modules/linux/../../compat/linux/linux_file.c:43: @/sys/mount.h:385: field `netc_rnodes' has incomplete type @/sys/mount.h:395: `AF_MAX' undeclared here (not in a function) @/sys/mount.h:395: size of array `ne_rtable' has non-integer type /usr/home/src/sys/modules/linux/../../compat/linux/linux_file.c: In function `linux_mount': /usr/home/src/sys/modules/linux/../../compat/linux/linux_file.c:963: warning: passing arg 2 of `vfs_mount' discards qualifiers from pointer target type *** Error code 1 Stop in /usr/home/src/sys/modules/linux. *** Error code 1 Stop in /usr/home/src/sys/modules. *** Error code 1 --- /**/ /* Hidden Agenda */ /*[EMAIL PROTECTED]*/ /* DoK, Intl. */ /* Ignotum per Ignotius */ /**/ PGP signature
Re: kernel core
In message [EMAIL PROTECTED] John Baldwin writes: : You need to rebuild fsck and install it and fsck your filesystems. This is the : dirpref changes biting you. Warner, we probably need an entry in UPDATING for : the dirpref changes that warn people to build and install a new fsck before : booting a dirpref kernel. We problably need to fix fsck/kernel to not lose. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: kernel core
In message [EMAIL PROTECTED] Mike Smith writes: : I assume there's a better fix in the works, so that a dirpref-touched : disk can be moved back to a pre-dirpref system? If not, then dirpref should be backed out, imho. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: kernel core
In message 03cb01c0cb0b$ce9369a0$[EMAIL PROTECTED] Chris Knight writes: : I've found the following sequence to be optimal from going from : pre-dirpref -current to post-dirpref -current and 4-stable to -current: But that won't work going from a pre-dirpref -stable to a post-dirpref -currnet because installworld will populate binaries that may not run with a -stable keernl. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
fsdb broken in -current
The last set of changes to fsck_ffs moved the initialisation of dev_bsize to sblock_init(), but this is not called by fsdb(8) so fsdb dies almost immediately with a floating exception. I'm just going to commit the obvious fix, which is to have fsdb call sblock_init() also. Ian To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
duplicate locks and lock order reversal
hello, world\n my current kernel cvsupped around Apr 14th tells me about duplicate locks and lock order reversal. Is this reason to worry? ... Apr 23 22:23:09 hal9000 /boot/kernel/kernel: da0 at ahc0 bus 0 target 2 lun 0 Apr 23 22:23:10 hal9000 /boot/kernel/kernel: da0: IBM DCAS-34330 S65A Fixed Direct Access SCSI-2 device Apr 23 22:23:10 hal9000 /boot/kernel/kernel: da0: 20.000MB/s transfers (20.000MHz, offset 15) Apr 23 22:23:10 hal9000 /boot/kernel/kernel: da0: 4134MB (8467200 512 byte sectors: 255H 63S/T 527C) Apr 23 22:23:10 hal9000 /boot/kernel/kernel: acquring duplicate lock of same type: allproc Apr 23 22:23:10 hal9000 /boot/kernel/kernel: 1st @ /usr/src/sys/kern/kern_proc.c:584 Apr 23 22:23:10 hal9000 /boot/kernel/kernel: 2nd @ /usr/src/sys/kern/kern_proc.c:143 Apr 23 22:23:10 hal9000 /boot/kernel/kernel: lock order reversal Apr 23 22:23:10 hal9000 /boot/kernel/kernel: 1st vnode interlock last acquired @ /usr/src/sys/kern/vfs_vnops.c:625 Apr 23 22:23:10 hal9000 /boot/kernel/kernel: 2nd 0xc03c0120 mntvnode @ /usr/src/sys/ufs/ffs/ffs_vfsops.c:967 Apr 23 22:23:10 hal9000 /boot/kernel/kernel: 3rd 0xc8f68eac vnode interlock @ /usr/src/sys/ufs/ffs/ffs_vfsops.c:976 Apr 23 22:23:10 hal9000 lpd[315]: lpd startup: logging=0 Apr 23 22:24:08 hal9000 /boot/kernel/kernel: cd0 at ahc0 bus 0 target 3 lun 0 Apr 23 22:24:08 hal9000 /boot/kernel/kernel: cd0: YAMAHA CRW6416S 1.0b Removable CD-ROM SCSI-2 device Apr 23 22:24:08 hal9000 /boot/kernel/kernel: cd0: 10.000MB/s transfers (10.000MHz, offset 15) Apr 23 22:24:08 hal9000 /boot/kernel/kernel: cd0: Attempt to query device size failed: NOT READY, Medium not present - tray closed Apr 23 22:26:44 hal9000 /boot/kernel/kernel: i4b: unit 0, assigned TEI = 126 = 0x7e Apr 23 22:27:08 hal9000 /boot/kernel/kernel: [agree] Regards, Jens -- Jens Schweikhardt http://www.schweikhardt.net/ SIGSIG -- signature too long (core dumped) To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: kernel core
In message [EMAIL PROTECTED] Mike Smith writes: : I assume there's a better fix in the works, so that a dirpref-touched : disk can be moved back to a pre-dirpref system? If not, then dirpref should be backed out, imho. I'd have to agree; this was a pretty poorly-thought-out aspect of the change. -- ... 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: upgrading from 3.0 to 4.3
On Mon, 23 Apr 2001, Mart Norman wrote: Hi! I'm trying to upgrade from 3.0 to 4.3 but make buildworld fails cc -O -pipe -I. -I/usr/src/usr.sbin/config -Wall -Wunused -Wmissing-prototypes -Wredundant-decls -I/usr/obj/usr/src/i386/usr/include -static -o config config.o main.o lang.o mkioconf.o mkmakefile.o mkheaders.o mkoptions.o -ll main.o: In function `main': main.o(.text+0x12a): undefined reference to `strlcpy' main.o(.text+0x234): undefined reference to `strlcpy' main.o(.text+0x249): undefined reference to `strlcat' mkoptions.o: In function `tooption': mkoptions.o(.text+0x540): undefined reference to `strlcpy' mkoptions.o(.text+0x573): undefined reference to `strlcpy' mkoptions.o(.text+0x59e): undefined reference to `strlcpy' *** Error code 1 Stop. Someone broke buildworld by putting `config' in bootstrap-tools although `config' is not portable enough to be put there. my /etc/make.conf looks like this: USA_RESIDENT=NO CFLAGS= -O -pipe NOPROFILE= true NO_OPENSSH=true# do not build OpenSSH NO_OPENSSL=true# do not build OpenSSL (implies NO_OPENSSH) Any hints what should i do to make buildworld successful? Start by deleting usr.sbin/config from bootstrap-tools. You won't be able to build any kernels until the new world is installed, and this may cause further problems. Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: fsdb broken in -current
To: Kirk McKusick [EMAIL PROTECTED] cc: [EMAIL PROTECTED] Subject: fsdb broken in -current Date: Mon, 23 Apr 2001 22:23:48 +0100 From: Ian Dowse [EMAIL PROTECTED] The last set of changes to fsck_ffs moved the initialisation of dev_bsize to sblock_init(), but this is not called by fsdb(8) so fsdb dies almost immediately with a floating exception. I'm just going to commit the obvious fix, which is to have fsdb call sblock_init() also. Ian Right you are. Sorry I missed that. It did not occur to me to verify fsdb. Kirk To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: kernel core
On 23-Apr-01 Warner Losh wrote: In message [EMAIL PROTECTED] John Baldwin writes: : You need to rebuild fsck and install it and fsck your filesystems. This is : the : dirpref changes biting you. Warner, we probably need an entry in UPDATING : for : the dirpref changes that warn people to build and install a new fsck before : booting a dirpref kernel. We problably need to fix fsck/kernel to not lose. Yes, but until such time as we do that we should warn people in UPDATING at least. 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: kernel core
In message [EMAIL PROTECTED] John Baldwin writes: : : On 23-Apr-01 Warner Losh wrote: : In message [EMAIL PROTECTED] John Baldwin writes: : : You need to rebuild fsck and install it and fsck your filesystems. This is : : the : : dirpref changes biting you. Warner, we probably need an entry in UPDATING : : for : : the dirpref changes that warn people to build and install a new fsck before : : booting a dirpref kernel. : : We problably need to fix fsck/kernel to not lose. : : Yes, but until such time as we do that we should warn people in UPDATING at : least. : OK, but you won't like the UPDATING entry. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
RE: duplicate locks and lock order reversal
On 23-Apr-01 Jens Schweikhardt wrote: hello, world\n my current kernel cvsupped around Apr 14th tells me about duplicate locks and lock order reversal. Is this reason to worry? ... Apr 23 22:23:09 hal9000 /boot/kernel/kernel: da0 at ahc0 bus 0 target 2 lun 0 Apr 23 22:23:10 hal9000 /boot/kernel/kernel: da0: IBM DCAS-34330 S65A Fixed Direct Access SCSI-2 device Apr 23 22:23:10 hal9000 /boot/kernel/kernel: da0: 20.000MB/s transfers (20.000MHz, offset 15) Apr 23 22:23:10 hal9000 /boot/kernel/kernel: da0: 4134MB (8467200 512 byte sectors: 255H 63S/T 527C) Apr 23 22:23:10 hal9000 /boot/kernel/kernel: acquring duplicate lock of same type: allproc Apr 23 22:23:10 hal9000 /boot/kernel/kernel: 1st @ /usr/src/sys/kern/kern_proc.c:584 Apr 23 22:23:10 hal9000 /boot/kernel/kernel: 2nd @ /usr/src/sys/kern/kern_proc.c:143 Apr 23 22:23:10 hal9000 /boot/kernel/kernel: lock order reversal Apr 23 22:23:10 hal9000 /boot/kernel/kernel: 1st vnode interlock last acquired @ /usr/src/sys/kern/vfs_vnops.c:625 Apr 23 22:23:10 hal9000 /boot/kernel/kernel: 2nd 0xc03c0120 mntvnode @ /usr/src/sys/ufs/ffs/ffs_vfsops.c:967 Apr 23 22:23:10 hal9000 /boot/kernel/kernel: 3rd 0xc8f68eac vnode interlock @ /usr/src/sys/ufs/ffs/ffs_vfsops.c:976 Apr 23 22:23:10 hal9000 lpd[315]: lpd startup: logging=0 Apr 23 22:24:08 hal9000 /boot/kernel/kernel: cd0 at ahc0 bus 0 target 3 lun 0 Apr 23 22:24:08 hal9000 /boot/kernel/kernel: cd0: YAMAHA CRW6416S 1.0b Removable CD-ROM SCSI-2 device Apr 23 22:24:08 hal9000 /boot/kernel/kernel: cd0: 10.000MB/s transfers (10.000MHz, offset 15) Apr 23 22:24:08 hal9000 /boot/kernel/kernel: cd0: Attempt to query device size failed: NOT READY, Medium not present - tray closed Apr 23 22:26:44 hal9000 /boot/kernel/kernel: i4b: unit 0, assigned TEI = 126 = 0x7e Apr 23 22:27:08 hal9000 /boot/kernel/kernel: [agree] This is a FAQ. Please keep up with -current if you are tracking it. These are known and not a problem right now. The VFS reversals have been around for a long time unfortunately, and the allproc warning is due to witness still needing some work to better handle recursing on sx locks. -- 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: kernel core
On 23-Apr-01 Warner Losh wrote: In message [EMAIL PROTECTED] John Baldwin writes: : : On 23-Apr-01 Warner Losh wrote: : In message [EMAIL PROTECTED] John Baldwin writes: : : You need to rebuild fsck and install it and fsck your filesystems. This : : is : : the : : dirpref changes biting you. Warner, we probably need an entry in : : UPDATING : : for : : the dirpref changes that warn people to build and install a new fsck : : before : : booting a dirpref kernel. : : We problably need to fix fsck/kernel to not lose. : : Yes, but until such time as we do that we should warn people in UPDATING at : least. : OK, but you won't like the UPDATING entry. I didn't do dirpref and I want to see this fixed as well. :( I just want to give people a fighting chance of making it past this change. 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: kernel core
In message [EMAIL PROTECTED] John Baldwin writes: : Yes, but until such time as we do that we should warn people in UPDATING at : least. 20010411: fsck and the kernel were changed to handle some optimizations to directory layout. This breaks backward compatbility. Update only if you understand that you must not use the old fsck with the new kernel ever. Explicit instructions for doing so not provided to a) encourage people to fix the problem and b) encournage the less technically competent to not update past this point. There are also problems using the dirpref updated disks on old kernels, so you have been warned. Is going in shortly. Typos/corrections to me by the end of the day. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: kernel core
In message [EMAIL PROTECTED], Warner Losh writes: : : Yes, but until such time as we do that we should warn people in UPDATING at : least. : OK, but you won't like the UPDATING entry. The bug actually looks fairly simple to fix. ffs_reload() isn't checking if the new superblock fields are zero, so if an old fsck zeros them out between a read-oly mount and a read-write remount, then we get a division by zero or something later. Ian To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: kernel core
In message [EMAIL PROTECTED] John Baldwin writes: : I didn't do dirpref and I want to see this fixed as well. :( I just want to : give people a fighting chance of making it past this change. Ah. Sorry for directing my grumpiness about the quality of the change against you. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: upgrading from 3.0 to 4.3
Bruce Evans wrote: On Mon, 23 Apr 2001, Mart Norman wrote: Hi! I'm trying to upgrade from 3.0 to 4.3 but make buildworld fails cc -O -pipe -I. -I/usr/src/usr.sbin/config -Wall -Wunused -Wmissing-prototypes -Wredundant-decls -I/usr/obj/usr/src/i386/usr/include -static -o config config.o main.o lang.o mkioconf.o mkmakefile.o mkheaders.o mkoptions.o -ll main.o: In function `main': main.o(.text+0x12a): undefined reference to `strlcpy' main.o(.text+0x234): undefined reference to `strlcpy' main.o(.text+0x249): undefined reference to `strlcat' mkoptions.o: In function `tooption': mkoptions.o(.text+0x540): undefined reference to `strlcpy' mkoptions.o(.text+0x573): undefined reference to `strlcpy' mkoptions.o(.text+0x59e): undefined reference to `strlcpy' *** Error code 1 Stop. Someone broke buildworld by putting `config' in bootstrap-tools although `config' is not portable enough to be put there. I have been tempted to work around this, but when I had the same task (ie: upgrade 3.0-CURRENT from Dec 98 - 4.2-stable) I discovered that there is a lot more that is broken. my /etc/make.conf looks like this: USA_RESIDENT=NO CFLAGS= -O -pipe NOPROFILE= true NO_OPENSSH=true# do not build OpenSSH NO_OPENSSL=true# do not build OpenSSL (implies NO_OPENSSH) Any hints what should i do to make buildworld successful? Start by deleting usr.sbin/config from bootstrap-tools. You won't be able to build any kernels until the new world is installed, and this may cause further problems. Dont forget -DNO_PERL. 'installworld' will destroy your system as just about every single application will fail with a SIGSYS due to signal calls. I got around this by building a kernel elsewhere (basically a slightly stripped GENERIC), booting that, and then doing something like: make -k buildworld; make -k installworld, then repeating. I think the only path that we officially support is 3.x - 3.4-stable - 4.0-R - 4.x-stable. If one has a lot of persistance (and patience) anything can be done. I did 3.0-CURRENT - 4.2-RC on a very very slow link (2000ms+ ping times) to a remote corner on the other side of the planet, on a slow machine (486), no serial console, no remote power and 12-hour turnaround if somebody needed to physically. I think the only reason I survived was because I run a 4.2-RC kernel with the 3.0-current userland for the duration of the build. Bruce 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
Re[2]: world is broken?
Hello Kris, Monday, April 23, 2001, 2:50:48 AM, you wrote: 'make buildworld' fails with the following symptoms: === usr.sbin/rpc.lockd [skipped] Stop in /garbage/src/usr.sbin/rpc.lockd. *** Error code 1 KK Looks like you're building with -j, no, i read about potential problems with -j in a mailing list, so i built my 'world' without this option. KK and haven't actually included the command which gave the error (which may be some way back in the KK make(1) output). Rebuild without -j and post the real error :-) /usr/src # cd /usr/src/usr.sbin/rpc.lockd/ /usr/src/usr.sbin/rpc.lockd # make 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. of course, the source tree is up to date. -- Best regards, Ilyamailto:[EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: kernel core
On 23-Apr-01 Ian Dowse wrote: In message [EMAIL PROTECTED], Warner Losh writes: : : Yes, but until such time as we do that we should warn people in UPDATING at : least. : OK, but you won't like the UPDATING entry. The bug actually looks fairly simple to fix. ffs_reload() isn't checking if the new superblock fields are zero, so if an old fsck zeros them out between a read-oly mount and a read-write remount, then we get a division by zero or something later. Fair enough, I guess ffs_reload() should just sanity check the values. Any takers? Ian -- 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: kernel core
In message [EMAIL PROTECTED], John Baldwin writes: Fair enough, I guess ffs_reload() should just sanity check the values. Any takers? You could try this (untested). I have to run now, but I can test it later as it's easy enough to reproduce. Ian Index: ffs_vfsops.c === RCS file: /dump/FreeBSD-CVS/src/sys/ufs/ffs/ffs_vfsops.c,v retrieving revision 1.146 diff -u -r1.146 ffs_vfsops.c --- ffs_vfsops.c2001/04/17 05:37:51 1.146 +++ ffs_vfsops.c2001/04/23 22:15:55 @@ -427,6 +427,11 @@ brelse(bp); mp-mnt_maxsymlinklen = fs-fs_maxsymlinklen; ffs_oldfscompat(fs); + /* An old fsck may have clobbered these fields, so recheck them. */ + if (fs-fs_avgfilesize = 0)/* XXX */ + fs-fs_avgfilesize = AVFILESIZ; /* XXX */ + if (fs-fs_avgfpdir = 0) /* XXX */ + fs-fs_avgfpdir = AFPDIR; /* XXX */ /* * Step 3: re-read summary information from disk. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: cp -d dir patch for review (or 'xargs'?)
Rodney W. Grimes [EMAIL PROTECTED] wrote:
Before anyone starts writing scripts, consider that {} will be
replaced by xargs with (roughly) ARG_MAX - 10 characters worth of the
stuff coming off the pipe. If your combined arguments plus
environment exceeds ARG_MAX execve(2) will give you E2BIG.
No rain here, it is ARG_MAX - 2048:
-s size
Set the maximum number of bytes for the command line length pro-
vided to utility. The sum of the length of the utility name and
the arguments passed to utility (including NULL terminators) will
be less than or equal to this number. The current default value
for size is ARG_MAX - 2048.
2K would be a pretty big env, root default std is about 367 bytes.
Yes, that is probably not a portable assumption to make, but it is
far better than using non-standard options to xargs.
If I'm not mistaken, the size of the environment is already
taken into account by the xargs utility (subtracted from
ARG_MAX). So this isn't an issue at all.
Unless xargs runs a command with lots of arguments and that command
increases the environment size then tries to run another command with
the same arguments - bang (E2BIG).
Regards
Oliver
--
Oliver Fromme, secnetix GmbH Co KG, Oettingenstr. 2, 80538 München
Any opinions expressed in this message may be personal to the author
and may not necessarily reflect the opinions of secnetix in any way.
All that we see or seem is just a dream within a dream (E. A. Poe)
--
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: kernel core
In message [EMAIL PROTECTED], Ian Dowse writes: You could try this (untested). I have to run now, but I can test it later as it's easy enough to reproduce. Almost, but I missed the fs_contigdirs field, which was the real culprit. An updated patch is below; this seems to stop the panics for me. I'll just run this by Kirk first, and commit it if he has no objections. There probably does need to be something in UPDATING saying that after the dirpref changes have been used, running a pre-dirpref version of fsck may generate some serious-looking warnings that are actually harmless. I think some people were seeing: VALUES IN SUPER BLOCK DISAGREE WITH THOSE IN FIRST ALTERNATE Is that correct? And was a fsck -b 32 /dev/xxx required to fix it or did fsck correct the problem itself? Ian Index: ffs_vfsops.c === RCS file: /dump/FreeBSD-CVS/src/sys/ufs/ffs/ffs_vfsops.c,v retrieving revision 1.146 diff -u -r1.146 ffs_vfsops.c --- ffs_vfsops.c2001/04/17 05:37:51 1.146 +++ ffs_vfsops.c2001/04/23 23:37:14 @@ -421,12 +421,18 @@ */ newfs-fs_csp = fs-fs_csp; newfs-fs_maxcluster = fs-fs_maxcluster; + newfs-fs_contigdirs = fs-fs_contigdirs; bcopy(newfs, fs, (u_int)fs-fs_sbsize); if (fs-fs_sbsize SBSIZE) bp-b_flags |= B_INVAL | B_NOCACHE; brelse(bp); mp-mnt_maxsymlinklen = fs-fs_maxsymlinklen; ffs_oldfscompat(fs); + /* An old fsck may have zeroed these fields, so recheck them. */ + if (fs-fs_avgfilesize = 0)/* XXX */ + fs-fs_avgfilesize = AVFILESIZ; /* XXX */ + if (fs-fs_avgfpdir = 0) /* XXX */ + fs-fs_avgfpdir = AFPDIR; /* XXX */ /* * Step 3: re-read summary information from disk. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: kernel core
On Mon, 23 Apr 2001, Ian Dowse wrote: In message [EMAIL PROTECTED], John Baldwin writes: Fair enough, I guess ffs_reload() should just sanity check the values. Any takers? You could try this (untested). I have to run now, but I can test it later as it's easy enough to reproduce. Ian Index: ffs_vfsops.c === RCS file: /dump/FreeBSD-CVS/src/sys/ufs/ffs/ffs_vfsops.c,v retrieving revision 1.146 diff -u -r1.146 ffs_vfsops.c --- ffs_vfsops.c 2001/04/17 05:37:51 1.146 +++ ffs_vfsops.c 2001/04/23 22:15:55 @@ -427,6 +427,11 @@ brelse(bp); mp-mnt_maxsymlinklen = fs-fs_maxsymlinklen; ffs_oldfscompat(fs); + /* An old fsck may have clobbered these fields, so recheck them. */ + if (fs-fs_avgfilesize = 0)/* XXX */ + fs-fs_avgfilesize = AVFILESIZ; /* XXX */ + if (fs-fs_avgfpdir = 0) /* XXX */ + fs-fs_avgfpdir = AFPDIR; /* XXX */ /* * Step 3: re-read summary information from disk. I think this and the corresponding code in ffs_mountfs() should be in ffs_oldfscompat(), or at least in a common routine. We need to do some fixups for old filesystems, and the present problem shows that a filesystem may become old again after the initial mount makes it new. Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
how can I increase freevnodes?
Hello, How can I increase free vnodes? kernel very often falls with message 'no free vnode'. Right now after reboot numbers of vnodes are: 9913 desiredvnodes 556 numvnodes 25 freevnodes -- bye Juriy Goloveshkin To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
vm_mtx
You can find the work I've done so far to make a giant vm mutex here: http://people.freebsd.org/~alfred/vm.diff It doesn't work (of course :)) it dies really early in the intialization when a vm_page is manipulated without the lock. It dies before it even gets to calibrating the clocks. I've been spending quite some time trying to get the higher level code to work and wanted to toss this diff out so that hopefully someone else (*nudge* John) might be able to get it further along. here's my notes: requires vm_page_queues_mtx: manipulation of vm_page_queues vm_add_new_page() asserts vm_page_io_start/finish vm_page_wakeup vm_page_busy vm_page_flash vm_page_flag_clear vm_page_flag_set vm_page_cache vm_page_free vm_page_free_zero vm_object_page_clean mtx_assert(vm_mtx, MA_OWNED); 283 vm_page_rename vm_page_insert vm_object_shadow - lock held from vm_map_lookup() vm_object.c line 912 of 1 pmap_kenter needs to aquire some mutex on it's own because of its use in the zone allocator looks like zone allocator might have to recurse on vm_mtx, looks like zone allocator might have to go under vm_mtx or some trickery will be required when using zones as to avoid it vm_object_terminate vm_object_collapse zone allocator should probably do something like test the state of the vm lock, and lock it if not locked same for kmem_alloc/free holding vm_mtx over copyout? should we do it? probably not, but for small copyouts this can kill perf to lock/release need work: get/putpages routines need to lock vm_mtx pmaps spotted: pmap_copy_page pmap_page_protect pmap_resident_count pmap_enter pmap_pageable get the lock themselves if needed: pmap_kenter pmap_qenter pmap_qremove blist_destroy (calls free) blist_create (calls malloc M_WAITOK) prolly called from a safe spot exec_new_vmspace swap_pager_strategy done: unlock_map vm_map_lookup_done _vm_object_allocate (memcache candidate) blist_free pagedaemon_wakeup flushchainbuf with, switches to Giant getchainbuf without waitchainbuf with/without swap_pager_copy swap_pager_freespace swapout_procs (blocks) (holds locks over schedlock) swp_pager_freeswapspace swp_pager_meta_build requires swp_pager_meta_ctl requires swp_pager_meta_free requires swp_pager_meta_free_all requires swp_sizecheck vm_daemon vm_fault_additional_pages vm_freeze_copyopts (vm_pager_get_pages, pmap_copy_page) vm_map_entry_create (zalloc) vm_map_entry_delete vm_map_entry_dispose (calls zfree) vm_map_entry_link vm_map_entry_unlink vm_map_insert (pmap_object_init_pt) vm_map_lock* vm_map_lookup vm_map_lookup_entry vm_map_simplify_entry vm_map_unlock* vm_object_allocate (x: unlocks for zalloc) vm_object_backing_scan vm_object_coalesce vm_object_collapse (calls zfree) vm_object_deallocate vm_object_page_clean vm_object_page_remove vm_object_pip_wakeup vm_object_qcollapse vm_object_reference vm_object_shadow vm_object_terminate (blocks) (zfree) vm_object_vndeallocate (blocks) vm_page_activate vm_page_alloc vm_page_busy vm_page_copy (calls pmap_copy_page(), maybe unwind the lock?) vm_page_deactivate vm_page_dirty vm_page_flag_clear vm_page_flag_set vm_page_flash vm_page_free vm_page_free_zero vm_page_grab (blocks) vm_page_hold vm_page_insert vm_page_io_finish vm_page_io_start vm_page_list_find vm_page_lookup vm_page_protect vm_page_protect vm_page_protect (calls pmap_page_protect) vm_page_remove vm_page_rename vm_page_sleep_busy vm_page_undirty vm_page_unhold vm_page_unqueue vm_page_wakeup vm_page_zero_fill (calls pmap_zero_page(), maybe unwind the lock?) vm_pageout_map_deactivate_pages (pmap_resident_count,pmap_remove) vm_pageout_object_deactivate_pages (pmap_resident_count,pmap_ts_referenced,pmap_page_exists vm_pager_get_pages (probably blocks, must check getpages routines for pagers) vm_pager_page_unswapped (pager pgo_pageunswapped routine) vm_pager_has_page (calls pager pgo_haspage) vm_req_vmdaemon needs vm lock: vfs_buf_test_cache requires inmem requires vfs_vmio_release with, but releases! vfs_clean_pages with vm_hold_load_pages without, aquires vm_hold_free_pages with/without, aquires vfs_busy_pages without, aquires vfs_unbusy_pages without, aquires vfs_setdirty with/without, aquires bfreekva with/without, aquires brelse without, aquires bqrelse without, noaquire gbincore without, noaquire incore without, noaquire inmem without, aquires bufdone without, aquires geteblk doesn't lock check stats, needs lock? vmmeter.h: vm_page_count_severe vm_page_count_reserved vm_page_count_min vm_page_count_target vm_paging_target vm_paging_needed -- -Alfred Perlstein - [[EMAIL PROTECTED]] http://www.egr.unlv.edu/~slumos/on-netbsd.html To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: upgrading from 3.0 to 4.3
On Mon, 23 Apr 2001, Peter Wemm wrote: Bruce Evans wrote: On Mon, 23 Apr 2001, Mart Norman wrote: Any hints what should i do to make buildworld successful? Start by deleting usr.sbin/config from bootstrap-tools. You won't be able to build any kernels until the new world is installed, and this may cause further problems. Dont forget -DNO_PERL. 'installworld' will destroy your system as just about every single application will fail with a SIGSYS due to signal calls. Hmm. It's really a bug to build the new libraries with the new system headers until a new kernel is installed. The new systems headers really belong to the new kernel, not to the library. However, the library probably depends on new features in them... I got around this by building a kernel elsewhere (basically a slightly stripped GENERIC), booting that, and then doing something like: make -k buildworld; make -k installworld, then repeating. This shows that building and running a new kernel first is more likely to be right than building a new world first. Therefore, it is important for tools needed to build the new kernel to be portable. config is much simpler than it used to be and could easily be portable. Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
