Re: cap_mkdb: illegal option -i. upgrade 5.4-6.1
Ruslan Ermilov wrote:
On Tue, Sep 12, 2006 at 04:52:32PM +0200, [EMAIL PROTECTED] wrote:
Hi list
I'm upgrading 5.4 p18 to 6.1 p6.
here's my tag: RELENG_6_1
I did:
make update
make cleanworld
make buildworld
which gives following issue:
cap_mkdb: illegal option -i
It seems a known problem on netbsd during buildworld compilation. here's
the solution I'm tring:
cd /usr/src/usr.bin/cap_mkdb
make clean
make
make install
and I'm building world again.
is that a known problem on freebsd?
This shouldn't happen. The buildworld target detects the current
version of your system, and bootstraps cap_mkdb if necessary:
: .if ${BOOTSTRAPPING} 600015
: _cap_mkdb= usr.bin/cap_mkdb
: .endif
BOOTSTRAPPING is defined as follows:
: .if !defined(OSRELDATE)
: .if exists(/usr/include/osreldate.h)
: OSRELDATE!= awk '/^\#define[[:space:]]*__FreeBSD_version/ { print $$3 }' \
: /usr/include/osreldate.h
: .else
: OSRELDATE= 0
: .endif
That is, it's the value of __FreeBSD_version as defined in
/usr/include/osreldate.h. If your /usr/include/osreldate.h
is lying about the current version, e.g. if you accidentally
installed the new headers, then you can force it to zero,
such as:
make buildworld OSRELDATE=0
Cheers,
I'm pretty sure about what's happing
i'd propably built my world twice...or something like that. anyway,
building
cap_mkdb before the world resolved the issue.
--
Richard VENNE
www.dental-on-line.com
Phone: 01 43 27 94 24
fax: 01 43 27 66 85
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: cap_mkdb: illegal option -i. upgrade 5.4-6.1
On Wed, Sep 13, 2006 at 10:20:39AM +0200, [EMAIL PROTECTED] wrote:
Ruslan Ermilov wrote:
On Tue, Sep 12, 2006 at 04:52:32PM +0200, [EMAIL PROTECTED] wrote:
Hi list
I'm upgrading 5.4 p18 to 6.1 p6.
here's my tag: RELENG_6_1
I did:
make update
make cleanworld
make buildworld
which gives following issue:
cap_mkdb: illegal option -i
It seems a known problem on netbsd during buildworld compilation. here's
the solution I'm tring:
cd /usr/src/usr.bin/cap_mkdb
make clean
make
make install
and I'm building world again.
is that a known problem on freebsd?
This shouldn't happen. The buildworld target detects the current
version of your system, and bootstraps cap_mkdb if necessary:
: .if ${BOOTSTRAPPING} 600015
: _cap_mkdb= usr.bin/cap_mkdb
: .endif
BOOTSTRAPPING is defined as follows:
: .if !defined(OSRELDATE)
: .if exists(/usr/include/osreldate.h)
: OSRELDATE!= awk '/^\#define[[:space:]]*__FreeBSD_version/ { print
$$3 }' \
: /usr/include/osreldate.h
: .else
: OSRELDATE= 0
: .endif
That is, it's the value of __FreeBSD_version as defined in
/usr/include/osreldate.h. If your /usr/include/osreldate.h
is lying about the current version, e.g. if you accidentally
installed the new headers, then you can force it to zero,
such as:
make buildworld OSRELDATE=0
Cheers,
I'm pretty sure about what's happing
i'd propably built my world twice...or something like that. anyway,
building
cap_mkdb before the world resolved the issue.
But that's what buildworld already does (when it detects the need
to do so). My point was to make it clear. :-)
Cheers,
--
Ruslan Ermilov
[EMAIL PROTECTED]
FreeBSD committer
pgpQTXfDuIF8I.pgp
Description: PGP signature
Re: ACPI resume problems in STABLE
On Wed, Sep 13, 2006 at 11:40:27AM +1000, Norberto Meijome wrote: $ uname -a FreeBSD ayiin.xxx.com 6.1-RELEASE-p6 FreeBSD 6.1-RELEASE-p6 #23: Tue Sep 12 14:52:32 EST 2006 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/AYIIN i386 The only thing I've noticed that in how my lappy works now is that if_iwi0 is loaded on startup, but iw_bss and firmware.ko are not. I can load them by hand, but haven't been able to test to see if it actually works (i have a feeling it doesnt). I have installed iwi-firmware-kmod-3.0_1 Intel PRO/Wireless 2200 Firmware Kernel Module You will need net/iwi-firmware (not net/iwi-firmware-kmod) for 6.1-RELEASE. Regards, Brix -- Henrik Brix Andersen [EMAIL PROTECTED] pgpcr0wTTdeIj.pgp Description: PGP signature
Re: FreeBSD 6.1-RELEASE -FreeBSD 6.1-Stable
Eric wrote: Oliver Fromme wrote: Vince wrote: Eric wrote: S. M. Ibrahim (Lavlu) wrote: Now i am using FreeBSD 6.1-RELEASE. Now want to upgrade to FreeBSD 6.1-Stable. What is the easy process ? this works well http://mikestammer.com/dokuwiki/doku.php?id=bsd:updateos the cvsup part looks ok but for the actual build then read /usr/src/Makefile for the recommended procedure. It's better to read /usr/src/UPDATING. my wiki above mentions reading UPDATING (in step 3) before starting... UPDATING pretty much says exactly the same thing, except its 80% of the way into UPDATING. The wiki above also explains things a bit more for someone who has never done it. I wasn't refering to your wiki (I didn't even look at it). I was refering to Vince's comment that /usr/src/Makefile should be read for the recommended procedure, which is wrong. The recommended procedure (according to the FreeBSD Handbook) is in /usr/src/UPDATING, which is more up-to-date than the comments in the Makefile. All of that is explained in great detail in the FreeBSD Handbook, section 21.4 Rebuilding ``world''. I think people should look at the Handbook more often; it contains answers to many questions on the mailing lists, including the one that started this thread. Best regards Oliver -- Oliver Fromme, secnetix GmbH Co. KG, Marktplatz 29, 85567 Grafing Dienstleistungen mit Schwerpunkt FreeBSD: http://www.secnetix.de/bsd Any opinions expressed in this message may be personal to the author and may not necessarily reflect the opinions of secnetix in any way. We, the unwilling, led by the unknowing, are doing the impossible for the ungrateful. We have done so much, for so long, with so little, we are now qualified to do anything with nothing. -- Mother Teresa ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 6.2? (fwd)
-- Forwarded message -- Date: Tue, 12 Sep 2006 11:02:42 -0400 From: John Baldwin [EMAIL PROTECTED] To: freebsd-current@freebsd.org Cc: kama [EMAIL PROTECTED] Subject: Re: 6.2? On Tuesday 12 September 2006 07:12, kama wrote: I just updated the sources on two of my machines and found: $ uname -sr FreeBSD 6.2-PRERELEASE Is this a mistake or is it actually a prerelease? Why isnt there any notice about it on the webpage or on this mailing list? The notice would be sent to stable@, not current@ as RELENG_6 is a stable branch. -- John Baldwin ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: optimization levels for 6-STABLE build{kernel,world}
Marc G. Fournier [EMAIL PROTECTED] wrote: What are ppl currently using for CFLAGS/COPTFLAGS in /etc/make.conf for building kernel/world? I know awhile back it wasn't recommended to go above -O2, for instance, but suspect that has changed ... ? The best optimization is probably to not override the defaults at all, because they're already pretty optimal. In fact, by overriding the defaults there's a good chance to make things worse. :-) The default CFLAGS are -O2 -pipe -fno-strict-aliasing. Anything above -O2 isn't supported, and using -O2 without -fno-strict-aliasing also isn't supported (and will create broken code for some programs). A common mistake is to specify CFLAGS=-O2 -pipe and omit -fno-strict-aliasing. That'll shot you in the foot sooner or later. Best regards Oliver -- Oliver Fromme, secnetix GmbH Co. KG, Marktplatz 29, 85567 Grafing Dienstleistungen mit Schwerpunkt FreeBSD: http://www.secnetix.de/bsd Any opinions expressed in this message may be personal to the author and may not necessarily reflect the opinions of secnetix in any way. 'Instead of asking why a piece of software is using 1970s technology, start asking why software is ignoring 30 years of accumulated wisdom.' ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Anyone??? (was Reproducible data corruption on 6.1-Stable)
Jonathan Stewart [EMAIL PROTECTED] wrote: I set up a new server recently and transferred all the information from my old server over. I tried to use unison to synchronize the backup of pictures I have taken and noticed that a large number of pictures where marked as changed on the server. After checking the pictures by hand I confirmed that many of the pictures on the server were corrupted. I attempted to use unison to update the files on the server with the correct local copies but it would fail on almost all the files with the message destination updated during synchronization. It appears the corruption happens during the read process because when I recompare the files in a graphical diff tool between cache flushes the differences move around!?!?!? The differences also appear to be very small for the most part, single bytes scattered throughout the file. I really have no idea what is causing the problem and would like to pin it down so I can either replace hardware if it's bad or fix whatever the bug is. That very much sounds like bad RAM, or overclocked CPU or bus. I assume you do not overclock, so I recommend you replace your RAM modules and check if the symptoms are gone. Also check your BIOS settings for the RAM timings. Setting the timings to more conservative values might already solve the problem. Best regards Oliver -- Oliver Fromme, secnetix GmbH Co. KG, Marktplatz 29, 85567 Grafing Dienstleistungen mit Schwerpunkt FreeBSD: http://www.secnetix.de/bsd Any opinions expressed in this message may be personal to the author and may not necessarily reflect the opinions of secnetix in any way. Clear perl code is better than unclear awk code; but NOTHING comes close to unclear perl code (taken from comp.lang.awk FAQ) ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: optimization levels for 6-STABLE build{kernel,world}
Hello, Oliver Fromme wrote: Marc G. Fournier [EMAIL PROTECTED] wrote: What are ppl currently using for CFLAGS/COPTFLAGS in /etc/make.conf for building kernel/world? I know awhile back it wasn't recommended to go above -O2, for instance, but suspect that has changed ... ? The best optimization is probably to not override the defaults at all, because they're already pretty optimal. In fact, by overriding the defaults there's a good chance to make things worse. :-) The default CFLAGS are -O2 -pipe -fno-strict-aliasing. Anything above -O2 isn't supported, and using -O2 without -fno-strict-aliasing also isn't supported (and will create broken code for some programs). A common mistake is to specify CFLAGS=-O2 -pipe and omit -fno-strict-aliasing. That'll shot you in the foot sooner or later. Best regards Oliver May be default flags have to be set here: /usr/src/share/examples/etc/make.conf ? I'm asking because in this file I read: # CFLAGS controls the compiler settings used when compiling C code. # Note that optimization settings other than -O and -O2 are not recommended # or supported for compiling the world or the kernel - please revert any # nonstandard optimization settings to -O or -O2 before submitting bug # reports without patches to the developers. # #CFLAGS= -O -pipe May be -fno-strict-aliasing have to be added here then ? -- Best Wishes, Stefan Lambrev ICQ# 24134177 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 6.2? (fwd)
kama wrote: I just updated the sources on two of my machines and found: $ uname -sr FreeBSD 6.2-PRERELEASE Is this a mistake or is it actually a prerelease? It's not a mistake. RELENG_6 has been frozen on Sep. 10th in preparation of the upcoming 6.2-RELEASE, so it's now in pre-release state. Why isnt there any notice about it on the webpage or on this mailing list? It's on the webpage (under Release Engineering): http://www.freebsd.org/releng/ I don't think there's need to announce it on this mailing list. The fact that RELENG_6 entered code-freeze is important for comitters and (some) developers, but not for normal users of the -stable branch. Best regards Oliver -- Oliver Fromme, secnetix GmbH Co. KG, Marktplatz 29, 85567 Grafing Dienstleistungen mit Schwerpunkt FreeBSD: http://www.secnetix.de/bsd Any opinions expressed in this message may be personal to the author and may not necessarily reflect the opinions of secnetix in any way. One Unix to rule them all, One Resolver to find them, One IP to bring them all and in the zone to bind them. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: optimization levels for 6-STABLE build{kernel,world}
Stefan Lambrev wrote: Oliver Fromme wrote: The default CFLAGS are -O2 -pipe -fno-strict-aliasing. Anything above -O2 isn't supported, and using -O2 without -fno-strict-aliasing also isn't supported (and will create broken code for some programs). A common mistake is to specify CFLAGS=-O2 -pipe and omit -fno-strict-aliasing. That'll shot you in the foot sooner or later. May be default flags have to be set here: /usr/src/share/examples/etc/make.conf ? I'm asking because in this file I read: # CFLAGS controls the compiler settings used when compiling C code. # Note that optimization settings other than -O and -O2 are not recommended # or supported for compiling the world or the kernel - please revert any # nonstandard optimization settings to -O or -O2 before submitting bug # reports without patches to the developers. # #CFLAGS= -O -pipe May be -fno-strict-aliasing have to be added here then ? Yes, you are right. I think a clarification should be added to the make.conf(5) manual page and to the /usr/share/examples/etc/make.conf file. Someone care to submit a PR ...? Best regards Oliver -- Oliver Fromme, secnetix GmbH Co. KG, Marktplatz 29, 85567 Grafing Dienstleistungen mit Schwerpunkt FreeBSD: http://www.secnetix.de/bsd Any opinions expressed in this message may be personal to the author and may not necessarily reflect the opinions of secnetix in any way. With sufficient thrust, pigs fly just fine. However, this is not necessarily a good idea. It is hard to be sure where they are going to land, and it could be dangerous sitting under them as they fly overhead. -- RFC 1925 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
PAE-SMP kernel generates NMI (PCI bus errors)
Hi all, I have a legacy system --- 4xXeon (PIII, 700MHz, 2MB cache), 16GB ECC RAM and 300GB Harddisk on an ICP Vortex Raid Controller --- which I tried to bring from RedHat6 to something more current and supported. (Un)Fortunately the only system that wanted to install on the machine is FreeBSD6. When I use a non-SMP kernel either with or without PAE everything works ok. When I use a SMP non-PAE kernel everything works ok, too. When I use a SMP+PAE kernel the system starts throwing NMIs (most likely due to PCI system bus errors, which is the only error reporting activated in BIOS) until the system finally freezes (which is most likely when the system event log of the server is full). I can give a lot more diagnostics to anyone interested in solving this, but I need a little handholding. Regards, Robert S ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 6.2? (fwd)
Oliver Fromme wrote: kama wrote: I just updated the sources on two of my machines and found: $ uname -sr FreeBSD 6.2-PRERELEASE Is this a mistake or is it actually a prerelease? It's not a mistake. RELENG_6 has been frozen on Sep. 10th in preparation of the upcoming 6.2-RELEASE, so it's now in pre-release state. Why isnt there any notice about it on the webpage or on this mailing list? It's on the webpage (under Release Engineering): http://www.freebsd.org/releng/ I don't think there's need to announce it on this mailing list. The fact that RELENG_6 entered code-freeze is important for comitters and (some) developers, but not for normal users of the -stable branch. Best regards Oliver Sure but it's only a schedule. The main purpose of the public release process would be that WE the users can see/check what are the problems that needs testing or anything. And an other main purpose is to do planning of the upgrade, if needed. I think I shouldn't have to remind you on this. :) Regards, Andras ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: optimization levels for 6-STABLE build{kernel,world}
Oliver Fromme wrote: Marc G. Fournier [EMAIL PROTECTED] wrote: What are ppl currently using for CFLAGS/COPTFLAGS in /etc/make.conf for building kernel/world? I know awhile back it wasn't recommended to go above -O2, for instance, but suspect that has changed ... ? The best optimization is probably to not override the defaults at all, because they're already pretty optimal. In fact, by overriding the defaults there's a good chance to make things worse. :-) The default CFLAGS are -O2 -pipe -fno-strict-aliasing. Anything above -O2 isn't supported, and using -O2 without -fno-strict-aliasing also isn't supported (and will create broken code for some programs). A common mistake is to specify CFLAGS=-O2 -pipe and omit -fno-strict-aliasing. That'll shot you in the foot sooner or later. /etc/make.conf on most of my 6.1 machines contains (in part) this: CFLAGS=-O2 -pipe -fno-strict-aliasing COPTFLAGS= -O2 -pipe I no longer remember exactly why, but at some point I must have understood or assumed that to be the recommendation. Just to be completely clear, are you saying that this CFLAGS=-O2 -pipe -fno-strict-aliasing COPTFLAGS= -O2 -pipe -fno-strict-aliasing would be better in the general case? ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: optimization levels for 6-STABLE build{kernel,world}
On Wed, Sep 13, 2006 at 03:08:23AM -0700, Pete Slagle wrote: Oliver Fromme wrote: Marc G. Fournier [EMAIL PROTECTED] wrote: What are ppl currently using for CFLAGS/COPTFLAGS in /etc/make.conf for building kernel/world? I know awhile back it wasn't recommended to go above -O2, for instance, but suspect that has changed ... ? The best optimization is probably to not override the defaults at all, because they're already pretty optimal. In fact, by overriding the defaults there's a good chance to make things worse. :-) The default CFLAGS are -O2 -pipe -fno-strict-aliasing. Anything above -O2 isn't supported, and using -O2 without -fno-strict-aliasing also isn't supported (and will create broken code for some programs). A common mistake is to specify CFLAGS=-O2 -pipe and omit -fno-strict-aliasing. That'll shot you in the foot sooner or later. /etc/make.conf on most of my 6.1 machines contains (in part) this: CFLAGS=-O2 -pipe -fno-strict-aliasing COPTFLAGS= -O2 -pipe I no longer remember exactly why, but at some point I must have understood or assumed that to be the recommendation. Just to be completely clear, are you saying that this CFLAGS=-O2 -pipe -fno-strict-aliasing COPTFLAGS= -O2 -pipe -fno-strict-aliasing would be better in the general case? Doesn't matter; kern.pre.mk will automatically add -fno-strict-aliasing to COPTFLAGS if needed: : . if !empty(COPTFLAGS:M-O[23s]) empty(COPTFLAGS:M-fno-strict-aliasing) : COPTFLAGS+= -fno-strict-aliasing : . endif Cheers, -- Ruslan Ermilov [EMAIL PROTECTED] FreeBSD committer pgpXqRQmgleu1.pgp Description: PGP signature
Re: optimization levels for 6-STABLE build{kernel,world}
On Wed, Sep 13, 2006 at 11:26:00AM +0200, Oliver Fromme wrote: Stefan Lambrev wrote: Oliver Fromme wrote: The default CFLAGS are -O2 -pipe -fno-strict-aliasing. Anything above -O2 isn't supported, and using -O2 without -fno-strict-aliasing also isn't supported (and will create broken code for some programs). A common mistake is to specify CFLAGS=-O2 -pipe and omit -fno-strict-aliasing. That'll shot you in the foot sooner or later. May be default flags have to be set here: /usr/src/share/examples/etc/make.conf ? I'm asking because in this file I read: # CFLAGS controls the compiler settings used when compiling C code. # Note that optimization settings other than -O and -O2 are not recommended # or supported for compiling the world or the kernel - please revert any # nonstandard optimization settings to -O or -O2 before submitting bug # reports without patches to the developers. # #CFLAGS= -O -pipe May be -fno-strict-aliasing have to be added here then ? Yes, you are right. I think a clarification should be added to the make.conf(5) manual page and to the /usr/share/examples/etc/make.conf file. Someone care to submit a PR ...? Should be fixed in src/share/examples/etc/make.conf,v 1.277. Cheers, -- Ruslan Ermilov [EMAIL PROTECTED] FreeBSD committer pgpCOeN3iL0RB.pgp Description: PGP signature
Re: 6.2? (fwd)
Andras Gót wrote: Oliver Fromme wrote: kama wrote: Why isnt there any notice about it on the webpage or on this mailing list? It's on the webpage (under Release Engineering): http://www.freebsd.org/releng/ I don't think there's need to announce it on this mailing list. The fact that RELENG_6 entered code-freeze is important for comitters and (some) developers, but not for normal users of the -stable branch. Sure but it's only a schedule. That's true, and the schedule will most probably change. Currently the release is listed for Oct. 9th, but I bet that it'll be delayed. The main purpose of the public release process would be that WE the users can see/check what are the problems that needs testing or anything. Yes, which will be announced when BETA state begins, I assume. PRERELEASE isn't BETA (yet). And an other main purpose is to do planning of the upgrade Uhm, would you please explain? What kind of upgrade depends on entering the pre-release state? When you're tracking -stable, then now is neither better nor worse a time for updating, except for the fact that -- due to the code freeze -- the code might have a tendency to stabilize better than before, because MFCs and commits that aren't bug fixes are held off. Best regards Oliver -- Oliver Fromme, secnetix GmbH Co. KG, Marktplatz 29, 85567 Grafing Dienstleistungen mit Schwerpunkt FreeBSD: http://www.secnetix.de/bsd Any opinions expressed in this message may be personal to the author and may not necessarily reflect the opinions of secnetix in any way. To this day, many C programmers believe that 'strong typing' just means pounding extra hard on the keyboard. -- Peter van der Linden ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: optimization levels for 6-STABLE build{kernel,world}
Pete Slagle wrote: Oliver Fromme wrote: Marc G. Fournier wrote: What are ppl currently using for CFLAGS/COPTFLAGS in /etc/make.conf for building kernel/world? I know awhile back it wasn't recommended to go above -O2, for instance, but suspect that has changed ... ? The best optimization is probably to not override the defaults at all, because they're already pretty optimal. In fact, by overriding the defaults there's a good chance to make things worse. :-) The default CFLAGS are -O2 -pipe -fno-strict-aliasing. Anything above -O2 isn't supported, and using -O2 without -fno-strict-aliasing also isn't supported (and will create broken code for some programs). A common mistake is to specify CFLAGS=-O2 -pipe and omit -fno-strict-aliasing. That'll shot you in the foot sooner or later. /etc/make.conf on most of my 6.1 machines contains (in part) this: CFLAGS=-O2 -pipe -fno-strict-aliasing Which is exactly the default, so there's no reason to specify it at all. If, at some point in the future, the default changes (e.g. -O3 is considered good and safe, or any other -fno-xxx option becomes necessary with -O2), then you won't benefit from it, because you override it. COPTFLAGS= -O2 -pipe As Ruslan explained, -fno-strict-aliasing will be added automatically in the case of COPTFLAGS if necessary. So my recommendation is still: Don't override CFLAGS or COPTFLAGS. Chances are that you make things worse, now or at some point in the future. Just to be completely clear, are you saying that this CFLAGS=-O2 -pipe -fno-strict-aliasing COPTFLAGS= -O2 -pipe -fno-strict-aliasing would be better in the general case? In the general case, it would be better to remove those two lines completely. :-) Best regards Oliver -- Oliver Fromme, secnetix GmbH Co. KG, Marktplatz 29, 85567 Grafing Dienstleistungen mit Schwerpunkt FreeBSD: http://www.secnetix.de/bsd Any opinions expressed in this message may be personal to the author and may not necessarily reflect the opinions of secnetix in any way. (On the statement print 42 monkeys + 1 snake:) By the way, both perl and Python get this wrong. Perl gives 43 and Python gives 42 monkeys1 snake, when the answer is clearly 41 monkeys and 1 fat snake.-- Jim Fulton ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 6.2? (fwd)
On Wed, 13 Sep 2006, Oliver Fromme wrote: Andras Gót wrote: Oliver Fromme wrote: kama wrote: Why isnt there any notice about it on the webpage or on this mailing list? It's on the webpage (under Release Engineering): http://www.freebsd.org/releng/ I don't think there's need to announce it on this mailing list. The fact that RELENG_6 entered code-freeze is important for comitters and (some) developers, but not for normal users of the -stable branch. Sure but it's only a schedule. That's true, and the schedule will most probably change. Currently the release is listed for Oct. 9th, but I bet that it'll be delayed. I disagree, I would like to have an notice about it. Even though it might not say much. Just a The code of the stable branch has been freezed due to the upcomming release of X.Y The main purpose of the public release process would be that WE the users can see/check what are the problems that needs testing or anything. Yes, which will be announced when BETA state begins, I assume. PRERELEASE isn't BETA (yet). PR-BETA-RC-REL ? Is that the correct order? Never the less. I was thinking of RC and not PR, when I posted the message. And search for the TODO list on the webpage. /Bjorn ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 6.2? (fwd)
I disagree, I would like to have an notice about it. Even though it might not say much. Just a The code of the stable branch has been freezed due to the upcomming release of X.Y It is kind of useful, because it's the code freeze point at which I start re-scheduling my work day so I can do BSD testing. I can't justify tracking all the time on work machine unfortunately, but I do like to make an effort to test thoroughly before something is released (the more the better, right?) so it's good to know these things. -pcf. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Anyone??? (was Reproducible data corruption on 6.1-Stable)
Oliver Fromme wrote: Jonathan Stewart [EMAIL PROTECTED] wrote: I set up a new server recently and transferred all the information from my old server over. I tried to use unison to synchronize the backup of pictures I have taken and noticed that a large number of pictures where marked as changed on the server. After checking the pictures by hand I confirmed that many of the pictures on the server were corrupted. I attempted to use unison to update the files on the server with the correct local copies but it would fail on almost all the files with the message destination updated during synchronization. It appears the corruption happens during the read process because when I recompare the files in a graphical diff tool between cache flushes the differences move around!?!?!? The differences also appear to be very small for the most part, single bytes scattered throughout the file. I really have no idea what is causing the problem and would like to pin it down so I can either replace hardware if it's bad or fix whatever the bug is. That very much sounds like bad RAM, or overclocked CPU or bus. I assume you do not overclock, so I recommend you replace your RAM modules and check if the symptoms are gone. Also check your BIOS settings for the RAM timings. Setting the timings to more conservative values might already solve the problem. Thanks for the suggestions but I have tried lowering the clock rate on the processor and and the RAM speed with no luck whatsoever. I appear to have forgotten to mention that the problem appears no matter how I read the file, unison, md5, etc. 1 out of maybe 100 times it will read correctly. I have another drive that I use for the OS and I have done many buildworlds/kernels without problems on that drive as well as compiling some very large software packages. I'm wondering if a possible cause is the controller ignoring read errors from the hard drive but I would think more than the occasional single byte would be changed. I'm thinking about maybe trying to dd the file from the raw device in an attempt to see if the problem is occurring in the filesystem code or is lower level yet. Any suggestions on how to locate the file on the disk or how to isolate the problem better are welcome. I don't mind doing the work I just have no idea where to look/what to try next. Thanks, Jonathan ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Request quotes for Computer equipment
IBM, HP, Compaq, Dell, Toshiba, Cisco, 3Com, Epson, Samsung, Sony and Ma= ny More Laptops, Desktops, Servers, Printers, Networking and Po= int of Sale More Dealers Resellers Brokers Service Companies= /p Maintenance Companies [1][USEMAP:Fre=] [3Dh=] Search Inven= tory [marketi=] Send Requests For Quotes [marketi=] Contact Vendors Directly [marketi=] Access Classifieds [marketi=] For Sale [marketi=] Want to Buy 100= 0's of Buyers, 100's of Stocking Vendor= s, 1.5 million lines of Inventory= , Nearly 2 million part searches= a month Contact us today [EMAIL PROTECTED] 888-265-3302 (U.S. = Canada) 1-450-677-7399 (International) Please do not reply to this email . If you have = any comments or questions regarding this message or the PowerSource Onlin= e service, please send an email to: [EMAIL PROTECTED] or visit us online: [4]www.powersourceonline.c= om This is an advertisement from PowerSource= Online. If you no longer wish to receive news and special o= ffers from PowerSource Online, [5]unsubscribe . PowerSource Online 1010 de Sérigny Suite 800 - Longueuil, CANADA - J4K 5G7 Tel: 1(888) 265-3302 - International: 001 (450) 677-7399 [3D] References Visible links 1. LYNXIMGMAP:file://localhost/tmp/3D#Map 2. 3Dmailto:[EMAIL PROTECTED] 3. 3Dmailto:[EMAIL PROTECTED] 4. file://localhost/tmp/3D 5. 3Dhttp://resp.powersourceonline.c=/ Hidden links: 6. 3Dhttp://re=/ 7. 3Dhttp://resp.powersourceonline.com/rspbp/ 8. 3Dhttp://resp.powersou=/ ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Request quotes for Computer equipment
IBM, HP, Compaq, Dell, Toshiba, Cisco, 3Com, Epson, Samsung, Sony and Ma= ny More Laptops, Desktops, Servers, Printers, Networking and Po= int of Sale More Dealers Resellers Brokers Service Companies= /p Maintenance Companies [1][USEMAP:Fre=] [3Dh=] Search Inven= tory [marketi=] Send Requests For Quotes [marketi=] Contact Vendors Directly [marketi=] Access Classifieds [marketi=] For Sale [marketi=] Want to Buy 100= 0's of Buyers, 100's of Stocking Vendor= s, 1.5 million lines of Inventory= , Nearly 2 million part searches= a month Contact us today [EMAIL PROTECTED] 888-265-3302 (U.S. = Canada) 1-450-677-7399 (International) Please do not reply to this email . If you have = any comments or questions regarding this message or the PowerSource Onlin= e service, please send an email to: [EMAIL PROTECTED] or visit us online: [4]www.powersourceonline.c= om This is an advertisement from PowerSource= Online. If you no longer wish to receive news and special o= ffers from PowerSource Online, [5]unsubscribe . PowerSource Online 1010 de Sérigny Suite 800 - Longueuil, CANADA - J4K 5G7 Tel: 1(888) 265-3302 - International: 001 (450) 677-7399 [3D] References Visible links 1. LYNXIMGMAP:file://localhost/tmp/3D#Map 2. 3Dmailto:[EMAIL PROTECTED] 3. 3Dmailto:[EMAIL PROTECTED] 4. file://localhost/tmp/3D 5. 3Dhttp://resp.powersourceonline.c=/ Hidden links: 6. 3Dhttp://re=/ 7. 3Dhttp://resp.powersourceonline.com/rspbp/ 8. 3Dhttp://resp.powersou=/ ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ARRRRGH! Guys, who's breaking -STABLE's GMIRROR code?!
On Sep 12, 2006, at 6:23 PM, hackmiester (Hunter Fuller) wrote: -STABLE is still a development branch without guarantee of a stable and working operating system. Hahahahaha... That's ironic... No, just misinterpretation of which attribute of the system to which the word stable applies.
Re: gjournal and Softupdates
On Tue, Sep 12, 2006 at 12:04:01PM +0200, Christian Laursen wrote: Ivan Voras [EMAIL PROTECTED] writes: - todays desktop drives can lie about writing data. SoftUpdates relies on some assumptions about when the data is physically written to media, and those are not always valid today I think journaling relies on the same assumptions. Not gjournal, because it uses BIO_FLUSH I/O requests which flushes disk write cache when needed. -- Pawel Jakub Dawidek http://www.wheel.pl [EMAIL PROTECTED] http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! pgpQ6N4IziEQX.pgp Description: PGP signature
Re: DNS query performance
Hi Pieter, My conclusion: there's definately something wrong with your setup. Maybe you could try a different NIC to see if the performance issues are driver related. I made a new test with another hardware because HP Blade Proliant doesn't allow me to put an additional NIC - there isn't any slot available. I posted the results at freebsd-net. If you want, I think you should try my test. It's pretty simple. -- Att., Marcelo Gardini ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ARRRRGH! Guys, who's breaking -STABLE's GMIRROR code?!
On Sat, Sep 09, 2006 at 12:38:13PM -0500, Karl Denninger wrote: This is not cool folks. I'm really sorry for the breakage. I'm trying to treat -STABLE very gently, unfortunately this time I made a mistake. The change was committed to HEAD at 9 August. The change fixed one bug, but introduced another, which I didn't expected. The change seemed to be trivial and I only tested that it fixes the bug I was tracking down, I haven't looked for regressions. After nearly one month in HEAD, I MFCed the change (at 4 September), because I wanted it to be released in -BETAs, so people can test it if they already didn't in HEAD and I was quite sure that after 1 month in HEAD the change is ok. I found the problem after 4 days (at 8 September) and backed the change out from the RELENG_6 branch. Once again, I'm really sorry, I'm trying not to make such surprises to the users, unfortunately it sometimes happens and you have to be ready that many changes goes to -STABLE branch just before release, so they can be tested by a wider audience. That's why we prepare -BETAs and not release -RELEASEs immediately. I'm not writting this to justify my mistake, just trying to show how you can avoid such bad days in the future. -- Pawel Jakub Dawidek http://www.wheel.pl [EMAIL PROTECTED] http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! pgpSmq7KzBDhd.pgp Description: PGP signature
Re: ACPI resume problems in STABLE
On Wed, 13 Sep 2006 10:54:12 +0200
Henrik Brix Andersen [EMAIL PROTECTED] wrote:
I have installed
iwi-firmware-kmod-3.0_1 Intel PRO/Wireless 2200 Firmware Kernel Module
You will need net/iwi-firmware (not net/iwi-firmware-kmod) for
6.1-RELEASE.
Regards,
Brix
Hi Brix, yes, that's correct, i actually rebuilt my RELENG_6_1 kernel with
if_iwi and firmware built in, then installed net/iwi-firmware and it's working
just fine.
Resume still works great with RELENG_6_1 - i assume broken in STABLE for me...
will test 6_2 when out... or earlier if anyone could kindly point me to a date
where I should test between RELENG_6_1 and current to test.
thanks,
B
_
{Beto|Norberto|Numard} Meijome
With sufficient thrust, pigs fly just fine. However, this is not necessarily a
good idea. RFC 1925 (quoting an unnamed source)
I speak for myself, not my employer. Contents may be hot. Slippery when wet.
Reading disclaimers makes you go blind. Writing them is worse. You have been
Warned.
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: gjournal and Softupdates
Pawel Jakub Dawidek wrote: - todays desktop drives can lie about writing data. SoftUpdates relies on some assumptions about when the data is physically written to media, and those are not always valid today I think journaling relies on the same assumptions. Not gjournal, because it uses BIO_FLUSH I/O requests which flushes disk write cache when needed so when the crash occur exactly when BIO_FLUSH is sent or while the cache is flushing, there is still no corruption possbile? If so, this would be an advantage over SU, as it does surely not use the new introduced BIO_FLUSH. In the other hand i've seen couple of other JFS that went corrupt for no reason. I don't want to be paranoid, but i really want to be sure that the design is trustable. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: gjournal and Softupdates
On Wed, Sep 13, 2006 at 05:28:49PM +0200, Teufel wrote: Pawel Jakub Dawidek wrote: - todays desktop drives can lie about writing data. SoftUpdates relies on some assumptions about when the data is physically written to media, and those are not always valid today I think journaling relies on the same assumptions. Not gjournal, because it uses BIO_FLUSH I/O requests which flushes disk write cache when needed so when the crash occur exactly when BIO_FLUSH is sent or while the cache is flushing, there is still no corruption possbile? [...] That's right. One BIO_FLUSH is send to ensure the data are safely stored, and another one is send when metadata is updated to point at the last consistent journal. [...] If so, this would be an advantage over SU, as it does surely not use the new introduced BIO_FLUSH. [...] Soft-updates doesn't handle disk write caches at all. [...] In the other hand i've seen couple of other JFS that went corrupt for no reason. I don't want to be paranoid, but i really want to be sure that the design is trustable. Of course a bug in file system (or gjournal) implementation is still possible and can lead to file system corruption, but such a bug can still corrupt file system in the way it will not be fixable by fsck. From what I saw, file systems with journaling still enforce fsck every X reboots or on the next reboot after Y days of uptime, whatever comes first. -- Pawel Jakub Dawidek http://www.wheel.pl [EMAIL PROTECTED] http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! pgp18OPHAEQqf.pgp Description: PGP signature
Re: gjournal and Softupdates
Teufel wrote: so when the crash occur exactly when BIO_FLUSH is sent or while the cache is flushing, there is still no corruption possbile? A small additional note ... If there's a _hardware_ crash (e.g. power outage) which causes a track write of the HDD to be interrupted, you will get corruption. There is *no* file system that protects you from such damage, except probably Sun's ZFS in a mirror configuration (because of its COW, checksumming and self-healing features). Best regards Oliver -- Oliver Fromme, secnetix GmbH Co. KG, Marktplatz 29, 85567 Grafing Dienstleistungen mit Schwerpunkt FreeBSD: http://www.secnetix.de/bsd Any opinions expressed in this message may be personal to the author and may not necessarily reflect the opinions of secnetix in any way. Perl is worse than Python because people wanted it worse. -- Larry Wall ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ARRRRGH! Guys, who's breaking -STABLE's GMIRROR code?!
On Wed, Sep 13, 2006 at 04:46:05PM +0200, Pawel Jakub Dawidek wrote: On Sat, Sep 09, 2006 at 12:38:13PM -0500, Karl Denninger wrote: This is not cool folks. I'm really sorry for the breakage. I'm trying to treat -STABLE very gently, unfortunately this time I made a mistake. The change was committed to HEAD at 9 August. The change fixed one bug, but introduced another, which I didn't expected. The change seemed to be trivial and I only tested that it fixes the bug I was tracking down, I haven't looked for regressions. Well, after this lengthy discussion, I've switched to -RELEASE. -STABLE just ain't... We all realize that none of us would put out a buggy release--not even -CURRENT. But let me ask the next obvious question. How difficult would it be to build a regression test, or suite of tests? Obviously, this could be done over months - years. (In my last lifetime as a hacker I was in the kernel test group [a BSD-4.4 based release on new architecture]. ) It's a bit hard to believe that with all the genius in this effort, that no regression testing is done. gary -- Gary Kline [EMAIL PROTECTED] www.thought.org Public service Unix ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: gjournal and Softupdates
Pawel Jakub Dawidek wrote: [...] If so, this would be an advantage over SU, as it does surely not use the new introduced BIO_FLUSH. [...] Soft-updates doesn't handle disk write caches at all. you're totaly right. I was refering to the assumption of SU that the drive cache will not lie about its handling. [...] In the other hand i've seen couple of other JFS that went corrupt for no reason. I don't want to be paranoid, but i really want to be sure that the design is trustable. Of course a bug in file system (or gjournal) implementation is still possible and can lead to file system corruption, but such a bug can still corrupt file system in the way it will not be fixable by fsck. sooner or later bugs should be fixed. At least i will do some terrible test to gjournal in the next days. So in case expect some feedback. From what I saw, file systems with journaling still enforce fsck every X reboots or on the next reboot after Y days of uptime, whatever comes first. That is also my experience. So hopefully gjournal will be an exception for this in the future :-) Thanks for clarifying and the great job. Stephan ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ARRRRGH! Guys, who's breaking -STABLE's GMIRROR code?!
On Sep 13, 2006, at 11:15 AM, Gary Kline wrote: Well, after this lengthy discussion, I've switched to -RELEASE. -STABLE just ain't... We all realize that none of us would put out a buggy release--not even -CURRENT. But let me ask the next obvious question. How difficult would it be to build a regression test, or suite of tests? There are already a number of regression tests under /usr/src/tools/ regression; Peter Holm has additional stress testing tools at http://www.holm.cc/ stress/ -- -Chuck ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ARRRRGH! Guys, who's breaking -STABLE's GMIRROR code?!
Chuck Swiger wrote: On Sep 13, 2006, at 11:15 AM, Gary Kline wrote: ... How difficult would it be to build a regression test, or suite of tests? There are already a number of regression tests under /usr/src/tools/ regression; Are they part of an (automated) tinderbox system somewhere ? regards, Hans Lambermont ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: DNS query performance
On Mon, 11 Sep 2006, Marcelo Gardini do Amaral wrote: I would like to discuss a little bit more about UDP performance. I've made some tests and the results may have some value here. In this test is easy to see that there is something different in the FreeBSD 6 branch. I made a benchmark with bind 9.3.2 (without threads support) and nsd 3.0.1 (1 server forked) on a HP Proliant Dual AMD Opteron 2.4GHz among FreeBSD 4.11, 6.1 and Linux kernel 2.6.15, all of them for i386 systems. I used this simple zone file: Are you able to boot a 7.x kernel on this box? An as yet un-MFC'd optimization to the UDP send path is present in the 7.x kernel, suggested by ISC, which significantly improves threaded BIND9 performance. I've not benchmarked unthreaded BIND9 with the change. If you want to test specifically the before/after case for that change, you can find the reference to sosend_dgram in src/sys/netinet/udp_usrreq.c and swap it to sosend, which restores the old behavior. Robert N M Watson Computer Laboratory University of Cambridge ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: DNS query performance
On Wed, 13 Sep 2006, Robert Watson wrote: On Mon, 11 Sep 2006, Marcelo Gardini do Amaral wrote: I would like to discuss a little bit more about UDP performance. I've made some tests and the results may have some value here. In this test is easy to see that there is something different in the FreeBSD 6 branch. I made a benchmark with bind 9.3.2 (without threads support) and nsd 3.0.1 (1 server forked) on a HP Proliant Dual AMD Opteron 2.4GHz among FreeBSD 4.11, 6.1 and Linux kernel 2.6.15, all of them for i386 systems. I used this simple zone file: Are you able to boot a 7.x kernel on this box? An as yet un-MFC'd optimization to the UDP send path is present in the 7.x kernel, suggested by ISC, which significantly improves threaded BIND9 performance. I've not benchmarked unthreaded BIND9 with the change. If you want to test specifically the before/after case for that change, you can find the reference to sosend_dgram in src/sys/netinet/udp_usrreq.c and swap it to sosend, which restores the old behavior. The other common optimization advice that you may already have received is to check which time counter FreeBSD has selected. Right now, 6.x/7.x err on the side of accurate over fast. There's been quite a bit of debate about this approach, and it's useful to investigate the issue. You can view and set the current choice by looking at the sysctl kern.timecounter.hardware, and you can see the choices on your hardware by looking at kern.timecounter.choice. Typically, TSC is the fastest, but may suffer from drift as the CPU changes speed (as a result of temperature, power saving, etc). Set it to TSC if it's not already TSC, and see what the effect is. As many event libraries read time stamps frequently to set up sleeping in user space, it can have a substantial performance impact. Robert N M Watson Computer Laboratory University of Cambridge ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: DNS query performance
At 01:27 PM 9/13/2006, Robert Watson wrote: The other common optimization advice that you may already have received is to check which time counter FreeBSD has selected. Right now, 6.x/7.x err on the side of accurate over fast. There's been quite a bit of debate about this approach, and it's useful to investigate the issue. You can view and set the current choice by looking at the sysctl kern.timecounter.hardware, and you can see the choices on your hardware by looking at kern.timecounter.choice. Typically, TSC is the fastest, but may suffer from drift as the CPU changes Hi, How safe is TSC on SMP systems on RELENG_6 ? Do you still have to boot with kern.timecounter.smp_tsc=1 in /boot/loader.conf ? I was able to set it to TSC on my SMP box # sysctl kern.timecounter kern.timecounter.tick: 1 kern.timecounter.choice: TSC(-100) ACPI-fast(1000) i8254(0) dummy(-100) kern.timecounter.hardware: TSC kern.timecounter.nsetclock: 4 kern.timecounter.ngetmicrotime: 1710689523 kern.timecounter.ngetnanotime: 0 kern.timecounter.ngetbintime: 0 kern.timecounter.ngetmicrouptime: 417696361 kern.timecounter.ngetnanouptime: 6622371 kern.timecounter.ngetbinuptime: 17943777 kern.timecounter.nmicrotime: 2454574760 kern.timecounter.nnanotime: 1315721638 kern.timecounter.nbintime: 3770262461 kern.timecounter.nmicrouptime: 407340 kern.timecounter.nnanouptime: 1397760 kern.timecounter.nbinuptime: 3787035688 kern.timecounter.stepwarnings: 0 kern.timecounter.smp_tsc: 0 But the console fills up with Sep 13 13:47:57 pumice1 kernel: calcru: runtime went backwards from 6336196518 usec to 6335379728 usec for pid 66442 (clamd) Sep 13 13:47:57 pumice1 kernel: calcru: runtime went backwards from 6336196518 usec to 6335379758 usec for pid 66442 (clamd) Sep 13 13:47:57 pumice1 kernel: calcru: runtime went backwards from 6336196518 usec to 6335379789 usec for pid 66442 (clamd) Sep 13 13:47:57 pumice1 kernel: calcru: runtime went backwards from 6336196518 usec to 6335379819 usec for pid 66442 (clamd) Sep 13 13:47:57 pumice1 kernel: calcru: runtime went backwards from 6336196518 usec to 6335379849 usec for pid 66442 (clamd) Sep 13 13:47:57 pumice1 kernel: calcru: runtime went backwards from 6336196518 usec to 6335379879 usec for pid 66442 (clamd) Sep 13 13:47:57 pumice1 kernel: calcru: runtime went backwards from 6336196518 usec to 6335379910 usec for pid 66442 (clamd) Sep 13 13:47:57 pumice1 kernel: calcru: runtime went backwards from 6336196518 usec to 6335379940 usec for pid 66442 (clamd) Sep 13 13:47:57 pumice1 kernel: calcru: runtime went backwards from 6336196518 usec to 6335379970 usec for pid 66442 (clamd) Sep 13 13:47:57 pumice1 kernel: calcru: runtime went backwards from 6336196518 usec to 6335380002 usec for pid 66442 (clamd) Sep 13 13:47:57 pumice1 kernel: calcru: runtime went backwards from 6336196518 usec to 6335380032 usec for pid 66442 (clamd) Sep 13 13:47:57 pumice1 kernel: calcru: runtime went backwards from 6336196518 usec to 6335380065 usec for pid 66442 (clamd) Sep 13 13:47:57 pumice1 kernel: calcru: runtime went backwards from 6336196518 usec to 6335380096 usec for pid 66442 (clamd) Sep 13 13:47:57 pumice1 kernel: calcru: runtime went backwards from 6336196518 usec to 6335380126 usec for pid 66442 (clamd) Sep 13 13:47:57 pumice1 kernel: calcru: runtime went backwards from 6336196518 usec to 6335380156 usec for pid 66442 (clamd) Sep 13 13:47:57 pumice1 kernel: calcru: runtime went backwards from 6336196518 usec to 6335380186 usec for pid 66442 (clamd) Sep 13 13:47:57 pumice1 kernel: calcru: runtime went backwards from 6336196518 usec to 6335380216 usec for pid 66442 (clamd) Sep 13 13:47:57 pumice1 kernel: calcru: runtime went backwards from 6336196518 usec to 6335380247 usec for pid 66442 (clamd) Sep 13 13:47:57 pumice1 kernel: calcru: runtime went backwards from 6336196518 usec to 6335380277 usec for pid 66442 (clamd) Sep 13 13:47:57 pumice1 kernel: calcru: runtime went backwards from 6336196518 usec to 6335380307 usec for pid 66442 (clamd) Sep 13 13:47:57 pumice1 kernel: calcru: runtime went backwards from 6336196518 usec to 6335380337 usec for pid 66442 (clamd) So I set things back to kern.timecounter.hardware: ACPI-fast ---Mike ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
network performance problem
Hello, I`ve some problems with the network performance on my Soekris NET 4801. (Freebsd 6.1 release-p3) When I start netio on the soekris and do a netio localhost, I get about 8.4 MB/sec, and when I start with netio 192.168.0.11(it´s localhost address) I get only ~2.3 MB/sec. That´s what top says when I do: localhost CPU states: 2.3% user, 0.0% nice, 72.5% system, 25.2% interrupt, 0.0% idle 192.168.0.11 CPU states: 1.2% user, 0.0% nice, 46.3% system, 52.5% interrupt, 0.0% idle As you can see, the interrupt load is more than doubled when I use the Ip address, and I´ve no idea why. Here are some other throughput results of the soekris: openbsd# ftp 192.16.8.0.20 2.0 MB/sec openbsd# iperf localhost 1.4 Mbit/sec openbsd# iperf 192.168.0.11(it´s localhost address) 1.4 Mbit/sec openbsd# netperf localhost 70MB/sec openbsd# netperf 192.168.0.11(it´s localhost address) 70MB/sec freebsd# ftp 192.168.0.20 2.3 MB/sec Freebsd# iperf localhost 45 Mbit/sec Freebsd# iperf 192.168.0.11 (it´s localhost address) 19 Mbit/sec Freebsd# netperf localhost 67 Mbit/sec Freebsd# netperf 192.168.0.11 (it´s localhost address) 19 Mbit/sec What causes the difference between localhost and the ip address on Freebsd? On Openbsd there is no diffenerce at all. Greetings -- Erstellt mit Operas revolutionärem E-Mail-Modul: http://www.opera.com/mail/ ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ARRRRGH! Guys, who's breaking -STABLE's GMIRROR code?!
On Wed, Sep 13, 2006 at 11:15:04AM -0700, Gary Kline wrote: On Wed, Sep 13, 2006 at 04:46:05PM +0200, Pawel Jakub Dawidek wrote: On Sat, Sep 09, 2006 at 12:38:13PM -0500, Karl Denninger wrote: This is not cool folks. I'm really sorry for the breakage. I'm trying to treat -STABLE very gently, unfortunately this time I made a mistake. The change was committed to HEAD at 9 August. The change fixed one bug, but introduced another, which I didn't expected. The change seemed to be trivial and I only tested that it fixes the bug I was tracking down, I haven't looked for regressions. Well, after this lengthy discussion, I've switched to -RELEASE. -STABLE just ain't... We all realize that none of us would put out a buggy release--not even -CURRENT. But let me ask the next obvious question. How difficult would it be to build a regression test, or suite of tests? Obviously, this could be done over months - years. (In my last lifetime as a hacker I was in the kernel test group [a BSD-4.4 based release on new architecture]. ) It's a bit hard to believe that with all the genius in this effort, that no regression testing is done. I'm trying to implement regression tests to the code I add. You can find them in /usr/src/tools/regression/: geom_concat 2 files, 2 tests geom_eli15 files, 5818 tests geom_gate 3 files, 6 tests geom_mirror 7 files, 27 tests geom_nop2 files, 2 tests geom_raid3 12 files, 13 tests geom_shsec 2 files, 6 tests geom_stripe 2 files, 2 tests ipsec 1 file, 306 tests redzone91 file, 6 tests usr.bin/pkill 27 files, 49 tests As I said already, I mistakenly thought the change was trivial and the only thing I tested was if it fixes a bug I was tracking down back then. We dicuss from time to time that we should have service simlar to tinderbox, which will run regression tests regularly and report regressions to the mailing lists - the more we automate the smaller chance for a human mistake like mine. Unfortunately this is not yet done. -- Pawel Jakub Dawidek http://www.wheel.pl [EMAIL PROTECTED] http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! pgp2bvrpeTG1I.pgp Description: PGP signature
Re: ARRRRGH! Guys, who's breaking -STABLE's GMIRROR code?!
On Wed, Sep 13, 2006 at 10:26:03PM +0200, Pawel Jakub Dawidek wrote: On Wed, Sep 13, 2006 at 11:15:04AM -0700, Gary Kline wrote: On Wed, Sep 13, 2006 at 04:46:05PM +0200, Pawel Jakub Dawidek wrote: On Sat, Sep 09, 2006 at 12:38:13PM -0500, Karl Denninger wrote: This is not cool folks. I'm really sorry for the breakage. I'm trying to treat -STABLE very gently, unfortunately this time I made a mistake. The change was committed to HEAD at 9 August. The change fixed one bug, but introduced another, which I didn't expected. The change seemed to be trivial and I only tested that it fixes the bug I was tracking down, I haven't looked for regressions. Well, after this lengthy discussion, I've switched to -RELEASE. -STABLE just ain't... We all realize that none of us would put out a buggy release--not even -CURRENT. But let me ask the next obvious question. How difficult would it be to build a regression test, or suite of tests? Obviously, this could be done over months - years. (In my last lifetime as a hacker I was in the kernel test group [a BSD-4.4 based release on new architecture]. ) It's a bit hard to believe that with all the genius in this effort, that no regression testing is done. I'm trying to implement regression tests to the code I add. You can find them in /usr/src/tools/regression/: geom_concat 2 files, 2 tests geom_eli15 files, 5818 tests geom_gate 3 files, 6 tests geom_mirror 7 files, 27 tests geom_nop2 files, 2 tests geom_raid3 12 files, 13 tests geom_shsec 2 files, 6 tests geom_stripe 2 files, 2 tests ipsec 1 file, 306 tests redzone91 file, 6 tests usr.bin/pkill 27 files, 49 tests As I said already, I mistakenly thought the change was trivial and the only thing I tested was if it fixes a bug I was tracking down back then. We dicuss from time to time that we should have service simlar to tinderbox, which will run regression tests regularly and report regressions to the mailing lists - the more we automate the smaller chance for a human mistake like mine. Unfortunately this is not yet done. You're right in saying that the more automation, the more stability. Hats off for all this good work (from somebody who has been there before:) This is the kind of thing tht needs to be done (i) to catch bugs before they are committed, and (ii) to make BSD all the more trustworthy and bullet-proof. HAving run FBSD since 2.0.5 and only *one* fatal trap is pretty hard to beat. gary -- Pawel Jakub Dawidek http://www.wheel.pl [EMAIL PROTECTED] http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! -- Gary Kline [EMAIL PROTECTED] www.thought.org Public service Unix ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: gjournal and Softupdates
On Wednesday 13 September 2006 23:53, Pawel Jakub Dawidek wrote: On Tue, Sep 12, 2006 at 12:04:01PM +0200, Christian Laursen wrote: Ivan Voras [EMAIL PROTECTED] writes: - todays desktop drives can lie about writing data. SoftUpdates relies on some assumptions about when the data is physically written to media, and those are not always valid today I think journaling relies on the same assumptions. Not gjournal, because it uses BIO_FLUSH I/O requests which flushes disk write cache when needed. It should be possible to use this same mechanism for SU too, right? Of course that may result in really poor write performance :) -- 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 GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C pgp48ku6K4tA0.pgp Description: PGP signature
Re: optimization levels for 6-STABLE build{kernel,world}
On Wed, Sep 13, 2006 at 12:17:15PM +0300, Stefan Lambrev wrote: Hello, Oliver Fromme wrote: Marc G. Fournier [EMAIL PROTECTED] wrote: What are ppl currently using for CFLAGS/COPTFLAGS in /etc/make.conf for building kernel/world? I know awhile back it wasn't recommended to go above -O2, for instance, but suspect that has changed ... ? The best optimization is probably to not override the defaults at all, because they're already pretty optimal. In fact, by overriding the defaults there's a good chance to make things worse. :-) The default CFLAGS are -O2 -pipe -fno-strict-aliasing. Anything above -O2 isn't supported, and using -O2 without -fno-strict-aliasing also isn't supported (and will create broken code for some programs). A common mistake is to specify CFLAGS=-O2 -pipe and omit -fno-strict-aliasing. That'll shot you in the foot sooner or later. Best regards Oliver May be default flags have to be set here: /usr/src/share/examples/etc/make.conf ? I'm asking because in this file I read: # CFLAGS controls the compiler settings used when compiling C code. # Note that optimization settings other than -O and -O2 are not recommended # or supported for compiling the world or the kernel - please revert any # nonstandard optimization settings to -O or -O2 before submitting bug # reports without patches to the developers. # #CFLAGS= -O -pipe May be -fno-strict-aliasing have to be added here then ? A couple of things. Will having gcc unroll loops have any negative consequences? (I can't imagine how:: but better informed than to have something crash inexplicability.) With 6.X safe at -O2 and with -funroll-loops, that should be a slight gain, right? (It also will make an upgrade from 5.5 to 6.[12] that much more rational.) [Dumb] questions:: first, what does the compiler do with -fno-strict-aliasing? And is there any guess, any SWAG even, on when FreeBSD will safe with -O3?? thanks, people, gary -- Best Wishes, Stefan Lambrev ICQ# 24134177 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED] -- Gary Kline [EMAIL PROTECTED] www.thought.org Public service Unix ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: optimization levels for 6-STABLE build{kernel,world}
On Wed, Sep 13, 2006 at 12:17:15PM +0300, Stefan Lambrev wrote: Hello, Oliver Fromme wrote: Marc G. Fournier [EMAIL PROTECTED] wrote: What are ppl currently using for CFLAGS/COPTFLAGS in /etc/make.conf for building kernel/world? I know awhile back it wasn't recommended to go above -O2, for instance, but suspect that has changed ... ? The best optimization is probably to not override the defaults at all, because they're already pretty optimal. In fact, by overriding the defaults there's a good chance to make things worse. :-) The default CFLAGS are -O2 -pipe -fno-strict-aliasing. Anything above -O2 isn't supported, and using -O2 without -fno-strict-aliasing also isn't supported (and will create broken code for some programs). A common mistake is to specify CFLAGS=-O2 -pipe and omit -fno-strict-aliasing. That'll shot you in the foot sooner or later. Best regards Oliver May be default flags have to be set here: /usr/src/share/examples/etc/make.conf ? I'm asking because in this file I read: # CFLAGS controls the compiler settings used when compiling C code. # Note that optimization settings other than -O and -O2 are not recommended # or supported for compiling the world or the kernel - please revert any # nonstandard optimization settings to -O or -O2 before submitting bug # reports without patches to the developers. # #CFLAGS= -O -pipe May be -fno-strict-aliasing have to be added here then ? A couple of things. Will having gcc unroll loops have any negative consequences? (I can't imagine how:: but better informed than to have something crash inexplicability.) With 6.X safe at -O2 and with -funroll-loops, that should be a slight gain, right? (It also will make an upgrade from 5.5 to 6.[12] that much more rational.) [Dumb] questions:: first, what does the compiler do with -fno-strict-aliasing? And is there any guess, any SWAG even, on when FreeBSD will safe with -O3?? Lots of code is not strict-aliasing safe. Gcc itself can't determine all the cases which a construct is not strict-aliasing safe so even after getting rid of all the warnings gcc produces you can't be sure your code is strict-aliasing safe. Think of -fstrict-aliasing as optimisation without a saftey net. If your code doesn't cast pointers you should be safe otherwise you need to be really, really, really careful when you turn this on. thanks, people, gary -- Best Wishes, Stefan Lambrev ICQ# 24134177 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED] -- Gary Kline [EMAIL PROTECTED] www.thought.org Public service Unix ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED] -- ISC Training! October 16-20, 2006, in the San Francisco Bay Area, covering topics from DNS to DHCP. Email [EMAIL PROTECTED] -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: optimization levels for 6-STABLE build{kernel,world}
Gary Kline wrote: deleted A couple of things. Will having gcc unroll loops have any negative consequences? (I can't imagine how:: but better informed than to have something crash inexplicability.) With 6.X safe at -O2 and with -funroll-loops, that should be a slight gain, right? (It also will make an upgrade from 5.5 to 6.[12] that much more rational.) -funroll-loops affect loader see http://lists.freebsd.org/pipermail/freebsd-stable/2006-September/028145.html -- tonym ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: optimization levels for 6-STABLE build{kernel,world}
On Sep 13, 2006, at 4:49 PM, Gary Kline wrote: A couple of things. Will having gcc unroll loops have any negative consequences? Yes, it certainly can have negative consequences. The primary intent of using that option is to change a loop from executing the test or control block for each iteration that the body is executed, to executing the loop body several times and checking the test or control block less often. The issue is that there is often additional setup or post-loop fixups to ensure that the loop body actually is executed the right number of times, which makes the generated binary code much larger. This can mean that the loop no longer fits within the L1 instruction cache, which will usually result in the program going slower, rather than faster. Using the option will always increase the size of compiled executables. (I can't imagine how:: but better informed than to have something crash inexplicability.) With 6.X safe at -O2 and with -funroll-loops, that should be a slight gain, right? -funroll-loops is as likely to decrease performance for a particular program as it is to help. One particular caveat with using that option is that the increase in program size apparently causes the initial bootloader code to no longer fit within a single sector, making the system unbootable. [Dumb] questions:: first, what does the compiler do with -fno-strict-aliasing? It prevents the compiler from generating buggy output from source code which uses type-punning. http://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html A safe optimizer must assume that an arbitrary assignment via a pointer dereference can change any value in memory, which means that you have to spill and reload any data being cached in CPU registers around the use of the pointer, except for const's, variables declared as register, and possibly function arguments being passed via registers and not on the stack (cf register windows on the SPARC hardware, or HP/PA's calling conventions). -- -Chuck ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: em0: watchdog timeout -- resetting (6.1-STABLE)
On Tue, 05 Sep 2006 23:52:05 +0200, Ronald Klop [EMAIL PROTECTED] wrote: Hello, I get these errors a lot. Sep 5 11:55:12 ronald kernel: em0: watchdog timeout -- resetting Sep 5 11:55:12 ronald kernel: em0: link state changed to DOWN Sep 5 11:55:14 ronald kernel: em0: link state changed to UP Sep 5 12:00:37 ronald kernel: em0: watchdog timeout -- resetting Sep 5 12:00:37 ronald kernel: em0: link state changed to DOWN Sep 5 12:00:39 ronald kernel: em0: link state changed to UP I tried turning off rxcsum/txcsum and set these sysctl's. dev.em.0.rx_int_delay: 0 dev.em.0.tx_int_delay: 0 (default 66) But the error is still there. Searching the internet and the list provides more of the same problems, but I didn't find an answer. My dmesg is attached. Is there any info I need to provide to debug this or can I try patches? Them manual page em(4) mentions trying another cable when the watchdog timeout happens, so I tried that. But it didn't help. Is there anything I can test to (help) debug this? It happens a lot when my machine is under load. (100% CPU) Is it possible that it happens since I upgraded the memory from 1GB to 2 GB? (dmesg was attached to my previous mail, but I can provide it again.) Ronald. -- Ronald Klop Amsterdam, The Netherlands ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ARRRRGH! Guys, who's breaking -STABLE's GMIRROR code?! - back to Pawel
On Wed, Sep 13, 2006 at 04:46:05PM +0200, Pawel Jakub Dawidek wrote: On Sat, Sep 09, 2006 at 12:38:13PM -0500, Karl Denninger wrote: This is not cool folks. I'm really sorry for the breakage. I'm trying to treat -STABLE very gently, unfortunately this time I made a mistake. (elided) Thank you Pawel for the explanation. I understand that things go wrong; as a software developer I've let bad code out of the barn before. I try like hell not to have it happen, but it has The explanation is appreciated. BTW, part of the issue here with the -BETA thing is that there's no clear timeline on this available to people. I certainly was not aware that you were in a pre-check period to locking down the code to start the process of burning the next minor official rev. BTW, if this is indeed the case, you guys definitely need to look at the PR I filed on the Rcoketport driver. That problem either needs to be found and taken care of or those boards need to come out of the supported hardware list for the next release - its definitely broken, and the cause is not something immediately obvious (or I would have fixed it by now!) I AM efforting this but its its only got a moderate priority around here right now. -- -- Karl Denninger ([EMAIL PROTECTED]) Internet Consultant Kids Rights Activist http://www.denninger.netMy home on the net - links to everything I do! http://scubaforum.org Your UNCENSORED place to talk about DIVING! http://genesis3.blogspot.comMusings Of A Sentient Mind ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ARRRRGH! Guys, who's breaking -STABLE's GMIRROR code?! - back to Pawel
On Sep 13, 2006, at 21:00, Karl Denninger wrote: BTW, part of the issue here with the -BETA thing is that there's no clear timeline on this available to people. I certainly was not aware that you were in a pre-check period to locking down the code to start the process of burning the next minor official rev. Some upcoming release information is available online: http://www.freebsd.org/releng/ ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 6.2? (fwd)
On Wed, 13 Sep 2006 12:53:29 +0100
Pete French [EMAIL PROTECTED] wrote:
I disagree, I would like to have an notice about it. Even though it might
not say much. Just a The code of the stable branch has been freezed due
to the upcomming release of X.Y
It is kind of useful, because it's the code freeze point at which I start
re-scheduling my work day so I can do BSD testing. I can't justify tracking
all the time on work machine unfortunately, but I do like to make an effort
to test thoroughly before something is released (the more the better, right?)
so it's good to know these things.
I agree with this - yet another automated email wont really hurt, specially if
it conveys useful information ;)
_
{Beto|Norberto|Numard} Meijome
...using the internet as it was originally intended... for the further research
of pornography and pipebombs.
I speak for myself, not my employer. Contents may be hot. Slippery when wet.
Reading disclaimers makes you go blind. Writing them is worse. You have been
Warned.
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: em0: watchdog timeout -- resetting (6.1-STABLE)
Sep 5 11:55:12 ronald kernel: em0: watchdog timeout -- resetting I got a bazillion of these, and a completely unusable machine, when I upgraded to 6.1-stable sources as of two days ago. The machine would simply freeze for minutes at a time. Going back to my previous kernel (dating from late July) made everything just fine. So something got seriously broken in the em driver in the last few weeks. -David. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: em0: watchdog timeout -- resetting (6.1-STABLE)
At 10:20 PM 9/13/2006, David Myers wrote: Sep 5 11:55:12 ronald kernel: em0: watchdog timeout -- resetting I got a bazillion of these, and a completely unusable machine, when I upgraded to 6.1-stable sources as of two days ago. The machine would simply freeze for minutes at a time. Going back to my previous kernel (dating from late July) made everything just fine. So something got seriously broken in the em driver in the last few weeks. Which version of the NIC do you have ? (pciconf -lv ) ---Mike ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: em0: watchdog timeout -- resetting (6.1-STABLE)
On 9/13/06, Ronald Klop [EMAIL PROTECTED] wrote: ... Them manual page em(4) mentions trying another cable when the watchdog timeout happens, so I tried that. But it didn't help. Is there anything I can test to (help) debug this? It happens a lot when my machine is under load. (100% CPU) Is it possible that it happens since I upgraded the memory from 1GB to 2 GB? watchdogs mean that the transmit ring is not being cleaned, so the question is what is your machine doing at 100% cpu, if its that busy the network watchdogs may just be a side effect and not the real problem? Jack ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
FreeBSD does not use all cpus on top show.
hi, I have HP Server install FreeBSD 6.1R/amd64 with 2CPUs ,2 logical CPUs per core. On top show, It should show 4 cpus, but I never see 1 and 3 cpu on show. Does anything I miss? --hwh # dmesg Copyright (c) 1992-2006 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 6.1-RELEASE #0: Sun May 7 04:15:57 UTC 2006 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/SMP ACPI APIC Table: HP 0083 Timecounter i8254 frequency 1193182 Hz quality 0 CPU: Intel(R) Xeon(TM) CPU 3.20GHz (3200.13-MHz K8-class CPU) Origin = GenuineIntel Id = 0xf4a Stepping = 10 Features=0xbfebfbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE Features2=0x641dSSE3,RSVD2,MON,DS_CPL,CNTX-ID,CX16,b14 AMD Features=0x2800SYSCALL,LM AMD Features2=0x1LAHF Logical CPUs per core: 2 real memory = 6912208896 (6591 MB) avail memory = 6150582272 (5865 MB) FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 cpu2 (AP): APIC ID: 6 cpu3 (AP): APIC ID: 7 ioapic0 Version 2.0 irqs 0-23 on motherboard ioapic1 Version 2.0 irqs 24-47 on motherboard ioapic2 Version 2.0 irqs 48-71 on motherboard ioapic3 Version 2.0 irqs 72-95 on motherboard ioapic4 Version 2.0 irqs 96-119 on motherboard kbd1 at kbdmux0 acpi0: HP P51 on motherboard acpi0: Power Button (fixed) Timecounter ACPI-safe frequency 3579545 Hz quality 1000 acpi_timer0: 24-bit timer at 3.579545MHz port 0x908-0x90b on acpi0 cpu0: ACPI CPU on acpi0 cpu1: ACPI CPU on acpi0 cpu2: ACPI CPU on acpi0 cpu3: ACPI CPU on acpi0 pcib0: ACPI Host-PCI bridge on acpi0 pci0: ACPI PCI bus on pcib0 pcib1: ACPI PCI-PCI bridge at device 2.0 on pci0 pci2: ACPI PCI bus on pcib1 pcib2: ACPI PCI-PCI bridge at device 0.0 on pci2 pci3: ACPI PCI bus on pcib2 bge0: Broadcom BCM5704C Dual Gigabit Ethernet, ASIC rev. 0x2100 mem 0xfdef-0xfdef irq 25 at device 1.0 on pci3 miibus0: MII bus on bge0 brgphy0: BCM5704 10/100/1000baseTX PHY on miibus0 brgphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseTX, 1000baseTX-FDX, auto bge0: Ethernet address: 00:18:71:74:2a:bf bge1: Broadcom BCM5704C Dual Gigabit Ethernet, ASIC rev. 0x2100 mem 0xfdee-0xfdee irq 26 at device 1.1 on pci3 miibus1: MII bus on bge1 brgphy1: BCM5704 10/100/1000baseTX PHY on miibus1 brgphy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseTX, 1000baseTX-FDX, auto bge1: Ethernet address: 00:18:71:74:2a:be pcib3: ACPI PCI-PCI bridge at device 0.2 on pci2 pci4: ACPI PCI bus on pcib3 ciss0: HP Smart Array 6i port 0x4000-0x40ff mem 0xfdff-0xfdff1fff,0xfdf8-0xfdfb irq 51 at device 3.0 on pci4 ciss0: [GIANT-LOCKED] pcib4: ACPI PCI-PCI bridge at device 6.0 on pci0 pci5: ACPI PCI bus on pcib4 pcib5: ACPI PCI-PCI bridge at device 0.0 on pci5 pci6: ACPI PCI bus on pcib5 pcib6: ACPI PCI-PCI bridge at device 0.2 on pci5 pci10: ACPI PCI bus on pcib6 uhci0: Intel 82801EB (ICH5) USB controller USB-A port 0x2000-0x201f irq 16 at device 29.0 on pci0 uhci0: [GIANT-LOCKED] usb0: Intel 82801EB (ICH5) USB controller USB-A 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 uhci1: Intel 82801EB (ICH5) USB controller USB-B port 0x2020-0x203f irq 19 at device 29.1 on pci0 uhci1: [GIANT-LOCKED] usb1: Intel 82801EB (ICH5) USB controller USB-B on uhci1 usb1: USB revision 1.0 uhub1: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub1: 2 ports with 2 removable, self powered uhci2: Intel 82801EB (ICH5) USB controller USB-C port 0x2040-0x205f irq 18 at device 29.2 on pci0 uhci2: [GIANT-LOCKED] usb2: Intel 82801EB (ICH5) USB controller USB-C on uhci2 usb2: USB revision 1.0 uhub2: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub2: 2 ports with 2 removable, self powered uhci3: Intel 82801EB (ICH5) USB controller USB-D port 0x2060-0x207f irq 16 at device 29.3 on pci0 uhci3: [GIANT-LOCKED] usb3: Intel 82801EB (ICH5) USB controller USB-D on uhci3 usb3: USB revision 1.0 uhub3: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub3: 2 ports with 2 removable, self powered ehci0: Intel 82801EB/R (ICH5) USB 2.0 controller mem 0xfbef-0xfbef03ff irq 23 at device 29.7 on pci0 ehci0: [GIANT-LOCKED] usb4: EHCI version 1.0 usb4: companion controllers, 2 ports each: usb0 usb1 usb2 usb3 usb4: Intel 82801EB/R (ICH5) USB 2.0 controller on ehci0 usb4: USB revision 2.0 uhub4: Intel EHCI root hub, class 9/0, rev 2.00/1.00, addr 1 uhub4: 8 ports with 8 removable, self powered pcib7: ACPI PCI-PCI bridge at device 30.0 on pci0 pci1: ACPI PCI bus on pcib7 pci1: display, VGA at device 3.0 (no driver attached) pci1: base peripheral at device 4.0 (no driver attached) pci1: base peripheral at device 4.2 (no driver attached) isab0: PCI-ISA bridge at device 31.0 on pci0 isa0: ISA bus on isab0 atapci0: Intel ICH5 UDMA100 controller port
Re: ARRRRGH! Guys, who's breaking -STABLE's GMIRROR code?!
On Tue, 12 Sep 2006, Steve O'Hara-Smith wrote: On Tue, 12 Sep 2006 10:55:48 -0500 Greg Barniskis [EMAIL PROTECTED] wrote: If you /track/ STABLE by frequently cvsupping it and rebuilding your system, you will very likely encounter a serious problem sooner or later. That's why tracking it is not recommended for production systems. I did exactly that all the way from 2.0 to 4.11 on various machines without ever having any trouble. Ditto ... in fact, I do that on my desktop and have yet to hit a problem ... -STABLE *is* generally very stable ... Stupid question here ... if -STABLE shouldn't be tracked, who exactly is doing testing on it? Those doing the work on -CURRENT, I would imagine, are tracking -CURRENT, and testing the code put in there for bugs ... when deemed 'bug free', then its being MFCd to -STABLE, but if those of us that *are* tracking -STABLE stop'd tracking it ... who would be testing it? Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email . [EMAIL PROTECTED] MSN . [EMAIL PROTECTED] Yahoo . yscrappy Skype: hub.orgICQ . 7615664 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: optimization levels for 6-STABLE build{kernel,world}
On Wed, Sep 13, 2006 at 05:25:35PM -0700, Chuck Swiger wrote: On Sep 13, 2006, at 4:49 PM, Gary Kline wrote: A couple of things. Will having gcc unroll loops have any negative consequences? Yes, it certainly can have negative consequences. The primary intent of using that option is to change a loop from executing the test or control block for each iteration that the body is executed, to executing the loop body several times and checking the test or control block less often. The issue is that there is often additional setup or post-loop fixups to ensure that the loop body actually is executed the right number of times, which makes the generated binary code much larger. This can mean that the loop no longer fits within the L1 instruction cache, which will usually result in the program going slower, rather than faster. Using the option will always increase the size of compiled executables. (I can't imagine how:: but better informed than to have something crash inexplicability.) With 6.X safe at -O2 and with -funroll-loops, that should be a slight gain, right? -funroll-loops is as likely to decrease performance for a particular program as it is to help. Isn't the compiler intelligent enough to have a reasonable limit, N, of the loops it will unroll to ensure a faster runtime? Something much less than 1000, say; possibly less than 100. At least, if the initializiation and end-loop code *plus* the loop code itself were too large for the cache, my thought is that gcc would back out. Imay be giving RMS too much credit; but if memory serves, thed compiler was GNU's first project. And Stallman was into GOFAI, c, for better/worse.[1] Anyway, for now I'll comment out the unroll-loops arg. One particular caveat with using that option is that the increase in program size apparently causes the initial bootloader code to no longer fit within a single sector, making the system unbootable. [Dumb] questions:: first, what does the compiler do with -fno-strict-aliasing? It prevents the compiler from generating buggy output from source code which uses type-punning. http://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html A safe optimizer must assume that an arbitrary assignment via a pointer dereference can change any value in memory, which means that you have to spill and reload any data being cached in CPU registers around the use of the pointer, except for const's, variables declared as register, and possibly function arguments being passed via registers and not on the stack (cf register windows on the SPARC hardware, or HP/PA's calling conventions). Well, I'd added the no-strict-aliasing flag to make.conf! Pointers give me indigestion ... even after all these years. Thanks for your insights. And the URL. gary [1]. Seems to me that good old-fashioned AI techniques would work in something like a compiler where you probblyhave a good idea of most heuristics. -gk -- -Chuck ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED] -- Gary Kline [EMAIL PROTECTED] www.thought.org Public service Unix ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ARRRRGH! Guys, who's breaking -STABLE's GMIRROR code?!
On Thu, Sep 14, 2006 at 01:37:53AM -0300, Marc G. Fournier wrote: On Tue, 12 Sep 2006, Steve O'Hara-Smith wrote: On Tue, 12 Sep 2006 10:55:48 -0500 Greg Barniskis [EMAIL PROTECTED] wrote: If you /track/ STABLE by frequently cvsupping it and rebuilding your system, you will very likely encounter a serious problem sooner or later. That's why tracking it is not recommended for production systems. I did exactly that all the way from 2.0 to 4.11 on various machines without ever having any trouble. Ditto ... in fact, I do that on my desktop and have yet to hit a problem ... -STABLE *is* generally very stable ... Stupid question here ... if -STABLE shouldn't be tracked No-one's said that, so yeah, not the best question ;^) Kris pgpBQxxydV6Mf.pgp Description: PGP signature
Re: ARRRRGH! Guys, who's breaking -STABLE's GMIRROR code?!
Marc G. Fournier wrote: On Tue, 12 Sep 2006, Steve O'Hara-Smith wrote: On Tue, 12 Sep 2006 10:55:48 -0500 Greg Barniskis [EMAIL PROTECTED] wrote: If you /track/ STABLE by frequently cvsupping it and rebuilding your system, you will very likely encounter a serious problem sooner or later. That's why tracking it is not recommended for production systems. I did exactly that all the way from 2.0 to 4.11 on various machines without ever having any trouble. Ditto ... in fact, I do that on my desktop and have yet to hit a problem ... -STABLE *is* generally very stable ... Stupid question here ... if -STABLE shouldn't be tracked, who exactly is doing testing on it? Those doing the work on -CURRENT, I would imagine, are tracking -CURRENT, and testing the code put in there for bugs ... when deemed 'bug free', then its being MFCd to -STABLE, but if those of us that *are* tracking -STABLE stop'd tracking it ... who would be testing it? It is not that you should not track it but where you should be tracking/testing it. Not on critical production servers would be a good start ;-) -- tonym ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: optimization levels for 6-STABLE build{kernel,world}
On Thu, Sep 14, 2006 at 10:07:35AM +1000, Tony Maher wrote: Gary Kline wrote: deleted A couple of things. Will having gcc unroll loops have any negative consequences? (I can't imagine how:: but better informed than to have something crash inexplicability.) With 6.X safe at -O2 and with -funroll-loops, that should be a slight gain, right? (It also will make an upgrade from 5.5 to 6.[12] that much more rational.) -funroll-loops affect loader see http://lists.freebsd.org/pipermail/freebsd-stable/2006-September/028145.html Right. This is probably what Chuck Swiger was talking about. I've never had this problems on my 5.[345] releases. And not with 6.1 (knock-wood!!). I've just upgraded to -RELEASE and going to rebuild overnight on the server that traped out. With -funroll-loops gone :-) gary -- tonym -- Gary Kline [EMAIL PROTECTED] www.thought.org Public service Unix ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: optimization levels for 6-STABLE build{kernel,world}
On Wed, Sep 13, 2006 at 09:57:25PM -0700, Gary Kline wrote: On Thu, Sep 14, 2006 at 10:07:35AM +1000, Tony Maher wrote: Gary Kline wrote: deleted A couple of things. Will having gcc unroll loops have any negative consequences? (I can't imagine how:: but better informed than to have something crash inexplicability.) With 6.X safe at -O2 and with -funroll-loops, that should be a slight gain, right? (It also will make an upgrade from 5.5 to 6.[12] that much more rational.) -funroll-loops affect loader see http://lists.freebsd.org/pipermail/freebsd-stable/2006-September/028145.html Right. This is probably what Chuck Swiger was talking about. I've never had this problems on my 5.[345] releases. And not with 6.1 (knock-wood!!). I've just upgraded to -RELEASE and going to rebuild overnight on the server that traped out. With -funroll-loops gone :-) Just leave it alone unless you know what you're doing...fiddling with the compiler flags just isn't going to give you a secret performance boost for general workloads, no matter how cool it might make you feel :) Kris pgp1sijwu2NnV.pgp Description: PGP signature
Re: 6.2? (fwd)
On Wed, 13 Sep 2006 13:07:20 +0200 (CEST) kama [EMAIL PROTECTED] wrote: On Wed, 13 Sep 2006, Oliver Fromme wrote: That's true, and the schedule will most probably change. Currently the release is listed for Oct. 9th, but I bet that it'll be delayed. I disagree, I would like to have an notice about it. Even though it might not say much. Just a The code of the stable branch has been freezed due to the upcomming release of X.Y I agree with Kama. I specificly switched once to stable for pre-release testing purpose. I saw email from one of the developers claiming that not many people join pre-release testing. (I do not remember whether it was not many people join BETA testing or RC testing. Anyway, I saw it in one of the quota issue e-mail chain on 6.1-RELEASE.) If we are not in such a stage, I personally prefer to stick with releases. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: optimization levels for 6-STABLE build{kernel,world}
On Thu, Sep 14, 2006 at 10:02:37AM +1000, Mark Andrews wrote: On Wed, Sep 13, 2006 at 12:17:15PM +0300, Stefan Lambrev wrote: Hello, Oliver Fromme wrote: Marc G. Fournier [EMAIL PROTECTED] wrote: What are ppl currently using for CFLAGS/COPTFLAGS in /etc/make.conf for building kernel/world? I know awhile back it wasn't recommended to go above -O2, for instance, but suspect that has changed ... ? The best optimization is probably to not override the defaults at all, because they're already pretty optimal. In fact, by overriding the defaults there's a good chance to make things worse. :-) The default CFLAGS are -O2 -pipe -fno-strict-aliasing. Anything above -O2 isn't supported, and using -O2 without -fno-strict-aliasing also isn't supported (and will create broken code for some programs). A common mistake is to specify CFLAGS=-O2 -pipe and omit -fno-strict-aliasing. That'll shot you in the foot sooner or later. Best regards Oliver [[ ... ]] A couple of things. Will having gcc unroll loops have any negative consequences? (I can't imagine how:: but better informed than to have something crash inexplicability.) With 6.X safe at -O2 and with -funroll-loops, that should be a slight gain, right? (It also will make an upgrade from 5.5 to 6.[12] that much more rational.) [Dumb] questions:: first, what does the compiler do with -fno-strict-aliasing? And is there any guess, any SWAG even, on when FreeBSD will safe with -O3?? Lots of code is not strict-aliasing safe. Gcc itself can't determine all the cases which a construct is not strict-aliasing safe so even after getting rid of all the warnings gcc produces you can't be sure your code is strict-aliasing safe. Think of -fstrict-aliasing as optimisation without a saftey net. If your code doesn't cast pointers you should be safe otherwise you need to be really, really, really careful when you turn this on. Well, my own pointer code is pretty trustworthy. It's also pretty simple-minded and thoroughly tested, even tho it's just for my own use. Other's code, dunno. People who cut their teeth on pointers and may be just a wee bit cavalier: *Bzzz* Point well taken. -- Gary Kline [EMAIL PROTECTED] www.thought.org Public service Unix ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
