I've seen a few reports that CVSup has suddenly started dumping
core on a segmentation violation under -current, but I need more
information. For starters, I would like to know whether the static
binary (ports/net/cvsup-bin) works or not under the very latest
-current on the i386. Could
On Tue, Oct 05, 1999 at 08:33:54AM +0200, Mark Murray [EMAIL PROTECTED] wrote:
I've seen a few reports that CVSup has suddenly started dumping
core on a segmentation violation under -current, but I need more
information. For starters, I would like to know whether the static
binary
On Tue, Oct 05, 1999 at 06:21:55AM +0800, Michael Kennett wrote:
Is this a known problem?
Yes, and it is well documented in the -current mailing lists.
I feel embarrassed as I'v just spoken to Marcel a couple fo days ago.
However I just resubscribed to -current. I did look in the
On Mon, Oct 04, 1999 at 11:12:10PM -0400, Matthew N. Dodd wrote:
On Mon, 4 Oct 1999, Timo Geusch wrote:
If you're interested I can send you the source code for the driver but it is
not clear if it works on -current at the moment as I haven't updated for
some time.
Send it here as I'm
Bruce Evans wrote:
3: *always* build (or try to) and install a new kernel before a
make world as that's a lot easier to back out of.
This badly bites the bum of anyone who uses KLD's regularly.
4: Don't use modules in -current unless you know what you are doing.
This normally
Just an anti-me too.
Static cvsup works perfectly for me (installed from ports cvsup-bin on
Sept 9th).
I run it both on my dumb terminal and on my X display.
(My X configuration is XFree86 3.3.5, Gnome/Enlightenment [all built
Sept 9th after a make world]).
My shell is tcsh 6.09 (built Sept
python-1.5.2 is broken with current this week when compiled with the
"--with-fpectl" option (a hack using jmpbuf.h, signal.h etc.) which is
default in the ports collection. Exponentiation fails i. e.
Python 1.5.2 [GCC egcs-2.91.66 19990314 (egcs-1.1.2 on freebsd4
Copyright 1991-1995
3: *always* build (or try to) and install a new kernel before a
make world as that's a lot easier to back out of.
This badly bites the bum of anyone who uses KLD's regularly.
4: Don't use modules in -current unless you know what you are doing.
This normally means not
Hi,
I'm trying to upgrade my system from 3.2-RELEASE to 4.0-CURRENT, i
CVsuped the source, but when I try to build it, (with cd /usr/src, make -j4
buildworld, but also with just make buildworld), it blows up on libgcc1.c
(the one everybody's been complaining about.) Greg Lehey told me to
Poul-Henning Kamp wrote:
You need to move your sources further forward.
Alas, it didn't help. What versions of what files I should have? The
warnings are still appearing, at fsck time.
In message [EMAIL PROTECTED], "Daniel C. Sobral" writes:
A kernel from this weekend's sources is
Fwiw, the problem seems to have disappeared over here. I'll check at home
later.
FreeBSD hal.mpn.cp.philips.com 4.0-CURRENT FreeBSD 4.0-CURRENT #0: Tue Oct 5
09:36:29 CEST 1999 [EMAIL PROTECTED]:/usr/src/sys/compile/HAL
i386
Cheers,
--
Jos Backus _/ _/_/_/
John Polstra [EMAIL PROTECTED] writes:
I've seen a few reports that CVSup has suddenly started dumping
core on a segmentation violation under -current, but I need more
information. For starters, I would like to know whether the static
binary (ports/net/cvsup-bin) works or not under the very
Hi,
It seems that the trampoline code got too long and resulted in the
coredumps people reported. The following patch solves that. it basicly
works as follows:
o Simplify the trampoline code so that it doesn't have to distinguish
between an old- and new sigframe and also restoring
On Mon, 4 Oct 1999, John Polstra wrote:
I've seen a few reports that CVSup has suddenly started dumping
core on a segmentation violation under -current, but I need more
information. For starters, I would like to know whether the static
binary (ports/net/cvsup-bin) works or not under the
Hi,
I'm trying to upgrade my system from 3.2-RELEASE to 4.0-CURRENT, i
CVsuped the source, but when I try to build it, (with cd /usr/src, make -j4
buildworld, but also with just make buildworld), it blows up on libgcc1.c
(the one everybody's been complaining about.) Greg Lehey told me to
On Tue, 05 Oct 1999 09:39:05 -0400, "Bill A. K." wrote:
I'm trying to upgrade my system from 3.2-RELEASE to 4.0-CURRENT
You're venturing into some virgin territory, but some old advice in the
FreeBSD Handbook still applies -- if you intend to run CURRENT,
subscribe to the freebsd-current
Wow, you guys have been busy while I was asleep! Thanks for the
reports, and for the diagnosis already done by Marcel, Luoqi, and
others.
If you are stuck with a kernel that can't run CVSup, I believe you can
work around the problem by adding "@M3novm" to the cvsup command line.
Add it anywhere
Luoqi Chen wrote:
o restoring %gs is now handled in the proper sigreturn.
Restoration of %gs should not be in the kernel because it comes from
user application and maybe invalid, if you restore it inside the kernel
it could be fatal to the whole system, and on the other hand just
Luoqi Chen wrote:
o restoring %gs is now handled in the proper sigreturn.
Restoration of %gs should not be in the kernel because it comes from
user application and maybe invalid, if you restore it inside the kernel
it could be fatal to the whole system, and on the other hand just a core
I have soft updates enabled on a fast machine at work. make
installworld can fill up slash even though it has 15M free before the
install. I think this is a bug in softupdates that it doesn't reclaim
space quickly enough or in overflow situations.
To work around it, I've used
make
According to Warner Losh:
install. I think this is a bug in softupdates that it doesn't reclaim
space quickly enough or in overflow situations.
Yes, it is a known issue Kirk know of AFAIK. It should probably reclaim the
soon-to-be-freed blocks when it needs them. I've removed softupdates on /
In message [EMAIL PROTECTED] Marcel Moolenaar writes:
: Yes, but if you need the tools you just compiled in your
: cross-compilation for cross-compilation itself, you'll have a big
: problem. And that's almost exacly what happens when building world...
No. The cross build world takes care to
In message [EMAIL PROTECTED] John-Mark Gurney writes:
: I thought we were working to the point that we could build a mips world
: on an x86 box?? w/ this, it completely breaks it... the whole idea of
: a buildworld is that the tools can be build on ANY platform and run,
: (assuming the tools
I have soft updates enabled on a fast machine at work. make
installworld can fill up slash even though it has 15M free before the
install. I think this is a bug in softupdates that it doesn't reclaim
space quickly enough or in overflow situations.
It's really not a bug, it's just
On Tue, 5 Oct 1999, Timo Geusch wrote:
I'll send it once I verified that it (still) works with -current. The
work dates from before newpnp, Also, some indication as to where you
made changes would benice - my PnP changes are pretty self-contained
but I made some more general changes that
On 1999-Oct-06 07:42:39 +1000, Warner Losh wrote:
Nearly full? It is a 32M file system with 15M free. That's not
nearly full. The problem is that the update rate is faster than the
softupdate code can deal with. Running sync between each install
shows that this is a bug.
As Ollivier Robert
In message 01bf0f86$d8d84670$[EMAIL PROTECTED] "David Schwartz" writes:
: I think anybody reasonable familiar with softupdates understands what
: 'sync' does in this context. It's not a bug because it is documented
: behavior done for a specific reason.
It is a bug. You've just said
In message 000101bf0f78$fbe58b40$[EMAIL PROTECTED] "David
Schwartz" writes:
: It's really not a bug, it's just a missing feature. There's
no requirement
: that a filesystem reclaim empty space immediately. You really
shouldn't be
: using fastupdates on nearly full filesystems -- it
In any case, you should not be doing lots of writes to root, so the
lack of softupdates should not be a problem.
So, are you suggesting make /tmp it's own disk, otherwise anytime you do
development alot of writes are done to /.
And, if you do lots of development, then you'll have the same
On Tue, 5 Oct 1999, David Schwartz wrote:
I have soft updates enabled on a fast machine at work. make
installworld can fill up slash even though it has 15M free before the
install. I think this is a bug in softupdates that it doesn't reclaim
space quickly enough or in overflow
On 1999-Oct-06 09:02:12 +1000, Nate Williams wrote:
In any case, you should not be doing lots of writes to root, so the
lack of softupdates should not be a problem.
So, are you suggesting make /tmp it's own disk, otherwise anytime you do
development alot of writes are done to /.
I've pretty
On 1999-Oct-06 09:55:26 +1000, Alfred Perlstein wrote:
I've seen softupdates nearly eliminate disk io for systems that used
an abmornal amount of temp files, but the fact that it can destabilize
a system worries me greatly.
What do you mean by `destabilize'? There are bugs in softupdates
which
On Wed, 6 Oct 1999, Peter Jeremy wrote:
On 1999-Oct-06 09:55:26 +1000, Alfred Perlstein wrote:
I've seen softupdates nearly eliminate disk io for systems that used
an abmornal amount of temp files, but the fact that it can destabilize
a system worries me greatly.
What do you mean by
W`hile installworld is being discussed, I wanted to get this out there:
Since rev 1.13 of usr.bin/make/arch.c, I've been seing a problem with
ELF archive libraries being rebuilt unnecessarily. I believe that
this problem can be traced to the RANLIBMAG string being set to "/".
The reason I care
Nate Williams [EMAIL PROTECTED] writes:
In any case, you should not be doing lots of writes to root, so the
lack of softupdates should not be a problem.
So, are you suggesting make /tmp it's own disk, otherwise anytime you do
development alot of writes are done to /.
And, if you do
On 1999-Oct-06 11:33:51 +1000, Alfred Perlstein wrote:
On Wed, 6 Oct 1999, Peter Jeremy wrote:
On 1999-Oct-06 09:55:26 +1000, Alfred Perlstein wrote:
I've seen softupdates nearly eliminate disk io for systems that used
an abmornal amount of temp files, but the fact that it can destabilize
a
Anyone could give me some hints about how to set up my ftp service
correctly ? thanks alot,
This looks like a recently introduced bogon. I'm seeing it too.
Hmmm. PAM Stuff. Have you fully updated (mergemaster) your etc
area?
M
--
Mark Murray
Join the anti-SPAM movement:
[.]
Please read more of the thread before replying, the fact of
[.]
Now if everyone used mailers that actually wrote correct in-reply-to
lines, this might be a realistic thing to suggest !
--
Brian [EMAIL PROTECTED][EMAIL PROTECTED]
In any case, you should not be doing lots of writes to root, so the
lack of softupdates should not be a problem.
So, are you suggesting make /tmp it's own disk, otherwise anytime you do
development alot of writes are done to /.
And, if you do lots of development, then you'll have the
On 1999-Oct-06 09:55:26 +1000, Alfred Perlstein wrote:
I've seen softupdates nearly eliminate disk io for systems that used
an abmornal amount of temp files, but the fact that it can destabilize
a system worries me greatly.
What do you mean by `destabilize'? There are bugs in softupdates
Hi,
On Mon, 4 Oct 1999, Adrian Penisoara wrote:
I have a -stable production server that keeps (solidly) blocking pretty
often (I don't get over 3 days uptimes). If you need details just let me
know.
Just to let you know: syncing every second in a loop like this:
while true
do
: The problem is that the machine is completely locked, I can't get into
:the debugger with CTR-ALT-ESC; no panics so there are no coredumps
:catched. Any advise ? Could you escape in the debugger when you were hit
:by these bugs ?
If it's completely locked up and ctl-alt-esc doesn't work
Hi,
On Mon, 4 Oct 1999, Matthew Dillon wrote:
: Excuse my intrusion, but could you be so kind to tell me whether you had
:the time to build patches for these MMAP-related freezes ? If not could
:you recommend me some workarounds ?
:
: I have a -stable production server that keeps (solidly)
43 matches
Mail list logo
