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 wrote:
> Gcc 4.2 has a new cpu_type (native) for x86 and amd64 systems. This
> cpu_typ
On Sun, Mar 21, 2010 at 7:29 PM, jhell 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 /dev/null -o /dev/null
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 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 li
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,
> >>> barr
-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 pa
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
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
[ 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
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
In message: <20100322185331.ga88...@dragon.nuxi.org>
"David O'Brien" 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. There's
: >
On Mon, Mar 22, 2010 at 2:45 PM, M. Warner Losh wrote:
> In message:
> Scott Long 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
In message:
Scott Long 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 two simple
: partition transforms (mbr, bsdlabel) and/or a simpl
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 8.0-RELE
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 i
On Mar 22, 2010, at 9:52 AM, Alexander Sack wrote:
> On Mon, Mar 22, 2010 at 8:39 AM, John Baldwin wrote:
>> On Monday 22 March 2010 7:40:18 am Gary Jennejohn wrote:
>>> On Sun, 21 Mar 2010 19:03:56 +0200
>>> Alexander Motin wrote:
>>>
Scott Long wrote:
> Are there non-CAM drivers that
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 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
> >
> > wrote:
> >> TB --- 2010-03-21 04:53:25 - /usr/bin/make -B buildkernel
> >> KERNCONF=PAE
> >>
> > Kernel build for PAE st
On Mon, Mar 22, 2010 at 8:39 AM, John Baldwin wrote:
> On Monday 22 March 2010 7:40:18 am Gary Jennejohn wrote:
>> On Sun, 21 Mar 2010 19:03:56 +0200
>> Alexander Motin wrote:
>>
>> > Scott Long wrote:
>> > > Are there non-CAM drivers that look at MAXPHYS, or that silently assume
> that
>> > > MA
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
dum
On Monday 22 March 2010 7:40:18 am Gary Jennejohn wrote:
> On Sun, 21 Mar 2010 19:03:56 +0200
> Alexander Motin 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 questio
Quoting Scott Long (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 media server.
I do
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 - /usr/bin/c
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:43A
On Sun, 21 Mar 2010 19:03:56 +0200
Alexander Motin 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 quick&dirty grep looking for MAXPHYS in /sys.
Some dr
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 avail
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
on 21/03/2010 08:25 Garrett Cooper said the following:
> On Sat, Mar 20, 2010 at 9:58 PM, FreeBSD Tinderbox
> 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 kernel
>>
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
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 bit
31 matches
Mail list logo
