if_ed, mii and no PCI?
Hi Just got round to rebuilding a -current kernel on a Libretto 50 with no PCI bus. make depend in sys/compile/WANDERER dies on: In file included from ../../dev/mii/dcphy.c:67: ../../dev/pci/pcivar.h:156: pci_if.h: No such file or directory Do I really need to add PCI... Duncan --- Duncan Barclay | God smiles upon the little children, [EMAIL PROTECTED] | the alcoholics, and the permanently stoned. [EMAIL PROTECTED]| Steven King To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: secure/lib/libcrypto: "make -jX buildworld" fix
On Tue, Mar 06, 2001 at 05:07:40PM +0900, Makoto MATSUSHITA wrote: > If there is no mean to create *.pl.s, how about using a pipe to pass > an assembler code to as(1) ? Sounds reasonable: I'll take a look. Kris PGP signature
Re: **HEADS UP** essential setlocale(3) fix
On Fri, Mar 02, 2001 at 08:58:54PM +0300, Andrey A. Chernov wrote: > On Fri, Mar 02, 2001 at 18:05:54 +0200, Ruslan Ermilov wrote: > > On Fri, Mar 02, 2001 at 06:00:25PM +0300, Andrey A. Chernov wrote: > > > On Fri, Mar 02, 2001 at 15:42:27 +0200, Ruslan Ermilov wrote: > > > > I am not checking src/ to see what other fixes are required. > > > > The typical fix will be "LC_TIME=C date" -> "LC_ALL=C date", > > > > probably preserving the "LC_TIME=C" setting so that the > > > > upgrade path from the old system isn't broken. > > > > > > I don't think it worth to preserve LC_TIME=C, those parts are not critical > > > > > Hmm, some parts are critical. For example, sys/conf/newvers.sh. > > And what critical happens in worst scenario? > Nothing critical, ``uname -v'' outputs date in LC_TIME locale :-) 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
typo in /usr/src/sys/sys/sx.h
There's a small typo in /usr/src/sys/sys/sx.h which causes kernel builds to break unless INVARIANTS is defined. Patch below against version 1.2 of the file. Nick --- /usr/src/sys/sys/sx.h.orig Tue Mar 6 10:57:31 2001 +++ /usr/src/sys/sys/sx.h Tue Mar 6 10:57:38 2001 @@ -78,7 +78,7 @@ #else /* INVARIANTS */ #defineSX_ASSERT_SLOCKED(sx) -#defineSX_ASSERT_XLOCKER(sx) +#defineSX_ASSERT_XLOCKED(sx) #endif /* INVARIANTS */ #endif /* _KERNEL */ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: if_ed, mii and no PCI?
Duncan Barclay wrote: > Hi > > Just got round to rebuilding a -current kernel on a Libretto 50 with no PCI bus. > make depend in sys/compile/WANDERER dies on: > In file included from ../../dev/mii/dcphy.c:67: > ../../dev/pci/pcivar.h:156: pci_if.h: No such file or directory > > Do I really need to add PCI... It is sideefect of the following commit (yes, I agree with you that mandatory device pci it is bogus and IMO should be fixed). -Maxim imp 2001/03/03 00:31:37 PST Modified files: sys/modules/ed Makefile sys/dev/ed if_ed.c if_ed_pccard.c if_ed_pci.c if_edreg.h if_edvar.h sys/i386/confGENERIC NEWCARD Log: Add support for Dlink DL10022 to the ed driver. This is a mii part bolted to a ne-2000 chip. This is necessary for the NetGear FA-410TX and other cards. This also requires you add mii to your kernel if you have an ed driver configured. This code will result in a couple of timeout messages for ed on the impacted cards. Additional work will be needed, but this does work right now, and many people need these cards. Submitted by: Ian Dowse <[EMAIL PROTECTED]> Revision ChangesPath 1.5 +2 -2 src/sys/modules/ed/Makefile 1.200 +145 -1src/sys/dev/ed/if_ed.c 1.29 +95 -1 src/sys/dev/ed/if_ed_pccard.c 1.28 +2 -1 src/sys/dev/ed/if_ed_pci.c 1.30 +30 -1 src/sys/dev/ed/if_edreg.h 1.12 +10 -1 src/sys/dev/ed/if_edvar.h 1.303 +2 -1 src/sys/i386/conf/GENERIC 1.40 +19 -10src/sys/i386/conf/NEWCARD To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: if_ed, mii and no PCI?
Maxim Sobolev wrote: > Duncan Barclay wrote: > > > Hi > > > > Just got round to rebuilding a -current kernel on a Libretto 50 with no PCI bus. > > make depend in sys/compile/WANDERER dies on: > > In file included from ../../dev/mii/dcphy.c:67: > > ../../dev/pci/pcivar.h:156: pci_if.h: No such file or directory > > > > Do I really need to add PCI... > > It is sideefect of the following commit (yes, I agree with you that mandatory device > pci it is bogus and IMO should be fixed). Fixed: Checking in files; /home/ncvs/src/sys/conf/files,v <-- files new revision: 1.493; previous revision: 1.492 > -Maxim > > imp 2001/03/03 00:31:37 PST > > Modified files: > sys/modules/ed Makefile > sys/dev/ed if_ed.c if_ed_pccard.c if_ed_pci.c > if_edreg.h if_edvar.h > sys/i386/confGENERIC NEWCARD > Log: > Add support for Dlink DL10022 to the ed driver. This is a mii part > bolted to a ne-2000 chip. This is necessary for the NetGear FA-410TX > and other cards. > > This also requires you add mii to your kernel if you have an ed driver > configured. > > This code will result in a couple of timeout messages for ed on the > impacted cards. Additional work will be needed, but this does work > right now, and many people need these cards. > > Submitted by: Ian Dowse <[EMAIL PROTECTED]> > > Revision ChangesPath > 1.5 +2 -2 src/sys/modules/ed/Makefile > 1.200 +145 -1src/sys/dev/ed/if_ed.c > 1.29 +95 -1 src/sys/dev/ed/if_ed_pccard.c > 1.28 +2 -1 src/sys/dev/ed/if_ed_pci.c > 1.30 +30 -1 src/sys/dev/ed/if_edreg.h > 1.12 +10 -1 src/sys/dev/ed/if_edvar.h > 1.303 +2 -1 src/sys/i386/conf/GENERIC > 1.40 +19 -10src/sys/i386/conf/NEWCARD > > > > > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-current" in the body of the message > 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: secure/lib/libcrypto: "make -jX buildworld" fix
On Tue, 6 Mar 2001, Makoto MATSUSHITA wrote:
> I've found that current libcrypto/Makefile is not parallel make(1)
> unfriendly, since it creates a temporary file to as(1). Followings are
> sample session log with "make buildworld -j2":
> ...
> If there is no mean to create *.pl.s, how about using a pipe to pass
> an assembler code to as(1) ?
Pipes aren't so good. They discard errors from all stages except the last.
> Index: Makefile
> ===
> RCS file: /home/ncvs/src/secure/lib/libcrypto/Makefile,v
> retrieving revision 1.35
> diff -u -r1.35 Makefile
> --- Makefile 2001/03/04 23:14:50 1.35
> +++ Makefile 2001/03/06 07:52:59
> @@ -384,12 +384,12 @@
> .SUFFIXES: .po .pl
> .SUFFIXES: .So .pl
> .pl.o:
> - perl -I${PERLPATH} $(.ALLSRC) elf ${CPUTYPE:Mi386:S/i//} > $(.PREFIX).pl.s ;
>${AS} ${AFLAGS} $(.PREFIX).pl.s -o $(.TARGET)
> + perl -I${PERLPATH} $(.ALLSRC) elf ${CPUTYPE:Mi386:S/i//} | ${AS} ${AFLAGS} -
>-o $(.TARGET)
>
> .pl.po:
> - perl -I${PERLPATH} $(.ALLSRC) elf ${CPUTYPE:Mi386:S/i//} > $(.PREFIX).pl.s ;
>${AS} ${AFLAGS} $(.PREFIX).pl.s -o $(.TARGET)
> + perl -I${PERLPATH} $(.ALLSRC) elf ${CPUTYPE:Mi386:S/i//} | ${AS} ${AFLAGS} -
>-o $(.TARGET)
>
> .pl.So:
> - perl -I${PERLPATH} $(.ALLSRC) elf ${CPUTYPE:Mi386:S/i//} > $(.PREFIX).pl.s ;
>${AS} ${AFLAGS} $(.PREFIX).pl.s -o $(.TARGET)
> + perl -I${PERLPATH} $(.ALLSRC) elf ${CPUTYPE:Mi386:S/i//} | ${AS} ${AFLAGS} -
>-o $(.TARGET)
> .endif
>
These lines have about 5 other bugs each. Fixing some of these would
make the problem with parallel makes go away. Note that the rules
are identical. They say to create 3 identical .s files with the same
name (but only 1 copy will be created in the non-parallel case) and
3 identical object files with different names. It would be better to
have only a .pl.S rule to create the assembler file and use the standard
.S.{o,po,So} rules to compile it to object files. This would fix using
slightly wrong rules for building the object files. The rule for building
the .po files is actually completely wrong (it is missing -DPROF ...), but
this currently makes no difference since the assembler files don't support
profiling either.
Bruce
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: if_ed, mii and no PCI?
Peter Wemm wrote: > Maxim Sobolev wrote: > > Duncan Barclay wrote: > > > > > Hi > > > > > > Just got round to rebuilding a -current kernel on a Libretto 50 with no PCI bus. > > > make depend in sys/compile/WANDERER dies on: > > > In file included from ../../dev/mii/dcphy.c:67: > > > ../../dev/pci/pcivar.h:156: pci_if.h: No such file or directory > > > > > > Do I really need to add PCI... > > > > It is sideefect of the following commit (yes, I agree with you that mandatory >device > > pci it is bogus and IMO should be fixed). > > Fixed: > Checking in files; > /home/ncvs/src/sys/conf/files,v <-- files > new revision: 1.493; previous revision: 1.492 Thank you! -Maxim To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Can't build 5-current world on 4-stable box (perl doesn't bootstrap properly)
Hi, I reported it about a month ago, but the problem still persists. 5-current buildworld can't be performed on reasonably recent 4-stable system, hence source upgrade path from -stable to -current is broken. Please fix. cc -pipe -O -I/usr/current/src/gnu/usr.bin/perl/libperl -I/usr/current/src/gnu/usr.bin/perl/libperl/../../../../contrib/perl5 -DPERL_CORE -I/shares/UF/obj/usr/current/src/i386/usr/include -c /usr/current/src/gnu/usr.bin/perl/libperl/../../../../contrib/perl5/perly.c -o perly.o building static perl library ranlib libperl.a sh /usr/current/src/tools/install.sh -c -o root -g wheel -m 444 libperl.a /shares/UF/obj/usr/current/src/i386/usr/libcd /usr/current/src/gnu/usr.bin/perl/miniperl; make obj; make depend; make all; make install /shares/UF/obj/usr/current/src/gnu/usr.bin/perl/miniperl created for /usr/current/src/gnu/usr.bin/perl/miniperl make: don't know how to make opnames.h. Stop *** Error code 2 1 error $ uname -a FreeBSD vic.sabbo.net 4.2-STABLE FreeBSD 4.2-STABLE #37: Wed Feb 21 11:59:36 EET 2001 [EMAIL PROTECTED]:/usr/src/sys/compile/VEGA i386 (system built from the sources cvsuped on 21 Feb 2001). -Maxim To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: tape device names and devfs
Steve Kargl <[EMAIL PROTECTED]> wrote: > dump.8 and dump(8) both refer explicitly to nsa0 and nrsa0 whereas > sa0 and nsa0 are the actual device names in -current. Then this should be fixed. The non-'r' device names have been standard in -CURRENT for quite some time. MAKEDEV only creates 'r'-names for backwards compatibility. -- Christian "naddy" Weisgerber [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Correct size of kinfo_proc
Warner Losh wrote: > In message <[EMAIL PROTECTED]> Igor Robul writes: > : On Wed, Feb 28, 2001 at 03:00:48PM +0200, Maxim Sobolev wrote: > : > Hi Poul, > : > > : > In revision 1.31 of src/sys/sys/user.h you have added new ki_layout field to > : > kinfo_proc structure, but forgot to increase KINFO_PROC_SIZE from 644 to 648. > : > Please correct. > : Why don't use sizeof() insead of hardcoding numbers? > > Because KINFO_PROC_SIZE is part of the ABI. Changes to its size are > always wrong, in that they break the ABI. The checks are there to > tell us when the ABI has been broken. Well, we are now well informed about this, could we just fix sys/sys/user.h to match relity (credit goes to phk for broking it and ignoring my posts completely)? max@notebook$ dmesg | grep WARNING WARNING: size of kinfo_proc (648) should be 644!!! max@notebook$ uname -a FreeBSD notebook 5.0-CURRENT FreeBSD 5.0-CURRENT #2: Tue Mar 6 15:34:23 EET 2001 root@notebook:/usr/src/sys/compile/NOTEBOOK i386 -Maxim To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Correct size of kinfo_proc
In message <[EMAIL PROTECTED]>, Maxim Sobolev writes: >Warner Losh wrote: > >> In message <[EMAIL PROTECTED]> Igor Robul writes: >> : On Wed, Feb 28, 2001 at 03:00:48PM +0200, Maxim Sobolev wrote: >> : > Hi Poul, >> : > >> : > In revision 1.31 of src/sys/sys/user.h you have added new ki_layout field to >> : > kinfo_proc structure, but forgot to increase KINFO_PROC_SIZE from 644 to 648. >> : > Please correct. >> : Why don't use sizeof() insead of hardcoding numbers? >> >> Because KINFO_PROC_SIZE is part of the ABI. Changes to its size are >> always wrong, in that they break the ABI. The checks are there to >> tell us when the ABI has been broken. > >Well, we are now well informed about this, could we just fix sys/sys/user.h to match >relity (credit goes to phk for broking it and ignoring my posts completely)? I've been kind of waiting for -current to actually work again. I hate commiting to -current when it's börked. Yes, fix it in for now, or better, do the right thing with version numbers. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: tape device names and devfs
Christian Weisgerber wrote: > Steve Kargl <[EMAIL PROTECTED]> wrote: > > > dump.8 and dump(8) both refer explicitly to nsa0 and nrsa0 whereas whoops rsa0 > > sa0 and nsa0 are the actual device names in -current. > > Then this should be fixed. But, what is the correct fix? Add symlink magic to rc.devfs? Change dump(8)? > The non-'r' device names have been standard in -CURRENT for quite > some time. MAKEDEV only creates 'r'-names for backwards compatibility. MAKEDEV's behavior satisfies POLA by creating the symlinks. If symlinks aren't created in rc.devfs, then how many (custom) scripts will this break? -- Steve To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Correct size of kinfo_proc
Poul-Henning Kamp wrote: > In message <[EMAIL PROTECTED]>, Maxim Sobolev writes: > >Warner Losh wrote: > > > >> In message <[EMAIL PROTECTED]> Igor Robul writes: > >> : On Wed, Feb 28, 2001 at 03:00:48PM +0200, Maxim Sobolev wrote: > >> : > Hi Poul, > >> : > > >> : > In revision 1.31 of src/sys/sys/user.h you have added new ki_layout field to > >> : > kinfo_proc structure, but forgot to increase KINFO_PROC_SIZE from 644 to 648. > >> : > Please correct. > >> : Why don't use sizeof() insead of hardcoding numbers? > >> > >> Because KINFO_PROC_SIZE is part of the ABI. Changes to its size are > >> always wrong, in that they break the ABI. The checks are there to > >> tell us when the ABI has been broken. > > > >Well, we are now well informed about this, could we just fix sys/sys/user.h to match > >relity (credit goes to phk for broking it and ignoring my posts completely)? > > I've been kind of waiting for -current to actually work again. I hate > commiting to -current when it's bÆrked. > > Yes, fix it in for now, or better, do the right thing > with version numbers. Ah ok if so, I though that you just forgot about it. I think it would be wise for me to avoid hacking this part, especially considering that the only harm from this is warning message at bootup. -Maxim To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
make(1) benchmarks [WAS: Re: cvs commit: src/gnu/usr.bin/binutils/ar Makefile src/gnu/usr.bin/binutils/as Makefile.inc0 ...]
Will Andrews wrote: > [ cc's trimmed, moved to -current ] > > On Wed, Feb 28, 2001 at 09:51:08AM -0700, Warner Losh wrote: > > So long as it is not forced unconditionally to be static. > > I agree. > > > b) I've not seen the numbers for this. If it is only 1% faster, it > > doesn't make sense, even though it sounds good on paper. > > I will perform careful benchmarks and publish results. Can people wait > until that is done before moving forward please? Give me until Saturday. Any updates? My quick test involving running pkg_version on a system with 92 installed ports, which is very make-intensive operation if ports have origin recorded, as pkg_version(1) runs `make -V' for each port, shown that statically-compiled make is about 15% faster than dynamically-compiled. Sound like a reasonable speed gain for 100k binary size increase. What do people think? -Maxim To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: make(1) benchmarks [WAS: Re: cvs commit: src/gnu/usr.bin/binutils/ar Makefile src/gnu/usr.bin/binutils/as Makefile.inc0 ...]
> > Any updates? My quick test involving running pkg_version on a system with 92 > installed ports, which is very make-intensive operation if ports have origin > recorded, as pkg_version(1) runs `make -V' for each port, shown that > statically-compiled make is about 15% faster than dynamically-compiled. Sound like a > reasonable speed gain for 100k binary size increase. What do people think? IFF it's only 100k difference, methink it's a no brainer. A static make is a good thing, if it's so good performancewise that I say go for it. pkg_version is quite intensive, that's for sure! Bye, Andrea -- The dark ages were caused by the Y1K problem. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: make(1) benchmarks [WAS: Re: cvs commit: src/gnu/usr.bin/binutils/ar Makefile src/gnu/usr.bin/binutils/as Makefile.inc0 ...]
:> Any updates? My quick test involving running pkg_version on a system with 92 :> installed ports, which is very make-intensive operation if ports have origin :> recorded, as pkg_version(1) runs `make -V' for each port, shown that :> statically-compiled make is about 15% faster than dynamically-compiled. Sound like a :> reasonable speed gain for 100k binary size increase. What do people think? : :IFF it's only 100k difference, methink it's a no brainer. A static make is a :good thing, if it's so good performancewise that I say go for it. pkg_version :is quite intensive, that's for sure! : :Bye, : Andrea 'make' is one of those programs that fork/exec's lots of copies of itself, even when used without -j parallelization. Try doing a 'make' in virtually any ports directory, ^Z it, then do a ps and you will see what I mean. Static binaries will not only start up much more quickly then dynamic binaries, they actually eat *less* memory if you are running a whole bunch of them independantly (independantly exec'd). Make fits this description to a T. Normally I would argue against making things static, I definitely do *NOT* agree with the 'system recovery' reasoning for making 'make' static. But I do agree that static is much better with regard to all the fork/exec'ing make does. I think making 'make' static is a very good idea. -Matt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: tape device names and devfs
Steve Kargl <[EMAIL PROTECTED]> wrote: > > > dump.8 and dump(8) both refer explicitly to rsa0 and nrsa0 whereas > > > sa0 and nsa0 are the actual device names in -current. > > > > Then this should be fixed. > > But, what is the correct fix? Add symlink magic to rc.devfs? > Change dump(8)? Yes, dump(8) and restore(8) need to be updated. I'll submit a PR. > MAKEDEV's behavior satisfies POLA by creating the symlinks. If > symlinks aren't created in rc.devfs, then how many (custom) > scripts will this break? I haven't heard any screaming yet. Besides, this is -CURRENT. devfs has also abandoned symlinks for 'r' disk devices. -- Christian "naddy" Weisgerber [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
subscribe
subscribe To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: tape device names and devfs
Christian Weisgerber wrote: > Steve Kargl <[EMAIL PROTECTED]> wrote: > > I haven't heard any screaming yet. Besides, this is -CURRENT. > devfs has also abandoned symlinks for 'r' disk devices. > The "r" in tape device names has traditionally meant "r"ewind. The "r" in disk names (such as rda0) meant a "r"aw device. Raw devices (or block devices) were removed from current. The rewind and non-rewind tape device names were changed under devfs from rsa0 and nrsa0 to sa0 and nsa0, (which IMHO violates POLA). I suspect we'll hear scream when 5.0 is released and early adopters start to have their backup scripts die. -- Steve To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Can't build 5-current world on 4-stable box (perl doesn't bootstrap properly)
> I reported it about a month ago, but the problem still persists. 5-current > buildworld can't be performed on reasonably recent 4-stable system, hence > source upgrade path from -stable to -current is broken. Please fix. I just did this on 4-STABLE with no problems at all. M -- Mark Murray Warning: this .sig is umop ap!sdn To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: tape device names and devfs
> Christian Weisgerber wrote: > > Steve Kargl <[EMAIL PROTECTED]> wrote: > > > > I haven't heard any screaming yet. Besides, this is -CURRENT. > > devfs has also abandoned symlinks for 'r' disk devices. > > > > The "r" in tape device names has traditionally meant "r"ewind. > The "r" in disk names (such as rda0) meant a "r"aw device. That is incorrect. r is raw in both cases. n is used to designate non-rewind devices. Please read mtio(4) and sa(4). non-raw tape devices don't make since... they aren't random block addressable devices. > Raw devices (or block devices) were removed from current. The > rewind and non-rewind tape device names were changed under > devfs from rsa0 and nrsa0 to sa0 and nsa0, (which IMHO > violates POLA). > > I suspect we'll hear scream when 5.0 is released and early > adopters start to have their backup scripts die. > > -- > Steve > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-current" in the body of the message > -- Rod Grimes - KD7CAX @ CN85sl - (RWG25) [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: make(1) benchmarks [WAS: Re: cvs commit: src/gnu/usr.bin/binutils/ar Makefile src/gnu/usr.bin/binutils/as Makefile.inc0 ...]
On Tue, Mar 06, 2001 at 08:37:35PM +0200, Maxim Sobolev wrote: > Any updates? My quick test involving running pkg_version on a system with 92 > installed ports, which is very make-intensive operation if ports have origin > recorded, as pkg_version(1) runs `make -V' for each port, shown that > statically-compiled make is about 15% faster than dynamically-compiled. Sound like a > reasonable speed gain for 100k binary size increase. What do people think? Err, sorry, I forgot to do it on the weekend, and have no time right now. Next weekend I will (but someone probably needs to remind me). -- wca PGP signature
Re: tape device names and devfs
Steve Kargl <[EMAIL PROTECTED]> wrote: > The "r" in tape device names has traditionally meant "r"ewind. No. We've been over this before. If you check the old 4.xBSD releases, the 'r' clearly means "raw device". Once upon a time there were tape block devices. > The rewind and non-rewind tape device names were changed under > devfs from rsa0 and nrsa0 to sa0 and nsa0, (which IMHO > violates POLA). They were changed in MAKEDEV long before that. MAKEDEV also provides 'r' names for compatibility. devfs simply did away with those compat links. For all kinds of devices, not only the tape drives. -- Christian "naddy" Weisgerber [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: tape device names and devfs
On Tue, Mar 06, 2001 at 11:01:32PM +, Christian Weisgerber wrote: > > The rewind and non-rewind tape device names were changed under > > devfs from rsa0 and nrsa0 to sa0 and nsa0, (which IMHO > > violates POLA). > > They were changed in MAKEDEV long before that. MAKEDEV also provides > 'r' names for compatibility. devfs simply did away with those > compat links. For all kinds of devices, not only the tape drives. MAKEDEV has made sa, etc devices with rsa, etc links in -STABLE for almost ten months now (as you know since you submitted the changes :-). What we really need to do is get all the utilities and docs updated in -STABLE ASAP in hopes of getting a few releases with the right names everywhere under our belt. That should at least help reduce the number of complaints come 5.0-RELEASE time. Obviously, nothing is going to stop them, but preemptive doc and utility updates including ports should go a long way. A preemptive FAQ like "where did /dev/rsa, /dev/nsa, and /dev/esa go?" would probably also be in order. Remember we've got at least six months and by many estimates a whole year to get people to recognize the fact that this change occured. Now's the time to start since we know it is going to confuse people. -- Brooks -- Any statement of the form "X is the one, true Y" is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 PGP signature
Re: Can't build 5-current world on 4-stable box (perl doesn't bootstrap properly)
Make sure you delete /usr/obj, I just did this too. Sometimes /usr/obj messes stuff up, also make sure that make.conf and all don't have any conflicting options set. Usually, I don't use things like -O2 optimizations for new makes. Make sure that isn't in your CFLAGS, also it would be a help to see the error message you get. Mark Murray had the audacity to say: > > > I reported it about a month ago, but the problem still persists. 5-current > > buildworld can't be performed on reasonably recent 4-stable system, hence > > source upgrade path from -stable to -current is broken. Please fix. > > I just did this on 4-STABLE with no problems at all. > > M > -- > Mark Murray > Warning: this .sig is umop ap!sdn > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-stable" in the body of the message > PGP signature
Is my USB programmer broken?
I've got a USB programmer for my Flashram for my Garmin GPS. It doesn't work, and causes blue screen under windows... Is this the proof for it is broken? Copyright (c) 1992-2001 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 5.0-CURRENT #6: Tue Mar 6 19:17:59 CET 2001 uhci0: port 0xb400-0xb41f irq 9 at device 4.2 on pci0 usb0: on uhci0 usb0: USB revision 1.0 uhub0: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 2 ports with 2 removable, self powered usbd_new_device: addr=2, getting first desc failed uhub_explore: usb_new_device failed, error=IOERROR uhub0: device problem, disabling port 1 It can't be because FreeBSD doesn't know the USB programmer; it doesn't know my USB webcam either, and it still shows up as ugen with manufacturer name at boot. Leif To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
faster worlds...
I read something (somewhere) about speeding up buildworlds with a ramdisk mounted to /usr/obj *IF* you have a lot of RAM but I cant seem to find it anymore. Any help? What are you guys doing to speed up your worlds? Are people still passing -j# option to make or is that old school now? Passing -j4 to my dual p3-500 didn't speed up buildworld at all but it speed up the kernel build/install plenty. Unfortunately it broke the installworld so I just did the installworld without the -j4 and it was fine. C'mon guys, spit out the tips-n-tricks :) OF To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Save Money
Do you want to save money and have the fastest most modern internet presence available? If yes there is only one company for you: www.northstar-internetsolutions.com Web Design, Webpage Hosting, System Building, Server Hosting, Virtual hosting, 0800 numbers, Lease Lines, WAP Site Building, E-Commerce Solutions, Free Consultations and much, much more. We cut out the middleman so that you can get low,low prices. Just take alook and see what we can save you today. NorthStar Crew To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: faster worlds...
On Tue, Mar 06, 2001 at 06:03:57PM -0800, some SMTP stream spewed forth: > I read something (somewhere) about speeding up buildworlds with a ramdisk > mounted to /usr/obj *IF* you have a lot of RAM but I cant seem to find it > anymore. Any help? What are you guys doing to speed up your worlds? Are I suppose you could do so. I have no experience with that, though. Ram just recently became relatively cheap. ;-) `du -d0 -c /usr/obj` 316617 /usr/obj 316617 total > people still passing -j# option to make or is that old school now? > Passing -j4 to my dual p3-500 didn't speed up buildworld at all but it speed > up the kernel build/install plenty. Unfortunately it broke the installworld > so I just did the installworld without the -j4 and it was fine. C'mon guys, > spit out the tips-n-tricks :) I still pass the -j option, usually a -j4 for a single-proc Athlon 700 with 256MB ram. I have not actually checked to see if it sped stuff up. ;-) Parallelizing installworld's is probably not going to work (as you have seen), and I think that it is even suggested *not* to. Heck, I even ran a -j64 once: 1229962.595u 3178499.752s 7:19:05.10 16733.5% 0+0k 52750+382894io 3616pf+477w That slowed things down a whole bunch, seven hours. I run a make -j4 buildworld/installword of -current on what has become a daily basis. It is probably not a good idea to do so blindly without tracking the lists. dan > OF > > > 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
HEADSUP: Kernel b0rked for a little while..
On 07-Mar-01 John Baldwin wrote: > jhb 2001/03/06 18:59:54 PST > > Modified files: > sys/kern kern_sig.c > Log: > - Proc locking. Most of signal handling is now MP safe and doesn't require > Giant. The only exception is the CANSIGNAL() macro. Unlocking the proc > lock around sendsig() in trapsignal() is also questionable. Note that > the functions sigexit(), psignal(), and issignal() must be called with > the proc lock of the process in question held. postsig() and > trapsignal() should not be called with the proc lock held, but they > also do not require Giant anymore either. > - Remove spl's that are now no longer needed as they are fully replaced. > > Revision ChangesPath > 1.110 +163 -71 src/sys/kern/kern_sig.c Until I finish committing all the changes to lock the process when calling psignal() and sigexit(), a kernel with INVARIANTS will panic. I'll send another message when I'm done. -- 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: HEADSUP: Kernel b0rked for a little while..
On 07-Mar-01 John Baldwin wrote: > > On 07-Mar-01 John Baldwin wrote: >> jhb 2001/03/06 18:59:54 PST >> >> Modified files: >> sys/kern kern_sig.c >> Log: >> - Proc locking. Most of signal handling is now MP safe and doesn't >> require >> Giant. The only exception is the CANSIGNAL() macro. Unlocking the proc >> lock around sendsig() in trapsignal() is also questionable. Note that >> the functions sigexit(), psignal(), and issignal() must be called with >> the proc lock of the process in question held. postsig() and >> trapsignal() should not be called with the proc lock held, but they >> also do not require Giant anymore either. >> - Remove spl's that are now no longer needed as they are fully replaced. >> >> Revision ChangesPath >> 1.110 +163 -71 src/sys/kern/kern_sig.c > > Until I finish committing all the changes to lock the process when calling > psignal() and sigexit(), a kernel with INVARIANTS will panic. I'll send > another message when I'm done. Ok, it should work again. I'll be making one or two more commits in a bit, but the kernel as it stands now should work fine. -- 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
