, CTF generation is turned off. You don't
need or want it yet.
--
John Birrell
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
On Wed, Aug 27, 2008 at 08:43:13AM +0100, N.J. Mann wrote:
> In message <[EMAIL PROTECTED]>,
> John Birrell ([EMAIL PROTECTED]) wrote:
> >
> > This is a belated heads up to let you know that I have merged DTrace to the
> > releng7
> > branch in the ni
_COHERENCE_SIZE - CPUC_SIZE
> +#define CPUC_SIZE1 roundup(CPUC_SIZE,
> CPU_CACHE_COHERENCE_SIZE)
> +#define CPUC_PADSIZECPUC_SIZE1 - CPUC_SIZE
>
> typedef struct cpu_core {
> uint16_tcpuc_dtrace_flags; /* DTrace flags */
--
Jo
test out the builds. I have no hardware to run an old version
of 6 on.
--
John Birrell
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
The feedback I've been getting indicates that it's safe to go back in the
water again.
--
John Birrell
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail
ction.
I believe that the buildworld that you have is OK, even when built with the
CTF data it's the installworld when things go bad.
Do you need me to send you any files to recover from this problem?
--
John Birrell
___
freebsd-stable@freebs
s problem?
>
> No problem, I have access to a previous 7.0-STABLE.
I am concerned about the high CPU problem. All the hooks that are built in
with KDTRACE_HOOKS are inactive until the DTrace modules are loaded. So there
should be no CPU implications there.
Are you usi
ld barfs on a missing _BIG_ENDIAN define is
an indication that either something hasn't updated correctly in your cvsup or
I've
f'up again (ugh).
The problem you are seeing has nothing to do with the kernel config. You can
have
KDTRACE_HOOKS i
re to include the
> options KDB, DDB and STACK in my kernel for zfs functionality.
> Unfortunately, I cannot try without those options since my root is zfs.
> Booting a kernel from 8/20 works fine.
That's not good news. :-(
I think I'll have to look at
reeBSD requires both _BIG_ENDIAN and
_LITTLE_ENDIAN
to be defined. It is Solaris code which undefines _BIG_ENDIAN and it would
have been that #undef which was wrong.
> For good measure, I rm'd the whole ../../cddl directory and re-sup'd it.
> Build with no errors --smooth as glass ;)
ing anything new.
> Is everything supposed to work out of box now?
Yes, but an obj tree from a broken build will cause problems.
--
John Birrell
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-sta
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
current /boot/kernel)
cd src/sys/modules/opensolaris
make obj && make depend && make all && make install
--
John Birrell
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
ave been seeing.
--
John Birrell
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
it worked. I would be interested to know what the correct fix is. In any
> case someone needs to look at this PDQ.
The bug is in `make'. "unknown" should be replaced by "i386" so that
the behaviour is the same as when MACHINE_ARCH was not defined at all.
--
John Birre
15 matches
Mail list logo
