On 09-Feb-2003 Dan Nelson wrote:
> In the last episode (Feb 08), Conrad Sabatier said:
>> Call me a fool, but I've been using this for quite some time now, in both
>> -stable (well, with slight modifications) and -current:
>>
>> CPUTYPE?=k7
>>
>> CFLAGS= -O2 -pipe -mmmx -m3dnow -fforce-mem -fforc
In the last episode (Feb 08), Conrad Sabatier said:
> Call me a fool, but I've been using this for quite some time now, in both
> -stable (well, with slight modifications) and -current:
>
> CPUTYPE?=k7
>
> CFLAGS= -O2 -pipe -mmmx -m3dnow -fforce-mem -fforce-addr -fstrength-reduce \
> -fthread-jump
Title: CepNews
On 08-Feb-2003 Ray Kohler wrote:
> Has anyone tried building world/kernel with high optimizations (-O2,
> -O3) recently? What breaks? (Booby prize to whoever says "common sense"
> ;) I last tried it quite a few months ago and the resolver died on me,
> don't know what else. I'm not really thinking
At 8:15 PM -0500 2/8/03, Garance A Drosihn wrote:
I'm also getting a number of syslog'ed error messages about
sshd[14235]: in _openpam_check_error_code():
pam_sm_setcred(): unexpected return value 24
with the system I built on Feb 3rd. However, I do notice there
have been mor
On Sat, Feb 08, 2003 at 02:04:56PM -0800, Kris Kennaway wrote:
> On Sat, Feb 08, 2003 at 04:12:26PM +0100, Thomas Moestl wrote:
>
> > addr2line will usually point to the first line of a statement if it
> > spans multiple lines; in this case, the full guard is:
> >
> > while (
Thus spake Terry Lambert <[EMAIL PROTECTED]>:
> David Schultz wrote:
> > Thus spake Terry Lambert <[EMAIL PROTECTED]>:
> > > Actually, failure to use optimization suppresses some compilation
> > > warnings, particularly those which normally print from using some
> > > variables without initializing
David Schultz wrote:
> Thus spake Terry Lambert <[EMAIL PROTECTED]>:
> > Actually, failure to use optimization suppresses some compilation
> > warnings, particularly those which normally print from using some
> > variables without initializing them.
>
> I think you're thinking of dataflow analysis
At 4:39 PM -0800 2/8/03, David O'Brien wrote:
cc -pipe -O -march=athlon -D_IEEE_LIBM -D_ARCH_INDIRECT=i387_ -c
/FBSD/src/lib/msun/src/e_gammaf_r.c -o e_gammaf_r.o
In file included from
/FBSD/obj/FBSD/src/secure/lib/libcrypto/openssl/e_os2.h:56,
from
/FBSD/obj/FBSD/src/secure/
cc -pipe -O -march=athlon -D_IEEE_LIBM -D_ARCH_INDIRECT=i387_ -c
/FBSD/src/lib/msun/src/e_gammaf_r.c -o e_gammaf_r.o
In file included from /FBSD/obj/FBSD/src/secure/lib/libcrypto/openssl/e_os2.h:56,
from /FBSD/obj/FBSD/src/secure/lib/libcrypto/openssl/symhacks.h:58,
--
>>> Rebuilding the temporary build tree
--
>>> stage 1: bootstrap tools
--
>>> stage 2: cleaning up the object tree
Thus spake Terry Lambert <[EMAIL PROTECTED]>:
> David Schultz wrote:
> > Thus spake Ray Kohler <[EMAIL PROTECTED]>:
> > > Has anyone tried building world/kernel with high optimizations (-O2,
> > > -O3) recently? What breaks? (Booby prize to whoever says "common sense"
> > > ;) I last tried it quite
David Schultz wrote:
> Thus spake Ray Kohler <[EMAIL PROTECTED]>:
> > Has anyone tried building world/kernel with high optimizations (-O2,
> > -O3) recently? What breaks? (Booby prize to whoever says "common sense"
> > ;) I last tried it quite a few months ago and the resolver died on me,
> > don't
On Saturday, 8 February 2003 at 18:34:04 +0100, Michael Reifenberger wrote:
> On Fri, 7 Feb 2003, Michael Reifenberger wrote:
> ...
>>> As a workaround, you can try setting
>>>
>>> vinum_load=YES
>>> vinum.autostart=YES
>>>
>>> in your /boot/loader.conf, /and/ remove the start_vinum line from
>>>
On Saturday, 8 February 2003 at 21:42:27 +0100, Joerg Wunsch wrote:
> As Greg 'groggy' Lehey wrote:
>
>>> I guess it's time to dump the old vinum start code from
>>> vinum(8) completely, and use the in-kernel scan now.
>>
>> This sounds like a good idea.
>
> Not after looking a bit closer. ;-) The
On Sat, Feb 08, 2003 at 03:06:27PM -0800, Kris Kennaway wrote:
> On Sat, Feb 08, 2003 at 02:59:30PM -0800, Kris Kennaway wrote:
> > Can someone take a look at lib/libc/gen/semctl.c and tell me where
> > the __semctl() sysctl should be prototyped?
>
> Also _fpathconf() in lib/libc/gen/statvfs.c
/u
Thus spake Ray Kohler <[EMAIL PROTECTED]>:
> Has anyone tried building world/kernel with high optimizations (-O2,
> -O3) recently? What breaks? (Booby prize to whoever says "common sense"
> ;) I last tried it quite a few months ago and the resolver died on me,
> don't know what else. I'm not really
Hi
The LOR detected in /usr/src/sys/kern/vfs_mount.c (process lock on line
1144, and filedesc structure on line 1151) has been previously reported:
I have noticed it upon shutdown. An LOR fix was presented recently for a
similar LOR arising in kern_descrip.c , see
http://www.freebsd.org/cgi/ge
On Sat, Feb 08, 2003 at 02:59:30PM -0800, Kris Kennaway wrote:
> Can someone take a look at lib/libc/gen/semctl.c and tell me where
> the __semctl() sysctl should be prototyped?
Also _fpathconf() in lib/libc/gen/statvfs.c
Kris
msg52023/pgp0.pgp
Description: PGP signature
Can someone take a look at lib/libc/gen/semctl.c and tell me where
the __semctl() sysctl should be prototyped?
Kris
msg52022/pgp0.pgp
Description: PGP signature
>I was trying to know how "printf" works in FreeBSD... I hvae reached
>to this
>point :
>
>#define _write(fd, s, n) \
> __syscall(SYS_write, (int)(fd), (const void *)(s), (size_t)(n))
>
>I'am not really familiar with the way FreeBSD handle interrupts. I
>like from
>any one of you to tell me
On Sat, Feb 08, 2003 at 04:55:07PM -0500, Brent Verner wrote:
> [2003-02-08 16:19] Matthew Emmerton said:
> | It compiled on -CURRENT and -STABLE using this:
> |
> | #include
> |
> | You've got #include in your example below.
>
> Deleting /usr/include/g++ and making installworld, fixes my
> "
On Sat, 8 Feb 2003 16:23:21 -0600
David Leimbach <[EMAIL PROTECTED]> wrote:
Howdy.
> Isn't it ultimately interrupt 08 on the PC with an index in the EAX
> register for the write "subroutine"?
>
> I am pretty sure that's correct. I might have the interrupt value
> wrong though.
s/08/0x80/ :-)
Isn't it ultimately interrupt 08 on the PC with an index in the EAX
register for the write "subroutine"?
I am pretty sure that's correct. I might have the interrupt value
wrong though.
Dave
On Saturday, February 8, 2003, at 04:12 PM, Auge Mike wrote:
Hi all,
I was trying to know how "pri
Hi all,
I was trying to know how "printf" works in FreeBSD... I hvae reached to this
point :
#define _write(fd, s, n) \
__syscall(SYS_write, (int)(fd), (const void *)(s), (size_t)(n))
I'am not really familiar with the way FreeBSD handle interrupts. I like from
any one of you to tell me what
On Sat, Feb 08, 2003 at 04:12:26PM +0100, Thomas Moestl wrote:
> addr2line will usually point to the first line of a statement if it
> spans multiple lines; in this case, the full guard is:
>
> while (p2->p_pid == trypid ||
> p2->p_pgrp->pg_id == tr
[2003-02-08 16:19] Matthew Emmerton said:
| It compiled on -CURRENT and -STABLE using this:
|
| #include
|
| You've got #include in your example below.
Deleting /usr/include/g++ and making installworld, fixes my
"problem". The compiler now gives the expected behavior; it
compiles the code w
I have played with the statistics collection in GEOM a bit, and need
more feedback, but first: try to play with it a bit.
Assuming you're running -current as of today, otherwise install
include files and libgeom by hand first.
Apply this patch in src/sys/geom and make a new kernel.
http
Specifically, this is the exact code that compiles error/warning free on gcc
2.95.4 (4-STABLE) and gcc 3.2.1 (5.0-REL)
// begin code
#include
using namespace std;
void xxx (ostream& os);
int main(void)
{
xxx(cout);
}
void xxx (ostream& os)
{
os << '>';
os << "out\n";
}
// end code
-
It compiled on -CURRENT and -STABLE using this:
#include
You've got #include in your example below.
Matt
- Original Message -
From: "Brent Verner" <[EMAIL PROTECTED]>
To: "Matthew Emmerton" <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Saturday, February 08, 2003 4:15 PM
Subject:
[2003-02-08 15:56] Matthew Emmerton said:
| Your working example below compiles without error using gcc 2.95.x (FreeBSD
| 4.x) and gcc 3.2.x (FreeBSD 5.x), which is expected since it's compliant
| C++. (See Stroustrup's The C++ Programming Language, section 9.2.2, which
| indicates that the proper
syslog(3) botches things if you pass it a string that has "%%m" in it.
this should fix it, any comments?
Index: syslog.c
===
RCS file: /home/ncvs/src/lib/libc/gen/syslog.c,v
retrieving revision 1.28
diff -u -r1.28 syslog.c
--- syslog.
Your working example below compiles without error using gcc 2.95.x (FreeBSD
4.x) and gcc 3.2.x (FreeBSD 5.x), which is expected since it's compliant
C++. (See Stroustrup's The C++ Programming Language, section 9.2.2, which
indicates that the proper way to include C++ standard library headers such
As Greg 'groggy' Lehey wrote:
> > I guess it's time to dump the old vinum start code from
> > vinum(8) completely, and use the in-kernel scan now.
>
> This sounds like a good idea.
Not after looking a bit closer. ;-) The only difference ist that the
userland "vinum start" uses devstat, while the
On Saturday 08 February 2003 17:22, Terry Lambert wrote:
> Wes Peters wrote:
> > On Friday 07 February 2003 01:25, David Gilbert wrote:
> > > I believe that someone here recomended Tigon III based cards ... but I
> > > was recently looking through 5.0-RELEASE's hardware notes and couldn't
> > > fin
On Sat, Feb 08, 2003 at 01:23:58PM +0100, taxman wrote:
> Very detailed information for every commit can be found at:
> http://www.freebsd.org/cgi/cvsweb.cgi/
Adrian,
For your FreeBSD news article, if you want to get in contact with developers
who have added new things to FreeBSD, I recommend yo
Hmm. somewhat OT for -current and very OT for -hackers (crossposting removed).
-questions would be better
On Thursday 06 February 2003 02:17 pm, Adrian Penisoara wrote:
> I'm about to write an article on FreeBSD for PC Magazine Romania and I
> would like to concentrate on the new technologies
In trying to compile the most recent native jdk-1.4.1, I noticed
that compiling with the header didn't work.
// ** won't link **
#include
// ** works **
// #include
// ** works **
// #include
// using namespace std;
int main(){
return 1;
}
void xxx (ostream& os) {
os << ' ';
os << "
Hi,
I've got the same problem after a panic, the produced core dump was invalid.
I'm on -CURRENT and I think the reason of the core production isn't the same as
you, but the core dump problem is the same, I'm sure of it.
I'm also on a laptop (Compaq Presarion) but ACPI is enabled.
I have removed
Has anyone tried building world/kernel with high optimizations (-O2,
-O3) recently? What breaks? (Booby prize to whoever says "common sense"
;) I last tried it quite a few months ago and the resolver died on me,
don't know what else. I'm not really thinking of running like that, but
I am curious ab
On a Dell Inspiron 8200 laptop, with ACPI disabled, 5.0-REL rebooted
while the system was quiescent. gdb appears to be unable to make sense
of the produced crash dump:
# gdb -k /usr/obj/usr/src/sys/MALEVIL/kernel.debug vmcore.1
GNU gdb 5.2.1 (FreeBSD)
[...]
This GDB was configured as "i386-undermy
On Fri, 7 Feb 2003, Michael Reifenberger wrote:
...
> > As a workaround, you can try setting
> >
> > vinum_load=YES
> > vinum.autostart=YES
> >
> > in your /boot/loader.conf, /and/ remove the start_vinum line from
> > rc.conf. Please tell me whether this gives different results.
Bad things happen
Wes Peters wrote:
> On Friday 07 February 2003 01:25, David Gilbert wrote:
> > I believe that someone here recomended Tigon III based cards ... but I
> > was recently looking through 5.0-RELEASE's hardware notes and couldn't
> > find any mention of Tigon III.
>
> The follow-on to the Tigon II is t
Le 2003-02-08, CHOI Junho écrivait :
> Oh sorry... I didn't restart cron :P. It works well. 'cron -x pars'
> says that whitespaces is correctly parsed.
OK, that's reassuring! Ollivier can you review the posted patch please?
Thanks,
Thomas.
--
[EMAIL PROTECTED]
To Unsubscribe: send mail to
On Sat, Feb 08, 2003 at 16:52:28 +1100, Bruce Evans wrote:
> >
> > Obvious workaround: could DEVFS be mounted read-only initially and then
> > re-mounted as read-write after adjkerntz started, in the same manner as /
> > remounted read-write, i.e. with "mount -u" ?
>
> No. devfs silently ignores
On Sat, Feb 08, 2003 at 09:01:20 +0100, [EMAIL PROTECTED] wrote:
> >I see no solving way until kernel will understand fully and can handle
> >timezone database format. It means timezone code should be integrated
> >into kernel. And for which reason? Only to heal DEVFS timestamps? Mount
> >workaro
On Sat, 2003/02/08 at 15:15:44 +0100, Morten Rodal wrote:
> On Sat, Feb 08, 2003 at 03:05:12AM -0800, Kris Kennaway wrote:
> > bento# addr2line -e kernel.debug 0xc01a1e2d
> > ../../../kern/kern_fork.c:388
> >
> > for (; p2 != NULL; p2 = LIST_NEXT(p2, p_list)) {
> >
On Sat, Feb 08, 2003 at 03:05:12AM -0800, Kris Kennaway wrote:
> bento# addr2line -e kernel.debug 0xc01a1e2d
> ../../../kern/kern_fork.c:388
>
> for (; p2 != NULL; p2 = LIST_NEXT(p2, p_list)) {
> PROC_LOCK(p2);
> 388 --> while (p2->p_pid == t
On Sat, Feb 08, 2003 at 06:03:53AM -0800, walt wrote the words in effect of:
> Hiten Pandya wrote:
> >On Fri, Feb 07, 2003 at 07:49:54PM -0800, walt wrote the words in effect
> >of:
> >
> >>Hiten Pandya wrote:
> >>
> >>>Hi gang.
> >>>
> >>>Recently removing the NO_GEOM option from my kernel; I not
Hiten Pandya wrote:
On Fri, Feb 07, 2003 at 07:49:54PM -0800, walt wrote the words in effect of:
Hiten Pandya wrote:
Hi gang.
Recently removing the NO_GEOM option from my kernel; I noticed that my
dos extended slices dev entries disappeared under a GEOM kernel...
I've been using extended sl
On Sat, 8 Feb 2003, Kris Kennaway wrote:
> I'm having lots of problems with crashdumps under 5.0. Most of the
> time trying to force a dump via 'call doadump' returns an error about
> 'Context switches not permitted in the debugger'. Calling it again
> causes the system to hang. Is anyone else
On Sat, 2003/02/08 at 03:18:54 -0800, Kris Kennaway wrote:
> I'm having lots of problems with crashdumps under 5.0. Most of the
> time trying to force a dump via 'call doadump' returns an error about
> 'Context switches not permitted in the debugger'. Calling it again
> causes the system to hang.
On Fri, Feb 07, 2003 at 07:49:54PM -0800, walt wrote the words in effect of:
> Hiten Pandya wrote:
> >Hi gang.
> >
> >Recently removing the NO_GEOM option from my kernel; I noticed that my
> >dos extended slices dev entries disappeared under a GEOM kernel...
>
> I've been using extended slices on
--
>>> Rebuilding the temporary build tree
--
>>> stage 1: bootstrap tools
--
>>> stage 2: cleaning up the object tree
I'm having lots of problems with crashdumps under 5.0. Most of the
time trying to force a dump via 'call doadump' returns an error about
'Context switches not permitted in the debugger'. Calling it again
causes the system to hang. Is anyone else seeing this?
Kris
msg51987/pgp0.pgp
Descr
On Sat, Feb 08, 2003 at 01:24:06AM -0800, Kris Kennaway wrote:
> Fatal trap 12: page fault while in kernel mode
> cpuid = 0; lapic.id = 0100
> fault virtual address = 0x14
> fault code = supervisor read, page not present
> instruction pointer = 0x8:0xc01a1e2d
> stack pointer
On Sat, Feb 08, 2003 at 01:24:06AM -0800, Kris Kennaway wrote:
> Fatal trap 12: page fault while in kernel mode
> cpuid = 0; lapic.id = 0100
> fault virtual address = 0x14
> fault code = supervisor read, page not present
> instruction pointer = 0x8:0xc01a1e2d
> stack pointer
Fatal trap 12: page fault while in kernel mode
cpuid = 0; lapic.id = 0100
fault virtual address = 0x14
fault code = supervisor read, page not present
instruction pointer = 0x8:0xc01a1e2d
stack pointer = 0x10:0xe4146c74
frame pointer = 0x10:0xe4146cbc
code
Likely part of the performance issue was due to the Chipset of the
motherboard. Your typical 32bit 33MHz PCI bus is going to be marginal for
routing GigE traffic, just due to bus bandwidth limitations, but it'll
handle multiple 100BaseTX cards just fine. While a higher-end setup like a
Serverworks
This
message is an advertisement. We will continue to bring you valuable permission
based messages on the products and services that interest you most unless
you wish to decline. We
process all requests immediately. Copyright 2000, 2001, 2002 all rights
In message <[EMAIL PROTECTED]>, "Andrey A. Chernov" writes:
>On Sat, Feb 08, 2003 at 00:16:24 +0100, [EMAIL PROTECTED] wrote:
>>
>> Can we stop considering workarounds, and instead work on solving
>> the problem please ?
>
>I see no solving way until kernel will understand fully and can handle
>ti
61 matches
Mail list logo
