TB --- 2008-09-01 05:28:34 - tinderbox 2.3 running on freebsd-stable.sentex.ca
TB --- 2008-09-01 05:28:34 - starting RELENG_7 tinderbox run for i386/i386
TB --- 2008-09-01 05:28:34 - cleaning the object tree
TB --- 2008-09-01 05:29:00 - cvsupping the source tree
TB --- 2008-09-01 05:29:00 - /usr/bi
John Birrell wrote:
For those people experiencing a performance degradation since the DTrace import,
please update your copy of
src/sys/cddl/compat/opensolaris/kern/opensolaris_kmem.c
by either cvsup of direct edit to remove "#define KMEM_DEBUG".
You only need to rebuild the opensolaris kernel
TB --- 2008-09-01 06:47:53 - tinderbox 2.3 running on freebsd-stable.sentex.ca
TB --- 2008-09-01 06:47:53 - starting RELENG_7 tinderbox run for i386/pc98
TB --- 2008-09-01 06:47:53 - cleaning the object tree
TB --- 2008-09-01 06:48:16 - cvsupping the source tree
TB --- 2008-09-01 06:48:16 - /usr/bi
TB --- 2008-09-01 06:55:05 - tinderbox 2.3 running on freebsd-stable.sentex.ca
TB --- 2008-09-01 06:55:05 - starting RELENG_7 tinderbox run for ia64/ia64
TB --- 2008-09-01 06:55:05 - cleaning the object tree
TB --- 2008-09-01 06:55:19 - cvsupping the source tree
TB --- 2008-09-01 06:55:19 - /usr/bi
Hello Michael,
Sunday, August 31, 2008, 7:12:54 PM, you wrote:
> Any progress here? Does anyone know if this will be fixed in 7.1 latest,
> or should we start looking for different backup solution (in this case I
> would suggest to remove dump from the source tree - having a backup tool
> that do
On Mon, 1 Sep 2008, John Birrell wrote:
For those people experiencing a performance degradation since the DTrace
import, please update your copy of
src/sys/cddl/compat/opensolaris/kern/opensolaris_kmem.c by either cvsup
of direct edit to remove "#define KMEM_DEBUG".
You only need to rebuild
On Mon, Sep 01, 2008 at 05:48:34AM -0500, Wes Morgan wrote:
> On Mon, 1 Sep 2008, John Birrell wrote:
>
>> For those people experiencing a performance degradation since the
>> DTrace import, please update your copy of
>> src/sys/cddl/compat/opensolaris/kern/opensolaris_kmem.c by either cvsup
>>
At 05:07 AM 9/1/2008, Derek KuliÅski wrote:
Now I'm honestly a bit scared about it (even if it will be fixed
before 7.1, I'm not sure I'll hurry with the update).
There have been a number of commits to releng_7
that fixed dump issues for me. A box that used
to regularly exhibit hung dump p
Wes Morgan a écrit :
On Mon, 1
Sep 2008, John Birrell wrote:
For those people experiencing a performance degradation since the
DTrace import, please update your copy of
src/sys/cddl/compat/opensolaris/kern/opensolaris_kmem.c by either
cvsup of direct edit to remove "#define KMEM_DEBUG".
Yo
> Date: Mon, 01 Sep 2008 09:36:11 -0400
> From: Mike Tancsa <[EMAIL PROTECTED]>
> Sender: [EMAIL PROTECTED]
>
> At 05:07 AM 9/1/2008, Derek KuliÅski wrote:
>
> >Now I'm honestly a bit scared about it (even if it will be fixed
> >before 7.1, I'm not sure I'll hurry with the update).
>
> There ha
At 12:00 PM 9/1/2008, Kevin Oberman wrote:
I have a 7-Stable system which has not been able to successfully dump(8)
for about 2 months. Since it contains almost no important data that is
subject to change, it's not too big a deal, but I worry that other
systems might start showing the same probl
John Birrell wrote:
> For those people experiencing a performance degradation since the DTrace
> import,
> please update your copy of
> src/sys/cddl/compat/opensolaris/kern/opensolaris_kmem.c
> by either cvsup of direct edit to remove "#define KMEM_DEBUG".
>
> You only need to rebuild the openso
I build releases nightly, and have been getting
(snip)
+ shift
+ FSLABEL=minimum3
+ shift
+ [ 4320 -eq 0 -a minimum3 = auto ]
+ rm -f /R/stage/mfsroot/mfsroot
+ dd of=/R/stage/mfsroot/mfsroot if=/dev/zero count=4320 bs=1k uname -r
+ [ -f /R/stage/trees/base/boot/boot ] BOOT=-B -b
+ /R/stage/tre
> Date: Mon, 01 Sep 2008 12:06:35 -0400
> From: Mike Tancsa <[EMAIL PROTECTED]>
>
> At 12:00 PM 9/1/2008, Kevin Oberman wrote:
>
> >I have a 7-Stable system which has not been able to successfully dump(8)
> >for about 2 months. Since it contains almost no important data that is
> >subject to chan
Hello Kevin,
Monday, September 1, 2008, 1:13:24 PM, you wrote:
> Thanks for the suggestion. I'm pretty sure I have done a full fsck, but
> not positive, so I will try one tomorrow. The system is in a location
> which is unmanned today due to the holiday, and a full fsck kind of needs
> either a h
Sorry to scare you, I was a little unhappy about dump hanging.
Based on the cvs repository I wrote a little patch that combines two
changes made by scott and jeff that works agains 7.0-RELEASE (looking at
the commit logs scared me away from trying STABLE on production right
now. After applying
On Mon, Sep 01, 2008 at 09:00:12AM -0700, Kevin Oberman wrote:
> > Date: Mon, 01 Sep 2008 09:36:11 -0400
> > From: Mike Tancsa <[EMAIL PROTECTED]>
> > Sender: [EMAIL PROTECTED]
> >
> > At 05:07 AM 9/1/2008, Derek Kuli??ski wrote:
> >
> > >Now I'm honestly a bit scared about it (even if it will be
On Mon, Sep 01, 2008 at 02:38:56PM -0700, Jeremy Chadwick wrote:
> ... I'll try to find the thread (it was a year or so ago)
> where a developer told me more or less what was going on. The problem
> was that UFS2 snapshot generation, over time, becomes slower and slower
> to generate (this is wha
At 05:38 PM 9/1/2008, Jeremy Chadwick wrote:
Can someone explain what "dump frequently hangs" actually means?
Does it lock up the entire machine indefinitely (and if so, how long did
you wait for it to (hopefully) recover)?
As in the process hanging. For me, it was fixed quite some time ago
On Mon, Sep 01, 2008 at 02:38:56PM -0700, Jeremy Chadwick wrote:
> The problem was that UFS2 snapshot generation, over time, becomes
> slower and slower to generate (this is what dump does on UFS2 systems,
> with or without the -L flag), and is a known design issue.
Clarification: dump on UFS2 (wi
On Tue, 19 Aug 2008 17:15:54 -0400
John Baldwin <[EMAIL PROTECTED]> wrote:
> That's right, but not the specific bug I am familiar with. :(
Ok.
The issue is now documented as PR i386/127029
http://www.freebsd.org/cgi/query-pr.cgi?pr=127029
No, I am not sure that this issue only relates to i386. B
> Date: Mon, 1 Sep 2008 14:38:56 -0700
> From: Jeremy Chadwick <[EMAIL PROTECTED]>
>
> On Mon, Sep 01, 2008 at 09:00:12AM -0700, Kevin Oberman wrote:
> > > Date: Mon, 01 Sep 2008 09:36:11 -0400
> > > From: Mike Tancsa <[EMAIL PROTECTED]>
> > > Sender: [EMAIL PROTECTED]
> > >
> > > At 05:07 AM 9/1
Hello Jeremy,
Monday, September 1, 2008, 3:27:38 PM, you wrote:
[... links about problems with snapshots ...]
the dump can be used without snapshots, in that case is it a still
worse method of doing backups?
as for the snapshots, you made me even more depressed :)
I don't have huge hard disk so
On Tue, Sep 02, 2008 at 09:39:20AM +0300, Danny Braniss wrote:
> take a look at:
> http://www.freebsd.org/cgi/query-pr.cgi?pr=117603
> danny
That PR may or may not be relevant, depending upon what FreeBSD version
users are using, and what kernel build date.
The bug mentioned in that PR got
24 matches
Mail list logo