-current build fails
echo '#include "i386/att.h"' tm.h echo '#include "i386/freebsd.h"' tm.h echo '#include "i386/perform.h"' tm.h cc -c -O -pipe -I/usr/src/gnu/lib/libgcc/../../../contrib/egcs/gcc/config -I/usr/src/gnu/lib/libgcc/../../../contrib/egcs/gcc -I. -fexceptions -DIN_GCC -I/usr/obj/usr/src/tmp/usr/include -DL_mulsi3 -o _mulsi3.o /usr/src/gnu/lib/libgcc/../../../contrib/egcs/gcc/libgcc1.c *** Signal 12 Stop in /usr/src/gnu/lib/libgcc. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop. *** Error code 1 Stop. *** Error code 1 Stop. Any ideas? Cheers, Vince - [EMAIL PROTECTED] - [EMAIL PROTECTED] __ Unix Networking Operations - FreeBSD-Real Unix for Free / / / / | / |[__ ] GaiaNet Corporation - M C Estate / / / / | / | __] ] Beverly Hills, California USA 90210 / / / / / |/ / | __] ] HongKong Stars/Gravis UltraSound Mailing Lists Admin /_/_/_/_/|___/|_|[] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
anyone have wine working?
Is there anyone that have wine working on -current? I have tried old binaries of wine that I have compiled and used a few months ago on -current and have recompiled them (99.07.31) and have also tried the latest (99.09.23), but they all just coredump. It did work a few months ago, so I would guess that it might be our signal changes. :-) The output of gdb looks like this: Core was generated by `wine'. Program terminated with signal 4, Illegal instruction. #0 0x80602ce in __regs_RtlRaiseException () (gdb) bt #0 0x80602ce in __regs_RtlRaiseException () #1 0x8060828 in EXC_segv () #2 0xbfbfdfac in ?? () #3 0x8060828 in EXC_segv () #4 0xbfbfdfac in ?? () #5 0x8060828 in EXC_segv () #6 0xbfbfdfac in ?? () #7 0x8060828 in EXC_segv () #8 0xbfbfdfac in ?? () #9 0x8060828 in EXC_segv () #10 0xbfbfdfac in ?? () #11 0x8060828 in EXC_segv () #12 0xbfbfdfac in ?? () ... #2525 0x8060828 in EXC_segv () #2526 0xbfbfdfac in ?? () #2527 0x8060828 in EXC_segv () #2528 0xbfbfdfac in ?? () #2529 0x8060828 in EXC_segv () #2530 0xbfbfdfac in ?? () #2531 0x8060828 in EXC_segv () #2532 0xbfbfdfac in ?? () #2533 0x8060a4b in EXC_int () #2534 0xbfbfdfac in ?? () #2535 0x8126e2c in server_call () #2536 0x8129e3f in WaitForMultipleObjectsEx () #2537 0x8129882 in SERVICE_Loop () #2538 0x812ab42 in THREAD_Start () #2539 0x8129f6b in SYSDEPS_StartThread () #2540 0x0 in ?? () --- John -- John Hay -- [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: -current build fails
-I/usr/src/gnu/lib/libgcc/../../../contrib/egcs/gcc -I. -fexceptions -DIN_GCC -I/usr/obj/usr/src/tmp/usr/include -DL_mulsi3 -o _mulsi3.o /usr/src/gnu/lib/libgcc/../../../contrib/egcs/gcc/libgcc1.c *** Signal 12 ...snip... Any ideas? YES. DELETE, YES DELETE, CURRENT FROM YOUR MACHINE since you are unpreparied to run it. When you have the TIME TO READ the freebsd-current mailing list then run it again. RTFML (and I'm starting to TRUELY hope that people stop answering this question other than pointing them to the list archive). -- -- David([EMAIL PROTECTED]) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: K6-III wrtalloc + mtrr support ?
On Fri, 29 Oct 1999, Brian Fundakowski Feldman wrote: I disabled (or asked Peter to, actually) the K6-2+ MTRR driver a while back because with XFree86 3.9.16 (an alpha which uses MTRR support) it would cause memory corruption. It's very strange, and something I really haven't figured out... If you want to enable it, go ahead, but be very wary; if you do find out what's wrong, let me know. I remember this now, I was one of those that got bit by this problem. What I recall is that MTRR support made a dramatic speed improvement, but alas was _extremely_ unstable. That was when I had an ATI Expert@Work card. Since then I've gotten a 3dfx Voodoo3, perhaps this card might be more stable? So Brian, how do I switch this back on ? On the other topic - write allocation - should I be seeing an indication of its status in the boot up messages ? Hmm, I guess I could just UTSL on this one :) ... Andrew. -- +-- | Andrew Atrens Nortel Networks, Ottawa, Canada. | | All opinions expressed are my own, not those of any employer. | --+ Heller's Law: The first myth of management is that it exists. Johnson's Corollary: Nobody really knows what is going on anywhere within the organization. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: -current build fails
On 30-Oct-99 Vincent Poy wrote: Hmmm, I can understand the build/install portion but will it boot since one machine is -CURRENT from 3/99 and the other is 3.3-RELEASE. I highly advise that you read the last month's archive of the -current mailing list archives: http://docs.FreeBSD.ORG/mail/archive/1999/freebsd-current/. Read ALL the messages. Oh, and update your -CURRENT. A -CURRENT machine with sources from March 1999 indicates you're not running a machine in sync with the purpose of -CURRENT. Use -STABLE instead. -- Will Andrews [EMAIL PROTECTED] GCS/E/S @d- s+:++:- a---+++ C++ UB P+ L- E--- W+++ !N !o ?K w--- ?O M+ V-- PS+ PE++ Y+ PGP t++ 5 X++ R+ tv+ b++ DI+++ D+ G+ e- h! r--+++ y? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: copy-on-write optimized faults
On Sat, Oct 30, 1999 at 06:54:07PM +0200, Leif Neland wrote: I would appreciate it if people running -current would run a "vmstat -s" and tell me if they see a NON-ZERO value for copy-on-write optimized faults. About six months ago, I implemented a simpler and more general optimization at an earlier "fork in the road". (In effect, I avoid the creation of the redundant vm object that "copy-on-write optimized faults" applies to.) FreeBSD ns.internet.dk 3.3-STABLE FreeBSD 3.3-STABLE #6: Fri Oct 1 16:06:46 CEST 1999 [EMAIL PROTECTED]:/usr/src/sys/compile/DK i386 [cut] 2062637 copy-on-write optimized faults [cut] I must have something configured wrong, or??? No, but you didn't read Allan's original posting, the change only applied to -CURRENT, your box is running -STABLE ... /Jesper -- Jesper Skriver (JS4261-RIPE), Network manager Tele Danmark DataNet, IP section (AS3292) One Unix to rule them all, One Resolver to find them, One IP to bring them all and in the zone to bind them. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: -current build fails
On Sat, 30 Oct 1999, Will Andrews wrote: On 30-Oct-99 Vincent Poy wrote: Hmmm, I can understand the build/install portion but will it boot since one machine is -CURRENT from 3/99 and the other is 3.3-RELEASE. I highly advise that you read the last month's archive of the -current mailing list archives: http://docs.FreeBSD.ORG/mail/archive/1999/freebsd-current/. Read ALL the messages. Actually, reading just the UPDATING file has all the info... I was just worried that compiling a kernel and rebooting may not boot successfully before the make world build. Oh, and update your -CURRENT. A -CURRENT machine with sources from March 1999 indicates you're not running a machine in sync with the purpose of -CURRENT. Use -STABLE instead. Well, I try to stay up to date but there are times when I am busy so things do get behind... I've ran -current since 1993. There is no real reason to use -STABLE. Cheers, Vince - [EMAIL PROTECTED] - [EMAIL PROTECTED] __ Unix Networking Operations - FreeBSD-Real Unix for Free / / / / | / |[__ ] GaiaNet Corporation - M C Estate / / / / | / | __] ] Beverly Hills, California USA 90210 / / / / / |/ / | __] ] HongKong Stars/Gravis UltraSound Mailing Lists Admin /_/_/_/_/|___/|_|[] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: -current build fails
On Sat, Oct 30, 1999, Vincent Poy wrote: Well, I try to stay up to date but there are times when I am busy so things do get behind... I've ran -current since 1993. There is no real reason to use -STABLE. Give me one single reason why there is on real reason to use -STABLE and I'll give you 10 reasons to use -STABLE. -- |Chris Costello [EMAIL PROTECTED] |Performance is easier to add than clarity. `-- To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: K6-III wrtalloc + mtrr support ?
On Sat, 30 Oct 1999, Andrew Atrens wrote:
On Fri, 29 Oct 1999, Brian Fundakowski Feldman wrote:
I disabled (or asked Peter to, actually) the K6-2+ MTRR driver a while
back because with XFree86 3.9.16 (an alpha which uses MTRR support) it
would cause memory corruption. It's very strange, and something I
really haven't figured out... If you want to enable it, go ahead, but
be very wary; if you do find out what's wrong, let me know.
I remember this now, I was one of those that got bit by this problem. What
I recall is that MTRR support made a dramatic speed improvement, but alas
was _extremely_ unstable. That was when I had an ATI Expert@Work card.
Since then I've gotten a 3dfx Voodoo3, perhaps this card might be more
stable? So Brian, how do I switch this back on ?
If you REALLY want to do this, which I wouldn't recommend since it
caused instability on my TNT too... But if you do, please apply the
included patch and give me the output it has generated. This is my
last resort in checking if I possibly did something wrong :(
Uncomment this line in src/sys/i386/conf/files.i386:
# i386/i386/k6_mem.cstandard
and reconfig/rebuild your kernel.
On the other topic - write allocation - should I be seeing an indication
of its status in the boot up messages ? Hmm, I guess I could just UTSL on
this one :) ...
No, write allocation status is only printed on boot -v. You could also
drop to ddb and type call print_AMD_info() to see if it's really on.
Andrew.
--
+--
| Andrew Atrens Nortel Networks, Ottawa, Canada. |
| All opinions expressed are my own, not those of any employer. |
--+
Heller's Law: The first myth of management is that it exists.
Johnson's Corollary: Nobody really knows what is going on
anywhere within the organization.
--
Brian Fundakowski Feldman \ FreeBSD: The Power to Serve! /
[EMAIL PROTECTED]`--'
Index: k6_mem.c
===
RCS file: /usr2/ncvs/src/sys/i386/i386/k6_mem.c,v
retrieving revision 1.4
diff -u -r1.4 k6_mem.c
--- k6_mem.c1999/09/05 15:45:57 1.4
+++ k6_mem.c1999/10/30 18:31:45
@@ -66,7 +66,8 @@
#define k6_reg_make(addr, mask, wc, uc)\
((addr) | ((mask) 2) | ((wc) 1) | uc)
-static void k6_mrinit(struct mem_range_softc *sc);
+static char *bitprint_4(u_int32_t, char [33]);
+static void k6_mrinit(struct mem_range_softc *);
static int k6_mrset(struct mem_range_softc *, struct mem_range_desc *, int *);
static __inline int k6_mrmake(struct mem_range_desc *, u_int32_t *);
static void k6_mem_drvinit(void *);
@@ -77,9 +78,22 @@
NULL
};
+static char *
+bitprint_4(u_int32_t i, char res[33]) {
+register int count;
+
+for (count = 0; count 32; count++)
+res[31 - count] = (i (1 count)) ? '1' : '0';
+res[32] = '\0';
+return res;
+}
+
static __inline int
k6_mrmake(struct mem_range_desc *desc, u_int32_t *mtrr) {
u_int32_t len = 0, wc, uc;
+#ifndef K6_MTRR_SILENT
+ char buf[33];
+#endif
register int bit;
if (desc-mr_base ~ 0xfffe)
@@ -95,6 +109,11 @@
uc = (desc-mr_flags MDF_UNCACHEABLE) ? 1 : 0;
*mtrr = k6_reg_make(desc-mr_base, len, wc, uc);
+#ifndef K6_MTRR_SILENT
+ printf("k6_mrmake: base = %p, len = %#x, flags = %#x\nk6_mrmake: %s\n",
+ desc-mr_base, desc-mr_len, desc-mr_flags,
+ bitprint_4(*mtrr, buf));
+#endif
return 0;
}
Re: -current build fails
Chris Costello writes: On Sat, Oct 30, 1999, Vincent Poy wrote: Well, I try to stay up to date but there are times when I am busy so things do get behind... I've ran -current since 1993. There is no real reason to use -STABLE. Give me one single reason why there is on real reason to use -STABLE and I'll give you 10 reasons to use -STABLE. Can -STABLE run applications that use shared memory on an SMP kernel? No? I didn't think so. I think a lot of the people who run older versions of -current, and upgrade sporadically, have done so because there are particular things missing out of -STABLE that they need (or want). For various reasons, they're not inclined to install a new version of -current daily, or even weekly, and wait until they feel that -current is relatively stable. Most of them have no interest in doing major OS internals development, but are capable of generating kernel dumps after a panic. They also know that nobody's going to spend a lot of time on any problems they encounter unless they're running a very current -current. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: -current build fails
Hmmm, I can understand the build/install portion but will it boot since one machine is -CURRENT from 3/99 and the other is 3.3-RELEASE. Are you still running current, Vince? I thought we established over a year a go that -current was *not* for you since you don't take the requisite time to read the -current mailing list on a regular basis. Certainly wasting everyone's time here with a "known problem" that you should have already known is not productive and if you intend to keep making a habit of it (it was in response to a similar query from you that we established your unsuitability for -current a year ago, after all) then you'd either better stop running -current or start reading the -current mailing list. The FAQ on this is very clear! - Jordan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: -current build fails
I think a lot of the people who run older versions of -current, and upgrade sporadically, have done so because there are particular things missing out of -STABLE that they need (or want). Which is a fair point, and hopefully we'll be branching 4.0 sooner this time so the wait is not so long. They also know that nobody's going to spend a lot of time on any problems they encounter unless they're running a very current -current. This is another fair point, but it still does not exonerate those same users from reading the -current mailing list on a semi-religious basis. :) - Jordan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Sv: copy-on-write optimized faults
2062637 copy-on-write optimized faults [cut] I must have something configured wrong, or??? No, but you didn't read Allan's original posting, the change only applied to -CURRENT, your box is running -STABLE ... OKOKOKOK! Don't nag me anymore. I forgot, I run current at home and stable at work. Leif To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: emacs / ncurses - problem somewhere
"Peter S. Housel" [EMAIL PROTECTED] writes: Ever since the libtermcap / libncurses consolidation, change emacs has problems positioning the cursor and properly updating the screen for character-only devices like the console. It also affects the display in an xterm in non-X mode, i.e., when DISPLAY is *not* set. ... I filed a bug report for this. I fixed it in Emacs with the following patch. I think it's a FreeBSD bug, though. Good detective work, Peter. So is the bug in FreeBSD or Emacs? The new man page for tgetstr says: Bugs If you call tgetstr to fetch ca or any other parameterized string, be aware that it will be returned in terminfo notation, not the older and not-quite-compatible termcap notation. This won't cause problems if all you do with it is call tgoto or tparm, which both expand terminfo-style. Emacs tries to expand the string itself rather than by calling tparm and we've surprised it by returning the string in terminfo style rather than termcap style. Here's an alternative patch that forces Emacs to use the library versions of tparm and tgoto to do the decoding rather than rolling its own. Put this in /usr/ports/editors/emacs20/patches/patch-ce (although it really should get merged into patch-ca). It works by using the module intended for Emacs running on terminfo machines (ie. it uses terminfo.c rather than tparam.c). I tried this (briefly) on -current and -stable and it seems to work ok. $ cat /usr/ports/editors/emacs20/patches/patch-ce --- src/Makefile.in.origSat Oct 30 15:52:15 1999 +++ src/Makefile.in Sat Oct 30 15:55:28 1999 @@ -546,7 +546,7 @@ #define LIBS_TERMCAP termcapobj = termcap.o tparam.o #else /* LIBS_TERMCAP */ -termcapobj = tparam.o +termcapobj = terminfo.o #endif /* LIBS_TERMCAP */ #endif /* ! defined (TERMINFO) */ -- Kevin Street [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: -current build fails
On Sat, 30 Oct 1999, Jordan K. Hubbard wrote: Hmmm, I can understand the build/install portion but will it boot since one machine is -CURRENT from 3/99 and the other is 3.3-RELEASE. Are you still running current, Vince? I thought we established over a year a go that -current was *not* for you since you don't take the requisite time to read the -current mailing list on a regular basis. Yes, I am still running -current. I read the -current mailing list on a more regular basis than most of the people out there. Certainly wasting everyone's time here with a "known problem" that you should have already known is not productive and if you intend to keep making a habit of it (it was in response to a similar query from you that we established your unsuitability for -current a year ago, after all) then you'd either better stop running -current or start reading the -current mailing list. The FAQ on this is very clear! I have always read the -current mailing list but you have to remember that by the time I do the update, the known problem should already have been gone. I did read the UPDATING file and search the list as soon as I posted and fixed the problem on my own. I was just worried that rebooting with a new kernel before a world build might actually render the system bootless. Cheers, Vince - [EMAIL PROTECTED] - [EMAIL PROTECTED] __ Unix Networking Operations - FreeBSD-Real Unix for Free / / / / | / |[__ ] GaiaNet Corporation - M C Estate / / / / | / | __] ] Beverly Hills, California USA 90210 / / / / / |/ / | __] ] HongKong Stars/Gravis UltraSound Mailing Lists Admin /_/_/_/_/|___/|_|[] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: -current build fails
On Sat, 30 Oct 1999, Vincent Poy wrote: I was just worried that rebooting with a new kernel before a world build might actually render the system bootless. If you're worried, then just cp /usr/src/sys/compile/NAME/kernel /kernel.new and reboot, using kernel.new If it fails, you haven't disturbed the old, working /kernel. Leif To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: -current build fails
On Sat, 30 Oct 1999, Leif Neland wrote: On Sat, 30 Oct 1999, Vincent Poy wrote: I was just worried that rebooting with a new kernel before a world build might actually render the system bootless. If you're worried, then just cp /usr/src/sys/compile/NAME/kernel /kernel.new and reboot, using kernel.new If it fails, you haven't disturbed the old, working /kernel. I guess it's not wise doing things when I'm half asleep or else I wouldn't even have posted the question in the first place... Cheers, Vince - [EMAIL PROTECTED] - [EMAIL PROTECTED] __ Unix Networking Operations - FreeBSD-Real Unix for Free / / / / | / |[__ ] GaiaNet Corporation - M C Estate / / / / | / | __] ] Beverly Hills, California USA 90210 / / / / / |/ / | __] ] HongKong Stars/Gravis UltraSound Mailing Lists Admin /_/_/_/_/|___/|_|[] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: NOT! KDE 1.1.2 package for current seems broken
On 1999-10-28 11:30 +0200, Reinier Bezuidenhout [EMAIL PROTECTED] wrote: It seems that the qt-1.42 package of current is different than that of the 3.3. packages ... I just installed the current version of qt-1.42 and now kde 1.1.2 is working fine ... Well, KDE and Qt are written in C++, and with C++ the times of compatibility between object files compiled by different compilers (or even releases of the same compiler) is gone ... There is no "official" algorithm for name mangling. The compilers in -stable and -current are different, and that means you better recompile all C++ libraries left over from -stable (and do not even try to install Qt libraries for -stable) on -current, but you already know that ;-) Regards, STefan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: K6-III wrtalloc + mtrr support ?
On 30-Oct-99 Andrew Atrens wrote: I remember this now, I was one of those that got bit by this problem. What I recall is that MTRR support made a dramatic speed improvement, but alas was _extremely_ unstable. That was when I had an ATI Expert@Work card. Since then I've gotten a 3dfx Voodoo3, perhaps this card might be more stable? So Brian, how do I switch this back on ? Well.. I think it depends on the video card.. For example I had a Matrox Millenium II and turning write-combining on worked fine.. No stability or video glitch problems.. I got a TNT2 and tried it.. Not so lucky. It would cause video to glitch badly.. If I just disabled caching for the video cards region it was fine though. I suspect that since the x server feeds commands to the card via a memory mapped region turning write combing hosed its ability to send the commands in the correct order. I suppose I could fiddle with it and find out how big the command window but I haven't bothered yet. --- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
