Re: Need help to boot (was : -current hangs during boot)
Hello FreeBSD-hackers. I had my first CVSup-ed source tre d/loaded today. It compiled correctly (make buildworld) and installed correctly (make installworld). Mistake #1 was CVSuping -CURRENT. [...] NOTE #3. Your machine is probably totaly broke. And you will need to reinstall. This time I suggest you install 4.1.1-RELEASE and follow -STABLE *not* -CURRENT. Hey pal, don't chew me up like that ... I solved the problem myself look, I'm not here to bother you guys, I use FreeBSD for years now, and I always used -RELEASE, bought cds the rest. I've also built several ISDN-routers, all FreeBSD-based. I simply LOVE the FreeBSD project, and, since I have some spare time, I decided to start testing -CURRENT. I also built modified many PicoBSD installations on a floppy for custom purposes. Even if I am "green" to many subjects, it doesn't mean I am a complete idiot. I can learn, damnit, but I have to start with something. Geez Bye, Wyk'00 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: platform byte order macros?
On Sat, Oct 28, 2000 at 04:13:46PM +1100, Bruce Evans wrote:
On Fri, 27 Oct 2000, Ruslan Ermilov wrote:
On Fri, Oct 27, 2000 at 06:11:49PM +0300, Ruslan Ermilov wrote:
On Fri, Oct 27, 2000 at 07:34:06AM -0700, Mike Smith wrote:
+#ifdef __OPTIMIZE__
Using macros does not "optimise" anything,
Not quite true. Using inline functions pessimizes everything that is
compiled without -O since the functions don't get inlined but code
for them is generated in each object file whether or not they are
used. sys/types.h is included a lot, so having inline functions in
it is especially pessimal for the -O0 case.
Hmm, even if these function declared static? I was not able to
reproduce this with static inline functions.
and this is a very poor choice
of defines. __MACRO_ENDIAN_CONVERSIONS might be better.
__OPTIMIZE__ is the standard gcc macro for telling whether gcc has been
invoked with -O. It is used sort of backwards here. There is no reason
to turn off the macros for constants, but turning off the inlines for
non-constants would fix the useless bloat in the -O0 case.
Is the htonl() family used enough on constants for the constant case to
be worth optimizing?
Probably it's not.
Writing the byte swapping using shifts and masks might be best in all
cases. The compiler can in theory reduce shifts and masks to bswap on
i386's if that is best, but it can't look inside asm statements.
And in practice (with -O), they are almost equivalent. The following C
code
#include sys/types.h
unsigned short
foo(unsigned short a)
{
return (htons(a));
}
produces the following asm code diffs when using the current __asm version
compared to the macro version:
--- a.s.ASM Tue Oct 31 13:17:32 2000
+++ a.s.MACRO Tue Oct 31 13:45:57 2000
@@ -1,20 +1,18 @@
.file "a.c"
.version"01.01"
gcc2_compiled.:
.text
.p2align 2,0x90
.globl foo
.typefoo,@function
foo:
pushl %ebp
movl %esp,%ebp
movl 8(%ebp),%eax
-#APP
- xchgb %ah, %al
-#NO_APP
+ rolw $8,%ax
andl $65535,%eax
leave
ret
.Lfe1:
.sizefoo,.Lfe1-foo
.ident "[ASM_FILE_END]GCC: (c) 2.95.2 19991024 (release)"
--
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: Intel Etherexpress support?
On Tue, Oct 31, 2000 at 00:08 +0100, Peter van Dijk wrote: Without looking at any of your code, I would kindly like to ask you not to look at the Linux driver for eexpress too much - it's severely broken and has all kinds of timing problems that can crash boxes at predictable moments (some boxes crash when you ifconfig, some crash when you run tcpdump [probably on the switch to PROMISC]). Slower boxes seem to work better. Which driver version are you talking about? I didn't follow this stuff too closely (my EEPro100 always worked when not sitting in an Asus SP3 board which has problems of its own regarding PCI) but there is an enhanced and corrected driver besides the "official" in the Linux kernel. It always got good critics and seems to work reliable from what I hear. Donald Becker's original http://cesdis.gsfc.nasa.gov/linux/drivers/kern-2.3/index.html ftp://cesdis.gsfc.nasa.gov/pub/linux/drivers/kern-2.3 Andrey Savochkin's improvements ftp://ftp.sw.com.sg/pub/Linux/people/saw/kernel/ I don't know whether the ML [EMAIL PROTECTED] (the Linux EEPro list) is archived somewhere and how useful http://support.intel.com/support/network/adapter/pro100/100linux.htm is. But I hope these links to be helpful. virtually yours 82D1 9B9C 01DC 4FB4 D7B4 61BE 3F49 4F77 72DE DA76 Gerhard Sittig true | mail -s "get gpg key" [EMAIL PROTECTED] -- If you don't understand or are scared by any of the above ask your parents or an adult to help you. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: cvs commit: src/sys/kern subr_diskslice.c src/sys/sys diskslice.h src/sys/cam/scsi scsi_cd.c
On Tue, Oct 31, 2000 at 16:16:26 +0900, Akinori MUSHA wrote: At Sun, 29 Oct 2000 23:03:02 -0800 (PST), Kenneth Merry wrote: ken 2000/10/29 23:03:02 PST Modified files: sys/kern subr_diskslice.c sys/sys diskslice.h sys/cam/scsi scsi_cd.c Log: Write support for the cd(4) driver. I get the following messages when I hit "cdcontrol -f /dev/cd0 play" against a music CD: Oct 31 16:06:40 archon /boot/kernel/kernel: (cd0:ahc0:0:2:0): READ(10). CDB: 28 0 0 0 0 1 0 0 1 0 Oct 31 16:06:40 archon /boot/kernel/kernel: (cd0:ahc0:0:2:0): ILLEGAL REQUEST asc:64,0 Oct 31 16:06:40 archon /boot/kernel/kernel: (cd0:ahc0:0:2:0): Illegal mode for this track Oct 31 16:06:40 archon /boot/kernel/kernel: (cd0:ahc0:0:2:0): cddone: got error 0x16 back Though the music goes just fine. Oops, thanks for the heads-up. I'll see if I can come up with a suitable fix. Ken -- Kenneth Merry [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
compile failure in current
cd /usr/src/gnu/lib/csu; make depend; make all; make install echo '#include "i386/i386.h"'tm.h echo '#include "i386/att.h"' tm.h echo '#include freebsd.h' tm.h echo '#include "i386/freebsd.h"' tm.h echo '#include "i386/perform.h"' tm.h rm -f .depend mkdep -f .depend -a-I/usr/src/gnu/lib/csu/../../../contrib/gcc/config -I. -DIN_GCC -I/usr/obj/usr/src/i386/usr/include /usr/src/gnu/lib/csu/../../../contrib/gcc/crtstuff.c cd /usr/src/gnu/lib/csu; make _EXTRADEPEND cc -Os -I/usr/src/gnu/lib/csu/../../../contrib/gcc/config -I. -DIN_GCC -finhibit-size-directive -fno-inline-functions -fno-exceptions -fno-omit-frame-pointer -I/usr/obj/usr/src/i386/usr/include -g0 -DCRT_BEGIN -c -o crtbegin.o /usr/src/gnu/lib/csu/../../../contrib/gcc/crtstuff.c cc -Os -I/usr/src/gnu/lib/csu/../../../contrib/gcc/config -I. -DIN_GCC -finhibit-size-directive -fno-inline-functions -fno-exceptions -fno-omit-frame-pointer -I/usr/obj/usr/src/i386/usr/include -g0 -DCRT_END -c -o crtend.o /usr/src/gnu/lib/csu/../../../contrib/gcc/crtstuff.c /usr/src/gnu/lib/csu/crtend.c cc: cannot specify -o with -c or -S and multiple compilations *** Error code 1 Stop in /usr/src/gnu/lib/csu. *** Error code 1 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Current Kernel build broken
On Sun, 29 Oct 2000, Manfred Antar wrote:
From latest sources:
cc -c -O -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes
-Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -ansi
-g -nostdinc -I- -I. -I../.. -I../../../include
-I../../contrib/dev/acpica/Subsystem/Include -D_KERNEL -include opt_global.h -elf
-mpreferred-stack-boundary=2 ../../ufs/ufs/ufs_vfsops.c
../../ufs/ufs/ufs_vfsops.c: In function `ufs_quotactl':
../../ufs/ufs/ufs_vfsops.c:119: warning: implicit declaration of function `suser_xxx'
../../ufs/ufs/ufs_vfsops.c:119: `PRISON_ROOT' undeclared (first use in this function)
../../ufs/ufs/ufs_vfsops.c:119: (Each undeclared identifier is reported only once
../../ufs/ufs/ufs_vfsops.c:119: for each function it appears in.)
*** Error code 1
Poul-henning recently committed changes to make suser{,_xxx}() be defined
in system.h instead of proc.h. If ufs_vfsops.c doesn't include systm.h,
it may now be broken. However, it's probably more likely that you cvsup'd
during his commit, and need to update your source tree to make sure all
files are properly in synch.
Robert N M Watson FreeBSD Core Team, TrustedBSD Project
[EMAIL PROTECTED] NAI Labs, Safeport Network Services
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
INVARIANTS and -current
(Based on suggestion from Robert Watson.) I want to enable INVARIANTS by default in -current. This result in some slowdown, but it also makes it more likely that we'll find bugs quickly. People that want to run -current should know enough to disable it if it is in the way, anyway. Well-reasoned objections welcome. Eivind. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Intel Etherexpress support?
On Tue, Oct 31, 2000 at 10:57:11AM +0100, Gerhard Sittig wrote: On Tue, Oct 31, 2000 at 00:08 +0100, Peter van Dijk wrote: Without looking at any of your code, I would kindly like to ask you not to look at the Linux driver for eexpress too much - it's severely broken and has all kinds of timing problems that can crash boxes at predictable moments (some boxes crash when you ifconfig, some crash when you run tcpdump [probably on the switch to PROMISC]). Slower boxes seem to work better. Which driver version are you talking about? I didn't follow this stuff too closely (my EEPro100 always worked when not sitting in an Asus SP3 board which has problems of its own regarding PCI) [snip] We're talking about the old eexpress cards, not the eepro's. eepro's rock :) Greetz, Peter -- dataloss networks '/ignore-ance is bliss' - me 'Het leven is een stuiterbal, maar de mijne plakt aan t plafond!' - me To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
docs for via kt133 south bridge
I was wondering if any of the developers here had any docs for the via kt133 south bridge. I need the docs so that I can write a driver for the hardware monitoring features of this chip... I looked on via's website, but the docs there are incomplete... Ken To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: INVARIANTS and -current
Eivind Eklund wrote: (Based on suggestion from Robert Watson.) I want to enable INVARIANTS by default in -current. This result in some slowdown, but it also makes it more likely that we'll find bugs quickly. People that want to run -current should know enough to disable it if it is in the way, anyway. I support your proposal. But, have a question: Has anyone actually measured the performance impact of INVARIANTS? I'm tempted to suggest that INVARIANTS should be the default in not only -current in 5.0 when she's released. Anyone interested in performance in 5.0 will build custom kernels, and so he can turn INVARIANTS off. -- Steve To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: threaded python seg faults?
In article [EMAIL PROTECTED], Dave Cornejo [EMAIL PROTECTED] wrote: For the last couple of days I've been trying to build python 2 from the ports tree without success. I updated my sources a couple of time and rebuilt the kernel and world with no effect. The problem seems to have appeared in the last couple of days and seems to happen while loading libc_r.so.4 - Is anyone else seeing this, or have any suggestion what I might be doing wrong? [...] Program received signal SIGSEGV, Segmentation fault. 0x28383ec6 in pthread_mutex_lock () from /usr/lib/libc_r.so.4 (gdb) bt #0 0x28383ec6 in pthread_mutex_lock () from /usr/lib/libc_r.so.4 #1 0x80bb5b0 in __register_frame_info () #2 0x2834713a in _init () from /usr/lib/libc_r.so.4 #3 0x28343fe5 in _init () from /usr/lib/libc_r.so.4 #4 0x2815086c in _rtld () from /usr/libexec/ld-elf.so.1 It's because libc_r isn't getting initialized in time. Please try applying the appended patch to "src/gnu/lib/libgcc_r/Makefile" and let us know if it fixes the problem. You will need to rebuild and reinstall libgcc_r, and then rebuild python. Thanks for providing the detailed information! This never would have caught my eye otherwise. John Index: Makefile === RCS file: /home/ncvs/src/gnu/lib/libgcc_r/Makefile,v retrieving revision 1.4 diff -u -r1.4 Makefile --- Makefile1999/10/03 02:43:20 1.4 +++ Makefile2000/10/31 18:06:34 @@ -2,5 +2,6 @@ LIB= gcc_r CFLAGS+=-D_PTHREADS +CFLAGS+=-D'__GTHREAD_MUTEX_INIT_FUNCTION(m)=pthread_mutex_init(m, NULL)' .include "../libgcc/Makefile" To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: threaded python seg faults?
The patch seems to solve my problems, thank you! dave c John Polstra wrote: It's because libc_r isn't getting initialized in time. Please try applying the appended patch to "src/gnu/lib/libgcc_r/Makefile" and let us know if it fixes the problem. You will need to rebuild and reinstall libgcc_r, and then rebuild python. Thanks for providing the detailed information! This never would have caught my eye otherwise. John Index: Makefile === RCS file: /home/ncvs/src/gnu/lib/libgcc_r/Makefile,v retrieving revision 1.4 diff -u -r1.4 Makefile --- Makefile 1999/10/03 02:43:20 1.4 +++ Makefile 2000/10/31 18:06:34 @@ -2,5 +2,6 @@ LIB= gcc_r CFLAGS+=-D_PTHREADS +CFLAGS+=-D'__GTHREAD_MUTEX_INIT_FUNCTION(m)=pthread_mutex_init(m, NULL)' .include "../libgcc/Makefile" -- Dave Cornejo @ Dogwood Media, Fremont, California "There aren't any monkeys chasing us..." - Xochi To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: docs for via kt133 south bridge
On Tue, Oct 31, 2000 at 12:02:47PM -0500, Kenneth Wayne Culver wrote: I was wondering if any of the developers here had any docs for the via kt133 south bridge. I need the docs so that I can write a driver for the hardware monitoring features of this chip... I looked on via's website, but the docs there are incomplete... I think one of our Japanese friends has been trying to get these docs from VIA. With little luck it seems. -- Wilko Bulte Arnhem, the Netherlands [EMAIL PROTECTED] http://www.freebsd.org http://www.nlfug.nl To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
device_tagenb in sys/cam/cam_xpt.c
After last changes , device_tagenb is not defined in sys/cam/cam_xpt.c Thanks, Val To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: docs for via kt133 south bridge
I think one of our Japanese friends has been trying to get these docs from VIA. With little luck it seems. Hrmm, well I'll send a messege or something over to VIA... I'm going to make this driver in such a way that it would be easy to add more drivers for other hwmon stuff in the future... Ken To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: compile failure in current
On Tue, Oct 31, 2000 at 07:49:08AM -0800, Charlie Root wrote: cc -Os -I/usr/src/gnu/lib/csu/../../../contrib/gcc/config -I. -DIN_GCC -finhibit-size-directive -fno-inline-functions -fno-exceptions -fno-omit-frame-pointer -I/usr/obj/usr/src/i386/usr/include -g0 -DCRT_END -c -o crtend.o /usr/src/gnu/lib/csu/../../../contrib/gcc/crtstuff.c /usr/src/gnu/lib/csu/crtend.c cc: cannot specify -o with -c or -S and multiple compilations *** Error code 1 What is the contents of your /usr/src/gnu/lib/csu ? -- -- David ([EMAIL PROTECTED]) GNU is Not Unix / Linux Is Not UniX To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
/dev/random strangeness
I have looked through the list (I am new to this list) and saw some mention of the /dev/random. However I have a strange problem that was not mentioned. After I did a proper make world and updated my system to 5.0-CURRENT, my /dev/random services do not "start ?". So if I where to do a make depend or start vi etc... anything that needs this device it will hang and wait. Now if I do someting like echo "100" /dev/random then it pops into service. Why ? I have remade all my devices in /dev and added: device random # Entropy device optionsNOBLOCKRANDOM # avoid any blocking on device random options to my kernel and rebuilt it, however this does not seem to help. any help would be greatly apprecieated. thank you nathan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: device_tagenb in sys/cam/cam_xpt.c
damn, and I thought it was cause I didn't do a buildworld before my
buildkernel ... ;(
On Tue, 31 Oct 2000, Valentin Chopov wrote:
After last changes , device_tagenb is not defined in sys/cam/cam_xpt.c
Thanks,
Val
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: [EMAIL PROTECTED] secondary: scrappy@{freebsd|postgresql}.org
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: docs for via kt133 south bridge
It seems Kenneth Wayne Culver wrote: I think one of our Japanese friends has been trying to get these docs from VIA. With little luck it seems. Hrmm, well I'll send a messege or something over to VIA... I'm going to make this driver in such a way that it would be easy to add more drivers for other hwmon stuff in the future... Hmm, I have the docs for the '686 chip, I'll see if it includes the monitoring stuff... -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: docs for via kt133 south bridge
cool, thanks. = | Kenneth Culver | FreeBSD: The best NT upgrade| | Unix Systems Administrator | ICQ #: 24767726 | | and student at The | AIM: muythaibxr | | The University of Maryland, | Website: (Under Construction) | | College Park. | http://www.wam.umd.edu/~culverk/| = On Tue, 31 Oct 2000, Soren Schmidt wrote: It seems Kenneth Wayne Culver wrote: I think one of our Japanese friends has been trying to get these docs from VIA. With little luck it seems. Hrmm, well I'll send a messege or something over to VIA... I'm going to make this driver in such a way that it would be easy to add more drivers for other hwmon stuff in the future... Hmm, I have the docs for the '686 chip, I'll see if it includes the monitoring stuff... -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Intel Etherexpress support?
Gerhard Sittig wrote: On Tue, Oct 31, 2000 at 00:08 +0100, Peter van Dijk wrote: Without looking at any of your code, I would kindly like to ask you not to look at the Linux driver for eexpress too much - it's severely broken and has all kinds of timing problems that can crash boxes at predictable moments (some boxes crash when you ifconfig, some crash when you run tcpdump [probably on the switch to PROMISC]). Slower boxes seem to work better. Which driver version are you talking about? I didn't follow this stuff too closely (my EEPro100 always worked when not sitting in an Asus SP3 board which has problems of its own regarding PCI) They're discussing the ISA card, which has very little to do with your PCI bus. -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC [EMAIL PROTECTED] http://softweyr.com/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
I need some nm output from today's -current on i386
Could somebody with today's -current on an i386 please send me the output from this command ASAP? nm -oa /usr/lib/libgcc_r.a | fgrep frame.o: Thanks! John -- John Polstra [EMAIL PROTECTED] John D. Polstra Co., Inc.Seattle, Washington USA "Disappointment is a good sign of basic intelligence." -- Chögyam Trungpa To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: I need some nm output from today's -current on i386
In article [EMAIL PROTECTED], John Polstra [EMAIL PROTECTED] wrote: Could somebody with today's -current on an i386 please send me the output from this command ASAP? nm -oa /usr/lib/libgcc_r.a | fgrep frame.o: Got it. Thanks! John To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
linux emulation
Anyone having problems with the linuxulator the past couple days? Module fails to load for me, with this message: link_elf: symbol makebdev undefined -- _ __ ___ ___ ___ ___ Wesley N Morgan _ __ ___ | _ ) __| \ [EMAIL PROTECTED] _ __ | _ \._ \ |) | FreeBSD: The Power To Serve _ |___/___/___/ 6bone: 3ffe:1ce3:7::b4ff:fe53:c297 Hi! I'm a .signature virus! Copy me into your ~/.signature to help me spread! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: linux emulation
Wesley Morgan wrote: Anyone having problems with the linuxulator the past couple days? Module fails to load for me, with this message: link_elf: symbol makebdev undefined Yah, i do. -- // Donny To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
making an install CD
I would line to make an Install CD with a non-release kernel and sysinstall. Only the newer software supports the device I want to install on, So I need both the new kernel and sysinstall. Does anybody have a link to instructions for making an install CD with the 'current' state. jan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
RE: making an install CD
On 01-Nov-00 [EMAIL PROTECTED] wrote: Does anybody have a link to instructions for making an install CD with the 'current' state. Well, you need to have the CVS repo handy for starters, then try cd /usr/src/release make release CHROOTDIR=/some/place/with/space CVSROOT=/my/cvsroot Read the Makefile for handy tips :) --- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Wierdness with cvsup
I am using cvsup to update my sources. in the supfile, there is a line that states *default compress. The comment above indicates to comment this out when you have a fast connection. I DO have a fast connection (100+ K sustained to ftp.freebsd.org) But when I comment this line out, cvsup indicates a smaller update rate than when I leave it in. Can someone shed light on this? Thanks, JAn To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Wierdness with cvsup
In article Pine.GSO.4.05.10010312026560.14609-10@gecko, [EMAIL PROTECTED] wrote: I am using cvsup to update my sources. in the supfile, there is a line that states *default compress. The comment above indicates to comment this out when you have a fast connection. I DO have a fast connection (100+ K sustained to ftp.freebsd.org) But when I comment this line out, cvsup indicates a smaller update rate than when I leave it in. Can someone shed light on this? Sure! The idea behind the comment in the sample supfile is that for link speeds beyond a certain point, compression takes so much CPU time that it slows things down more than just sending the bits uncompressed. That certain point depends on a lot of things -- the speed of your CPU, the speed of your mirror's CPU, etc. So it is ultimately up to you to decide whether to use compression or not, based on your experiences. Second, the "update rate" can be misleading if you don't understand what it means. It's the total size of the files actually updated divided by the elapsed time. It tends to be kind of meaningless unless a lot of files get updated. If you do an update where nothing has changed and therefore no files are updated, the update rate will be 0. So it doesn't work to look at the update rate with compression on, then turn off compression, update again, and look at the update rate a second time. On your second update probably nothing will be updated, because everything was already up-to-date from your first update. The bottom line is, do what seems to work well for you. In cases where compression maybe makes a little difference but not much, don't use it. That will help lighten the CPU load on the mirrors. John -- John Polstra [EMAIL PROTECTED] John D. Polstra Co., Inc.Seattle, Washington USA "Disappointment is a good sign of basic intelligence." -- Chögyam Trungpa To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: INVARIANTS and -current
On Tue, 31 Oct 2000, Eivind Eklund wrote:
I want to enable INVARIANTS by default in -current. This result in some
slowdown, but it also makes it more likely that we'll find bugs quickly.
People that want to run -current should know enough to disable it if it is
in the way, anyway.
Well-reasoned objections welcome.
Yes, running kernel with INVARIANTS is a very good idea (in fact,
my -current setup runs it for over a year now). But this option will
produce inconsistent data structures in the kernel and modules (just like
with SMP case). While it is recommended to avoid modules on -current - I'm
don't agree with this statement because many people use them.
In any way, fix for this is very simple (it assumes that
INVARIANTS defined somewhere in the make.conf or sys.mk):
Index: conf/kmod.mk
===
RCS file: /home/ncvs/src/sys/conf/kmod.mk,v
retrieving revision 1.83
diff -u -r1.83 kmod.mk
--- conf/kmod.mk2000/09/05 22:37:46 1.83
+++ conf/kmod.mk2000/09/30 05:55:55
@@ -90,6 +90,10 @@
CFLAGS+= ${COPTS} -D_KERNEL ${CWARNFLAGS}
CFLAGS+= -DKLD_MODULE
+.if defined(INVARIANTS)
+CFLAGS+= -DINVARIANTS
+.endif
+
# Don't use any standard or source-relative include directories.
# Since -nostdinc will annull any previous -I paths, we repeat all
# such paths after -nostdinc. It doesn't seem to be possible to
--
Boris Popov
http://www.butya.kz/~bp/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: INVARIANTS and -current
Could someone give a quick explanation what INVARIANTS does?
JAn
On Wed, 1 Nov 2000, Boris Popov wrote:
On Tue, 31 Oct 2000, Eivind Eklund wrote:
I want to enable INVARIANTS by default in -current. This result in some
slowdown, but it also makes it more likely that we'll find bugs quickly.
People that want to run -current should know enough to disable it if it is
in the way, anyway.
Well-reasoned objections welcome.
Yes, running kernel with INVARIANTS is a very good idea (in fact,
my -current setup runs it for over a year now). But this option will
produce inconsistent data structures in the kernel and modules (just like
with SMP case). While it is recommended to avoid modules on -current - I'm
don't agree with this statement because many people use them.
In any way, fix for this is very simple (it assumes that
INVARIANTS defined somewhere in the make.conf or sys.mk):
Index: conf/kmod.mk
===
RCS file: /home/ncvs/src/sys/conf/kmod.mk,v
retrieving revision 1.83
diff -u -r1.83 kmod.mk
--- conf/kmod.mk 2000/09/05 22:37:46 1.83
+++ conf/kmod.mk 2000/09/30 05:55:55
@@ -90,6 +90,10 @@
CFLAGS+= ${COPTS} -D_KERNEL ${CWARNFLAGS}
CFLAGS+= -DKLD_MODULE
+.if defined(INVARIANTS)
+CFLAGS+= -DINVARIANTS
+.endif
+
# Don't use any standard or source-relative include directories.
# Since -nostdinc will annull any previous -I paths, we repeat all
# such paths after -nostdinc. It doesn't seem to be possible to
--
Boris Popov
http://www.butya.kz/~bp/
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: platform byte order macros?
On Tue, 31 Oct 2000, Ruslan Ermilov wrote:
On Sat, Oct 28, 2000 at 04:13:46PM +1100, Bruce Evans wrote:
On Fri, 27 Oct 2000, Ruslan Ermilov wrote:
On Fri, Oct 27, 2000 at 06:11:49PM +0300, Ruslan Ermilov wrote:
On Fri, Oct 27, 2000 at 07:34:06AM -0700, Mike Smith wrote:
+#ifdef __OPTIMIZE__
Using macros does not "optimise" anything,
Not quite true. Using inline functions pessimizes everything that is
compiled without -O since the functions don't get inlined but code
for them is generated in each object file whether or not they are
used. sys/types.h is included a lot, so having inline functions in
it is especially pessimal for the -O0 case.
Hmm, even if these function declared static? I was not able to
reproduce this with static inline functions.
This seems to have been fixed. Do you remember when compiling certain
libraries with -O0 -Wa lot -Werror broke the world because stdio.h has
some static inline functions and there were warnings about these functions
being unused? IIRC, code was generated for the functions, so the warning
was appropriate. I can't reproduce this behaviour with the current gcc.
Writing the byte swapping using shifts and masks might be best in all
cases. The compiler can in theory reduce shifts and masks to bswap on
i386's if that is best, but it can't look inside asm statements.
And in practice (with -O), they are almost equivalent. The following C
code
#include sys/types.h
unsigned short
foo(unsigned short a)
{
return (htons(a));
}
produces the following asm code diffs when using the current __asm version
compared to the macro version:
...
-#APP
- xchgb %ah, %al
-#NO_APP
+ rolw $8,%ax
Good, except there may be a problem with partial register stores (are
xchgb's handled better than rolw?).
I think we should use a non-asm version for the 16-bit swap. gcc didn't
do so well for the 32-bit swap.
Bruce
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: linux emulation
Wesley Morgan wrote: Anyone having problems with the linuxulator the past couple days? Define "past couple of days". I have a working linuxulator made on Oct 29, 12:25 PST. -- Marcel Moolenaar mail: [EMAIL PROTECTED] / [EMAIL PROTECTED] tel: (408) 447-4222 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: linux emulation
On Tue, Oct 31, 2000 at 10:59:48PM -0800, Marcel Moolenaar wrote: Wesley Morgan wrote: Anyone having problems with the linuxulator the past couple days? Define "past couple of days". I have a working linuxulator made on Oct 29, 12:25 PST. Mine: Mon Oct 30 17:01:15 CET 2000 and works. (using it right now.:-) -- Regards: Szilveszter ADAM Szeged University Szeged Hungary To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: INVARIANTS and -current
On Tue, Oct 31, 2000 at 10:06:14PM -0700, [EMAIL PROTECTED] wrote: Could someone give a quick explanation what INVARIANTS does? It adds more internal consistency checks to the kernel. This make bugs show up more promptly and in a more predictable fashion, which again makes it easier to fix the bugs. (It also makes the bugs more likely to result in a crash and less likely to result in data corruption, which IMO is good.) Eivind. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
wierd ata driver problem
with a -STABLE as of last night at 1:30 AM EST the ata driver refuses to configure my DVD drive. Here is the output of a dmesg: ad0: 8063MB Maxtor 90845D4 [16383/16/63] at ata0-master UDMA33 ad1: 13029MB Maxtor 91366U4 [26473/16/63] at ata1-master UDMA66 ad2: 14655MB Maxtor 51536H3 [29777/16/63] at ata1-slave UDMA66 ata0-slave: \M-vO\M-wH\M^?B\M-w \M-vV\M-v-\M-vO\M^? \M-wD\M^?M\M-w2\M-w2\M-v \M -v \M-v \M-v \M-v \M-v \M-v \M-v/\M-wR\M-v2\M-v \M-v Unknown device - NO DRIVER ! This is quite wierd because it was working before this.. here are some other relavent lines from my dmesg atapci0: VIA 82C686 ATA66 controller port 0xd000-0xd00f at device 7.1 on pci0 ata0: at 0x1f0 irq 14 on atapci0 ata1: at 0x170 irq 15 on atapci0 Thanks Ken To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
ata problems, nevermind
Wierd, I turned the computer off and turned it back on again and the problem is solved... sorry bout that. Ken To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
