Re: Interesting sysctl variables in Mac OS X with hw info
On Fri, Mar 15, 2002 at 10:27:22AM -0800, Terry Lambert wrote: > Josh Paetzel wrote: > > This is a perfect example of, "Just because you can do something, > > doesn't mean you should." > > > > I wouldn't see anything wrong with grabbing the clock frequency of the > > first cpu in the system and noting in the man page that if you have > > multiple cpus and you aren't running them at the same frequency, then > > the reported value is applicable only to the first cpu. > > > > This would save a ton of time in implementing Jordan's ideas, at the > > cost of not being able to deal correctlywith a situation that > > (hopefully) isn't too common in the field. The other less tangible > > disadvantage to my suggestion is that it takes us one step further in our > > single-cpu-centric userland, ala top, uptime, and so forth only > > displaying stats for "one" cpu. > > Incorrect information is always worse than no information. > > -- Terry Yeah, you're right. Six hours of contemplation and I've changed my tune. If it's going to be done, should be done right. Josh To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Removing data segment size limit
In the last episode (Mar 16), Francis Vidal said: > memory_pools is off, main memory is 1.5GB with cache_mem set at > 128MB. cache_dir total is around 96GB (spread across 3 HDDs). I > haven't really monitored the memory growth but it's now at 548MB > (from top). That doesn't sound too bad; For comparison, I've got an 8gb cache_dir with 500k objects, an 8MB cache_dir, and my squid process sits at around 80MB of RAM used. You've got a cache_dir about 10x larger than mine, so I wouldn't be surprised to see an 800MB squid process. I could be completely off base, though. You might want to check with the people on the Squid mailing-list: [EMAIL PROTECTED] -- Dan Nelson [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
[no subject]
To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: gcc -O broken in CURRENT
"Brian T.Schellenberger" wrote: > Well, the linux-netscape 4 is the only browser I know that can handle Java > pages on FreeBSD. > > Are there others? > > If you mean the FreeBSD-native netscape 4.x; yes, it's perfectly silly to run > *that*. 4.7 does this just fine, if you don't move the mouse until it's done loading. That restriction only exists for image mapped interfaces, where the Java GIF loader is used, and then only if the image loading is not serialized by the page design. Note that only Solaris, Windows, and Linux, all of which assume (incorrectly) that a threaded process that is preempted involuntarily will resume executin in the thread that was runningat preemption time, handle the concurrent image loading correctly, if you move the mouse or otherwise cause input to the browser before the loads are complete. Basically, it's bad threading assumptions, and it's fixed in a more recent version, if you can find one. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: PCI read config functions
In message: <[EMAIL PROTECTED]> "Daniel O'Connor" <[EMAIL PROTECTED]> writes: : On Fri, 2002-03-15 at 03:13, M. Warner Losh wrote: : > The pci config space is always mapped. What does pciconf -r pciX:Y:Z : > 0:0xff say? X:Y:Z is the pci bus address. : : mdtest# pciconf -r pci0:11:0 0:0xff : 0x0004 0x0283 0x07000202 0x0008 : 0xd8002000 0xc001 0x 0xc401 : 0x 0x 0x 0x : 0x 0x 0x 0x0109 : 0x 0x 0x 0x : 0x 0x 0x 0x : 0x 0x 0x 0x : 0x 0x 0x 0x : 0x 0x 0x 0x : 0x 0x 0x 0x : 0x 0x 0x 0x : 0x 0x 0x 0x : 0x 0x 0x 0x : 0x 0x 0x 0x : 0x 0x 0x 0x : 0x 0x 0x 0x : : Very odd :( : Time to install Linux on the machine and see if it works there I : think... So it does look like freeBSD is returning something sane and that maybe the card is insane :-(. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
RE: gcc -O broken in CURRENT
Err--the linux netscape 6 runs fine. It's also quite slow to load, but
so far appears to be rather robust.
Cheers,
Ben
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]] On Behalf Of Brian
> T.Schellenberger
> Sent: Friday, March 15, 2002 10:41 PM
> To: Kenneth Culver; Matthew D. Fuller
> Cc: Terry Lambert; [EMAIL PROTECTED]; [EMAIL PROTECTED];
> [EMAIL PROTECTED]
> Subject: Re: gcc -O broken in CURRENT
>
>
> On Friday 15 March 2002 08:53 pm, Kenneth Culver wrote:
> | > (ttypa):{1078}% file
> /usr/local/lib/netscape/communicator-4.7.us.bin
> | > /usr/local/lib/netscape/communicator-4.7.us.bin:
> FreeBSD/i386 compact
> | > demand paged dynamically linked executable
> | >
> | > Now, if you'd like to talk Netscape into building a
> version intended for
> | > a version of FreeBSD newer than, say, 3 years, 3.5 months
> (approximately)
> | > old...
> |
> | I didn't realize anyone still used netscape 4.x. It's so
> disgustingly
> | unstable and slow.
>
> Well, the linux-netscape 4 is the only browser I know that
> can handle Java
> pages on FreeBSD.
>
> Are there others?
>
> If you mean the FreeBSD-native netscape 4.x; yes, it's
> perfectly silly to run
> *that*.
>
> |
> | Ken
> |
> |
> | To Unsubscribe: send mail to [EMAIL PROTECTED]
> | with "unsubscribe freebsd-hackers" in the body of the message
>
> --
> Brian T. Schellenberger . . . . . . . [EMAIL PROTECTED] (work)
> Brian, the man from Babble-On . . . . [EMAIL PROTECTED] (personal)
> ME --> http://www.babbleon.org
> http://www.eff.org <-- GOOD GUYS -->
> http://www.programming-freedom.org
>
> To Unsubscribe: send
> mail to [EMAIL PROTECTED]
> with "unsubscribe freebsd-current" in the body of the message
>
>
>
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: gcc -O broken in CURRENT
On Friday 15 March 2002 08:53 pm, Kenneth Culver wrote:
| > (ttypa):{1078}% file /usr/local/lib/netscape/communicator-4.7.us.bin
| > /usr/local/lib/netscape/communicator-4.7.us.bin: FreeBSD/i386 compact
| > demand paged dynamically linked executable
| >
| > Now, if you'd like to talk Netscape into building a version intended for
| > a version of FreeBSD newer than, say, 3 years, 3.5 months (approximately)
| > old...
|
| I didn't realize anyone still used netscape 4.x. It's so disgustingly
| unstable and slow.
Well, the linux-netscape 4 is the only browser I know that can handle Java
pages on FreeBSD.
Are there others?
If you mean the FreeBSD-native netscape 4.x; yes, it's perfectly silly to run
*that*.
|
| Ken
|
|
| To Unsubscribe: send mail to [EMAIL PROTECTED]
| with "unsubscribe freebsd-hackers" in the body of the message
--
Brian T. Schellenberger . . . . . . . [EMAIL PROTECTED] (work)
Brian, the man from Babble-On . . . . [EMAIL PROTECTED] (personal)
ME --> http://www.babbleon.org
http://www.eff.org <-- GOOD GUYS --> http://www.programming-freedom.org
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: gcc -O broken in CURRENT
On Sat, 16 Mar 2002, Greg Black wrote:
> [Cc's trimmed]
>
> Kenneth Culver wrote:
>
> | > (ttypa):{1078}% file /usr/local/lib/netscape/communicator-4.7.us.bin
> | > /usr/local/lib/netscape/communicator-4.7.us.bin: FreeBSD/i386 compact
> | > demand paged dynamically linked executable
> | >
> | > Now, if you'd like to talk Netscape into building a version intended for
> | > a version of FreeBSD newer than, say, 3 years, 3.5 months (approximately)
> | > old...
> | >
> | I didn't realize anyone still used netscape 4.x. It's so disgustingly
> | unstable and slow.
>
> It's less slow and much more reliable than mozilla and remains
> the only available browser that can access most of the sites I
> need to access.
>
and I use it's mail reader a lot..
> Greg
>
> To Unsubscribe: send mail to [EMAIL PROTECTED]
> with "unsubscribe freebsd-hackers" in the body of the message
>
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: gcc -O broken in CURRENT
> That's odd, I've never had any mozilla problems. All I know is that it > doesn't crash on sites that Netscape crashes on (anything java) and for > me it runs much faster than netscape. It loads slower, but renders pages > much faster, and I tend to load my browser once per day, and just leave > it on. Anyway, this is way OT, so that was my last message about it. Ken To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: gcc -O broken in CURRENT
> It's less slow and much more reliable than mozilla and remains the only > available browser that can access most of the sites I need to access. That's odd, I've never had any mozilla problems. All I know is that it doesn't crash on sites that Netscape crashes on (anything java) and for me it runs much faster than netscape. It loads slower, but renders pages much faster, and I tend to load my browser once per day, and just leave it on. Ken To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: gcc -O broken in CURRENT
> #include , see the thread we had on this a few weeks back on > -chat. > OK, I'll look, but I disagree... Mozilla runs flawlessly for me, and renders much faster than netscape, however it loads really slow. Opera runs nicely too, although it's linux only. Ken To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Removing data segment size limit
Dan, memory_pools is off, main memory is 1.5GB with cache_mem set at 128MB. cache_dir total is around 96GB (spread across 3 HDDs). I haven't really monitored the memory growth but it's now at 548MB (from top). - Original Message - From: "Dan Nelson" <[EMAIL PROTECTED]> To: "Francis Vidal" <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]> Sent: Saturday, March 16, 2002 12:21 AM Subject: Re: Removing data segment size limit > In the last episode (Mar 15), Francis Vidal said: > > Hi, > > > > I'm running a very busy Squid proxy/cache system and I've bumped up the > > data segment size to 768MB but the cache is growing and I'm afraid it > > (Squid process) might stop again once the limit is reached. Is there a > > way to remove the kernel-imposed data segment size limit? Are there > > Squid admins here that might give me tips on fine-tuning? > > You can try setting 'memory_pools off' in your Squid config, which > might make squids memory usage stay closer to its 'cache_mem' setting. > What's cache_mem currently set to, and how fast does squid's memory > usage grow? > > -- > Dan Nelson > [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: gcc -O broken in CURRENT
[Cc's trimmed]
Kenneth Culver wrote:
| > (ttypa):{1078}% file /usr/local/lib/netscape/communicator-4.7.us.bin
| > /usr/local/lib/netscape/communicator-4.7.us.bin: FreeBSD/i386 compact
| > demand paged dynamically linked executable
| >
| > Now, if you'd like to talk Netscape into building a version intended for
| > a version of FreeBSD newer than, say, 3 years, 3.5 months (approximately)
| > old...
| >
| I didn't realize anyone still used netscape 4.x. It's so disgustingly
| unstable and slow.
It's less slow and much more reliable than mozilla and remains
the only available browser that can access most of the sites I
need to access.
Greg
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: gcc -O broken in CURRENT
On Fri, Mar 15, 2002 at 08:53:16PM -0500 I heard the voice of Kenneth Culver, and lo! it spake thus: > > I didn't realize anyone still used netscape 4.x. It's so disgustingly > unstable and slow. That it is. The problem, of course, is that all the alternatives are more unstable and slowER. #include , see the thread we had on this a few weeks back on -chat. -- Matthew Fuller (MF4839) |[EMAIL PROTECTED] Unix Systems Administrator |[EMAIL PROTECTED] Specializing in FreeBSD |http://www.over-yonder.net/ "The only reason I'm burning my candle at both ends, is because I haven't figured out how to light the middle yet" To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: gcc -O broken in CURRENT
> (ttypa):{1078}% file /usr/local/lib/netscape/communicator-4.7.us.bin
> /usr/local/lib/netscape/communicator-4.7.us.bin: FreeBSD/i386 compact
> demand paged dynamically linked executable
>
> Now, if you'd like to talk Netscape into building a version intended for
> a version of FreeBSD newer than, say, 3 years, 3.5 months (approximately)
> old...
>
I didn't realize anyone still used netscape 4.x. It's so disgustingly
unstable and slow.
Ken
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: gcc -O broken in CURRENT
[ Trim the CC's a bit ]
On Fri, Mar 15, 2002 at 04:00:08PM -0800 I heard the voice of
Terry Lambert, and lo! it spake thus:
> Kenneth Culver wrote:
> > > Other reasons I haven't even thought of yet 8-).
> >
> > Yeah, I was just wondering if there were issues making us keep a.out stuff
> > in FreeBSD aside from the "I wanna run 2.2.x programs" issue.
>
> Linking with third party a.out libraries.
>
> Other reasons I haven't even thought of yet 8-).
(ttypa):{1078}% file /usr/local/lib/netscape/communicator-4.7.us.bin
/usr/local/lib/netscape/communicator-4.7.us.bin: FreeBSD/i386 compact
demand paged dynamically linked executable
Now, if you'd like to talk Netscape into building a version intended for
a version of FreeBSD newer than, say, 3 years, 3.5 months (approximately)
old...
--
Matthew Fuller (MF4839) |[EMAIL PROTECTED]
Unix Systems Administrator |[EMAIL PROTECTED]
Specializing in FreeBSD |http://www.over-yonder.net/
"The only reason I'm burning my candle at both ends, is because I
haven't figured out how to light the middle yet"
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: Extending loader(8) for loading kerels/modules split across several disks
For whatever it is worth, I like it.
Maxim Sobolev wrote:
>
> Michael Smith wrote:
> >
> > > > > Please review attached patch, which adds long overdue feature to our
> > > > > loader(8), allowing it to load sequence of files as a single object.
> > > >
> > > > I don't like this. I would much rather see support for 'split' files
> > > > implemented as a stacking filesystem layer like the gzip support, with
> > > > the simple recognition of 'foo.gz.aa' as the first part of a split
> > > > version of 'foo.gz', which in turn is recognised as a compressed version
> > > > of 'foo'.
> > >
> > > I am curious how in this case the layer is going to know how many
> > > parts the file contains?
> >
> > The simple way to do it is to keep asking for more parts until there are
> > no more.
> >
> > You can take the NetBSD approach of wrapping the file in a multipart tar
> > archive.
> >
> > Or a more elegant method involves the use of a control file.
> >
> > eg. the splitfs code, when asked to open "foo" looks for "foo.split"
> > which is a text file containing a list of filenames and media names, eg.
> >
> > foo.aa "Kernel floppy 1"
> > foo.ab "Kernel floppy 2"
> > foo.ac "Kernel and modules floppy"
> >
> > For each file segment, the process is:
> >
> > - try to open the file
> > - prompt "please insert the disk labelled '"
> > - try to open the file
> > - return error
> >
> > At any rate, my key point is that the splitting should be invisible, and
> > *definitely* not pushed up into the loader.
>
> Ok, attached is the path, which does exactly what described. Please
> review and if there are no objections I would like to commit it
> shortly, so that our re@ team would be able to consider it for the
> forthcoming 5.0-DP1 release.
>
> Thanks!
>
> -Maxim
>
>
> Index: src/lib/libstand/Makefile
> ===
> RCS file: /home/ncvs/src/lib/libstand/Makefile,v
> retrieving revision 1.27
> diff -d -u -r1.27 Makefile
> --- src/lib/libstand/Makefile 27 Feb 2002 17:15:37 - 1.27
> +++ src/lib/libstand/Makefile 15 Mar 2002 08:40:31 -
> @@ -153,6 +153,7 @@
> SRCS+= ufs.c nfs.c cd9660.c tftp.c zipfs.c bzipfs.c
> SRCS+= netif.c nfs.c
> SRCS+= dosfs.c ext2fs.c
> +SRCS+= splitfs.c
>
> beforeinstall:
> ${INSTALL} -C -o ${BINOWN} -g ${BINGRP} -m 444 ${.CURDIR}/stand.h \
> Index: src/lib/libstand/bzipfs.c
> ===
> RCS file: /home/ncvs/src/lib/libstand/bzipfs.c,v
> retrieving revision 1.3
> diff -d -u -r1.3 bzipfs.c
> --- src/lib/libstand/bzipfs.c 1 Feb 2002 16:33:40 - 1.3
> +++ src/lib/libstand/bzipfs.c 15 Mar 2002 08:40:31 -
> @@ -150,7 +150,7 @@
>
> /* If the name already ends in .gz or .bz2, ignore it */
> if ((cp = strrchr(fname, '.')) && (!strcmp(cp, ".gz")
> - || !strcmp(cp, ".bz2")))
> + || !strcmp(cp, ".bz2") || !strcmp(cp, ".split")))
> return(ENOENT);
>
> /* Construct new name */
> Index: src/lib/libstand/splitfs.c
> ===
> RCS file: src/lib/libstand/splitfs.c
> diff -N src/lib/libstand/splitfs.c
> --- /dev/null 1 Jan 1970 00:00:00 -
> +++ src/lib/libstand/splitfs.c 15 Mar 2002 08:40:31 -
> @@ -0,0 +1,287 @@
> +/*
> + * Copyright (c) 2002 Maxim Sobolev
> + * All rights reserved.
> + *
> + * Redistribution and use in source and binary forms, with or without
> + * modification, are permitted provided that the following conditions
> + * are met:
> + * 1. Redistributions of source code must retain the above copyright
> + *notice, this list of conditions and the following disclaimer.
> + * 2. Redistributions in binary form must reproduce the above copyright
> + *notice, this list of conditions and the following disclaimer in the
> + *documentation and/or other materials provided with the distribution.
> + *
> + * THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND
> + * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
> + * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
> + * ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE
> + * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
> + * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
> + * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
> + * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
> + * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
> + * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
> + * SUCH DAMAGE.
> + */
> +
> +#include
> +__FBSDID("$FreeBSD$");
> +
> +#include "stand.h"
> +
> +#define NTRIES (3)
> +#define CONF_BUF (512)
> +#define SEEK_BUF
Re: weird sh behaviour
On Fri, Mar 15, 2002 at 04:26:09PM -0800, Luigi Rizzo wrote: > /bin/sh seems not to expanding metacharacters in filenames used for > I/O redirection: *snip* > Is it a feature or a bug ? >From my understanding of the POSIX standard, pathname expansion (globbing etc.) should be performed on the word following the > or <, and the result is undefined if more than one file name matches the pattern. FWIW Solaris /bin/sh does not expand, /bin/ksh does, ksh93 does, zsh does. Tim To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
weird sh behaviour
/bin/sh seems not to expanding metacharacters in filenames used for I/O redirection: $ /bin/sh $ ls -l $ touch bbb $ echo test > b* $ ls -l total 2 -rw-r--r-- 1 luigi wheel 5 Mar 16 01:20 b* -rw-r--r-- 1 luigi wheel 0 Mar 16 01:20 bbb $ By contrast, csh and bash do the right thing: bash-2.05a$ ls -l bash-2.05a$ touch bbb bash-2.05a$ echo test > b* bash-2.05a$ ls -l total 2 -rw-r--r-- 1 luigi wheel 5 Mar 16 01:24 bbb Is it a feature or a bug ? cheers luigi To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: gcc -O broken in CURRENT
Kenneth Culver wrote: > > Other reasons I haven't even thought of yet 8-). > > Yeah, I was just wondering if there were issues making us keep a.out stuff > in FreeBSD aside from the "I wanna run 2.2.x programs" issue. Linking with third party a.out libraries. Other reasons I haven't even thought of yet 8-). I can probably add one new reason per email indefinitely, if you want to insist... -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: gcc -O broken in CURRENT
> > At the risk of being yelled at, I have a question: Why do we still need to > > support a.out? I know that a lot of people MIGHT still have some a.out > > binaries lying around, but FreeBSD's default binary format has been ELF > > for 3 or 4 years (Since 3.0-3.1 I believe). I'm not saying that we should > > entirely switch over to the regular gnu toolchain, but is it really > > necessary to keep supporting a.out? Just my $0.02 > > The switchover is not trivial. You're asking someone to do > work for something that's not really valuable to them. > > There are certain boot code features that require the use of > a.out kernels; this is less an issue than it was, but there > were a number of things lost when we went to the new loader > that are important for embedded environments. > > Cross-building for older platforms (not as big an issue, IMO). > > Other reasons I haven't even thought of yet 8-). > Yeah, I was just wondering if there were issues making us keep a.out stuff in FreeBSD aside from the "I wanna run 2.2.x programs" issue. Ken To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: gcc -O broken in CURRENT
> We aren't changing this for GCC 2.95 in 5-CURRENT. PEROID. There is > zero reason for subjecting users to this ABI change for what would be > gained. > > If you want to do something productive, submit patches that Bmake GCC 3.1 > (which move us to Dwarf2 unwinding as a product). > Oh ok, that's another story altogether... If nobody has gotten to it by the May timeframe I'll do it. I've been looking for a way to contribute to the FreeBSD project anyway. Right now I'm working nearly 40 hrs a week and going to college full-time, so I don't really have time to do anything else. Ken To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: gcc -O broken in CURRENT
Kenneth Culver wrote: > At the risk of being yelled at, I have a question: Why do we still need to > support a.out? I know that a lot of people MIGHT still have some a.out > binaries lying around, but FreeBSD's default binary format has been ELF > for 3 or 4 years (Since 3.0-3.1 I believe). I'm not saying that we should > entirely switch over to the regular gnu toolchain, but is it really > necessary to keep supporting a.out? Just my $0.02 The switchover is not trivial. You're asking someone to do work for something that's not really valuable to them. There are certain boot code features that require the use of a.out kernels; this is less an issue than it was, but there were a number of things lost when we went to the new loader that are important for embedded environments. Cross-building for older platforms (not as big an issue, IMO). Other reasons I haven't even thought of yet 8-). -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: gcc -O broken in CURRENT
On Fri, Mar 15, 2002 at 05:26:37PM -0500, Kenneth Culver wrote: > > > At the risk of being yelled at, I have a question: Why do we still need to > > > support a.out? I know that a lot of people MIGHT still have some a.out ... > > Rather than offer $0.02, send the patch. > > Well, I was just asking if it is necessary, I'd make a patch if there was > interest. My mail was asking if there is interest. We aren't changing this for GCC 2.95 in 5-CURRENT. PEROID. There is zero reason for subjecting users to this ABI change for what would be gained. If you want to do something productive, submit patches that Bmake GCC 3.1 (which move us to Dwarf2 unwinding as a product). -- -- David ([EMAIL PROTECTED]) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: gcc -O broken in CURRENT
> > At the risk of being yelled at, I have a question: Why do we still need to > > support a.out? I know that a lot of people MIGHT still have some a.out > > binaries lying around, but FreeBSD's default binary format has been ELF > > for 3 or 4 years (Since 3.0-3.1 I believe). I'm not saying that we should > > entirely switch over to the regular gnu toolchain, but is it really > > necessary to keep supporting a.out? Just my $0.02 > > Rather than offer $0.02, send the patch. > Well, I was just asking if it is necessary, I'd make a patch if there was interest. My mail was asking if there is interest. Ken To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: gcc -O broken in CURRENT
On Fri, Mar 15, 2002 at 04:54:59PM -0500, Kenneth Culver wrote: > > At the risk of being yelled at, I have a question: Why do we still need to > support a.out? I know that a lot of people MIGHT still have some a.out > binaries lying around, but FreeBSD's default binary format has been ELF > for 3 or 4 years (Since 3.0-3.1 I believe). I'm not saying that we should > entirely switch over to the regular gnu toolchain, but is it really > necessary to keep supporting a.out? Just my $0.02 Rather than offer $0.02, send the patch. -- -- David ([EMAIL PROTECTED]) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: gcc -O broken in CURRENT
> I guess it's possible to change over entirely. That would
> mean we would loase a.out support because the GNU tools are
> becoming incapable of supporting a.out ("all machines we
> run on are Linux machines" syndrome).
>
> If we really wanted to avoid problems like this in the future,
> we'd just scrap FreeBSD entirely, and go to Linux, a bit at a
> time, starting with ELF, then DWARF2 exceptions, and then
> the Linux ABI instead of the FreeBSD ABI, and then all of Linux,
> a piece at a time.
At the risk of being yelled at, I have a question: Why do we still need to
support a.out? I know that a lot of people MIGHT still have some a.out
binaries lying around, but FreeBSD's default binary format has been ELF
for 3 or 4 years (Since 3.0-3.1 I believe). I'm not saying that we should
entirely switch over to the regular gnu toolchain, but is it really
necessary to keep supporting a.out? Just my $0.02
Ken
>
> PS: If I sound annoyed, it's because it's sometimes annoying
> to have your toolchain controlled by someone with an interest
> in a product that competes with yours; that works for people
> competing with Microsoft products on Microsoft platforms with
> a need to use Microsoft tools, and it applies to Cygnus being
> owned by RedHat and them controlling the FreeBSD tools.
>
> -- Terry
>
> To Unsubscribe: send mail to [EMAIL PROTECTED]
> with "unsubscribe freebsd-current" in the body of the message
>
>
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: Interesting sysctl variables in Mac OS X with hw info
:Doug White wrote: :> I've been asked several times about how to get CPU speed information for :> inventory purposes. :> :> People would really like the speed number printed on the chip, not what :> it's currently running at, if that's retrievable :) : :Can't mask the speed number. : :Chips with a lower printed number are just chips that failed :testing at higher clock rates. Sometimes, they don't even :fail, if they have a big demand swing. 8-). : :I guess they could laser it out... : :If Intel really didn't want overclocking to happen, they would :put the clock on board the CPU, and make it an output, not an :input... 8-) 8-). : :-- Terry Actually, Intel did just that on their Celerons a little while after they were first introduced. People realized that Intel was stamping chips that tested at higher clock rates with lower clock labels in order to keep their lower-rated distribution pipelines full. That created a major overclocking craze on the Celeron line as well as no small amount of grey-market relabeling of chips. This also led to a certain percentage of grey-market relabeled chips failing since not all the lower-rated chips passed the higher rated tests. Enough did, however, and Intel actually began losing market share in their higher-rated chips to their lower-rated chips. Oops! To combat this Intel actually started either lasering or fuse-blowing the PLLs on the chips to make them match their labels and prevent them from being too seriously overclocked. I don't know if they bother to do it anymore, though, as the chip speed testing gap is now back to normal... packaging and heat dissipation has become important again. -Matt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
poll() timing problems?
We are experiencing some problems which I think *could* be related to timeout problems with poll(). 1) mysql-3.23.48 + FreeBSD 4.2-RELEASE (also happens with prior mysql releases) CPU: Pentium III/Pentium III Xeon/Celeron (796.54-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x683 Stepping = 3 Features=0x387fbff FreeBSD/SMP: Multiprocessor motherboard cpu0 (BSP): apic id: 1, version: 0x00040011, at 0xfee0 cpu1 (AP): apic id: 0, version: 0x00040011, at 0xfee0 io0 (APIC): apic id: 2, version: 0x00170011, at 0xfec0 MySQL works fine for a while (sometimes a day, sometimes only an hour) but then switches into "busy mode". Attaching a "truss" to the pid gives the following: poll(0x8253000,0x3,0x2690) = 1 (0x1) gettimeofday(0x283512e8,0x0) = 0 (0x0) poll(0x8253000,0x3,0x268f) = 1 (0x1) gettimeofday(0x283512e8,0x0) = 0 (0x0) poll(0x8253000,0x3,0x268e) = 1 (0x1) gettimeofday(0x283512e8,0x0) = 0 (0x0) poll(0x8253000,0x3,0x268e) = 1 (0x1) gettimeofday(0x283512e8,0x0) = 0 (0x0) poll(0x8253000,0x3,0x268e) = 1 (0x1) gettimeofday(0x283512e8,0x0) = 0 (0x0) poll(0x8253000,0x3,0x268d) = 1 (0x1) gettimeofday(0x283512e8,0x0) = 0 (0x0) poll(0x8253000,0x3,0x268d) = 1 (0x1) over and over and over again with a lot of those loops per second (however it still works correctly answering queries and that) using one of the two CPUs at nearly 100%. To me it looks like poll() returns from a timeout as I can't see any read()/write() syscalls in the trace and I assume they should be visible if a I/O operation on a FD would be ready, causing poll() to return. 2) Mutt 1.2.5i + FreeBSD 4.4-RELEASE [using ncurses 5.1] CPU: Pentium III/Pentium III Xeon/Celeron (995.68-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x686 Stepping = 6 Features=0x387fbff FreeBSD/SMP: Multiprocessor motherboard cpu0 (BSP): apic id: 1, version: 0x00040011, at 0xfee0 cpu1 (AP): apic id: 0, version: 0x00040011, at 0xfee0 io0 (APIC): apic id: 2, version: 0x00170011, at 0xfec0 If the user terminates the X session the xterm dies, but the bash and the mutt survive and from that point mutt does nearly the same as above (sorry no trace avail): poll(), gettimeofday(), check mailbox, poll(), ... at a *very* high rate. Here I also assume timeout as the reason for returning from poll. I've checked the PRs (open and closed) but couldn't find a problems I would put in relation to our problems. Has anybody else encountered this kind of problems? Any solutions? If you need more information, I'll try my best to provide them. Thanks, \Maex -- SpaceNet AG| Joseph-Dollinger-Bogen 14 | Fon: +49 (89) 32356-0 Research & Development | D-80807 Muenchen| Fax: +49 (89) 32356-299 "The security, stability and reliability of a computer system is reciprocally proportional to the amount of vacuity between the ears of the admin" To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Interesting sysctl variables in Mac OS X with hw info
Doug White wrote: > I've been asked several times about how to get CPU speed information for > inventory purposes. > > People would really like the speed number printed on the chip, not what > it's currently running at, if that's retrievable :) Can't mask the speed number. Chips with a lower printed number are just chips that failed testing at higher clock rates. Sometimes, they don't even fail, if they have a big demand swing. 8-). I guess they could laser it out... If Intel really didn't want overclocking to happen, they would put the clock on board the CPU, and make it an output, not an input... 8-) 8-). -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Interesting sysctl variables in Mac OS X with hw info
On Thu, 14 Mar 2002, Jordan Hubbard wrote: > > What for? You haven't caught the Megahertz bug too, have you? 8) > > I'm not supposed to focus on Megahertz, I work for Apple, but various > benchmarking folks also like to be able to print stats like this out > on their comparison charts and it seems a lot easier than grepping > /var/run/dmesg.boot. :) I've been asked several times about how to get CPU speed information for inventory purposes. People would really like the speed number printed on the chip, not what it's currently running at, if that's retrievable :) Doug White| FreeBSD: The Power to Serve [EMAIL PROTECTED] | www.FreeBSD.org To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Should the stat(2) man page contain information on test macros
> Just cross-reference to a man page that has them. chmod(2) > seems to be the most logical choice. The chmod(2) man page doesn't have the S_ISBLK, S_ISCHR and related macros documented, and personally I don't think that is the right place for this particular stat related macros.. :) Thanks, Regards, -- Hiten Pandya http://jfs4bsd.sf.net - JFS for FreeBSD (JFS4BSD) http://www.FreeBSD.org - The Power to Serve msg32883/pgp0.pgp Description: PGP signature
Re: Should the stat(2) man page contain information on test macros
On Friday, March 15, 2002, Hiten Pandya wrote: > OK, is it a good idea, to have the S_IS* macros documented in the > stat(2) man page, or are they documented in the man pages (other > than stat(2)) already? :) Just cross-reference to a man page that has them. chmod(2) seems to be the most logical choice. -- +---++ | Chris Costello| Performance is easier to add than clarity. | | [EMAIL PROTECTED] || +---++ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Should the stat(2) man page contain information on test macros
Hi, I might be missing the point here, and I tried looking for this in all the stat man pages (apropos stat), but couldn't find it. OK, is it a good idea, to have the S_IS* macros documented in the stat(2) man page, or are they documented in the man pages (other than stat(2)) already? :) Thanks, Regards, -- Hiten Pandya http://jfs4bsd.sf.net - JFS for FreeBSD (JFS4BSD) http://www.FreeBSD.org - The Power to Serve msg32881/pgp0.pgp Description: PGP signature
Re: Extending loader(8) for loading kerels/modules split across several disks
Michael Smith wrote:
>
> > > > Please review attached patch, which adds long overdue feature to our
> > > > loader(8), allowing it to load sequence of files as a single object.
> > >
> > > I don't like this. I would much rather see support for 'split' files
> > > implemented as a stacking filesystem layer like the gzip support, with
> > > the simple recognition of 'foo.gz.aa' as the first part of a split
> > > version of 'foo.gz', which in turn is recognised as a compressed version
> > > of 'foo'.
> >
> > I am curious how in this case the layer is going to know how many
> > parts the file contains?
>
> The simple way to do it is to keep asking for more parts until there are
> no more.
>
> You can take the NetBSD approach of wrapping the file in a multipart tar
> archive.
>
> Or a more elegant method involves the use of a control file.
>
> eg. the splitfs code, when asked to open "foo" looks for "foo.split"
> which is a text file containing a list of filenames and media names, eg.
>
> foo.aa "Kernel floppy 1"
> foo.ab "Kernel floppy 2"
> foo.ac "Kernel and modules floppy"
>
> For each file segment, the process is:
>
> - try to open the file
> - prompt "please insert the disk labelled '"
> - try to open the file
> - return error
>
> At any rate, my key point is that the splitting should be invisible, and
> *definitely* not pushed up into the loader.
Ok, attached is the path, which does exactly what described. Please
review and if there are no objections I would like to commit it
shortly, so that our re@ team would be able to consider it for the
forthcoming 5.0-DP1 release.
Thanks!
-Maxim
Index: src/lib/libstand/Makefile
===
RCS file: /home/ncvs/src/lib/libstand/Makefile,v
retrieving revision 1.27
diff -d -u -r1.27 Makefile
--- src/lib/libstand/Makefile 27 Feb 2002 17:15:37 - 1.27
+++ src/lib/libstand/Makefile 15 Mar 2002 08:40:31 -
@@ -153,6 +153,7 @@
SRCS+= ufs.c nfs.c cd9660.c tftp.c zipfs.c bzipfs.c
SRCS+= netif.c nfs.c
SRCS+= dosfs.c ext2fs.c
+SRCS+= splitfs.c
beforeinstall:
${INSTALL} -C -o ${BINOWN} -g ${BINGRP} -m 444 ${.CURDIR}/stand.h \
Index: src/lib/libstand/bzipfs.c
===
RCS file: /home/ncvs/src/lib/libstand/bzipfs.c,v
retrieving revision 1.3
diff -d -u -r1.3 bzipfs.c
--- src/lib/libstand/bzipfs.c 1 Feb 2002 16:33:40 - 1.3
+++ src/lib/libstand/bzipfs.c 15 Mar 2002 08:40:31 -
@@ -150,7 +150,7 @@
/* If the name already ends in .gz or .bz2, ignore it */
if ((cp = strrchr(fname, '.')) && (!strcmp(cp, ".gz")
- || !strcmp(cp, ".bz2")))
+ || !strcmp(cp, ".bz2") || !strcmp(cp, ".split")))
return(ENOENT);
/* Construct new name */
Index: src/lib/libstand/splitfs.c
===
RCS file: src/lib/libstand/splitfs.c
diff -N src/lib/libstand/splitfs.c
--- /dev/null 1 Jan 1970 00:00:00 -
+++ src/lib/libstand/splitfs.c 15 Mar 2002 08:40:31 -
@@ -0,0 +1,287 @@
+/*
+ * Copyright (c) 2002 Maxim Sobolev
+ * All rights reserved.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+ * are met:
+ * 1. Redistributions of source code must retain the above copyright
+ *notice, this list of conditions and the following disclaimer.
+ * 2. Redistributions in binary form must reproduce the above copyright
+ *notice, this list of conditions and the following disclaimer in the
+ *documentation and/or other materials provided with the distribution.
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND
+ * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
+ * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
+ * ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE
+ * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
+ * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
+ * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
+ * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
+ * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
+ * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
+ * SUCH DAMAGE.
+ */
+
+#include
+__FBSDID("$FreeBSD$");
+
+#include "stand.h"
+
+#define NTRIES (3)
+#define CONF_BUF (512)
+#define SEEK_BUF (512)
+
+struct split_file
+{
+char **filesv;/* Filenames */
+char **descsv;/* Descriptions */
+int filesc; /* Number of parts */
+int curfile; /* Current file number */
+int curfd;/* Current file descriptor */
+off_t tot_pos; /* Offset from the beginning of the sequence */
+
Re: Interesting sysctl variables in Mac OS X with hw info
Josh Paetzel wrote: > This is a perfect example of, "Just because you can do something, > doesn't mean you should." > > I wouldn't see anything wrong with grabbing the clock frequency of the > first cpu in the system and noting in the man page that if you have > multiple cpus and you aren't running them at the same frequency, then > the reported value is applicable only to the first cpu. > > This would save a ton of time in implementing Jordan's ideas, at the > cost of not being able to deal correctlywith a situation that > (hopefully) isn't too common in the field. The other less tangible > disadvantage to my suggestion is that it takes us one step further in our > single-cpu-centric userland, ala top, uptime, and so forth only > displaying stats for "one" cpu. Incorrect information is always worse than no information. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Interesting sysctl variables in Mac OS X with hw info
On Fri, Mar 15, 2002 at 10:08:53AM +, Josh Paetzel wrote: > This is a perfect example of, "Just because you can do something, > doesn't mean you should." > > I wouldn't see anything wrong with grabbing the clock frequency of the > first cpu in the system and noting in the man page that if you have > multiple cpus and you aren't running them at the same frequency, then > the reported value is applicable only to the first cpu. > > This would save a ton of time in implementing Jordan's ideas, at the > cost of not being able to deal correctlywith a situation that > (hopefully) isn't too common in the field. The other less tangible > disadvantage to my suggestion is that it takes us one step further in our > single-cpu-centric userland, ala top, uptime, and so forth only > displaying stats for "one" cpu. That would be shortsighted and save nearly nothing. I certaintly would not have a problem with doing something lame in the first implementation like just looped over the number of CPUs to create identical (possiably wrong) per-cpu info. That would add maybe half a dozen lines of code and would be right in most cases. However, there's no telling what the future holds and mismatched CPUs might become more common with time so we should avoid intrenching poorly designed sysctls when they don't add much to the ease of implementation. -- Brooks -- Any statement of the form "X is the one, true Y" is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 msg32878/pgp0.pgp Description: PGP signature
Re: gcc -O broken in CURRENT
On Fri, Mar 15, 2002 at 01:37:39PM +0100, Jan Stocker wrote: > A little bit... most of you argumenting about binary incompatibility > for -stable. OK... no chance to do it there, its my opinion too. But why not > doing it for current and using that most common dwarf unwinding now (for a There is no need to cause developers to go thru several ABI changes such that they cannot get their other FreeBSD development done. With GCC 3.1 a number of ABI changes will happen. > > Port has less patches. If you look at > > /usr/src/contrib/gcc/contrib/freebsd.h and > > /usr/src/contrib/gcc/contrib/i386/freebsd.h you will see how much things > > have to be modified because we support dual ELF/a.out [still]. > > This may be changed too for 5.0 shouldnt it? Why? I don't see how you justfied removing the functionality and I don't see how it is causing you any problems being there. -- -- David ([EMAIL PROTECTED]) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: gcc -O broken in CURRENT
Jan Stocker wrote:
[ ... DWARF vs. setjmp/longjmp ... ]
> A little bit... most of you argumenting about binary incompatibility
> for -stable. OK... no chance to do it there, its my opinion too. But why not
> doing it for current and using that most common dwarf unwinding now (for a
> later ia64 port it should be faster than setjump i think). Okay everything
> needs a recompile but this -current is current and not a production os.
>
> You're right that we need a patch for -stable. But if we take the approach
> for -current maybe we leave these problems behind us and following the path
> of the rank and file (using dwarf2) and making profit of their experience
> versus doing this ourself and creating patches.
I guess it's possible to change over entirely. That would
mean we would loase a.out support because the GNU tools are
becoming incapable of supporting a.out ("all machines we
run on are Linux machines" syndrome).
If we really wanted to avoid problems like this in the future,
we'd just scrap FreeBSD entirely, and go to Linux, a bit at a
time, starting with ELF, then DWARF2 exceptions, and then
the Linux ABI instead of the FreeBSD ABI, and then all of Linux,
a piece at a time.
PS: If I sound annoyed, it's because it's sometimes annoying
to have your toolchain controlled by someone with an interest
in a product that competes with yours; that works for people
competing with Microsoft products on Microsoft platforms with
a need to use Microsoft tools, and it applies to Cygnus being
owned by RedHat and them controlling the FreeBSD tools.
-- Terry
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: Removing data segment size limit
In the last episode (Mar 15), Francis Vidal said: > Hi, > > I'm running a very busy Squid proxy/cache system and I've bumped up the > data segment size to 768MB but the cache is growing and I'm afraid it > (Squid process) might stop again once the limit is reached. Is there a > way to remove the kernel-imposed data segment size limit? Are there > Squid admins here that might give me tips on fine-tuning? You can try setting 'memory_pools off' in your Squid config, which might make squids memory usage stay closer to its 'cache_mem' setting. What's cache_mem currently set to, and how fast does squid's memory usage grow? -- Dan Nelson [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Interesting sysctl variables in Mac OS X with hw info
On Wed, Mar 13, 2002 at 08:46:46PM -0800, Terry Lambert wrote: > Matthew Emmerton wrote: > > > > > This was actually discussed a while back (a month or two ago). > > > > > > > > > > It got really bogged down when someone pointed out that > > > > > they were running CPUs with different clock rates in their > > > > > SMP box, just to see what the net effect would be. THe > > > > > problem was, of course, which one do you report, when the > > > > > numbers don't match exactly, and/or how do you report both > > > > > (or N)? > > > > I thought it was a real bad thing to run CPUs in SMP systems at different > > clock rates. In fact, I never thought it was possible. I know I can't on > > my old 2-way P166 box, but things have changed a lot since '91. > > It depends on the stepping, and that the external interfaces > are all the same (voltage, clock speed for memory and I/O, > etc.). > > PIII's can run this way, for sure. This is a perfect example of, "Just because you can do something, doesn't mean you should." I wouldn't see anything wrong with grabbing the clock frequency of the first cpu in the system and noting in the man page that if you have multiple cpus and you aren't running them at the same frequency, then the reported value is applicable only to the first cpu. This would save a ton of time in implementing Jordan's ideas, at the cost of not being able to deal correctlywith a situation that (hopefully) isn't too common in the field. The other less tangible disadvantage to my suggestion is that it takes us one step further in our single-cpu-centric userland, ala top, uptime, and so forth only displaying stats for "one" cpu. Josh > > If you want to find out who's doing it, you only need to search > the SMP list archives; it wasn't important enough for me to commit > the message to memory, I only remember the fact that someone was > doing it successfully. > > -- Terry > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-hackers" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
RE: gcc -O broken in CURRENT
> > 2) Bug is in os delivered gcc but not in port gcc. > >a) port has more or less patches / os gcc has been modified > > --> Didn't someone told they are the same? > >b) other options were set at compile time > > --> Why dont change to the same in the port? > > Leads it to a broken world? > > If the only difference is the lost of binary compatibility, > > i would say, ok... do it now and we'll need to compile > > or ports... > > SOme bugs are related to the FreeBSD use of setjmp/longjmp > to do exception unwinding rather than using the DWARF primitives. > > When you change the toolchain, you change the exception unwinding > code when you use the ports version. > > You also introduce incompatabilities with the installed libstdc++ > library, which uses the setjmp/longjmp exception unwinding, which > will be in conflict with any exception throwing/handling code > compiled with the ports compiler that uses the DWARF2 version. > > The tests that show it working with the ports version do not test > anything other than bare-bones operation, without testing code > interoperability eith vendor libraries. > > Does that clear things up for you? A little bit... most of you argumenting about binary incompatibility for -stable. OK... no chance to do it there, its my opinion too. But why not doing it for current and using that most common dwarf unwinding now (for a later ia64 port it should be faster than setjump i think). Okay everything needs a recompile but this -current is current and not a production os. You're right that we need a patch for -stable. But if we take the approach for -current maybe we leave these problems behind us and following the path of the rank and file (using dwarf2) and making profit of their experience versus doing this ourself and creating patches. > -Original Message- > From: David O'Brien [mailto:[EMAIL PROTECTED]] > Sent: Thursday, March 14, 2002 7:16 PM > To: Jan Stocker > Cc: Alexander Kabaev; Martin Blapp; [EMAIL PROTECTED]; > [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; > [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] > Subject: Re: gcc -O broken in CURRENT > > > On Thu, Mar 14, 2002 at 06:36:05PM +0100, Jan Stocker wrote: > > 2) Bug is in os delivered gcc but not in port gcc. > >a) port has more or less patches / os gcc has been modified > > --> Didn't someone told they are the same? > > Port has less patches. If you look at > /usr/src/contrib/gcc/contrib/freebsd.h and > /usr/src/contrib/gcc/contrib/i386/freebsd.h you will see how much things > have to be modified because we support dual ELF/a.out [still]. This may be changed too for 5.0 shouldnt it? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Removing data segment size limit
On Fri, Mar 15, 2002 at 06:49:28PM +0800, Francis Vidal wrote: > Hi, > > I'm running a very busy Squid proxy/cache system and I've bumped up the > data segment size to 768MB but the cache is growing and I'm afraid it > (Squid process) might stop again once the limit is reached. Is there a > way to remove the kernel-imposed data segment size limit? Are there > Squid admins here that might give me tips on fine-tuning? Remove squid and try to use oops cache proxy-server (at www/oops). -- Rgdz,/"\ Sergey Osokin aka oZZ, \ / ASCII RIBBON CAMPAIGN [EMAIL PROTECTED]X AGAINST HTML MAIL http://freebsd.org.ru/~osa/ / \ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
bin/35454
Hello, I hope this mail is appropriate for this mailinglist. I have a question regarding a pr I've submitted. I've made the mistake to submit it without a patch. One week later I wrote a patch, and submitted it in a followup, but I fear that everybody interessted in the PR had already looked at it, and so no one will see the patch. Is there anything I can/should do except submitting the PR with a patch in the beginning? Thanks Nicolas To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Removing data segment size limit
Hi, I'm running a very busy Squid proxy/cache system and I've bumped up the data segment size to 768MB but the cache is growing and I'm afraid it (Squid process) might stop again once the limit is reached. Is there a way to remove the kernel-imposed data segment size limit? Are there Squid admins here that might give me tips on fine-tuning? Thanks! --- Francis A. Vidal Bitstop Network Services, Inc. www.dagupan.com | www.kuro.ph To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
