Kai Lockwood wrote on Friday, January 26, 2007 5:10 AM:
Oliver Fromme wrote:
[EMAIL PROTECTED] wrote:
Torfinn Ingolfsen wrote:
BTW, what is the reason this hack isn't included in the base kernel
/ code?
Because it is probably unnecessary? I run a recent 6-STABLE and use
the
On Thursday 25 January 2007 11:18, Peter N. M. Hansteen wrote:
JoaoBR [EMAIL PROTECTED] writes:
all this methods are certainly useless, stay calm ok
I fully sympathize with your need to rant, but in this context most of
what you say is really quite beside the point. Please read what the
I had wanted to build static binaries in /bin and /sbin - so
I set NO_SHARED. The man pages says ... this can be bad. If set
every utility that uses bsd.prog.mk will be linked statically.
I have problems in the past - on other platforms - where having
statically linked tools in /bin saved the
On 1/26/07, Bill Vermillion [EMAIL PROTECTED] wrote:
I had wanted to build static binaries in /bin and /sbin - so
I set NO_SHARED. The man pages says ... this can be bad. If set
every utility that uses bsd.prog.mk will be linked statically.
I have problems in the past - on other platforms -
In the last episode (Jan 26), Bill Vermillion said:
I had wanted to build static binaries in /bin and /sbin - so
I set NO_SHARED. The man pages says ... this can be bad. If set
every utility that uses bsd.prog.mk will be linked statically.
Here is the tail end of the output of make
Hello,
(Not subscribed, let's hope this gets through..)
I saw the strangest case I've yet seen today when upgrading a dual-P3
system using sources (buildworld etc.) from FreeBSD 5.5 to RELENG_6
(6.2). The system paniced at boot with a message like:
panic: kmem_malloc(-1059844096): kmem_map
I've just updated the sources in FreeBSD 6.2-RELEASE and tried to
rebuild world. With option 'NO_CXX=YES' in /etc/make.conf world compiled
successful, if this option not added 'make buildworld' failed. 'make
buildworld' fails:
..
=== gnu/usr.bin/groff/src/libs/libgroff (depend)
Making version.cpp
Pekka Savola wrote:
Hello,
(Not subscribed, let's hope this gets through..)
I saw the strangest case I've yet seen today when upgrading a dual-P3
system using sources (buildworld etc.) from FreeBSD 5.5 to RELENG_6
(6.2). The system paniced at boot with a message like:
panic:
...or when will FreeBSD support Pentium features?
I want to apologize in advance if this should be on the kern@
But it seemed apropriate for this list too and I'm already on it.
I've noticed building kernels, that since v. = 5 that during
the phase 2/3 all the lines echoed to the screen contain:
...or when will FreeBSD support Pentium features?
I want to apologize in advance if this should be on the kern@
But it seemed apropriate for this list too and I'm already on it.
I've noticed building kernels, that since v. = 5 that during
the phase 2/3 all the lines echoed to the screen contain:
Chris H. wrote:
I've noticed building kernels, that since v. = 5 that during
the phase 2/3 all the lines echoed to the screen contain:
-mno-mmx -mno-3dnow -mno-sse -mno-sse2 ...
See /usr/share/examples/etc/make.conf.
As Pentium have been the norm for many years now, why aren't
these
Chris H. wrote:
...or when will FreeBSD support Pentium features?
I want to apologize in advance if this should be on the kern@
But it seemed apropriate for this list too and I'm already on it.
I've noticed building kernels, that since v. = 5 that during
the phase 2/3 all the lines echoed to
Context switching.
We already preserve the core CPU state and the FPU state between
context switches. Adding MMX into the mix means preserving an MMX
state (since it can clobber the FPU state) and so forth.
jmc
Quoting Dimitry Andric [EMAIL PROTECTED]:
Chris H. wrote:
I've noticed building
Quoting Dimitry Andric [EMAIL PROTECTED]:
Chris H. wrote:
I've noticed building kernels, that since v. = 5 that during
the phase 2/3 all the lines echoed to the screen contain:
-mno-mmx -mno-3dnow -mno-sse -mno-sse2 ...
See /usr/share/examples/etc/make.conf.
Sigh, the obvious is so
Chris H. wrote:
CPU: AMD Athlon(tm) XP (1102.51-MHz 686-class CPU)
Origin = AuthenticAMD Id = 0x680 Stepping = 0
Features=0x383fbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,MMX,FXSR,SSE
AMD Features=0xc0400800SYSCALL,MMX+,3DNow+,3DNow
That I simply build
On Fri, 2007-Jan-26 09:24:58 -0200, JoaoBR wrote:
like I said, for my understandings firewall implemention for spam fighting is
wrong
because you reject the message
Except that the original mail was talking about greylisting. This won't
reject any mail sent from a MTA that correctly implements
Hello and thank you for your response...
Quoting Mike Jakubik [EMAIL PROTECTED]:
Chris H. wrote:
CPU: AMD Athlon(tm) XP (1102.51-MHz 686-class CPU)
Origin = AuthenticAMD Id = 0x680 Stepping = 0
On Fri, Jan 26, 2007 at 08:45:15PM -0800, Chris H. wrote:
Hello and thank you for your response...
Quoting Mike Jakubik [EMAIL PROTECTED]:
Chris H. wrote:
CPU: AMD Athlon(tm) XP (1102.51-MHz 686-class CPU)
Origin = AuthenticAMD Id = 0x680 Stepping = 0
On Fri, 26 Jan 2007, Scott Long wrote:
makeoptions DEBUG=-g
.. when I added this, boot works fine. When removing it, you get the
panic.
Strange, huh? :-/
Below is a snippet of the boot log:
Please compile KDB and DDB into your kernel so we can see exactly where
the panic is
19 matches
Mail list logo
