Re: INVARIANTS (was Re: RELENG_4 -> 5 -> 6: significant performance regression)

Hello! On Sat, 13 May 2006, Matthew D. Fuller wrote: On Sat, May 13, 2006 at 11:58:26AM -0400 I heard the voice of Kris Kennaway, and lo! it spake thus: FYI, INVARIANTS adds checks but does not (is not supposed to) divert code paths. It does at least in UMA; it does a lot of bzero()/NULL'in

Re: RELENG_4 -> 5 -> 6: significant performance regression

Hello! On Sat, 13 May 2006, Jonathan Noack wrote: Have you tried putting I586_CPU in there? See http://lists.freebsd.org/pipermail/freebsd-stable/2005-December/020696.html. Thanks for suggestion. I've just tried it, performance difference is indistinguishable. Also, use the link0 option w

Re: INVARIANTS (was Re: RELENG_4 -> 5 -> 6: significant performance regression)

Matthew D. Fuller wrote: > On Sat, May 13, 2006 at 11:58:26AM -0400 I heard the voice of > Kris Kennaway, and lo! it spake thus: > > > > FYI, INVARIANTS adds checks but does not (is not supposed to) divert > > code paths. > > It does at least in UMA; it does a lot of bzero()/NULL'ing out of > mem

Re: INVARIANTS (was Re: RELENG_4 -> 5 -> 6: significant performance regression)

On Sat, May 13, 2006 at 11:58:26AM -0400 I heard the voice of Kris Kennaway, and lo! it spake thus: > > FYI, INVARIANTS adds checks but does not (is not supposed to) divert > code paths. It does at least in UMA; it does a lot of bzero()/NULL'ing out of memory, which might hide later uninitialized

Re: INVARIANTS (was Re: RELENG_4 -> 5 -> 6: significant performance regression)

On Sat, May 13, 2006 at 10:52:32AM -0500, Matthew D. Fuller wrote: > On Sat, May 13, 2006 at 10:37:40AM -0400 I heard the voice of > Kris Kennaway, and lo! it spake thus: > > > > With respect to INVARIANTS, you just need to get used to the fact > > that running thousands of checks for bugs is inco

INVARIANTS (was Re: RELENG_4 -> 5 -> 6: significant performance regression)

On Sat, May 13, 2006 at 10:37:40AM -0400 I heard the voice of Kris Kennaway, and lo! it spake thus: > > With respect to INVARIANTS, you just need to get used to the fact > that running thousands of checks for bugs is incompatible with > running at optimal speed. (I'm not sure what the point of sa

Re: RELENG_4 -> 5 -> 6: significant performance regression

On Sat, May 13, 2006 at 08:59:01AM +0300, Dmitry Pryanishnikov wrote: > > Hello! > > On Fri, 12 May 2006, Kris Kennaway wrote: > >> %Sys %Intr %Idl > >>RELENG_6 + rl0 45 40 15 > >>RELENG_6 + fxp0 45 35 20 > >>> > %Sys

Re: RELENG_4 -> 5 -> 6: significant performance regression

On Sat, May 13, 2006 at 08:59:01AM +0300, Dmitry Pryanishnikov wrote: > I'm just trying to understand why performance of RELENG_6 is worse than > in RELENG_4 _that much_, and whether this sad situation can be improved > somehow. The architecture of the system substantially changed in the 5.X timef

Re: RELENG_4 -> 5 -> 6: significant performance regression

On Sat, May 13, 2006 at 03:01:18AM -0400 I heard the voice of Jonathan Noack, and lo! it spake thus: > > Have you tried putting I586_CPU in there? See > http://lists.freebsd.org/pipermail/freebsd-stable/2005-December/020696.html. As Peter Jeremy mentioned in

Re: RELENG_4 -> 5 -> 6: significant performance regression

On 05/13/06 01:59, Dmitry Pryanishnikov wrote: > On Fri, 12 May 2006, Kris Kennaway wrote: >>>%Sys %Intr %Idl >>> RELENG_6 + rl0 45 40 15 >>> RELENG_6 + fxp0 45 35 20 > %Sys %Intr %Idl "time md5 -t" wall clock

Re: RELENG_4 -> 5 -> 6: significant performance regression

Hello! On Fri, 12 May 2006, Kris Kennaway wrote: So maybe it's time to add, say, options INVARIANTS_EXTENDED for these new and expensive checks, and leave only basic and cheap (yet effective for bug hunting) asserts enabled when only options INVARIANTS is defined? No, they are

Re: RELENG_4 -> 5 -> 6: significant performance regression

Hello! On Fri, 12 May 2006, Kris Kennaway wrote: %Sys %Intr %Idl RELENG_6 + rl0 45 40 15 RELENG_6 + fxp0 45 35 20 %Sys %Intr %Idl "time md5 -t" wall clock time RELENG_6 + rl0 34 24 42 1:43 RELENG_6 + fxp0

Re: RELENG_4 -> 5 -> 6: significant performance regression

On Fri, May 12, 2006 at 11:25:58PM +0300, Dmitry Pryanishnikov wrote: > > Hello! > > On Fri, 28 Apr 2006, Kris Kennaway wrote: > makeoptions CONF_CFLAGS=-fno-builtin > >I don't know, it needs to be tested in your particular case. > > I've built another kernel, adding back > > makeopt

Re: RELENG_4 -> 5 -> 6: significant performance regression

On Fri, May 12, 2006 at 11:32:44PM +0300, Dmitry Pryanishnikov wrote: > > Hello! > > On Tue, 2 May 2006, Robert Watson wrote: > >>options INVARIANTS > >>options INVARIANT_SUPPORT > > > >In FreeBSD 5.x and FreeBSD 6.x, the INVARIANTS option has been > >significantly expanded to test a muc

Re: RELENG_4 -> 5 -> 6: significant performance regression

Hello! On Tue, 2 May 2006, Robert Watson wrote: options INVARIANTS options INVARIANT_SUPPORT In FreeBSD 5.x and FreeBSD 6.x, the INVARIANTS option has been significantly expanded to test a much larger set of invariants, and also incorporate kernel use-after-free checking, wh

Re: RELENG_4 -> 5 -> 6: significant performance regression

Hello! On Fri, 28 Apr 2006, Kris Kennaway wrote: makeoptions CONF_CFLAGS=-fno-builtin I don't know, it needs to be tested in your particular case. I've built another kernel, adding back makeoptions CONF_CFLAGS=-fno-builtin options QUOTA Results are almost the same as w/o these 2

Re: RELENG_4 -> 5 -> 6: significant performance regression

On Thu, 27 Apr 2006, Dmitry Pryanishnikov wrote: options INVARIANTS options INVARIANT_SUPPORT In FreeBSD 5.x and FreeBSD 6.x, the INVARIANTS option has been significantly expanded to test a much larger set of invariants, and also incorporate kernel use-after-free checking, w

Re: RELENG_4 -> 5 -> 6: significant performance regression

On Sun, Apr 30, 2006 at 10:05:40AM +0100, Chris wrote: > On 28/04/06, Kris Kennaway <[EMAIL PROTECTED]> wrote: > >On Fri, Apr 28, 2006 at 03:31:17PM +0300, Dmitry Pryanishnikov wrote: > >> > >> Hello! > >> > >> On Thu, 27 Apr 2006, Kris Kennaway wrote: > >> > >> Thanks for your suggestions, they'v

Re: RELENG_4 -> 5 -> 6: significant performance regression

Dominic Marks wrote: Peter Jeremy wrote: On Sun, 2006-Apr-30 10:05:40 +0100, Chris wrote: Does 'makeoptions DEBUG=-g' add any kind of performance hit or overhead as I noticed it wasnt default in 5.4 but is in 6.0. No. It just means that a debug kernel is built in addition to the normal k

Re: RELENG_4 -> 5 -> 6: significant performance regression

Peter Jeremy wrote: On Sun, 2006-Apr-30 10:05:40 +0100, Chris wrote: Does 'makeoptions DEBUG=-g' add any kind of performance hit or overhead as I noticed it wasnt default in 5.4 but is in 6.0. No. It just means that a debug kernel is built in addition to the normal kernel. The major bene

Re: RELENG_4 -> 5 -> 6: significant performance regression

On Sun, 2006-Apr-30 10:05:40 +0100, Chris wrote: >Does 'makeoptions DEBUG=-g' add any kind of performance hit or >overhead as I noticed it wasnt default in 5.4 but is in 6.0. No. It just means that a debug kernel is built in addition to the normal kernel. The major benefit is that if you do

Re: RELENG_4 -> 5 -> 6: significant performance regression

On 28/04/06, Kris Kennaway <[EMAIL PROTECTED]> wrote: On Fri, Apr 28, 2006 at 03:31:17PM +0300, Dmitry Pryanishnikov wrote: > > Hello! > > On Thu, 27 Apr 2006, Kris Kennaway wrote: > > Thanks for your suggestions, they've made a difference (though not as big > as one could hope). > > >On Thu, Ap

Re: RELENG_4 -> 5 -> 6: significant performance regression

On Fri, Apr 28, 2006 at 03:31:17PM +0300, Dmitry Pryanishnikov wrote: > > Hello! > > On Thu, 27 Apr 2006, Kris Kennaway wrote: > > Thanks for your suggestions, they've made a difference (though not as big > as one could hope). > > >On Thu, Apr 27, 2006 at 05:08:11PM +0300, Dmitry Pryanishnikov

Re: RELENG_4 -> 5 -> 6: significant performance regression

Hello! On Thu, 27 Apr 2006, Kris Kennaway wrote: Thanks for your suggestions, they've made a difference (though not as big as one could hope). On Thu, Apr 27, 2006 at 05:08:11PM +0300, Dmitry Pryanishnikov wrote: makeoptions CONF_CFLAGS=-fno-builtin Non-default option; this may conce

Re: RELENG_4 -> 5 -> 6: significant performance regression

On Thu, Apr 27, 2006 at 01:57:02PM -0700, Doug Hardie wrote: > > On Apr 27, 2006, at 11:12, Kris Kennaway wrote: > > >On Thu, Apr 27, 2006 at 05:08:11PM +0300, Dmitry Pryanishnikov wrote: > > > >>options QUOTA > > > >This definitely effects performance on 6.x since it makes your > >filesystem

Re: RELENG_4 -> 5 -> 6: significant performance regression

On Apr 27, 2006, at 11:12, Kris Kennaway wrote: On Thu, Apr 27, 2006 at 05:08:11PM +0300, Dmitry Pryanishnikov wrote: options QUOTA This definitely effects performance on 6.x since it makes your filesystem giant-locked, which may also interfere with your network processing. Any in

Re: RELENG_4 -> 5 -> 6: significant performance regression

On Thu, Apr 27, 2006 at 04:43:07PM -0400, Mike Jakubik wrote: > Kris Kennaway wrote: > >On Thu, Apr 27, 2006 at 03:47:37PM -0400, Mike Jakubik wrote: > > > >>Why isn't QUOTA mpsafe then? > >> > > > >Because code doesn't grow on trees. There are uncommitted patches > >though - perhaps you can

Re: RELENG_4 -> 5 -> 6: significant performance regression

Kris Kennaway wrote: On Thu, Apr 27, 2006 at 03:47:37PM -0400, Mike Jakubik wrote: Why isn't QUOTA mpsafe then? Because code doesn't grow on trees. There are uncommitted patches though - perhaps you can test them and get back to the author with your feedback. What? There is a bea

Re: RELENG_4 -> 5 -> 6: significant performance regression

On Thu, Apr 27, 2006 at 03:47:37PM -0400, Mike Jakubik wrote: > Bartosz Fabianowski wrote: > >>You wrote that Giant is needed in 6.0 and now you write it has been > >>removed. > > > >In 4.x, every UFS write requires the Giant lock. In 6.x, Giant is not > >normally required, making file system oper

Re: RELENG_4 -> 5 -> 6: significant performance regression

Bartosz Fabianowski wrote: You wrote that Giant is needed in 6.0 and now you write it has been removed. In 4.x, every UFS write requires the Giant lock. In 6.x, Giant is not normally required, making file system operations faster. When you enable QUOTA, you basically get back to the 4.x behav

Re: RELENG_4 -> 5 -> 6: significant performance regression

You wrote that Giant is needed in 6.0 and now you write it has been removed. In 4.x, every UFS write requires the Giant lock. In 6.x, Giant is not normally required, making file system operations faster. When you enable QUOTA, you basically get back to the 4.x behavior where Giant is needed f

Re: RELENG_4 -> 5 -> 6: significant performance regression

Kris Kennaway a écrit : On Thu, Apr 27, 2006 at 08:26:06PM +0200, [EMAIL PROTECTED] wrote: Kris Kennaway a ?crit : On Thu, Apr 27, 2006 at 05:08:11PM +0300, Dmitry Pryanishnikov wrote: options QUOTA This definitely effects performance on 6.x since it makes your filesystem giant-lock

Re: RELENG_4 -> 5 -> 6: significant performance regression

On Thu, Apr 27, 2006 at 08:26:06PM +0200, [EMAIL PROTECTED] wrote: > Kris Kennaway a ?crit : > >On Thu, Apr 27, 2006 at 05:08:11PM +0300, Dmitry Pryanishnikov wrote: > > > > > >>options QUOTA > > > >This definitely effects performance on 6.x since it makes your > >filesystem giant-locked, which

Re: RELENG_4 -> 5 -> 6: significant performance regression

Kris Kennaway a écrit : On Thu, Apr 27, 2006 at 05:08:11PM +0300, Dmitry Pryanishnikov wrote: options QUOTA This definitely effects performance on 6.x since it makes your filesystem giant-locked, which may also interfere with your network processing. Why would QUOTA affect performa

Re: RELENG_4 -> 5 -> 6: significant performance regression

On Thu, Apr 27, 2006 at 05:08:11PM +0300, Dmitry Pryanishnikov wrote: > makeoptions CONF_CFLAGS=-fno-builtin Non-default option; this may conceivably affect performance. > options INVARIANTS > options INVARIANT_SUPPORT These definitely effect performance, much more in 5.x and 6.x

Re: RELENG_4 on flash disk and swap

On Mon, Mar 13, 2006 at 11:48:06AM -0800, Jon Dama wrote: > > If you feel this situation is undesirable, the first thing to do is to put > together the patches necessary to allow the kernel to actually track how > much ram+swap might be needed to cover the address-space allocations > that have bee

Re: RELENG_4 on flash disk and swap

Hello! I won't reply to the overcommit part of your letter, since my concern is rather local: I'm just not sure whether FreeBSD does it's best during the DoS-attack in swapless environment. On Mon, 13 Mar 2006, Jon Dama wrote: Also, when the system is page-starved it kills the largest consum

Re: RELENG_4 on flash disk and swap

If you feel this situation is undesirable, the first thing to do is to put together the patches necessary to allow the kernel to actually track how much ram+swap might be needed to cover the address-space allocations that have been granted. This isn't trivial: just start thinking about shared all

Re: RELENG_4 on flash disk and swap

>On Fri, 10 Mar 2006, Michael Proto wrote: >> My suggestion would then be to utilize resource limits in >> /etc/login.conf for the sshd user (in your example) or other user >> accounts for applications that you don't want running out of control. >> See login.conf(5) and login_cap(3) for more detai

Re: RELENG_4 on flash disk and swap

On Fri, Mar 10, 2006 at 01:57:50PM +0200, Dmitry Pryanishnikov wrote: > > This is still a concern for me. IMHO it would be useful to have the ability > to disable process killing due to the lack of swap, because having this > enabled on e.g. transit router can lead to very unpleasant scenario. >

Re: RELENG_4 on flash disk and swap

Hello! On Fri, 10 Mar 2006, Michael Proto wrote: My suggestion would then be to utilize resource limits in /etc/login.conf for the sshd user (in your example) or other user accounts for applications that you don't want running out of control. See login.conf(5) and login_cap(3) for more details

Re: RELENG_4 on flash disk and swap

Dmitry Pryanishnikov wrote: > On Sat, 4 Mar 2006, Peter Jeremy wrote: >> Once you've received this message, the OS is free to kill your >> processes until it frees up some swap (which it can't do if you don't >> have any). I suggest you have a quick look through vm/swap_pager.c >> and vm/vm_pageou

Re: RELENG_4 on flash disk and swap

Hello! On Fri, 10 Mar 2006, Michael Proto wrote: [EMAIL PROTECTED] ps axu |grep ssh root 20213 0.0 1.3 54724 3356 ?? Is4:00PM 0:00.10 sshd: dmitry [priv] dmitry 20216 0.0 1.3 54724 3356 ?? I 4:00PM 0:00.03 s

Re: RELENG_4 on flash disk and swap

On Fri, 2006-Mar-10 15:53:43 +0200, Dmitry Pryanishnikov wrote: > But AFAIK the kernel kills NOT the requesting process but the one with the >largest RSS. This selection algorithm seems to be the dumbest one, since >process with largest RSS almost always is the process which does some real >work.

Re: RELENG_4 on flash disk and swap

Hello! On Sat, 11 Mar 2006, Peter Jeremy wrote: But AFAIK the kernel kills NOT the requesting process but the one with the largest RSS. This selection algorithm seems to be the dumbest one, since process with largest RSS almost always is the process which does some real work. This frees up th

Re: RELENG_4 on flash disk and swap

Hello! On Fri, 10 Mar 2006, Kostik Belousov wrote: the largest RSS - it could e.g. be a vital part of the routing software (zebra/ripd/bgpd), and killing this process will render our router unreachable and unusable! Then, what should kernel do ? It kills the process because it _needs_ the pag

Re: RELENG_4 on flash disk and swap

Hello! Date: Fri, 3 Mar 2006 08:04:55 -0500 From: Michael Proto <[EMAIL PROTECTED]> To:freebsd-stable@freebsd.org Subject: Re: RELENG_4 on flash disk and swap I'm running FreeBSD in 64Mb with no swap and it works fine. A few sysctls that I've found hel

Re: RELENG_4 on flash disk and swap

Hello! On Sat, 4 Mar 2006, Peter Jeremy wrote: Once swap_pager_full is set (which it has been in your case), the kernel will kill processes if it thinks it's short of memory, defined as (the following are all sysctl names): vm.stats.vm.v_free_reserved + vm.stats.vm.v_cache_min > vm.stats.vm.v_f

Re: RELENG_4 on flash disk and swap

On Sat, 2006-Mar-04 00:25:01 +0200, Dmitry Pryanishnikov wrote: >On Sat, 4 Mar 2006, Peter Jeremy wrote: >>swap space for a process and failed. The kernel tries to recover by >>killing the largest process (which should also be syslog'd). I'm > > In my case, not a single process has been killed. A

Re: RELENG_4 on flash disk and swap

Hello! On Sat, 4 Mar 2006, Peter Jeremy wrote: 4.11-RELEASE) such as "make buildwolrd". After successful completion of this procedure I issued "rm -rf /usr/obj/usr" and got the following (single) message from kernel: Mar 3 11:05:32 test3 /kernel: swap_pager_getswapspace: failed Does anybody

Re: RELENG_4 on flash disk and swap

On Fri, 2006-Mar-03 11:16:00 +0200, Dmitry Pryanishnikov wrote: > I'm running some heavy tests on my machine (256Mb RAM, HDD, no swap, >4.11-RELEASE) such as "make buildwolrd". After successful completion of >this procedure I issued "rm -rf /usr/obj/usr" and got the following >(single) message fro

Re: RELENG_4 on flash disk and swap

In this case I'd just ignore swap. Since /dev/md0 is only a memory disk anyway, you don't really buy anything by having it as swap as opposed to unallocated RAM. Just make sure that all your running programs are able to fit in the 256Mb of RAM you have, otherwise processes will fail to start or oth

Re: RELENG_4 on flash disk and swap

Hello! On Fri, 3 Mar 2006, Jeremy Bogan wrote: In other words, does RELENG_4 kernel work stable and robust w/o swap or should I provide a minimum-size swap device? Which configuration (1 or 2) will give more robustness in case of physical memory shortage? I've got 4.11 running on a Geode base

Re: RELENG_4 pam update doesn't work correct

Hello, i have also opened a PR: http://www.freebsd.org/cgi/query-pr.cgi?pr=85796 regards michael 2005/9/6, Michael Schuh <[EMAIL PROTECTED]>: > Hello, > > yesterday i have made an cvsup from RELENG_4 and made the typically > system-update with: > > make buildworld kernel > mergemaster -p > ma

Re: [RELENG_4] buildkernel failure with MAKEOBJDIRPREFIX

> In <[EMAIL PROTECTED]> > Ruslan Ermilov <[EMAIL PROTECTED]> wrote: > > I think this is a bug of make, *.mk or other Makefiles in /sys but I > > cannot fix it. > No, this is because MAKEOBJDIRPREFIX must be an environment variable > and should not be set on make's command line or in /

Re: [RELENG_4] buildkernel failure with MAKEOBJDIRPREFIX

On Sun, May 22, 2005 at 10:30:12AM +0900, NAKAJI Hiroyuki wrote: > Hello, > > I tried to rebuild a debug kernel to analyze one of my problem(*), > and, I faced to another problem. Now this is the main problem for me. > > The problem I have now is that 'make buildkernel' does not refer to > ${MAKE

Re: RELENG_4 tag in stable-supfile on 5.2.1 box - change it to RELENG_5?

On Tue, 22 Feb 2005, W C wrote: > I would like to upgrade my 5.2.1 box from source with cvsup to 5-STABLE. > > Do I need to change the tag to RELENG_5 for FreeBSD 5-STABLE? Or can I > cvsup a new stable-supfile? At the time 5.2.1 was released, RELENG_4 was still the stable branch. You'll ne

Re: RELENG_4 tag in stable-supfile on 5.2.1 box - change it to RELENG_5?

> From: "W C" <[EMAIL PROTECTED]> > Date: Tue, 22 Feb 2005 14:35:28 -0800 > Sender: [EMAIL PROTECTED] > > I would like to upgrade my 5.2.1 box from source with cvsup to 5-STABLE. > > Do I need to change the tag to RELENG_5 for FreeBSD 5-STABLE? > Or can I cvsup a new stable-supfile? Yes, change

Re: RELENG_4 tag in stable-supfile on 5.2.1 box - change it to RELENG_5?

On Tue, Feb 22, 2005 at 02:35:28PM -0800, W C <[EMAIL PROTECTED]> was witnessed plotting the following conspiracy: > I would like to upgrade my 5.2.1 box from source with cvsup to 5-STABLE. > > Do I need to change the tag to RELENG_5 for FreeBSD 5-STABLE? > Or can I cvsup a new stable-supfile? >

Re: [releng_4 tinderbox] failure on i386/i386

Jared ''Danger'' Earle <[EMAIL PROTECTED]> writes: > FreeBSD Tinderbox wrote: > > >>> Kernel build for LINT started on Thu Feb 19 05:10:26 GMT 2004 > um ... were you *supposed* to build the LINT kernel? Yes. Why should I not? DES -- Dag-Erling Smørgrav - [EMAIL PROTECTED] __

Re: RELENG_4: Problems with mpt driver

On Tue, 27 Jan 2004, Matti Saarinen wrote: > > I have IBM x345 which has integrated LSI 1030 raid controller. I don't > know if the problem is in the driver or do I have malfunctioning > hardware. Many times but not all, when the system boots the console > output contains almost denumerable number

Re: [releng_4 tinderbox] failure on alpha/alpha

On Sun, 17 Aug 2003 14:02:18 -0700, Andy Sparrow <[EMAIL PROTECTED]> writes: > > > The same thing started in -PORTS quite some time ago, where I find > > > personally find that it generates more [EMAIL PROTECTED] than the real traffic > > > at > > > times. > > > > You're entitled to your opinio

Re: [releng_4 tinderbox] failure on alpha/alpha

> > The same thing started in -PORTS quite some time ago, where I find > > personally find that it generates more [EMAIL PROTECTED] than the real traffic at > > times. > > You're entitled to your opinion, Thanks, I will clarify it further for you. > but since you've never had to deal > with t

Re: [releng_4 tinderbox] failure on alpha/alpha

>You're entitled to your opinion, but since you've never had to deal >with the flood of support requests when INDEX builds were broken by >careless committers before I started the automated tinderbox, I'd >suggest you try to consider it from point of view of those of us who >are actually involved

Re: [releng_4 tinderbox] failure on alpha/alpha

On Sat, Aug 16, 2003 at 06:00:26PM -0700, Andy Sparrow wrote: > The same thing started in -PORTS quite some time ago, where I find > personally find that it generates more [EMAIL PROTECTED] than the real traffic at > times. You're entitled to your opinion, but since you've never had to deal wit

Re: RELENG_4

If memory serves me right, Chris Johnson wrote: > On Sun, Aug 18, 2002 at 04:50:28PM -0300, Vitor de Matos Carvalho wrote: > > Because when it left the 4.1.1-release version turned STABLE? > > I may be wrong, but I believe that was before the invention of the security > branches. 4.1.1-RELEASE wa

Re: releng_4

Thus spake dnu <[EMAIL PROTECTED]>: > I was reading about cvsup in the handbook and I'm a bit confused. > It said that releng_4 is the main stable branch while releng_4_6 > is for critical fixes. > > So, if I cvs releng_4, do I also need to cvs releng_4_6? Or do > the updates to releng_4_6 a

Re: releng_4

If memory serves me right, dnu wrote: > I was reading about cvsup in the handbook and I'm a bit confused. > It said that releng_4 is the main stable branch while releng_4_6 > is for critical fixes. > > So, if I cvs releng_4, do I also need to cvs releng_4_6? No. You either grab one or the

Re: RELENG_4 buildworld errors

In message <[EMAIL PROTECTED]> Barney Wolff writes: : This is WRONG. You got bad advice. The sequence documented in UPDATING : is buildworld, buildkernel, installkernel, reboot (single-user to be safe, : although quiet machines can get away with a normal reboot), installworld, : mergemaster, reb

Re: RELENG_4 world broken?

On Sun, Sep 09, 2001 at 01:00:24PM +0200, Johan Mulder wrote: > On Sat, Sep 08, 2001 at 11:18:18PM -0700, Kris Kennaway wrote: > > On Sun, Sep 09, 2001 at 02:29:33AM +0200, Johan Mulder wrote: > > > I didn't try it with a full buildworld, but just with make most. > > > Maybe it doesn't happen when

Re: RELENG_4 installworld broken

On Wed, Aug 01, 2001 at 12:43:23PM +0200, Anders Andersson wrote: > Just cvsup'd and built world, > > make installworld... > > ===> sbin/init > install -c -s -o root -g wheel -m 500 -fschg -b -B.bak init /sbin Install the new "install" by hand, that does it. cd /usr/src/usr.bin/xinst

Re: RELENG_4 -> RELENG_4_3

* Jason Stephenson <[EMAIL PROTECTED]> [010703 15:20]: > Over the weekend, I went from RELENG_4 to RELENG_4_3, but I did by wiping my > system partitions (/, /usr, /var) and reinstalling 4.3 from CD-ROM. Then, I > cvsup'd to RELENG_4_3 and the latest ports. I finally reinstalled everything > th

Re: RELENG_4 -> RELENG_4_3

Over the weekend, I went from RELENG_4 to RELENG_4_3, but I did by wiping my system partitions (/, /usr, /var) and reinstalling 4.3 from CD-ROM. Then, I cvsup'd to RELENG_4_3 and the latest ports. I finally reinstalled everything that I need from ports. I thought of doing it with a cvsup and d

Re: RELENG_4 crashes under SMP

Since my machine is co-located and over an hour away, I would love to know whether this is solved. Thanks. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message

Re: RELENG_4 kern.flp broken (was: Re: Broken kern.flp?)

rwatson> I just started running into the same thing using the Jan 16, rwatson> 2001 kernel floppy disk. The same error: I don't know why, but the latest floppy image available at current.jp.FreeBSD.org, ftp://current.jp.FreeBSD.org/pub/FreeBSD/snapshots/i386/4.2-STABLE-20010117-JPSNAP/floppie

Re: RELENG_4 'make -DNOINFO installworld' SIGNAL 12 on install of'test'

On Wed, 29 Mar 2000, Dave Runkle wrote: > The kernel process went well, although it seems that contrary to > UPDATING saying to manually do the kernel install, it was done by > 'installkernel' as part of that script. So I did not have to do that > part. The new kernel is sitting, ready to boot.