Hi,
With a CURRENT build/installworld from yesterday ... i get a VERY unstable
system that page faults under the slightest CPU load (e.g. playing MP3's)
i fortunately have a (very outdated) backup-kernel that will hopefully at
least let me do new buildworld's ...
I have to be off for work right
I wonder status of KSE, I am dreaming rewrite our application
server using kqueue+pthread(KSE), current, we use poll()+pthread
because pthread does not work with kqueue at present.
--
Best regards,
David Xu
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current"
On Wed, 14 Mar 2001, Garrett Wollman wrote:
> > You need options LIBMCHAIN as well. We don't have mechanism for
> > specifying dependancies between options as of yet. (sorry, should put a
> > note in the NOTES).
>
> Actually, yes we do, although it's not often used. If the relevant
> source
Peter Wemm wrote:
> Richard Todd wrote:
> > In message <[EMAIL PROTECTED]>, Peter Wemm write
s:
> > >Richard Todd wrote:
> > >
> > >> < No crashes as of here
> > >> pushl $begin /* jump to high virtualized add
> > >ress */
> > >> ret
> > >>
> > >> /* no
:
:On Wed, Mar 14, 2001 at 04:39:53PM -0800, Matt Dillon wrote:
:
:> fsck all of your filesystems from single-user to remove the possibility
:> of 'old' corruption (as in 'fsck', not 'fsck -p').
:
:So if an fsck -f doesn't bomb out, the filesystem should be in an okay
:state?
:
:- alex
On Wed, Mar 14, 2001 at 04:39:53PM -0800, Matt Dillon wrote:
> fsck all of your filesystems from single-user to remove the possibility
> of 'old' corruption (as in 'fsck', not 'fsck -p').
So if an fsck -f doesn't bomb out, the filesystem should be in an okay
state?
- alex
To Unsubscri
Richard Todd wrote:
> In message <[EMAIL PROTECTED]>, Peter Wemm writes:
> >Richard Todd wrote:
> >
> >> < No crashes as of here
> >>pushl $begin /* jump to high virtualized add
> >ress */
> >>ret
> >>
> >> /* now running relocated at KERNBASE where t
:I was cvsupping the GNATS database (the *entire* GNATS database, that
:is - I didn't already have a copy) when I got this panic:
How old a kernel are you running?
Kirk and I have been attempting to locate the filesystem bitmap
corruption for months. We've fixed a number of bugs but
On Wed, Mar 14, 2001 at 08:43:11PM -, Jason R. Mastaler wrote:
> I've noticed that lots of the perl ports are now broken since the move
> to perl 5.6.0. Some examples:
>
> http://bento.freebsd.org/errorlogs/5-full/p5-Crypt-IDEA-1.01.log
> http://bento.freebsd.org/errorlogs/5-full/p5-Devel-Pe
On Mar 14, 11:24pm, [EMAIL PROTECTED] ("Andrey A. Chernov") wrote:
-- Subject: Re: tcsh 6.10.00 echo;echo;echo; bug with fix
With the new information about solaris having fixed this, I've decided
against keeping compatibility and just applying the fix you proposed.
christos
| On Wed, Mar 14, 20
* Jason R. Mastaler <[EMAIL PROTECTED]> [010314 12:43] wrote:
> I've noticed that lots of the perl ports are now broken since the move
> to perl 5.6.0. Some examples:
>
> http://bento.freebsd.org/errorlogs/5-full/p5-Crypt-IDEA-1.01.log
> http://bento.freebsd.org/errorlogs/5-full/p5-Devel-Peek-0.
I've noticed that lots of the perl ports are now broken since the move
to perl 5.6.0. Some examples:
http://bento.freebsd.org/errorlogs/5-full/p5-Crypt-IDEA-1.01.log
http://bento.freebsd.org/errorlogs/5-full/p5-Devel-Peek-0.96.log
With these two in particular, the problem can be fixed by compil
On Wed, Mar 14, 2001 at 09:54:32 -0500, Christos Zoulas wrote:
> Yeah, that is a good idea. I think that I'll add an echo_style "bsdbug",
> and leave the default alone.
Even if we left old default in place (which I personally not like), old
code have signal handler bug, we can't just "return" fr
On Wed, Mar 14, 2001 at 18:41:37 +0100, Daniel Rock wrote:
> David Malone schrieb:
> >
> > > echo is more like as external command, even in its internal form it
> > > tends to be compatible even with SysV-isms. What non-BSD grown (i.e. SysV)
> > > csh echo prints?
> >
> > Solaris, AIX and HPUX a
David Malone schrieb:
>
> > echo is more like as external command, even in its internal form it
> > tends to be compatible even with SysV-isms. What non-BSD grown (i.e. SysV)
> > csh echo prints?
>
> Solaris, AIX and HPUX all print nothing. I guess all csh versions
> are likely to be BSD dervied
< said:
> You need options LIBMCHAIN as well. We don't have mechanism for
> specifying dependancies between options as of yet. (sorry, should put a
> note in the NOTES).
Actually, yes we do, although it's not often used. If the relevant
sources are listed twice in `files', conditional on
I agree with Andrey -- although this has the possibility of breaking
old scripts that expect no output from echoing an empty variable.
Since the DEC/OSF system update script only works with their ancient
/bin/sh (and not with the XPG4 sh) I wouldn't be surprised to find
such scripts out there...
On Mar 14, 2:41pm, [EMAIL PROTECTED] (David Malone) wrote:
-- Subject: Re: tcsh 6.10.00 echo;echo;echo; bug with fix
| > echo is more like as external command, even in its internal form it
| > tends to be compatible even with SysV-isms. What non-BSD grown (i.e. SysV)
| > csh echo prints?
|
| So
> echo is more like as external command, even in its internal form it
> tends to be compatible even with SysV-isms. What non-BSD grown (i.e. SysV)
> csh echo prints?
Solaris, AIX and HPUX all print nothing. I guess all csh versions
are likely to be BSD dervied, so there is likely to be a consista
On Wed, Mar 14, 2001 at 14:10:06 +, David Malone wrote:
> Will it change what happens if you do:
>
> set null=""
> echo $null
>
> (this produces nothing in "traditional" tcsh and csh)?
It will change.
> I guess we should leave it up to the tcsh folks. There are other
> internal
> Since internal 'echo' does nothing, it _not_ used in any old csh scripts,
> while 'echo ""' does the same thing in both old and new variants, so old
> scripts will works in the same way.
Will it change what happens if you do:
set null=""
echo $null
(this produces nothing in "t
On Wed, Mar 14, 2001 at 15:46:39 +0300, Andrey A. Chernov wrote:
> On Wed, Mar 14, 2001 at 12:41:09 +, David Malone wrote:
> > On Tue, Mar 13, 2001 at 07:52:49AM -0500, Christos Zoulas wrote:
> >
> > > Thanks so much! I wonder how come this bug remained unnoticed for such
> > > a long time!
>
On Wed, Mar 14, 2001 at 12:41:09 +, David Malone wrote:
> On Tue, Mar 13, 2001 at 07:52:49AM -0500, Christos Zoulas wrote:
>
> > Thanks so much! I wonder how come this bug remained unnoticed for such
> > a long time!
>
> AFAIK, this isn't a bug. It's what csh has always done. (It's what
> IB
On Tue, Mar 13, 2001 at 07:52:49AM -0500, Christos Zoulas wrote:
> Thanks so much! I wonder how come this bug remained unnoticed for such
> a long time!
AFAIK, this isn't a bug. It's what csh has always done. (It's what
IBM and Sun's csh do anyway...) To echo a newline in csh you do
'echo ""'.
At Tue, 13 Mar 2001 16:53:46 +0100, Martin Blapp wrote:
>
> Hi,
>
> > I have made something like this and submitted a PR
> > http://www.freebsd.org/cgi/query-pr.cgi?pr=25771
>
> Yep, something like this I'd like to do, but with md5 checksums,
> so we do not have to say 'yes' to each file we upd
On Mon, 12 Mar 2001 18:46:16 -0500
James FitzGibbon <[EMAIL PROTECTED]> wrote:
> Both of the patches below fix the problem mentioned in PR bin/25110. The
> first one fixes it inside of kern_fork.c and would appear to apply the
> corrective behaviour regardless of whether the process uses libc_r
Dmitry Valdov wrote:
>
> Hi!
>
> Try to make an .rhosts file and rlogin to fresh RELENG_4 or -CURRENT branch.
> > rlogin -l dv xxx.xxx.xxx.xxx
>
I saw the rlogin problem but somehow fixed it later
my pam.conf was OK so I uncommented the ipv6 versions of
the services in /etc/inetd.conf and
Brian Somers wrote:
> 3. Have a cvs-aware option.
>
> If the installed and new version numbers differ, mergemaster does a
> cvs diff -u -rINSTALLEDVERSION newversion | patch INSTALLEDFILE. If
> this works, everyone's happy. If not, it forces you to modify the
> new file 'till there are no
Alex Zepeda wrote:
>
> I haven't been able to track this down since the kernel won't panic.. but
> with more recent kernels I've noticed:
>
> * options NCP prevents the kernel from linking
> * midi panics the system right after bootup
>
Saw the NCP problem today at ctm-cvs-cur 7214.
Saw the mi
On Wed, 14 Mar 2001, Alex Zepeda wrote:
> I haven't been able to track this down since the kernel won't panic.. but
> with more recent kernels I've noticed:
>
> * options NCP prevents the kernel from linking
You need options LIBMCHAIN as well. We don't have mechanism for
specifying dep
> Yes, I mean when we extract and install all /etc files, is it possible
> to add then then md5 checksum to all installed config files into the
> cvs header ? (With grep -v "$FreeBSD:" of course).
Oh. No, not easily.
- Jordan
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe fre
Hi Jordan,
> > If it is possible to add these checksums also in sysinstall when
> > extracting the first time you install, nothing has to be done
> > with commit scripts and also the first time you run mergemaster,
> > you can run it a lot more faster than now.
>
> Can you be more specific? Som
From: Martin Blapp <[EMAIL PROTECTED]>
Subject: Re: Proposal to mergemaster
Date: Wed, 14 Mar 2001 09:51:28 +0100 (CET)
> If it is possible to add these checksums also in sysinstall when
> extracting the first time you install, nothing has to be done
> with commit scripts and also the first time
On Wed, Mar 14, 2001 at 12:49:01AM -0800, Alex Zepeda wrote:
> The kernel that seems to work was built on Feb 18th, and the ones that
> aren't are from as recently as March 13th.
D'oh. Forgot the kernel config file and dmesg output.
The config file hasn't changed, but the dmesg output is (obvi
On Wed, 14 Mar 2001 00:49:53 -0800,
Alex Zepeda <[EMAIL PROTECTED]> said:
Alex> On Mon, Mar 12, 2001 at 04:38:50PM +0100, Szilveszter Adam wrote:
>> I wonder if this is known? If not, I can certainly provide more
>> information. The offending sound hw is a Creative SB 64 AWE ISAPnP card. It
>>
Hmm, just some thoughts here:
I modified mergemaster so he add's to every file he touches or
installs this md5 checksum. When mergemaster reads a file and
compares it, it extracts the md5 checksum form the file (if it
exists) and looks if the file has been changed or not. If a new
file get's ins
I haven't been able to track this down since the kernel won't panic.. but
with more recent kernels I've noticed:
* options NCP prevents the kernel from linking
* midi panics the system right after bootup
But the biggest problem seems to be the spontaneous rebooting. At first I
thought it might
On Mon, Mar 12, 2001 at 04:38:50PM +0100, Szilveszter Adam wrote:
> I wonder if this is known? If not, I can certainly provide more
> information. The offending sound hw is a Creative SB 64 AWE ISAPnP card. It
> works fine otherwise. (as it always has)
Yup I'm seeing this too. SMP kernel, AWE64
38 matches
Mail list logo
