Re: CVSup core dumps
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 somebody please check that and report back to the list? I can't sacrifice my i386 -current machine to the cause right now. The static binary seems to be OK an a 3-day-old CURRENT. M -- Mark Murray Join the anti-SPAM movement: http://www.cauce.org To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: CVSup core dumps
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 (ports/net/cvsup-bin) works or not under the very latest -current on the i386. Could somebody please check that and report back to the list? I can't sacrifice my i386 -current machine to the cause right now. The static binary seems to be OK an a 3-day-old CURRENT. And as opposite, the cvsup 16.0 static a.out binary, downloaded a day ago from ftp.freebsd.org dumps reliably core for me. I'm sorry, can't provide any info yet because it's my home machine. The machine runs also 3 day old -current, perhaps with deviation of some 12 hours or so, can't remember. -- Vallo Kallaste [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: make buildworld broken?
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 UPDATING file and saw the sigset_t change but overlooked the 'build and boot a new kernel' part :-( -Guido To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Recent kernel hangs during boot with pnp sio.
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 working on if_ep in some fashion. 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 might cause problems. Anyway I'll get back to you end of next week (earliest I can manage). Someone find me a verified PnP 3c509 too. I'll pay shipping and $10 for one. I've got a normal 3c509 and a 3c579 in transit and a 3c529 in use. I'd be interested in a 3c589 for testing purposes but at this point it would be of little use has I've not yet put my hands on a ISA to PCMCIA reader. Afaik all 3C509B's are PnP. At least here in the UK there is not shortage of those cards. Timo To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: my make world is broken !
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 means not using modules in -current except for ones that you are developing. This is not actually relevant. If the procedure becomes first kernel then world, it will affect -stable sooner or later. Obviously, we have to deal with it _before_ 4.x becomes -stable. -- Daniel C. Sobral(8-DCS) [EMAIL PROTECTED] [EMAIL PROTECTED] Rule 69: Do unto other's code as you'd have it done unto yours To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Not for me. (was: CVSup core dumps)
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 1st).
I have never had cvsup-bin core dump.
I have built the world twice since the signal changes and am currently
running on my build which completed about 36 hours ago.
localhost# {8} cvsup -v
CVSup client, GUI version
Software version: REL_16_0
Protocol version: 16.0
http://www.polstra.com/projects/freeware/CVSup/
Report problems to [EMAIL PROTECTED]
localhost# {9}
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 very latest
-current on the i386. Could somebody please check that and report
back to the list? I can't sacrifice my i386 -current machine to the
cause right now.
Also, for those of you who are experiencing problems: Please state
as precisely as possible:
- which vintage of -current are you running?
- what is the output from "cvsup -v"?
- is "cvsup" a static binary or is it dynamically linked?
- did you build it, or did you simply install a binary?
- if you built it, when did you build it?
Note, you are going to have trouble getting much out of the core dumps
from the binaries, because they're a.out. I've placed an unstripped
ELF binary here if you'd like to help out by getting a stack trace:
http://www.freebsd.org/~jdp/cvsup-16.0.gz
The compressed file is about 2.3 MB in size.
John
--
/===\
| Work: [EMAIL PROTECTED] | Home: [EMAIL PROTECTED] |
\===/
"If it is true that our Universe has a zero net value for all conserved
quantities, then it may simply be a fluctuation of the vacuum of some
larger space in which our Universe is imbedded. In answer to the
question of why it happened, I offer the modest proposal that our
Universe is simply one of those things which happen from time to time."
E. P. Tryon from "Nature" Vol.246 Dec.14, 1973
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
python-1.5.2 port broken with current
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 Stichting Mathematisch Centrum, Amsterdam 3**1.5 Traceback (innermost last): File "stdin", line 1, in ? OverflowError: (14, 'Bad address') (without --with-fpectl): make test output: 52 tests OK. 1 test failed: test_fcntl 8 tests skipped: test_al ... test_sunaudiodev Last week the fcntl-tests failed the first time but this does no harm to i.e. the "sketch" program. -- Fritz Heinrichmeyer mailto:[EMAIL PROTECTED] FernUniversitaet Hagen, LG ES, 58084 Hagen (Germany) tel:+49 2331/987-1166 fax:987-355 http://ES-i2.fernuni-hagen.de/~jfh To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: my make world is broken !
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 using modules in -current except for ones that you are developing. This is not actually relevant. If the procedure becomes first kernel then world, it will affect -stable sooner or later. Obviously, we have to deal with it _before_ 4.x becomes -stable. And then there is the stuff in /boot. Although not as big a problem, once in a while it grows a new capabilty which is needed to boot a new kernel, so it probably have to be installed before booting with a new kernel? John -- John Hay -- [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
4.0-CURRENT from 3.2-RELEASE
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 build the kernel first, but the 3.2 config won't correctly run the 4.0 kernel config file. Any suggestions? What do you think of the problem Greg? I really want to get this up. Thanks Bill [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: maxphys = 0??
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 showing this warning message at boot: WARNING: #ad/0x30005 maxphys = 0 ??WARNING: #ad/0x30004 maxphys = 0 ?? These are: brw-r- 1 root operator 30, 0x00030004 Apr 6 11:48 ad0s2e brw-r- 1 root operator 30, 0x00030005 Apr 6 11:48 ad0s2f -- Daniel C. Sobral(8-DCS) [EMAIL PROTECTED] [EMAIL PROTECTED] "I always feel generous when I'm in the inner circle of a conspiracy to subvert the world order and, with a small group of allies, just defeated an alien invasion. Maybe I should value myself a little more?" To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: CVSup core dumps
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 _/ _/_/_/ "Reliability means never _/ _/ _/ having to say you're sorry." _/ _/_/_/ -- D. J. Bernstein _/ _/ _/_/ [EMAIL PROTECTED] _/_/ _/_/_/ use Std::Disclaimer; To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: CVSup core dumps
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 latest -current on the i386. Could somebody please check that and report back to the list? I can't sacrifice my i386 -current machine to the cause right now. I don't have access to the machine right now, but I installed the cvsup-bin (both GUI and non-GUI versions) and both core dumped for me. Both versions were obtained from ftp://ftp.freebsd.org/pub/FreeBSD/development/CVSup/binaries This is on the latest -current (as of 9PM Oct 4, 99). Running it under truss helps with the core dump, but runs out of swap space very quickly. Truss keeps complaining about free()'ing a pointer that does not point to allocated memory. If you want more details, I shall be happy to provide them this evening. Hope this helps, Regards, Rajappa -- [EMAIL PROTECTED] a.k.a. Rajappa Iyer.New York, New York. We're too busy mopping the floor to turn off the faucet. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: CVSup segfaults identified/solved [PATCH]
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 %gs in both cases. o Which sigreturn to use is now determined by the process flag that is used to determine which sendsig is to be used (symmetry) o restoring %gs is now handled in the proper sigreturn. I'll commit this if noone objects. -- Marcel Moolenaarmailto:[EMAIL PROTECTED] SCC Internetworking Databases http://www.scc.nl/ The FreeBSD projectmailto:[EMAIL PROTECTED] 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 dump if done in the trampoline code which is still in user mode. -lq To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: CVSup core dumps
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 very latest -current on the i386. Could somebody please check that and report back to the list? I can't sacrifice my i386 -current machine to the cause right now. It works here with world/kernel built this morning from sources cvsup'd at 0100 EDT from cvsup6.freebsd.org. - what is the output from "cvsup -v"? earth:~# cvsup -v CVSup client, GUI version Software version: REL_16_0 Protocol version: 16.0 http://www.polstra.com/projects/freeware/CVSup/ Report problems to [EMAIL PROTECTED] earth:~# - is "cvsup" a static binary or is it dynamically linked? earth:~# file /usr/local/bin/cvsup /usr/local/bin/cvsup: FreeBSD/i386 compact demand paged executable earth:~# ldd /usr/local/bin/cvsup ldd: /usr/local/bin/cvsup: not a dynamic executable (same on all versions) - did you build it, or did you simply install a binary? no problems with the one retreived using /usr/ports/net/cvsup-bin: earth:/usr/ports/distfiles# md5 cvsup-freebsd-ix86-aout-16.0.tar.gz MD5 (cvsup-freebsd-ix86-aout-16.0.tar.gz) = 57c25981d3c1d82a79b9ae18aaea715b earth:/usr/ports/distfiles# nor from one pkg_add 'ed from ftp://ftp.freebsd.org/pub/FreeBSD/packages/All/cvsup-bin-16.0.tgz : earth:~# md5 cvsup-bin-16.0.tgz MD5 (cvsup-bin-16.0.tgz) = 3e60e196c8ed9f7dac3f145bd72ac536 earth:~# Note, you are going to have trouble getting much out of the core dumps from the binaries, because they're a.out. I've placed an unstripped ELF binary here if you'd like to help out by getting a stack trace: http://www.freebsd.org/~jdp/cvsup-16.0.gz This one works without fault also. - Chris D. Faulhaber [EMAIL PROTECTED] | All the true gurus I've met never System/Network Administrator, | claimed they were one and always Reality Check Information, Inc. | pointed to someone better. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
4.0-CURRENT from 3.2-RELEASE
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 build the kernel first, but the 3.2 config won't correctly run the 4.0 kernel config file. Any suggestions? What do you think of the problem Greg? I really want to get this up. Thanks Bill [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: 4.0-CURRENT from 3.2-RELEASE
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 mailing list a little while _before_ you intend to migrate. Recent discusssions on the freebsd-current mailing list would answer this question: Greg Lehey told me to build the kernel first, but the 3.2 config won't correctly run the 4.0 kernel config file. And the answer is... ;-) You'll need to build and install config(8) first. You might get away with this: cd /usr/src/usr.sbin/config make cleandir make obj make install Ciao, Sheldon. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
CVSup core dumps: a work-around
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 on the command line -- its position doesn't matter. Also, I recommend that you _not_ try to rebuild CVSup and/or Modula-3 from the sources at this time. I suspect Modula-3 is broken because of the changed size of the jmp_buf type in -current. (The M3 runtime thinks it knows how big a jmp_buf is.) This shouldn't affect old binaries, but it will bite you if you try to rebuild from the sources. I'll commit a patch as soon as I can, but I am on some other deadlines and it might take me a day or two. John -- John Polstra [EMAIL PROTECTED] John D. Polstra Co., Inc.Seattle, Washington USA "No matter how cynical I get, I just can't keep up."-- Nora Ephron To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: CVSup segfaults identified/solved [PATCH]
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 dump if done in the trampoline code which is still in user mode. Hmmm... What if the application passes a (possibly handcrafted) sigcontext to an explicit call to sigreturn. %gs should be restored in that case too, right? Isn't it therefore better to have %gs in the trapframe? -- Marcel Moolenaarmailto:[EMAIL PROTECTED] SCC Internetworking Databases http://www.scc.nl/ The FreeBSD projectmailto:[EMAIL PROTECTED] The only place sigreturn is called explicitly is to enter VM86 mode, and in that case, %gs is restored inside kernel as part of vm86 trapframe. In fact, you may choose to restore %gs in the kernel, but you have to be prepared to take a fault on the load_gs operation and to recover from the fault properly. The reason why %gs is not in the trapframe is that trapframe is used at all entrances to the kernel (syscall/trap/intr), if %gs is included, then we need to save and restore %gs for each syscall/trap/intr, that's about 40 clock cycles wasted each time. -lq To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: CVSup segfaults identified/solved [PATCH]
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 dump if done in the trampoline code which is still in user mode. Hmmm... What if the application passes a (possibly handcrafted) sigcontext to an explicit call to sigreturn. %gs should be restored in that case too, right? Isn't it therefore better to have %gs in the trapframe? -- Marcel Moolenaarmailto:[EMAIL PROTECTED] SCC Internetworking Databases http://www.scc.nl/ The FreeBSD projectmailto:[EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
make install trick
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 INSTALL="/bin/sync install" or make INSTALL="/bin/sync install -C" Of course it takes longer this way, but it has worked 4 times in a row where the last 20 make installworlds failed. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: make install trick
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 / for the moment, it is not that written to on my machines anyway. -- Ollivier ROBERT -=- FreeBSD: The Power to Serve! -=- [EMAIL PROTECTED] FreeBSD keltia.freenix.fr 4.0-CURRENT #74: Thu Sep 9 00:20:51 CEST 1999 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADS UP: sigset_t changes committed
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 build host runable binaries. It doesn't take sufficient care because your change highlights places where it doesn't. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADS UP: sigset_t changes committed
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 support it) and then be able to build the target... No. It won't built completely, but only through the first kernel files that are needed (at least in the checked in tree). I had things further, but lost them in a disk crash. I've not had the time to revisit it since then. I defintely will have to try this again after these changes. If it can't be made to work, this is a huge deal... However, the current build tree isn't careful enough to distinguish between host run programs and target programs, which is why we're having this problem. I suspect that making this work will make cross building easier (and vice versa). Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
RE: make install trick
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 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 doesn't handle that situation particularly well. Once could even argue that it's preferable to force the make to abort than thrash the filesystem. Though a switch to allow it to thrash might be helpful in degenerate cases such as this. Fastupdates is great for the most common case -- a typical /usr or /home partition. That's where you care about write performance anyway. DS To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Recent kernel hangs during boot with pnp sio.
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 might cause problems. Anyway I'll get back to you end of next week (earliest I can manage). Just send me the code and I'll sort it out. This would be easiest for you. If I wanted easy it wouldn't be touching if_ep. Afaik all 3C509B's are PnP. At least here in the UK there is not shortage of those cards. If I can get a difinitive statement to this effect then I'll grab a 3c509B. There was some question as to them actually being PnP though. -- | Matthew N. Dodd | '78 Datsun 280Z | '75 Volvo 164E | FreeBSD/NetBSD | | [EMAIL PROTECTED] | 2 x '84 Volvo 245DL| ix86,sparc,pmax | | http://www.jurai.net/~winter | This Space For Rent | ISO8802.5 4ever | To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: make install trick
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 pointed out, it is a known problem. Kirk says it's non-trivial to fix (though I'm sure he'll welcome your patches :-). The suggested work-around is not to run softupdates on root. In any case, you should not be doing lots of writes to root, so the lack of softupdates should not be a problem. Peter -- Peter Jeremy (VK2PJ)[EMAIL PROTECTED] Alcatel Australia Limited 41 Mandible St Phone: +61 2 9690 5019 ALEXANDRIA NSW 2015 Fax: +61 2 9690 5982 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: make install trick
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 so. It isn't a bug that can be fixed trivially, yet it is still a bug. now that I know what's going on, I know why my kludg-eo-round works. Something that doesn't deal with reclaiming unused space is broken for that case, no matter how hard it is to fix. I also know how to work around it... Geeze, it isn't like I'm demanding you fix the bug. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
RE: make install trick
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 doesn't handle that : situation particularly well. Nearly full? It is a 32M file system with 15M free. That's not nearly full. Whether that qualifies as 'nearly full' or not depends upon the update rate. The problem is that the update rate is faster than the softupdate code can deal with. I would say a filesystem that adds new files in an amount close to its free space is nearly full. Running sync between each install shows that this is a bug. sync is supposed to be idempotent. 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. DS To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: make install trick
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 problem on /tmp as you did on / unless you waste a huge disk for /tmp. :( Nate To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
RE: make install trick
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 situations. 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 doesn't handle that situation particularly well. Once could even argue that it's preferable to force the make to abort than thrash the filesystem. Though a switch to allow it to thrash might be helpful in degenerate cases such as this. Fastupdates is great for the most common case -- a typical /usr or /home partition. That's where you care about write performance anyway. Actually this becomes quite dangerous when used on tmp filesystems, it used to be that mfs was a good idea for /tmp, but now softupdates drastically improves performance... however given that a full /tmp can kill a system that places us in a dilemma now doesn't it? *shrug* 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. Of course I'm trying desperately to understand the softupdates code right now. :) -Alfred To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: make install trick
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 well always used a separate /tmp partition. I've always used MFS with FreeBSD. This makes the root partition virtually read-only (which has robustness and security advantages). And, if you do lots of development, then you'll have the same problem on /tmp as you did on / unless you waste a huge disk for /tmp. :( Solutions: 1) Use -pipe 2) Don't use softupdates 3) Use a RAMdisk (eg MFS) instead of a physical disk (which makes the previous point irrelevant). I don't recall seeing anyone mention problems like this (though they might be on lists I don't read). Peter -- Peter Jeremy (VK2PJ)[EMAIL PROTECTED] Alcatel Australia Limited 41 Mandible St Phone: +61 2 9690 5019 ALEXANDRIA NSW 2015 Fax: +61 2 9690 5982 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: make install trick
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 mean that an application may receive ENOSPC when writing to a filesystem even though space on that filesystem has been recently freed. Any application that cannot handle this situation is _broken_. Another option for /tmp - which I forgot last time, and seems to avoid the known problems with MFS and softupdates - it to mount /tmp async. Since you're going to blow it all away on the next reboot anyway, it doesn't really matter if the a crash trashes the FS (which is the major problem with async mounts). Peter -- Peter Jeremy (VK2PJ)[EMAIL PROTECTED] Alcatel Australia Limited 41 Mandible St Phone: +61 2 9690 5019 ALEXANDRIA NSW 2015 Fax: +61 2 9690 5982 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: make install trick
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 `destabilize'? There are bugs in softupdates which mean that an application may receive ENOSPC when writing to a filesystem even though space on that filesystem has been recently freed. Any application that cannot handle this situation is _broken_. Please read more of the thread before replying, the fact of the matter is that softupdates can crash the system when this happens, not a mere application, but the entire system can lock up. Another option for /tmp - which I forgot last time, and seems to avoid the known problems with MFS and softupdates - it to mount /tmp async. Since you're going to blow it all away on the next reboot anyway, it doesn't really matter if the a crash trashes the FS (which is the major problem with async mounts). Which isn't an option unless you dedicate a partition for /tmp which is pretty wasteful imo. -Alfred To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
installworld broken from R/O /usr/obj
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 about this is that its causing perl's libsdbm.a to
get rebuilt during an installworld. This is causing installworlds to
fail for me from R/O /usr/obj partitions.
When make does its initial open of the library, Arch_LibOODate() calls
ArchStatMember with the member arg equal to RANLIBMAG (or "/"). This
in turn calls ArchStatMember() with member="/". This calls
ArchFindMember() with member="/". ArchFindMember() will then return
NULL because the strrchr() on line 809 of arch.c causes the pointer to
be advanced past the last "/" in the member path, which makes it NULL.
I have a hackish fix for this which just looks at the length of
RANLIBMAG the length of member. If they are both 1 are equal, it
fails to advance member past the trailing /. This allows the
RANLIBMAG string to be found prevents an up-to-date lib from being
rebuilt:
Index: usr.bin/make/arch.c
===
RCS file: /usr/project/ari_scratch2/freebsd-cvs/src/usr.bin/make/arch.c,v
retrieving revision 1.14
diff -u -b -B -r1.14 arch.c
--- arch.c 1999/09/11 13:08:00 1.14
+++ arch.c 1999/09/21 13:25:39
@@ -807,7 +807,9 @@
* the comparisons easier...
*/
cp = strrchr (member, '/');
-if (cp != (char *) NULL) {
+if ((cp != (char *) NULL)
+ !((strlen(member) == 1) (strlen(RANLIBMAG) == 1)
+ strncmp(member, RANLIBMAG, 1) == 0)){
member = cp + 1;
}
len = tlen = strlen (member);
Anybody interested in comitting this? I passed it by the person who
committed 1.13 of arch.c was ignored. I don't know make well
enough to feel comfortable committing this myself.
Drew
--
Andrew Gallatin, Sr Systems Programmer http://www.cs.duke.edu/~gallatin
Duke University Email: [EMAIL PROTECTED]
Department of Computer Science Phone: (919) 660-6590
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: make install trick
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 lots of development, then you'll have the same problem on /tmp as you did on / unless you waste a huge disk for /tmp. :( You could just symlink /tmp to someplace big and softupdateable. At least then you can share the free space with another big filesystem. The only problem then is that when you boot standalone you either need to be able to mount wherever you've symlinked it into or rm the symlink and mkdir /tmp while you're standalone (and remember to put it back before going multi user). In some ways symlinking is better than having /tmp as a mount point. If it's a real mount point you're likely to create stuff in /tmp while standalone that can't be seen while you're multi user with a file system mounted on top of it. Which leads to "...my / is full and I can't find the files that are using all the space!" -- Kevin Street [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: make install trick
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 system worries me greatly. What do you mean by `destabilize'? ... softupdates can crash the system when this happens, not a mere application, but the entire system can lock up. I don't recall this coming up in this thread. Last I recall, that bug was supposed to be fixed (and Kirk(?) wanted anyone who still saw it to report it). Unfortunately, I can't find that thread in the archives :-(. Which isn't an option unless you dedicate a partition for /tmp which is pretty wasteful imo. I guess we disagree on this. My feeling is that write activity on root should be minimised to minimise the risk that root will be inconsistent following a crash. Secondly, there's a security viewpoint that users should not have write access anywhere in the root or /usr filesystems. Peter -- Peter Jeremy (VK2PJ)[EMAIL PROTECTED] Alcatel Australia Limited 41 Mandible St Phone: +61 2 9690 5019 ALEXANDRIA NSW 2015 Fax: +61 2 9690 5982 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: FTP daemon error messages when login
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: http://www.cauce.org To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: make install trick
[.] 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] http://www.Awfulhak.org [EMAIL PROTECTED] Don't _EVER_ lose your sense of humour ! [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: make install trick
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 problem on /tmp as you did on / unless you waste a huge disk for /tmp. :( Ah, but if you have /tmp on your root partition, you should really have more than 12M of free space: $ du -sk /bin /sbin 3247/bin 8519/sbin :-) Interestingly enough, I believe there's another ``bug'' here in the softupdates code. If softupdates is short on required disk space, it sould at least go through the todo list and optimise out what it can, possibly reducing the disk space requirements. If it did this, repeating the make install a few times should eventually work as it will ultimately end up overwriting things with exactly the same data and optimising the whole operation out - but this isn't currently the case. Nate -- Brian [EMAIL PROTECTED][EMAIL PROTECTED] http://www.Awfulhak.org [EMAIL PROTECTED] Don't _EVER_ lose your sense of humour ! [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: make install trick
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 mean that an application may receive ENOSPC when writing to a filesystem even though space on that filesystem has been recently freed. Any application that cannot handle this situation is _broken_. [.] :-] You're joking right ? Most applications don't even *notice* the situation let alone handle it. Whaddaya do when /var/log runs out of space ? Show me an app that handles it. I guess you can argue the case, but in real life, running out of any machine resource can cause all sorts of possibly unrecoverable problems. IMHO the best way to deal with it in a generic way is to have the give-me-the-resource function block if it really thinks it's a temporary thing. In the case of softupdtes, I'd be surprised if it couldn't easily figure out that the problem is *probably* transient and block, but of course to figure out exactly how transient it is would probably involve about the same amount of effort as just processing the softupdates ``todo'' list there and then. Anyway, I'll shut up now :-I -- Brian [EMAIL PROTECTED][EMAIL PROTECTED] http://www.Awfulhak.org [EMAIL PROTECTED] Don't _EVER_ lose your sense of humour ! [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: [Patches avail?] Re: MMAP() in STABLE/CURRENT ...
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 sync ; sleep 1 done doesn't prove to be a workaround -- the system still locks up. I tried this as per Mattew's suggestion in an e-mail on the list. BTW: I'll downgrade to 3.1-STABLE as of aprox. end of April; I'll let you know if it's stable for me. Thanks, Ady (@warpnet.ro) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: [Patches avail?] Re: MMAP() in STABLE/CURRENT ...
: 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 (and normally does work - try it on a working system to make sure that you've compiled in the appropriate DDB options), and you aren't in an X display (ctl-alt-esc isn't useful when done from an X display)... then your lockup problem is unrelated to mmap. If you are running an X display on this box, you may be able to get more information in regards to the crash if you turn off X. : : I have: squid (20Mb), nntpcached (17Mb SIZE, 1Mb RES), apache, named, :MFS, a few PPP processes and the rest of the standard menu. The only programs known to cause the swap problem are innd and innxmit, both part of the inn news system. : OK, how about some workarounds, I can't wait anylonger for this to be :fixed, my situation got critical. Should I downgrade to 3.1-RELEASE (that :hadn't exhibit this way) or can I dare a 4.0-CURRENT (are these problems :present in -current too ?) ? : : Thanks, : Ady (@warpnet.ro) If the machine is locking up to the point where you cannot even drop into DDB, this bug is not related to the known mmap() bugs. At this point I have no idea what might be causing your lockup problem. -Matt Matthew Dillon [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: [Patches avail?] Re: MMAP() in STABLE/CURRENT ...
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) blocking pretty :often (I don't get over 3 days uptimes). If you need details just let me :know. : :-Matt :Matthew Dillon :[EMAIL PROTECTED] : Thanks, : Ady (@warpnet.ro) Well, your lockups may or may not be related to the remaining mmap problems. They could be related to the swap fragmentation problems in stable, or they could be related to something else entirely. In order to determine the cause of your lockup problems, some additional information is necessary. The easiest way to get the information is to enable DDB and kernel core dumps so you can panic the machine from 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 ? the console and get a core. Once you have the core 'cd /var/crash; ps -M vmcore.X -N kernel.X' (where X is the latest dump number) can be used to determine what the processes were doing when they locked up. The two most common VM-related lockups in -stable are: (1) swap metadata fragmentation due to paging in the face of large running processes (system runs out of KVM), and I have: squid (20Mb), nntpcached (17Mb SIZE, 1Mb RES), apache, named, MFS, a few PPP processes and the rest of the standard menu. (2) write()ing the mmap'd area of one file descriptor to another. OK, how about some workarounds, I can't wait anylonger for this to be fixed, my situation got critical. Should I downgrade to 3.1-RELEASE (that hadn't exhibit this way) or can I dare a 4.0-CURRENT (are these problems present in -current too ?) ? -Matt Matthew Dillon [EMAIL PROTECTED] Thanks, Ady (@warpnet.ro) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
