On Mon, 1 Sep 2008, John Birrell wrote:
On Sun, Aug 31, 2008 at 06:35:16AM -0500, Wes Morgan wrote:
I know this has been reported already, but I want to give a "me too".
After installing a new world and kernel from the tree yesterday afternoon,
I let my system run all night. This morning everyt
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 doesn't work is worse than having none). After upgrading we
basically cann
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 module after this chan
On Sun, Aug 31, 2008 at 06:35:16AM -0500, Wes Morgan wrote:
> I know this has been reported already, but I want to give a "me too".
> After installing a new world and kernel from the tree yesterday afternoon,
> I let my system run all night. This morning everything was extremely
> sluggish and u
,--- You/John (Sun, 31 Aug 2008 23:35:38 +) *
| It's supposed to, but I don't trust it. There is no substitute for
| a rm -rf of the obj tree. That's also quicker.
Ah, OK...
| Sorry about the problems.
Oh, no problem at all -- I learned a lot as a result. Just wanted to
make sure I unde
On Sun, Aug 31, 2008 at 07:32:14PM -0400, Alex Goncharov wrote:
> | or
> |
> | 2. Delete the obj tree before building anything new.
> |
> | > Is everything supposed to work out of box now?
> |
> | Yes, but an obj tree from a broken build will cause problems.
>
> That's a bit strange:
>
> 1. W
,--- You/John (Sun, 31 Aug 2008 22:36:36 +) *
| If you still have the obj tree from the problem build, there are two things
| you can do:
|
| 1. make STRIP= installworld
Thank you -- that's good to know, for the future.
For now, I updated again and using my saved "four cc tools kit"
rebu
On Sun, Aug 31, 2008 at 10:27:22AM -0400, Alex Goncharov wrote:
> Is there anything else I should have done to avoid these problems?
If you still have the obj tree from the problem build, there are two things
you can do:
1. make STRIP= installworld
or
2. Delete the obj tree before building any
On Sun, Aug 31, 2008 at 03:22:18PM -0700, John Scroggins wrote:
> On Sat, 2008-08-30 at 19:57 -0700, John Scroggins wrote:
>
> thanks John,
> found the offending file dtrace.h -- lines 520 and 630 had the #if
> BYTE_ORDER == _BIG_ENDIAN entries.
That code is correct though. FreeBSD requires both
On Sun, Aug 31, 2008 at 06:35:16AM -0500, Wes Morgan wrote:
> I know this has been reported already, but I want to give a "me too".
> After installing a new world and kernel from the tree yesterday afternoon,
> I let my system run all night. This morning everything was extremely
> sluggish and u
On Sat, 2008-08-30 at 19:57 -0700, John Scroggins wrote:
thanks John,
found the offending file dtrace.h -- lines 520 and 630 had the #if
BYTE_ORDER == _BIG_ENDIAN entries.
For good measure, I rm'd the whole ../../cddl directory and re-sup'd it.
Build with no errors --smooth as glass ;)
> On Sun,
Wes Morgan wrote:
> I know this has been reported already, but I want to give a "me too".
> After installing a new world and kernel from the tree yesterday
> afternoon, I let my system run all night. This morning everything was
> extremely sluggish and unresponsive. According to top, which I
> than
Still having problems...
,--- I/Alex (Wed, 27 Aug 2008 20:42:00 -0400) *
| ,--- You/Kostik (Wed, 27 Aug 2008 19:04:32 +0300) *
| | cd into /usr/src/gnu/usr.bin/cc/cc1,
| | make install DEBUG_FLAGS=-g
|
| That simple thing didn't work for me:
| But I've found what may be an extremely
I know this has been reported already, but I want to give a "me too".
After installing a new world and kernel from the tree yesterday afternoon,
I let my system run all night. This morning everything was extremely
sluggish and unresponsive. According to top, which I thankfully left
running, pro
This is an FYI rather than a HEADS UP, as it should make no functional
difference (ideally). Per e-mail a couple of weeks ago, I have removed the
uncompilable and unusable netatm code from the 7.x source tree. We are now
down to two (2) ATM stacks in 7.x, both of which are MPSAFE and work, a
Jeremy Chadwick wrote:
On Sat, Aug 30, 2008 at 09:28:36PM +0200, Henri Hennebert wrote:
John Baldwin wrote:
This patch merges a few changes from HEAD back to 7.x. I think the
endian changes specifically might solve the issue people saw with
zpools created with non-dtrace kernels not being rea
16 matches
Mail list logo
