On 2010-03-21 22:20, Garrett Cooper wrote:
From gcc(1):
-s Remove all symbol table and relocation information from the exe-
cutable.
This is more or less the same as running strip(1) over the produced
executables. Usually one uses it for non-debug builds.
That seems a
on 22/03/2010 00:12 Alexander Best said the following:
Andriy Gapon schrieb am 2010-03-21:
on 21/03/2010 23:11 Alexander Best said the following:
*hehe* that makes more sense. well i already sent you lp.
unfortunately str is
not available to gdb:
(gdb) print str
Variable str is not
on 21/03/2010 08:25 Garrett Cooper said the following:
On Sat, Mar 20, 2010 at 9:58 PM, FreeBSD Tinderbox
tinder...@freebsd.org wrote:
TB --- 2010-03-21 04:53:25 - /usr/bin/make -B buildkernel KERNCONF=PAE
Kernel build for PAE started on Sun Mar 21 04:53:25 UTC 2010
stage 1: configuring the
In message 4ba633a0.2090...@icyb.net.ua, Andriy Gapon writes:
on 21/03/2010 16:05 Alexander Motin said the following:
Ivan Voras wrote:
Hmm, it looks like it could be easy to spawn more g_* threads (and,
barring specific class behaviour, it has a fair chance of working out of
the box) but the
Andriy Gapon schrieb am 2010-03-22:
on 22/03/2010 00:12 Alexander Best said the following:
Andriy Gapon schrieb am 2010-03-21:
on 21/03/2010 23:11 Alexander Best said the following:
*hehe* that makes more sense. well i already sent you lp.
unfortunately str is
not available to gdb:
On Sun, 21 Mar 2010 19:03:56 +0200
Alexander Motin m...@freebsd.org wrote:
Scott Long wrote:
Are there non-CAM drivers that look at MAXPHYS, or that silently assume that
MAXPHYS will never be more than 128k?
That is a question.
I only did a quickdirty grep looking for MAXPHYS in /sys.
On Sun, 21 Mar 2010 14:22, Anton Shterenlikht wrote:
In Message-Id: 20100321182214.gk84...@mech-cluster241.men.bris.ac.uk
On Sat, Mar 20, 2010 at 08:53:37PM +, Anton Shterenlikht wrote:
On Sat, Mar 20, 2010 at 03:44:46PM +, Anton Shterenlikht wrote:
On Sat, Mar 20, 2010 at 07:27:43AM
TB --- 2010-03-22 10:55:00 - tinderbox 2.6 running on freebsd-current.sentex.ca
TB --- 2010-03-22 10:55:00 - starting HEAD tinderbox run for i386/i386
TB --- 2010-03-22 10:55:00 - cleaning the object tree
TB --- 2010-03-22 10:55:21 - cvsupping the source tree
TB --- 2010-03-22 10:55:21 -
Quoting Scott Long sco...@samsco.org (from Sat, 20 Mar 2010 12:17:33 -0600):
code was actually taking advantage of the larger I/O's. The
improvement really
depends on the workload, of course, and I wouldn't expect it to be noticeable
for most people unless they're running something like a
On Monday 22 March 2010 7:40:18 am Gary Jennejohn wrote:
On Sun, 21 Mar 2010 19:03:56 +0200
Alexander Motin m...@freebsd.org wrote:
Scott Long wrote:
Are there non-CAM drivers that look at MAXPHYS, or that silently assume
that
MAXPHYS will never be more than 128k?
That is a
On Mon, 22 Mar 2010 01:53, Alexander Motin wrote:
In Message-Id: 4ba705cb.9090...@freebsd.org
jhell wrote:
On Sun, 21 Mar 2010 20:54, jhell@ wrote:
I played with it on one re-compile of a kernel and for the sake of it
DFLTPHYS=128 MAXPHYS=256 and found out that I could not cause a crash
dump
On Mon, Mar 22, 2010 at 8:39 AM, John Baldwin j...@freebsd.org wrote:
On Monday 22 March 2010 7:40:18 am Gary Jennejohn wrote:
On Sun, 21 Mar 2010 19:03:56 +0200
Alexander Motin m...@freebsd.org wrote:
Scott Long wrote:
Are there non-CAM drivers that look at MAXPHYS, or that silently
On Monday 22 March 2010 04:19 am, Andriy Gapon wrote:
on 21/03/2010 08:25 Garrett Cooper said the following:
On Sat, Mar 20, 2010 at 9:58 PM, FreeBSD Tinderbox
tinder...@freebsd.org wrote:
TB --- 2010-03-21 04:53:25 - /usr/bin/make -B buildkernel
KERNCONF=PAE
Kernel build for PAE
On Mar 22, 2010, at 5:04 AM, jhell wrote:
Not that this has anything to do with your problem but might turn into a
problem if it is not your intent. But the above command will update your src
to 9.0-CURRENT
That is his intend.
Anton: I fixed a bunch of things yesterday. You should be
On Mar 22, 2010, at 9:52 AM, Alexander Sack wrote:
On Mon, Mar 22, 2010 at 8:39 AM, John Baldwin j...@freebsd.org wrote:
On Monday 22 March 2010 7:40:18 am Gary Jennejohn wrote:
On Sun, 21 Mar 2010 19:03:56 +0200
Alexander Motin m...@freebsd.org wrote:
Scott Long wrote:
Are there non-CAM
On Mon, Mar 15, 2010 at 09:00:18AM -0700, Julian Elischer wrote:
I certainly agree.. can it be changed please?
I've waited a while to see what other opinions would be expressed on this
topic. I believe there is sufficient support to rename COMPAT_FREEBSD32
to something else based on responses
That's strange, after recompiling the lastest 8_0 that contain the patch (
http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/rpc/clnt_vc.c.diff?r1=1.8.2.2.2.1;r2=1.8.2.2.2.2)
after 5 days it stuck again with same symptoms, I've also got some in the
nfs state:
FreeBSD .. 8.0-RELEASE-p2 FreeBSD
In message: d9d66012-16fd-4fb6-ab6a-9a8d17727...@samsco.org
Scott Long sco...@samsco.org writes:
: I'd like to go in the opposite direction. The queue-dispatch-queue
: model of GEOM is elegant and easy to extend, but very wasteful for
: the simple case, where the simple case is one or
On Fri, Mar 12, 2010 at 12:50:32PM -0700, M. Warner Losh wrote:
: On Thu, Mar 11, 2010 at 07:24:23PM -0700, M. Warner Losh wrote:
So the issue isn't as cut and dried as you might think. There's
multiple different conventions used here in addition to your simple
example.
I guess we'd have to
On Mon, Mar 22, 2010 at 2:45 PM, M. Warner Losh i...@bsdimp.com wrote:
In message: d9d66012-16fd-4fb6-ab6a-9a8d17727...@samsco.org
Scott Long sco...@samsco.org writes:
: I'd like to go in the opposite direction. The queue-dispatch-queue
: model of GEOM is elegant and easy to
In message: 20100322185331.ga88...@dragon.nuxi.org
David O'Brien obr...@freebsd.org writes:
: On Fri, Mar 12, 2010 at 12:50:32PM -0700, M. Warner Losh wrote:
: : On Thu, Mar 11, 2010 at 07:24:23PM -0700, M. Warner Losh wrote:
: So the issue isn't as cut and dried as you might think.
P.S. I think that there's much traction to the idea of moving from
COMPAT_FREEBSDx to some other variable called, for example,
COMPAT_FREEBSD_BACK_TO=x, which will give compatibility for binaries
as old as FreeBSD x.0, and have all the other magic handled behind the
scenes. This would render the
[ Some CC's stripped ]
On Mon, 22 Mar 2010, M. Warner Losh wrote:
P.S. I think that there's much traction to the idea of moving from
COMPAT_FREEBSDx to some other variable called, for example,
COMPAT_FREEBSD_BACK_TO=x, which will give compatibility for binaries
as old as FreeBSD x.0, and have
In message 3c0b01821003221207p4e4eecabqb4f448813bf5a...@mail.gmail.com, Alexa
nder Sack writes:
Am I going crazy or does this sound a lot like Sun/SVR's stream based
network stack?
That is a good and pertinent observation.
I did investigate a number of optimizations to the g_up/g_down scheme
I
On Mar 22, 2010, at 10:52 AM, David O'Brien wrote:
On Mon, Mar 15, 2010 at 09:00:18AM -0700, Julian Elischer wrote:
I certainly agree.. can it be changed please?
I've waited a while to see what other opinions would be expressed on this
topic. I believe there is sufficient support to
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi,
Just a heads-up that zlib in base system (libz) has been updated to
1.2.4. We tried to keep -HEAD as close as possible to the vendor
version, but there is some changes in its internal data structure, and
we did not use versioned symbols in the
On Mon, Mar 22, 2010 at 08:23:43AM +, Poul-Henning Kamp wrote:
In message 4ba633a0.2090...@icyb.net.ua, Andriy Gapon writes:
on 21/03/2010 16:05 Alexander Motin said the following:
Ivan Voras wrote:
Hmm, it looks like it could be easy to spawn more g_* threads (and,
barring specific
On Mar 22, 2010, at 5:36 PM, Pawel Jakub Dawidek wrote:
On Mon, Mar 22, 2010 at 08:23:43AM +, Poul-Henning Kamp wrote:
In message 4ba633a0.2090...@icyb.net.ua, Andriy Gapon writes:
on 21/03/2010 16:05 Alexander Motin said the following:
Ivan Voras wrote:
Hmm, it looks like it could be
Pawel Jakub Dawidek wrote:
On Mon, Mar 22, 2010 at 08:23:43AM +, Poul-Henning Kamp wrote:
In message 4ba633a0.2090...@icyb.net.ua, Andriy Gapon writes:
on 21/03/2010 16:05 Alexander Motin said the following:
Ivan Voras wrote:
Hmm, it looks like it could be easy to spawn more g_* threads
On Sun, Mar 21, 2010 at 7:29 PM, jhell jh...@dataix.net wrote:
Native is equal to CPUTYPE not being defined right ?
Built into GCC is the ability to auto-detect the CPUTYPE when
-mtune=native, if you run this command GCC will tell ouput your
processor type:
gcc -v -x c -E -mtune=native
Could someone commit the last patch in PR 112997 to
share/mk/bsd.cpu.mk, as it fixes the bug where MACHINE_CPU is not set
correctly when CPUTYPE is set to 'native'.
On Tue, Aug 28, 2007 at 1:54 AM, Scot Hetzel swhet...@gmail.com wrote:
Gcc 4.2 has a new cpu_type (native) for x86 and amd64
31 matches
Mail list logo
