Re: -current results (was something funny with soft updates?)
At 11:01 PM -0700 7/2/02, Matthew Dillon wrote: I get just about the same performance for GCC2 as I do for GCC3 in the tests I've run so far. It makes me wonder what the hell GCC3 is burning all that cpu *on*. One of the guys here at RPI (dec, actually) claims he got buildworld under current to run at more reasonable speeds by explicitly setting the CPUTYPE. I haven't had the time to run any experiments with that yet. -- Garance Alistair Drosehn= [EMAIL PROTECTED] Senior Systems Programmer or [EMAIL PROTECTED] Rensselaer Polytechnic Instituteor [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: additional queue macro
On Tue, 2 Jul 2002, Ian Dowse wrote: In message [EMAIL PROTECTED], Jonathan Lemon writes: Essentially, this provides a traversal of the tailq that is safe from element removal, while being simple to drop in to those sections of the code that need updating, as evidenced in the patch below. Note that this of course is not safe from element removal in general; it is just safe when you remove any element other than the next element, whereas TAILQ_FOREACH is safe when you remove any element other than the current one. For example it would not be safe to call a callback that could potentially remove arbitrary elements. It may be clearer in this case just to expand the macro in the code so that it is more obvious what assumptions can be made. This would be clearer in all case :-). I think even the committer of the FOREACH macros thinks that they shouldn't be used if the list traversal has any surprises. Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
what does it take to rsh as root now days?
I can rlogin to a -CURRENT box as root. However `rsh box id' comes back with: Jul 3 00:11:33 box rshd[4916]: root@dragon as rootk: permission denied (authentication error). cmd='id' Is PAM getting in the way here or something? To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: What's the right way to build XFree86-4 now?
At 4:57 PM +0200 6/26/02, Sheldon Hearn wrote: Here's what I did to get XFree86-4 to build with the base system's toolchain in -CURRENT: I thought I'd try this out. Before starting, I did a cvsup of all my ports tree. a) ports/devel/imake-4: Replace files/patch-d and files/patch-xthreads with the attached patch-config::cf::FreeBSD.cf. Add the attached patch-config::cf::bsdLib.tmpl. In both of these, I had to change the header lines (the lines which specify the file to patch) from: config/cf/FreeBSD.cf.orig to cf/FreeBSD.cf.orig I was then able to 'make patch' and 'make install' (I did a 'make extract' before touching any patches in imake-4/files). Without changing those lines, the 'make patch' would fail. b) ports/x11/XFree86-4-libraries: Replace files/patch-z45 with the attached patch-z45. I made the above switch, and it compiled fine. It then died in the middle of my 'make install' attempt: - - - - - installing in lib/GL/GL... /usr/bin/install -c -m 0644 libGL.a /usr/X11R6/lib ranlib /usr/X11R6/lib/libGL.a + /usr/bin/install -c -m 0755 libGL.so.1.2 /usr/X11R6/lib/libGL.so.1 + true + rm -f /usr/X11R6/lib/libGL.so + ln -s libGL.so.1 /usr/X11R6/lib/libGL.so install in lib/GL/GL done installing in lib/GL/mesa/src/OSmesa... /usr/bin/install -c -m 0644 libOSMesa.a /usr/X11R6/lib ranlib /usr/X11R6/lib/libOSMesa.a rm -f ../../../../../lib/GL/mesa/src/translate.o unshared/../../../../../lib/GL/mesa/src/translate.o LD_LIBRARY_PATH=../../../../../exports/lib cc -c -ansi -pedantic -Dasm=__asm -Wall -Wpointer-arith -I../../../../../exports/include/X11 -I../../../../../include/extensions -I../../../../../extras/Mesa/src/OSmesa -I../../../../../extras/Mesa/src -I../../../../../extras/Mesa/include -I../../../../.. -I../../../../../exports/include -DCSRG_BASED -DFUNCPROTO=15 -DNARROWPROTO -DXTHREADS -DXUSE_MTSAFE_API -DXNO_MTSAFE_PWDAPI -DMALLOC_0_RETURNS_NULL ../../../../../lib/GL/mesa/src/translate.c -o unshared/../../../../../lib/GL/mesa/src/translate.o Assembler messages: FATAL: can't create unshared/../../../../../lib/GL/mesa/src/translate.o: No such file or directory *** Error code 1 Stop in /usr/ports/x11/XFree86-4-libraries/work/xc/lib/GL/mesa/src/OSmesa. *** Error code 1 Stop in /usr/ports/x11/XFree86-4-libraries/work/xc/lib/GL. *** Error code 1 Stop in /usr/ports/x11/XFree86-4-libraries/work/xc/lib. *** Error code 1 Stop in /usr/ports/x11/XFree86-4-libraries/work/xc. *** Error code 1 Stop in /usr/ports/x11/XFree86-4-libraries/work/xc. *** Error code 1 Stop in /usr/ports/x11/XFree86-4-libraries. - - - - - (note that this means the package didn't get registered...) I did not even try to guess what this problem might be (hey, it's pretty late at this point!). c) ports/x11-servers/XFree86-4-Server: Add the attached patch-gcc31, taken from Motoyuki Konno's post to [EMAIL PROTECTED] with the following Message-ID: [EMAIL PROTECTED] I thought I'd pretend that #b worked perfectly, and try this too. In my case, I also wanted the matrox drives, so I have export WITH_MATROX_GXX_DRIVER=yes but that still died with internal compiler error in failed_reload, at reload1.c:5050, while compiling translate.c, while processing included file ../../../../extras/Mesa/src/trans_tmp.h. So, no joy in mudville just yet... -- Garance Alistair Drosehn= [EMAIL PROTECTED] Senior Systems Programmer or [EMAIL PROTECTED] Rensselaer Polytechnic Instituteor [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: KSE signal problems still
On Tue, 2 Jul 2002, Julian Elischer wrote:
On Tue, 2 Jul 2002, Andrew Gallatin wrote:
An easy way to induce a panic w/a post KSE -current is to ^C gdb as it
starts on an SMP machine:
A possibly related breakage is:
type ^Z while doing make buiildworld (or something similar).
when you type 'fg' there is a high change the build will abort..
# gdb -k /var/crash/kernel.1 /var/crash/vmcore.1
GNU gdb 5.2.0 (FreeBSD) 20020627
Copyright 2002 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and
you are
welcome to change it and/or distribute copies of it under certain
conditions.
Type show copying to see the conditions.
There is absolutely no warranty for GDB. Type show warranty for
details.
This GDB was configured as i386-undermydesk-freebsd...
^C
panic: mutex sched lock not owned at ../../../kern/subr_smp.c:126
cpuid = 1; lapic.id = 0100
Debugger(panic)
Stopped at Debugger+0x46: xchgl %ebx,in_Debugger.0
db where
No such command
db tr
Debugger(c02dbf5a) at Debugger+0x46
panic(c02db1a8,c02db318,c02df736,7e,c4445540) at panic+0xd6
_mtx_assert(c0315440,1,c02df736,7e) at _mtx_assert+0xa8
forward_signal(c4445540) at forward_signal+0x1a
tdsignal(c4445540,2,2) at tdsignal+0x182
psignal(c443d558,2) at psignal+0x3c8
pgsignal(c441ad00,2,1,c441ad1c,0) at pgsignal+0x63
ttyinput(3,c41e8e30,c41e8e00,0,c0347903) at ttyinput+0x316
ptcwrite(c4307a00,d7d5ec88,7f0011,1,d7d5ebc4) at ptcwrite+0x17f
spec_write(d7d5ebf0,d7d5ec3c,c0204cc8,d7d5ebf0,7f0011) at spec_write+0x5a
spec_vnoperate(d7d5ebf0) at spec_vnoperate+0x13
vn_write(c41ded5c,d7d5ec88,c440cd80,0,c409e780) at vn_write+0x1c8
dofilewrite(c409e780,c41ded5c,5,8088000,1) at dofilewrite+0xaf
write(c409e780,d7d5ed14,3,b,282) at write+0x39
syscall(2f,2f,2f,1,8073410) at syscall+0x23c
syscall_with_err_pushed() at syscall_with_err_pushed+0x1b
--- syscall (4, FreeBSD ELF, write), eip = 0x281fb3a3, esp =
0xbfbff37c, ebp = 0xbfbff3e8 ---
hum
so, the question is:
where should we get the sched lock?
Maybe just remove the foot-shooting that releases it?
% Index: kern_sig.c
% ===
% RCS file: /home/ncvs/src/sys/kern/kern_sig.c,v
% retrieving revision 1.170
% retrieving revision 1.171
% diff -u -1 -r1.170 -r1.171
% --- kern_sig.c29 Jun 2002 02:00:01 - 1.170
% +++ kern_sig.c29 Jun 2002 17:26:18 - 1.171
% @@ -1486,15 +1540,9 @@
%*/
% - if (p-p_stat == SRUN) {
% + mtx_unlock_spin(sched_lock);
^ shoot foot
% + if (td-td_state == TDS_RUNQ ||
% + td-td_state == TDS_RUNNING) {
I think sched_lock is needed for checking td_state too (strictly to use
the result of the check, so the lock is not critical if the use doesn't
do anything harmful), but there is no lock indication for td_state
in proc.h like there used to be for p_stat.
% + signotify(td-td_proc);
Holding sched_lock when calling signotify() used to be an error, but that
was changed in rev.1.155. This signotify() call seems to be bogus anyway.
signotify() should only be called after the signal mask is changed. The
call to signotify() here was removed in rev.1.154 when the semantics of
signotify() was changed a little. Bogus calls to signotify() just waste
time.
% #ifdef SMP
% - struct kse *ke;
% - struct thread *td = curthread;
% -/* we should only deliver to one thread.. but which one? */
% - FOREACH_KSEGRP_IN_PROC(p, kg) {
% - FOREACH_KSE_IN_GROUP(kg, ke) {
% - if (ke-ke_thread == td) {
% - continue;
% - }
% - forward_signal(ke-ke_thread);
% - }
% - }
% + if (td-td_state == TDS_RUNNING td != curthread)
% + forward_signal(td);
% #endif
forward_signal() was called with sched_lock held in rev.1.170, and
forward_signal() still requires it to be held. I think sched_lock is
needed for checking td_state too, as above. Here it is fairly clear
that calling forward_signal() bogusly after losing a race is harmless.
It just wakes up td to look for a signal that isn't there or can't
be handled yet. Since this only happens if we lose a race, it may be
more efficient to let it happen (rarely) than to lock (always) to prevent
it happening. But we already held the lock so the locking was free
except for latency issues.
Bruce
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: KSE signal problems still
On Wed, 3 Jul 2002, Bruce Evans wrote:
Maybe just remove the foot-shooting that releases it?
% Index: kern_sig.c
% ===
% RCS file: /home/ncvs/src/sys/kern/kern_sig.c,v
% retrieving revision 1.170
% retrieving revision 1.171
% diff -u -1 -r1.170 -r1.171
% --- kern_sig.c 29 Jun 2002 02:00:01 - 1.170
% +++ kern_sig.c 29 Jun 2002 17:26:18 - 1.171
% @@ -1486,15 +1540,9 @@
% */
% - if (p-p_stat == SRUN) {
% + mtx_unlock_spin(sched_lock);
^ shoot foot
% + if (td-td_state == TDS_RUNQ ||
% + td-td_state == TDS_RUNNING) {
I think sched_lock is needed for checking td_state too (strictly to use
the result of the check, so the lock is not critical if the use doesn't
do anything harmful), but there is no lock indication for td_state
in proc.h like there used to be for p_stat.
% + signotify(td-td_proc);
Holding sched_lock when calling signotify() used to be an error, but that
was changed in rev.1.155. This signotify() call seems to be bogus anyway.
signotify() should only be called after the signal mask is changed. The
call to signotify() here was removed in rev.1.154 when the semantics of
signotify() was changed a little. Bogus calls to signotify() just waste
time.
% #ifdef SMP
% - struct kse *ke;
% - struct thread *td = curthread;
% -/* we should only deliver to one thread.. but which one? */
% - FOREACH_KSEGRP_IN_PROC(p, kg) {
% - FOREACH_KSE_IN_GROUP(kg, ke) {
% - if (ke-ke_thread == td) {
% - continue;
% - }
% - forward_signal(ke-ke_thread);
% - }
% - }
% + if (td-td_state == TDS_RUNNING td != curthread)
% + forward_signal(td);
% #endif
forward_signal() was called with sched_lock held in rev.1.170, and
forward_signal() still requires it to be held. I think sched_lock is
needed for checking td_state too, as above. Here it is fairly clear
that calling forward_signal() bogusly after losing a race is harmless.
It just wakes up td to look for a signal that isn't there or can't
be handled yet. Since this only happens if we lose a race, it may be
more efficient to let it happen (rarely) than to lock (always) to prevent
it happening. But we already held the lock so the locking was free
except for latency issues.
Bruce
Untested fix for thes bugs and some style bugs in tdsignal():
Index: kern_sig.c
===
RCS file: /home/ncvs/src/sys/kern/kern_sig.c,v
retrieving revision 1.171
diff -u -2 -r1.171 kern_sig.c
--- kern_sig.c 29 Jun 2002 17:26:18 - 1.171
+++ kern_sig.c 3 Jul 2002 07:42:31 -
@@ -1468,5 +1449,5 @@
/*
* The force of a signal has been directed against a single
- * thread. We need to see what we can do about knocking it
+ * thread. We need to see what we can do about knocking it
* out of any sleep it may be in etc.
*/
@@ -1485,8 +1466,7 @@
*/
mtx_lock_spin(sched_lock);
- if ((action == SIG_DFL) (prop SA_KILL)) {
- if (td-td_priority PUSER) {
+ if (action == SIG_DFL (prop SA_KILL)) {
+ if (td-td_priority PUSER)
td-td_priority = PUSER;
- }
}
mtx_unlock_spin(sched_lock);
@@ -1496,7 +1476,7 @@
* except that stopped processes must be continued by SIGCONT.
*/
- if (action == SIG_HOLD) {
+ if (action == SIG_HOLD)
goto out;
- }
+
mtx_lock_spin(sched_lock);
if (td-td_state == TDS_SLP) {
@@ -1531,24 +1511,17 @@
}
goto runfast;
- /* NOTREACHED */
-
} else {
/*
-* Other states do nothing with the signal immediatly,
+* Other states do nothing with the signal immediately,
* other than kicking ourselves if we are running.
* It will either never be noticed, or noticed very soon.
*/
- mtx_unlock_spin(sched_lock);
- if (td-td_state == TDS_RUNQ ||
- td-td_state == TDS_RUNNING) {
- signotify(td-td_proc);
#ifdef SMP
- if (td-td_state == TDS_RUNNING td != curthread)
- forward_signal(td);
+ if (td-td_state == TDS_RUNNING td != curthread)
+ forward_signal(td);
#endif
- }
+ mtx_unlock_spin(sched_lock);
goto out;
}
- /*NOTREACHED*/
Re: -current results (was something funny with soft updates?)
On Tue, Jul 02, 2002 at 11:01:14PM -0700, Matthew Dillon wrote: (csh built with GCC2, -O3) test3:/home/dillon time ./x.csh 0.832u 0.848s 0:01.68 99.4% 881+645k 0+0io 0pf+0w test3:/home/dillon time ./x.csh 0.926u 0.755s 0:01.68 99.4% 889+654k 0+0io 0pf+0w (csh built with GCC3, -O3) You aren't taking advantage of what GCC 3.1 gives you. Try optimizing for your CPU also, -march=pentium4. Also the extra slowdown with Gcc 3.1 is all the changes needed in the backend to handle ISO-C++ and Java. I guess I should just stay out of this type of discussion... but I hate it when people are extra-critical about a piece of software w/o learning something about it first. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
ipfw divert not accepted
hunter# ipfw add 50 divert natd all from any to any via fxp0 ipfw: getsockopt(IP_FW_ADD): Invalid argument hunter# ipfw list 00100 allow ip from any to any via lo0 00200 deny ip from any to 127.0.0.0/8 00300 deny ip from 127.0.0.0/8 to any 65000 allow ip from any to any 65535 deny ip from any to any hunter# ifconfig fxp0 fxp0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST mtu 1500 inet6 fe80::2c0:9fff:fe05:9a1f%fxp0 prefixlen 64 scopeid 0x1 inet 172.17.22.32 netmask 0xff00 broadcast 172.17.22.255 ether 00:c0:9f:05:9a:1f media: Ethernet autoselect (100baseTX full-duplex) status: active hunter# ps ax | grep nat 188 ?? Is 0:00,00 /sbin/natd -t 255.255.255.255 -n fxp0 1059 p1 RV 0:00,00 grep nat (csh) hunter# This is with a -current of date=2002.06.27.22.00.00. -- Regards, Georg. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: What's the right way to build XFree86-4 now?
At 3:18 AM -0400 7/3/02, Garance A Drosihn wrote: At 4:57 PM +0200 6/26/02, Sheldon Hearn wrote: c) ports/x11-servers/XFree86-4-Server: Add the attached patch-gcc31, taken from Motoyuki Konno's post to [EMAIL PROTECTED] with the following Message-ID: [EMAIL PROTECTED] I thought I'd pretend that #b worked perfectly, and try this too. In my case, I also wanted the matrox drives, so I have export WITH_MATROX_GXX_DRIVER=yes but that still died with internal compiler error in failed_reload, at reload1.c:5050, while compiling translate.c, while processing included file ../../../../extras/Mesa/src/trans_tmp.h. So, no joy in mudville just yet... So As I mentioned in another thread, [EMAIL PROTECTED] had been telling me that compiles under gcc3 go faster when he sets CPUTIME. So just for the fun of it I added CPUTIME=i686 in my /etc/make.conf, and tried to recompile the XFree86-4-Server. This time it compiled. I tried a 'make install', and that also worked. I started up XDM, and that also worked. Not only that, but my machine didn't instantly reboot when XDM started, which had been happening to me for the last few days... [this on a dual-CPU, 650 MHz, Pentium 3 machine. No gnome, no KDE, just plain X with twm as the window manager...] So, mudville is a bit tired, but this is a definite step forward! -- Garance Alistair Drosehn= [EMAIL PROTECTED] Senior Systems Programmer or [EMAIL PROTECTED] Rensselaer Polytechnic Instituteor [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: What's the right way to build XFree86-4 now?
At 4:00 AM -0400 7/3/02, Garance A Drosihn wrote: I started up XDM, and that also worked. Not only that, but my machine didn't instantly reboot when XDM started, which had been happening to me for the last few days... Bah humbug. I went to log into XDM, and the machine sat there for awhile, and then rebooted. That might have been because the -libraries were only partially installed, though... Still, it's a step forward. -- Garance Alistair Drosehn= [EMAIL PROTECTED] Senior Systems Programmer or [EMAIL PROTECTED] Rensselaer Polytechnic Instituteor [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: KSE signal problems still
On Wed, 3 Jul 2002, Bruce Evans wrote:
On Tue, 2 Jul 2002, Julian Elischer wrote:
Maybe just remove the foot-shooting that releases it?
Yes I'm rationalising it at the moment..
turns out that just holding it for all of tdsignal works well.
Also removing it from setrunnable() is ok as all the callers I could find
have already locked it.
I checked in a stopgap to stop panics but I'm reworking it now.
the trouble is that thread semantics are really not well
defined for multi thread processes.
What does it mean to make a process run when it has many threads?
Should ALL threads be awakened, or is it enough if ONE thread awakens to
deliver the thread.
For right now it's mostly important that single threaded processs act
as they used to. We can always change how multithreaded processes
work.
% Index: kern_sig.c
% ===
% RCS file: /home/ncvs/src/sys/kern/kern_sig.c,v
% retrieving revision 1.170
% retrieving revision 1.171
% diff -u -1 -r1.170 -r1.171
% --- kern_sig.c 29 Jun 2002 02:00:01 - 1.170
% +++ kern_sig.c 29 Jun 2002 17:26:18 - 1.171
% @@ -1486,15 +1540,9 @@
% */
% - if (p-p_stat == SRUN) {
% + mtx_unlock_spin(sched_lock);
^ shoot foot
% + if (td-td_state == TDS_RUNQ ||
% + td-td_state == TDS_RUNNING) {
I think sched_lock is needed for checking td_state too (strictly to use
the result of the check, so the lock is not critical if the use doesn't
do anything harmful), but there is no lock indication for td_state
in proc.h like there used to be for p_stat.
% + signotify(td-td_proc);
Holding sched_lock when calling signotify() used to be an error, but that
was changed in rev.1.155. This signotify() call seems to be bogus anyway.
signotify() should only be called after the signal mask is changed. The
call to signotify() here was removed in rev.1.154 when the semantics of
signotify() was changed a little. Bogus calls to signotify() just waste
time.
Signotify is already calledin psignal so I've removed this one
from my version.
% #ifdef SMP
% - struct kse *ke;
% - struct thread *td = curthread;
% -/* we should only deliver to one thread.. but which one? */
% - FOREACH_KSEGRP_IN_PROC(p, kg) {
% - FOREACH_KSE_IN_GROUP(kg, ke) {
% - if (ke-ke_thread == td) {
% - continue;
% - }
% - forward_signal(ke-ke_thread);
% - }
% - }
% + if (td-td_state == TDS_RUNNING td != curthread)
% + forward_signal(td);
% #endif
forward_signal() was called with sched_lock held in rev.1.170, and
forward_signal() still requires it to be held. I think sched_lock is
needed for checking td_state too, as above. Here it is fairly clear
that calling forward_signal() bogusly after losing a race is harmless.
It just wakes up td to look for a signal that isn't there or can't
be handled yet. Since this only happens if we lose a race, it may be
more efficient to let it happen (rarely) than to lock (always) to prevent
it happening. But we already held the lock so the locking was free
except for latency issues.
much of what you say will be in my next commit
I told Andrew Gallatin that I would work on cleaning up
tdsignal and maybe psignal tonight, so that's what I've been doing..
it's not perfect tough..
but it clears it up a bit..
I'm just testing it at the moment.
Bruce
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: KSE signal problems still
On 03-Jul-2002 Julian Elischer wrote: On Wed, 3 Jul 2002, John Baldwin wrote: Erm, I thought I changd signotify() to require sched_lock and made the second half of psignal() (the whole case statement) lock sched_lock. Did you change that? (To Julian) psignal as a whole hasn't existed in the KSE tree since December. I must have missed it in the complicated merge that came from that in P4. I just checked it in like this for now to stop the panics until I can work out what he equivalent change to your is.. (feel free to check out the new psignal/tdsignal combination.) Well then it must be full of races then that were fixed since DP1. *sigh* I wonder how many other things were lost and need to be reimplemented. -- John Baldwin [EMAIL PROTECTED]http://www.FreeBSD.org/~jhb/ Power Users Use the Power to Serve! - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: About GEOM...
In message [EMAIL PROTECTED], Mario Goebbels writes: Hi! I have some questions about it. The first one is, when I compiled GEOM into the kernel, will physical disks be controlled by it already? Or does it apply to md mounted devices yet? all disks should be GEOM'ized. And the second is, when will it be officially activated? Seems to work fine yet (toying around with it). Some bits are missing yet, for instance the ioctls to change disklabels etc. when they're done and it works also with sysinstall it'll be standard. Before 5.0 if at all possible. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: ipfw divert not accepted
Georg-W. Koltermann wrote: hunter# ipfw add 50 divert natd all from any to any via fxp0 ipfw: getsockopt(IP_FW_ADD): Invalid argument Add option IPFIREWALL_FORWARD into your kernel config. -Maxim hunter# ipfw list 00100 allow ip from any to any via lo0 00200 deny ip from any to 127.0.0.0/8 00300 deny ip from 127.0.0.0/8 to any 65000 allow ip from any to any 65535 deny ip from any to any hunter# ifconfig fxp0 fxp0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST mtu 1500 inet6 fe80::2c0:9fff:fe05:9a1f%fxp0 prefixlen 64 scopeid 0x1 inet 172.17.22.32 netmask 0xff00 broadcast 172.17.22.255 ether 00:c0:9f:05:9a:1f media: Ethernet autoselect (100baseTX full-duplex) status: active hunter# ps ax | grep nat 188 ?? Is 0:00,00 /sbin/natd -t 255.255.255.255 -n fxp0 1059 p1 RV 0:00,00 grep nat (csh) hunter# This is with a -current of date=2002.06.27.22.00.00. -- Regards, Georg. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: KSE signal problems still
Julian Elischer wrote: Should ALL threads be awakened, or is it enough if ONE thread awakens to deliver the thread. For right now it's mostly important that single threaded processs act as they used to. We can always change how multithreaded processes work. POSIX makes no guarantees for threads delivery of signals. Specifically, signals are not thread-things, they are process things, and there are seperate threads-things for sending the moral equivalents (e.g. pthread_kill) to threads on an individual basis, but the system is not expected to make a distinction on signal delivery as to what theread is running, nor are there expected to be per thread masking, etc.. Garrett would probably be the right person to ask; he's a much better POSIX lawyer. This is really the problem I tried to explain earlier when it came to the disabling on SIG_POLL on a per descriptor basis. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: About GEOM...
aren't you suppost to be honeymooning from yesterday? On Wed, 3 Jul 2002, Poul-Henning Kamp wrote: To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: KSE signal problems still
On Wed, 3 Jul 2002, John Baldwin wrote: On 03-Jul-2002 Julian Elischer wrote: On Wed, 3 Jul 2002, John Baldwin wrote: Erm, I thought I changd signotify() to require sched_lock and made the second half of psignal() (the whole case statement) lock sched_lock. Did you change that? (To Julian) psignal as a whole hasn't existed in the KSE tree since December. I must have missed it in the complicated merge that came from that in P4. I just checked it in like this for now to stop the panics until I can work out what he equivalent change to your is.. (feel free to check out the new psignal/tdsignal combination.) Well then it must be full of races then that were fixed since DP1. *sigh* I wonder how many other things were lost and need to be reimplemented. Psignal is asside from kern_switch.c probably the largest single casualty. I'm just checking in a cleanup now.. wait a few minutes. -- John Baldwin [EMAIL PROTECTED]http://www.FreeBSD.org/~jhb/ Power Users Use the Power to Serve! - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: ipfw divert not accepted
Operator error, sorry for the false alarm. I had removed all of my IPFIREWALL options from my config in an attempt to find the cause of instability. I'm surprised that ipfw(8) did anything useful at all with that kernel. -- Thanks a lot, Georg. Am Mi, 2002-07-03 um 10.48 schrieb Maxim Sobolev: Georg-W. Koltermann wrote: hunter# ipfw add 50 divert natd all from any to any via fxp0 ipfw: getsockopt(IP_FW_ADD): Invalid argument Add option IPFIREWALL_FORWARD into your kernel config. -Maxim To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: KSE signal problems still
Expanding on my own mail: On Wed, 3 Jul 2002, Julian Elischer wrote: On Wed, 3 Jul 2002, John Baldwin wrote: Well then it must be full of races then that were fixed since DP1. *sigh* I wonder how many other things were lost and need to be reimplemented. Almost anything you checked into psignal will need looking at. It may not be mising but since signals for threaded processes are fundamentally different than signals for non threaded processes, some things just don't apply. for example if you checked in something to code that just doesn;t exist any more in a KSE kernel, what is the correct integration? Each one has to be evaluated on it's own.. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: KSE signal problems still
On 03-Jul-2002 Julian Elischer wrote: Expanding on my own mail: On Wed, 3 Jul 2002, Julian Elischer wrote: On Wed, 3 Jul 2002, John Baldwin wrote: Well then it must be full of races then that were fixed since DP1. *sigh* I wonder how many other things were lost and need to be reimplemented. Almost anything you checked into psignal will need looking at. It may not be mising but since signals for threaded processes are fundamentally different than signals for non threaded processes, some things just don't apply. for example if you checked in something to code that just doesn;t exist any more in a KSE kernel, what is the correct integration? Each one has to be evaluated on it's own.. The one in question here was fairly simple, it just expanded the sched_lock locking some. The argument could be made that you shouldn't be checking in stuff until you know how it works, etc., or that you could commit in smaller pieces (say, get multiple threads per process for kernel processes working in the scheduler and just ignoring userland-only things like signals until you have the other working). -- John Baldwin [EMAIL PROTECTED]http://www.FreeBSD.org/~jhb/ Power Users Use the Power to Serve! - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: About GEOM...
In message [EMAIL PROTECTED], Jul ian Elischer writes: aren't you suppost to be honeymooning from yesterday? I am, I'm not working, only doing things I do for fun :-) -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: About GEOM...
On Wed, 2002-07-03 at 10:59, Poul-Henning Kamp wrote: In message [EMAIL PROTECTED], Jul ian Elischer writes: aren't you suppost to be honeymooning from yesterday? I am, I'm not working, only doing things I do for fun :-) Isn't it a bit worrying when the two overlap? :) -- Simon Dick [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: -current results (was something funny with soft updates?)
Thus spake Terry Lambert [EMAIL PROTECTED]: Personally, I prefer knowing my code should work before giving it to the compiler, rather than using the compiler to think about things I'm too lazy/incapable of thinking of on my own. Given that, I would always favor a trade for faster run time and slower compile time. Error checking can be a good thing, but then there's... javac: Variable MIGHT have been used uninitialized. I don't really know because I can't do dataflow analysis, but I will refuse to compile until you change your code. On the topic of good commercial compilers, I always liked the old versions of Borland TurboC (later BorlandC). They generated compact, efficient code with a number of reasonable optimizations. (I suppose that isn't hard when your target platforms range from the 8086 to the 80386.) For the record, TurboC 1.0 on an 8088 is roughly half as fast as GCC 2.95 on a 450MHz Pentium 3. ``For every change in hardware capacity, there is an equal and opposite change in software efficiency.'' To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: -current results (was something funny with soft updates?)
On Wed, 3 Jul 2002, Garance A Drosihn wrote: At 11:01 PM -0700 7/2/02, Matthew Dillon wrote: I get just about the same performance for GCC2 as I do for GCC3 in the tests I've run so far. It makes me wonder what the hell GCC3 is burning all that cpu *on*. One of the guys here at RPI (dec, actually) claims he got buildworld under current to run at more reasonable speeds by explicitly setting the CPUTYPE. I haven't had the time to run any experiments with that yet. I got some improvements in generated code for a microbenchmark by compiling with -march=runtime arch. gcc on i386's now likes to optimize andb $1,%al and testb $1,%al as andl $1,%eax and testl $1,%eax, respectively. This tends to give a large pessimization (50% for the above in a loop) on at least PentiumPro's and PII's due to a partal register stall. Compiling with -march=pentium2 regains the original speed on a Celeron400 at least by zero-extending %eax before using it, but double-crosses itself by going back to using %al and not actually using %eax. Manually changing the code back to use %eax gave a 5% speedup for the loop relative to the old version. The manual change also gave a 5% speedup for an AthlonXP. AthlonXP's don't have partial register stalls and all versions generated by gcc gave the same results (-march=athlon-xp generated the same code as -march=pentium2). Summary: we can break even on all tested arches with gcc-3 for the microbenchmark by setting CPUTYPE right. We can beat gcc-2 by tweaking the generated code to be what gcc-3 apparently intended. But I don't like setting CPUTYPE or use -march, since I want to run the same code on different (i386-sub-)arches. I have 2 different ones on active machines and 3 more on inactive machines). Releases need to run on even more arches. Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: About GEOM...
On Wed, 3 Jul 2002, Poul-Henning Kamp wrote: In message [EMAIL PROTECTED], Mario Goebbels writes: And the second is, when will it be officially activated? Seems to work fine yet (toying around with it). Some bits are missing yet, for instance the ioctls to change disklabels etc. when they're done and it works also with sysinstall it'll be standard. It shouldn't be standard, because then using it wouldn't be optional. Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: About GEOM...
In message [EMAIL PROTECTED], Bruce Evans writes: On Wed, 3 Jul 2002, Poul-Henning Kamp wrote: In message [EMAIL PROTECTED], Mario Goebbels writes: And the second is, when will it be officially activated? Seems to work fine yet (toying around with it). Some bits are missing yet, for instance the ioctls to change disklabels etc. when they're done and it works also with sysinstall it'll be standard. It shouldn't be standard, because then using it wouldn't be optional. It will be standard because the current code does not support at least two of our platforms for normal disk sizes and none of our platforms for big disk sizes. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: ASUS CUSL2 panic on acpi
On Tue, Jul 02, 2002 at 11:55:18AM -0700, Shizuka Kudo wrote: Dear all, I wonder if anyone experienced the same issue as mime. I have an ASUS CUSL2 running -current and starting about three days ago, it panic when acpi is autoloaded. If I unset acpi_load at the boot prompt, the machine works fine. Here's the panic message and a trace for those interested acpi0: ASUS CUSL2on motherboard Fatal trap 12: page fault while in kernel mode fault virtual address = 0x16 fault code = supervisor read, page not present instruction pointer = 0x8:0xc04f9aca stack pointer = 0x10:0xc054ea14 frame pointer = 0x10:0xc054ea34 code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags= interrupt enabled, resume, IOPL = 0 current process = 0 (swapper) kernel: type 12 trap, code=0 Stopped at AcpiExReadDataFromField+0x5a: movzbl 0x16(%eax),%eax db trace AcpiExReadDataFromField(c0f00400,c25da200,c054ea50,c25e50c0,0) at AcpiExReadDataFromField+0x5a AcpiExResolveNodeToValue(c0f005b0,c0f00400,1,c0ed6d40,c054eab0) at AcpiExResolveNodeToValue+0xd9 AcpiExResolveToValue(c0f005b0,c0f00400,c0f00400,0,c054eab0) at AcpiExResolveToValue+0x53 AcpiExResolveOperands(5b80,c0f005b4,c0f00400,c0efbe00,c0f00400) at AcpiExResolveOperands+0x1cf AcpiDsEvalRegionOperands(c0f00400,c25d6480,c050411e,c25d6480,0) at AcpiDsEvalRegionOperands+0x50 AcpiDsExecEndOp(c0f00400,c054eb14,c0f00414,c0f0040c,cdd4f1b1) at AcpiDsExecEndOp+0x258 AcpiPsParseLoop(c0f00400,c257f900,c054eb74,0,0) at AcpiPsParseLoop+0x579 AcpiPsParseAml(c0f00400,c25dcc40,0,cdd4f1a6,e) at AcpiPsParseAml+0x7c AcpiDsExecuteArguments(c0efbe00,c051de10,e,cdd4f1a6,c257fdc0) at AcpiDsExecuteArguments+0x182 AcpiDsGetRegionArguments(c257fdc0,0,c0efbe00,1,c054ec10) at AcpiDsGetRegionArguments+0x56 AcpiNsInitOneObject(c0efbe00,1,c054ec60,0,0) at AcpiNsInitOneObject+0xd8 AcpiNsWalkNamespace(0,,,1,c0500620) at AcpiNsWalkNamespace+0xad AcpiWalkNamespace(0,,,c0500620,c054ec60) at AcpiWalkNamespace+0x77 AcpiNsInitializeObjects(0,c054ecc8,c050b8ab,0,2) at AcpiNsInitializeObjects+0x4d AcpiEnableSubsystem(0,2,c04fd110,0,0) at AcpiEnableSubsystem+0x8a acpi_attach(c25d7580,c25b5090,c03d3590,c0ed4d00,c0f04c80) at acpi_attach+0x13b device_probe_and_attach(c25d7580,c0f04c80,c054ed2c,c0368864,c0f04c80) at device_probe_and_attach+0xaf bus_generic_attach(c0f04c80,0,c0ed4d00,c0efda80,c0f04c80) at bus_generic_attach+0x28 nexus_attach(c0f04c80,c2596090,c03d3590,c03c4480,0) at nexus_attach+0x14 device_probe_and_attach(c0f04c80,c0ef9780,c054ed80,c035b5e5,c0f04f00) at device_probe_and_attach+0xaf root_bus_configure(c0f04f00,c03c4480,0,c054ed98,c020b175) at root_bus_configure+0x28 configure(0,54b000,54bc00,54b000,0) at configure+0x35 mi_startup() at mi_startup+0xb5 begin() at begin+0x43 db Hi, I'm getting a similar message with my Asus A7M266 (Yesterday's sources). What is the best way to record those messages at boot time? Writing them down by hand is pretty suboptimal and I don´t have a serial console installed. TIA, Christian -- http://www.unixpages.org[EMAIL PROTECTED] GPG Pub-Key: www.unixpages.org/cbrueffer.asc GPG Fingerprint: 0DB5 8563 2473 C72A A8D1 56EA DAD2 B05D 5F3C 3185 GPG Key ID : DAD2B05D5F3C3185 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: About GEOM...
On Wed, 3 Jul 2002, Poul-Henning Kamp wrote: In message [EMAIL PROTECTED], Bruce Evans writes: On Wed, 3 Jul 2002, Poul-Henning Kamp wrote: Some bits are missing yet, for instance the ioctls to change disklabels etc. when they're done and it works also with sysinstall it'll be standard. It shouldn't be standard, because then using it wouldn't be optional. It will be standard because the current code does not support at least two of our platforms for normal disk sizes and none of our platforms for big disk sizes. This is mostly because resources have been diverted away from updating working code to write a second system. Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: About GEOM...
In message [EMAIL PROTECTED], Bruce Evans writes: On Wed, 3 Jul 2002, Poul-Henning Kamp wrote: In message [EMAIL PROTECTED], Bruce Evans writes: On Wed, 3 Jul 2002, Poul-Henning Kamp wrote: Some bits are missing yet, for instance the ioctls to change disklabels etc. when they're done and it works also with sysinstall it'll be standard. It shouldn't be standard, because then using it wouldn't be optional. It will be standard because the current code does not support at least two of our platforms for normal disk sizes and none of our platforms for big disk sizes. This is mostly because resources have been diverted away from updating working code to write a second system. Make that third system, the current slice/label code is our second system, and I don't think the resources have been diverted as much as defected. Either way, I know you don't want either of DEVFS or GEOM, I think I know where you come from, I just happen to not agree that we should stay stuck back there. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
gcc 3.1 can't compile XFree86-4-Server
Hi,
I am trying to upgrade installed XFree86-4-Server package, but found that
a new gcc can't compile it. Following is relevant error output:
rm -f texutil.o
LD_LIBRARY_PATH=../../../../exports/lib cc -c -pipe -O -mpreferred-stack-boundar
y=2 -march=pentium-mmx -ansi -pedantic -Dasm=__asm -Wall -Wpointer-arith -I..
/../../../exports/include -I../../../../exports/include/X11 -I../../../../includ
e/extensions-I../../../../extras/Mesa/src -I../../../../lib/GL/dri
-I../../../.. -I../../../../exports/include -DCSRG_BASED -DFUNCPROTO=15 -DNAR
ROWPROTO -DXTHREADS -DXUSE_MTSAFE_API -DXNO_MTSAFE_PWDAPI-DMALLOC_0_RETURN
S_NULL -DGLXEXT -DXF86DRI -DGLX_DIRECT_RENDERING -DGLX_USE_DLOPEN -DGLX_USE_MESA
-DUSE_X86_ASM -DUSE_MMX_ASM -ansi -pedantic -Dasm=__asm -W
all -Wpointer-arith -I../../../../exports/include -I../../../../exports/include
/X11 -I../../../../include/extensions -I../../../../extras/Mesa/src -I
../../../../lib/GL/dri -I../../../.. -I../../../../exports/include -DCSRG_BAS
ED -DFUNCPROTO=15 -DNARROWPROTO -DXTHREADS -DXUSE_MTSAFE_API -DXNO_MTSAFE_PWD
API-DMALLOC_0_RETURNS_NULL -DGLXEXT -DXF86DRI -DGLX_DIRECT_RENDERING -DGLX_U
SE_DLOPEN -DGLX_USE_MESA-DUSE_X86_ASM -DUSE_MMX_ASM-fPIC
texutil.c
rm -f translate.o
LD_LIBRARY_PATH=../../../../exports/lib cc -c -pipe -O -mpreferred-stack-boundar
y=2 -march=pentium-mmx -ansi -pedantic -Dasm=__asm -Wall -Wpointer-arith -I..
/../../../exports/include -I../../../../exports/include/X11 -I../../../../includ
e/extensions-I../../../../extras/Mesa/src -I../../../../lib/GL/dri
-I../../../.. -I../../../../exports/include -DCSRG_BASED -DFUNCPROTO=15 -DNAR
ROWPROTO -DXTHREADS -DXUSE_MTSAFE_API -DXNO_MTSAFE_PWDAPI-DMALLOC_0_RETURN
S_NULL -DGLXEXT -DXF86DRI -DGLX_DIRECT_RENDERING -DGLX_USE_DLOPEN -DGLX_USE_MESA
-DUSE_X86_ASM -DUSE_MMX_ASM -ansi -pedantic -Dasm=__asm -W
all -Wpointer-arith -I../../../../exports/include -I../../../../exports/include
/X11 -I../../../../include/extensions -I../../../../extras/Mesa/src -I
../../../../lib/GL/dri -I../../../.. -I../../../../exports/include -DCSRG_BAS
ED -DFUNCPROTO=15 -DNARROWPROTO -DXTHREADS -DXUSE_MTSAFE_API -DXNO_MTSAFE_PWD
API-DMALLOC_0_RETURNS_NULL -DGLXEXT -DXF86DRI -DGLX_DIRECT_RENDERING -DGLX_U
SE_DLOPEN -DGLX_USE_MESA-DUSE_X86_ASM -DUSE_MMX_ASM-fPIC
translate.c
In file included from translate.c:779:
../../../../extras/Mesa/src/trans_tmp.h: In function `trans_1_GLdouble_1ub_elt':
../../../../extras/Mesa/src/trans_tmp.h:124: could not find a spill register
(insn 96 94 97 (set (subreg:SF (reg:QI 75) 0)
(plus:SF (reg:SF 8 st(0) [76])
(reg:SF 9 st(1) [80]))) 525 {*fop_sf_comm_nosse} (insn_list 87 (nil)
)
(expr_list:REG_DEAD (reg:SF 8 st(0) [76])
(nil)))
../../../../extras/Mesa/src/trans_tmp.h:124: Internal compiler error in failed_r
eload, at reload1.c:5050
Please submit a full bug report,
with preprocessed source if appropriate.
See URL:http://www.gnu.org/software/gcc/bugs.html for instructions.
*** Error code 1
Stop in /tmp/portbuild/usr/ports/x11-servers/XFree86-4-Server/work/xc/lib/GL/mes
a/src.
*** Error code 1
Stop in /tmp/portbuild/usr/ports/x11-servers/XFree86-4-Server/work/xc/lib/GL.
*** Error code 1
Please investigate fix.
-Maxim
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: Xmms
Andrzej Kwiatkowski [EMAIL PROTECTED] wrote: I've upgrade my FreeBSD 5.0 two days ago. Yesterday when i have compile XMMS from ports, Threads were broken. Update and try again. -- Christian naddy Weisgerber [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
dump(8) is hosed
On a 27-June-2002 23:02:00 UTC system (just before ipfw2 went in, pre-KSE3), dump will not complete dumping more than 5GB. At that point it stops responding properly to ^T, which should give DUMP: 47.52% done, finished in 1:19. At the 5GB mark, ^T gives: load: 0.00 cmd: dump 3981 [physstr] 2.11u 43.06s 0% 1536k and never changes. The user and system times never advance. Anybody have any ideas? To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: gcc 3.1 can't compile XFree86-4-Server
On Wed, Jul 03, 2002 at 05:26:50PM +0300, Maxim Sobolev wrote:
Hi,
I am trying to upgrade installed XFree86-4-Server package, but found that
a new gcc can't compile it. Following is relevant error output:
...
In file included from translate.c:779:
../../../../extras/Mesa/src/trans_tmp.h: In function `trans_1_GLdouble_1ub_elt':
../../../../extras/Mesa/src/trans_tmp.h:124: could not find a spill register
(insn 96 94 97 (set (subreg:SF (reg:QI 75) 0)
(plus:SF (reg:SF 8 st(0) [76])
(reg:SF 9 st(1) [80]))) 525 {*fop_sf_comm_nosse} (insn_list 87 (nil)
)
(expr_list:REG_DEAD (reg:SF 8 st(0) [76])
(nil)))
../../../../extras/Mesa/src/trans_tmp.h:124: Internal compiler error in failed_r
eload, at reload1.c:5050
Please submit a full bug report,
with preprocessed source if appropriate.
See URL:http://www.gnu.org/software/gcc/bugs.html for instructions.
*** Error code 1
...
Please investigate fix.
A fix is to submit a full bug report, with preprocessed source if
appropriate..
You can try the gcc31 port and see if it gets any farther.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: gcc 3.1 can't compile XFree86-4-Server
At 5:26 PM +0300 7/3/02, Maxim Sobolev wrote: Hi, I am trying to upgrade installed XFree86-4-Server package, but found that a new gcc can't compile it. Following is relevant error output: [...skipped...] Please investigate fix. Some information is in the email-thread under the subject: Re: What's the right way to build XFree86-4 now? which has been seeing sporadic messages over the past week or two. Sheldon has a few informative messages which include some patches to test. (although I don't think the patches are a complete fix for the problems we're seeing -- see my replies to that thread which were sent just last night...) -- Garance Alistair Drosehn= [EMAIL PROTECTED] Senior Systems Programmer or [EMAIL PROTECTED] Rensselaer Polytechnic Instituteor [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: KSE status report
After building today's -CURRENT successfully (CVSup started at 0347 hrs. Pacific (7 hrs. west of GMT/UTC at this time of year) from cvsup14, with the addition of Ruslan's updates to the src/share/mk/bsd.*.mk files), I thought it might be of use to just let this SMP (2x866 PIII) box sit in a make -j8 buildworld loop for a while and see how far it gets. The answer would appear to be not as far as I would have expected -- I tried to ssh back into the machine, was getting no response, so I resumed the screen session on another machine that had a tip going to the test machine's serial console. This is what I see (modulo tab/space replacement): Local package initialization:Creating DISK md10 md10: invalid primary partition table: no magic md10: invalid primary partition table: no magic [1] 234 Floating point exception (core dumped) Jul 3 07:21:37 freebeast kernel: pid 234 (newfs), uid 0: exited on signal 8 (core dumped) apache cvsupd . Additional TCP options:. Starting background filesystem checks Wed Jul 3 07:21:38 PDT 2002 FreeBSD/i386 (freebeast.catwhisker.org) (cuaa0) login: panic: vm_page_free: invalid wire count (360), pindex: 0x1 cpuid = 0; lapic.id = Debugger(panic) uernteilm etoruatp s9t owpiptihn gi nctpeursr Sttso pdpiesda balte d in_Debugger.0x46: xchgl %ebx, db al trap 9: general protectinuwlppippelo u 1lcd i10 irtnot 0:c026scpnr 01:da20fmpnr 010a2ppx8cxppxexpeppxxeppxp pps@xxltx = DPL 0, pres 1, def32 1, gran 1 processor eflags= resume, IOPL = 0 current process = c)elt r,o= S Xc pDcXKK`K$KhK,KpK4KxK Fatal trap 12: page fault while in kernel mode Fatal trap 12: page fault while in kernel mode cpuid = 1; lapic.id = 0100 fault virtual address = 0x199 fault code = supervisor read, page not present instruction pointer = 0x1ba0:0x9b stack pointer = 0x10:0xc03d39a8 frame pointer = 0x10:0xc0361ba0 code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags= trace trap, IOPL = 0 current process = 92825 (cc1) kernel: type 12 trap, code=0 Stopped at Debugger+0x46: xchgl %ebx,in_Debugger.0 db which isn't all that bad, in that it should provide some access to poke around and get some clues as to what broke. Unfortunately, that serial console appears to be completely unresponsive: I tried typing tr at it; nothing. Sent a break; nothing. Is there anything anyone can suggest for getting some additional information out of this? I don't have a critical need for the machine until tomorrow morning, so the only disadvantage to leaving it on is that it consumes electricity generates heat. Thanks, david -- David H. Wolfskill [EMAIL PROTECTED] Trying to support or use Microsoft products makes about as much sense as painting the outside of a house with watercolors. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: strange netstat output on Intel pro/1000 netperf testing
In article [EMAIL PROTECTED], zhang jack [EMAIL PROTECTED] wrote: Hi, When I using netperf to test Intel Pro/1000 performance, I got strange netstat output: #./netperf -H 10.0.0.2 TCP STREAM TEST to 10.0.0.2 on 10.0.0.2, I start netstat -w 1 , but got strange output: it seems the link is dowm and up ceaselessly. input(Total) output packets errs bytespackets errs bytes colls 1 01212460 1 0 9462 0 553 01206100277 0 10458 0 1 01203800 1 0 9291 0 554 01214652278 0 10461 0 1 01203816 1 0 9291 0 553 01214636277 0 10461 0 1 01203888 1 0 9291 0 553 01214636277 0 10461 0 4 01203784 2 0 9291 0 555 01214692277 0 10465 0 1 01195140 1 0 9225 0 551 01214596276 0 10457 0 1 01203768 1 0 9291 0 553 01214652277 0 10461 0 That is just because the interface statistics are only updated once per second, and your 1-second netstat delays are in sync with the stats updates. If you do netstat -w 2 or more, this artifact vanishes. John -- John Polstra John D. Polstra Co., Inc.Seattle, Washington USA Disappointment is a good sign of basic intelligence. -- Chögyam Trungpa To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: gcc 3.1 can't compile XFree86-4-Server
On Wed, Jul 03, 2002 at 11:45:19AM -0400, Garance A Drosihn wrote: which has been seeing sporadic messages over the past week or two. Sheldon has a few informative messages which include some patches to test. (although I don't think the patches are a complete fix for the problems we're seeing -- see my replies to that thread which were sent just last night...) I thought Sheldon's patches deal with using C (cc) vs. C++ (c++) to do the linking. Herhaps someone could summarize what is known. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: About GEOM...
Sick sick sick :-) On Wed, 3 Jul 2002, Poul-Henning Kamp wrote: In message [EMAIL PROTECTED], Jul ian Elischer writes: aren't you suppost to be honeymooning from yesterday? I am, I'm not working, only doing things I do for fun :-) -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: KSE signal problems still
On Wed, 3 Jul 2002, John Baldwin wrote: The argument could be made that you shouldn't be checking in stuff until you know how it works, etc., or that you could commit in smaller pieces (say, get multiple threads per process for kernel processes working in the scheduler and just ignoring userland-only things like signals until you have the other working). You can't do those separatly unfortulatly.. anyhow, it's not that I don't understand it, it's just that it's complicated.. The new version is as clse as I can get quickly but it still needs some cleaning. -- John Baldwin [EMAIL PROTECTED] http://www.FreeBSD.org/~jhb/ Power Users Use the Power to Serve! - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: recent bsd.lib.mk changes
On Fri, Jun 21, 2002 at 07:11:16PM -0400, Mikhail Teterin wrote: On Friday 21 June 2002 06:02 pm, David O'Brien wrote: = On Fri, Jun 21, 2002 at 05:46:17PM -0400, Mikhail Teterin wrote: = Why can't we have some way to explicitly list what is and what is not = needed? = = Feel free to send a patch adding ONLYSHAREDLIBS. INTERNALLIB in no = logical way I can think of would lead someone to think that only shared = libs should be built and they should be installed. Here I agree completely. I have always been puzzled by the naming of this knob. But it was the only way to achieve the goal. It is now a different knob entirely -- but under the same name, which is quite confusing. I am thinking, however, of something explicit like: WANT_SHARED_LIB ?= yes WANT_STATIC_LIB ?= yes WANT_PIC_LIB?= yes with the existing NOPROFILE and others to remain as compatibility interfaces for a while, for example: .ifndef WANT_PIC_LIB .ifndef NOPROFILE WANT_PIC_LIB = yes .else WANT_PIC_LIB = no .endif .endif The last change broke not only some ports, but who knows how many personal projects, which where doing the Right Thing (IMO) and used the bsd.*.mk The lost functionality should now be available again in revision 1.132. I will not have time to make a patch in a while :-\, however... Any way to determine quickly from inside the Makefile, which version of the bsd.lib.mk is installed? OSVERSION. Cheers, -- Ruslan Ermilov Sysadmin and DBA, [EMAIL PROTECTED] Sunbay Software AG, [EMAIL PROTECTED] FreeBSD committer, +380.652.512.251Simferopol, Ukraine http://www.FreeBSD.org The Power To Serve http://www.oracle.com Enabling The Information Age msg40392/pgp0.pgp Description: PGP signature
Re: KSE signal problems still
On 03-Jul-2002 Julian Elischer wrote: On Wed, 3 Jul 2002, John Baldwin wrote: The argument could be made that you shouldn't be checking in stuff until you know how it works, etc., or that you could commit in smaller pieces (say, get multiple threads per process for kernel processes working in the scheduler and just ignoring userland-only things like signals until you have the other working). You can't do those separatly unfortulatly.. Sure you could, just have kernel-only KSE processes at first and use some special kernel processes for testing. They would never return to userland but would be adequate to test that all the various run and sleep queues, etc. worked fine. anyhow, it's not that I don't understand it, it's just that it's complicated.. That part of my message was overly harsh. I'm sorry. -- John Baldwin [EMAIL PROTECTED]http://www.FreeBSD.org/~jhb/ Power Users Use the Power to Serve! - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: KSE status report
congratulations.. I think that you win the Matt Dillon got both processors to enter the ddb at the same time award.. On Wed, 3 Jul 2002, David Wolfskill wrote: login: panic: vm_page_free: invalid wire count (360), pindex: 0x1 cpuid = 0; lapic.id = Debugger(panic) uernteilm etoruatp s9t owpiptihn gi nctpeursr Sttso pdpiesda balte d in_Debugger.0x46: xchgl %ebx, db al trap 9: general protectinuwlppippelo u 1lcd i10 irtnot 0:c026scpnr 01:da20fmpnr 010a2ppx8cxppxexpeppxxeppxp pps@xxltx = DPL 0, pres 1, def32 1, gran 1 processor eflags= resume, IOPL = 0 current process = c)elt r,o= S Xc pDcXKK`K$KhK,KpK4KxK doing an nm and figuring out where the processor was might be informative. Julian To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: gcc 3.1 can't compile XFree86-4-Server
David O'Brien wrote:
On Wed, Jul 03, 2002 at 05:26:50PM +0300, Maxim Sobolev wrote:
Hi,
I am trying to upgrade installed XFree86-4-Server package, but found that
a new gcc can't compile it. Following is relevant error output:
...
In file included from translate.c:779:
../../../../extras/Mesa/src/trans_tmp.h: In function `trans_1_GLdouble_1ub_elt':
../../../../extras/Mesa/src/trans_tmp.h:124: could not find a spill register
(insn 96 94 97 (set (subreg:SF (reg:QI 75) 0)
(plus:SF (reg:SF 8 st(0) [76])
(reg:SF 9 st(1) [80]))) 525 {*fop_sf_comm_nosse} (insn_list 87 (nil)
)
(expr_list:REG_DEAD (reg:SF 8 st(0) [76])
(nil)))
../../../../extras/Mesa/src/trans_tmp.h:124: Internal compiler error in failed_r
eload, at reload1.c:5050
Please submit a full bug report,
with preprocessed source if appropriate.
See URL:http://www.gnu.org/software/gcc/bugs.html for instructions.
*** Error code 1
...
Please investigate fix.
A fix is to submit a full bug report, with preprocessed source if
appropriate..
Oh, I supposed that those dirt is not necessary for majestic FreeBSD
users. :(
Anyway, I've submitted it along with pre-processed source (c/7200), so
that it should be fairly easy to reproduce. There is a similar one
(c/7190), but it is without pre-processed sources, so that I think
that mine is better.
You can try the gcc31 port and see if it gets any farther.
Could you please try to compile translate.i attached to c/7200 with
gcc from ports (the right command to do it is also in the report) and
let me know if it works or not, because I have neither a time nor
spare bandwith to download/compile gcc just to test it.
Thanks!
-Maxim
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: gcc 3.1 can't compile XFree86-4-Server
At 9:27 AM -0700 7/3/02, David O'Brien wrote: On Wed, Jul 03, 2002, Garance A Drosihn wrote: Sheldon has a few informative messages which include some patches to test. (although I don't think the patches are a complete fix for the problems we're seeing -- see my replies to that thread which were sent just last night...) I thought Sheldon's patches deal with using C (cc) vs. C++ (c++) to do the linking. Perhaps someone could summarize what is known. I'm afraid I only have a vague idea. Certainly part of what Sheldon was sorting out was C vs C++, and just general build problems. With his patches I was able to compile and install imake. I was able to compile XFree86-4-libraries, but the 'make install' of it fails for me after getting most of the way through. I suspect this is a build problem, not a cc problem. I was not able to compile XFree86-4-Server, as I ran into the same compiler error that Maxim reported. Or at least, it looked about the same. After that build failed, I happened to retry the same build (again with the patches Sheldon had recommended) after setting CPUTYPE=i686 in /etc/make.conf. This time the build succeeded, and I was able to install it. At that point I can start XDM, and everything seems fine until I try to log into XDM. At that point, my machine instantly reboots. I have no idea why, but I suspect that the incomplete 'make install' of XFree86-4-libraries probably does not help... It could easily be million other things, too. That's how much I had figured out as of 4am this morning... -- Garance Alistair Drosehn= [EMAIL PROTECTED] Senior Systems Programmer or [EMAIL PROTECTED] Rensselaer Polytechnic Instituteor [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: additional queue macro
Julian Elischer wrote: TAILQ_FOREACH_REMOVABLE or TAILQ_FOREACH_SAFE (I prefer the first) are my suggestions for the name.) TAILQ_FOREACH_MODIFY ? -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: additional queue macro
At 10:38 AM -0700 7/3/02, Terry Lambert wrote: Julian Elischer wrote: TAILQ_FOREACH_REMOVABLE or TAILQ_FOREACH_SAFE (I prefer the first) are my suggestions for the name.) TAILQ_FOREACH_MODIFY ? I sense great material for a bikeshed... :-) For mine, how about: TAILQ_FOREACH_VOLATILE -- Garance Alistair Drosehn= [EMAIL PROTECTED] Senior Systems Programmer or [EMAIL PROTECTED] Rensselaer Polytechnic Instituteor [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: gcc 3.1 can't compile XFree86-4-Server
On (2002/07/03 13:29), Garance A Drosihn wrote: With his patches I was able to compile and install imake. I was able to compile XFree86-4-libraries, but the 'make install' of it fails for me after getting most of the way through. I suspect this is a build problem, not a cc problem. Yes, remember that you're building the MATROX stuff, which I'm not. Also, remember that my patches were for the base system's toolchain, not lang/gcc31's. Ciao, Sheldon. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: gcc 3.1 can't compile XFree86-4-Server
At 8:07 PM +0200 7/3/02, Sheldon Hearn wrote: Yes, remember that you're building the MATROX stuff, which I'm not. Yes, I should have mentioned that. Is Maxim compiling the matrox drivers? Perhaps I should retry without those. Also, remember that my patches were for the base system's toolchain, not lang/gcc31's. Fwiw, I am also using the system toolchain (as cvsup'ed late last night), and not the port. -- Garance Alistair Drosehn= [EMAIL PROTECTED] Senior Systems Programmer or [EMAIL PROTECTED] Rensselaer Polytechnic Instituteor [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: About GEOM...
Bruce Evans wrote: On Wed, 3 Jul 2002, Poul-Henning Kamp wrote: In message [EMAIL PROTECTED], Mario Goebbels writes: And the second is, when will it be officially activated? Seems to work fine yet (toying around with it). Some bits are missing yet, for instance the ioctls to change disklabels etc. when they're done and it works also with sysinstall it'll be standard. It shouldn't be standard, because then using it wouldn't be optional. Are you kidding?!? That's why it *should* be standard! -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
panic at boot in ffs_valloc
I cvsup'd and built world+kernel a few hours ago and was happy to see KDE working again, but I got a spontaneous reboot while trying to track down a segfault in a mozilla build component. I boot -v'ed and as soon as the login prompt came up I hit a panic. I'm guessing the backgorund fsck had something to do with it. I'll hand-copy the trace here; any debugging info needed while my box is stuck at the debugger, lemme know: -- Anthony Jenkins Additional TCP options:. Starting background filesystem checks Wed Jul 3 13:24:09 EDT 2002 FreeBSD/i386 (foo) (ttyv0) login: mode = 041777, inum = 12871, fs = /usr panic: ffs_valloc: dup alloc cpuid = 0; lapic.id = Debugger(panic) Stopped at Debugger+0x46: xchgl %ebx,in_Debugger.0 db trace Debugger(c02d9eda) at Debugger+0x46 panic(c02e9a21,c02e9a00,43ff,3247,c41c58d4) at panic+0xd6 ffs_valloc(c4284100,8100,c159a180,d6afd6f0) at ffs_valloc+0x141 ufs_makeinode(8100,c4284100,d6afda20,d6afda34) at ufs_makeinode+0x58 ufs_create(d6afd94c,d6afda68,c0248a68,d6afd94c,c0346b78) at ufs_create+0x26 ufs_vnoperate(d6afd94c) at ufs_vnoperate+0x13 ffs_snapshot(c41b7600,80b2ba0,d6afda94,c41db700,c0346bf0) at ffs_snapshot+0x2a0 ffs_mount(c41b7600,c4421200,bfbffcc0,d6afdbf8,c159f300) at ffs_mount+0x48 vfs_mount(c159f300,c41b2eb0,c4421200,1211000,bfbffcc0) at ffs_mount+0x6dc mount(c159f300,d6afdd14,4,1,202) at mount+0x6a syscall(2f,2f,2f,0,bfbffde0) at syscall+0x23c syscall_with_err_pushed() at syscall_with_err_pushed+0x1b --- syscall (21, FreeBSD ELF, mount), eip = 0x80549d7, esp = 0xbfbffbdc, ebp = 0xbfbffd48 --- db -- Anthony Jenkins http://www.mindspring.com/~abjenkins/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: panic at boot in ffs_valloc
:I cvsup'd and built world+kernel a few hours ago and was happy to see :KDE working again, but I got a spontaneous reboot while trying to track :down a segfault in a mozilla build component. I boot -v'ed and as :soon as the login prompt came up I hit a panic. I'm guessing the :backgorund fsck had something to do with it. I'll hand-copy the trace :here; any debugging info needed while my box is stuck at the debugger, :lemme know: I don't have the output to show people since I was trying to reproduce but couldnt, but i got essentially the same panic, but it came only from a syscall to open() that called ufs_create() - ufs_makeinode - ffs_valloc() - panic. I can try and reproduce (tho, mine occured when just running cscope) and get a dump. Cheers, Andrew :FreeBSD/i386 (foo) (ttyv0) : :login: mode = 041777, inum = 12871, fs = /usr :panic: ffs_valloc: dup alloc :cpuid = 0; lapic.id = :Debugger(panic) :Stopped at Debugger+0x46: xchgl %ebx,in_Debugger.0 :db trace :Debugger(c02d9eda) at Debugger+0x46 :panic(c02e9a21,c02e9a00,43ff,3247,c41c58d4) at panic+0xd6 :ffs_valloc(c4284100,8100,c159a180,d6afd6f0) at ffs_valloc+0x141 :ufs_makeinode(8100,c4284100,d6afda20,d6afda34) at ufs_makeinode+0x58 :ufs_create(d6afd94c,d6afda68,c0248a68,d6afd94c,c0346b78) at ufs_create+0x26 :ufs_vnoperate(d6afd94c) at ufs_vnoperate+0x13 :ffs_snapshot(c41b7600,80b2ba0,d6afda94,c41db700,c0346bf0) at :ffs_snapshot+0x2a0 :ffs_mount(c41b7600,c4421200,bfbffcc0,d6afdbf8,c159f300) at ffs_mount+0x48 :vfs_mount(c159f300,c41b2eb0,c4421200,1211000,bfbffcc0) at ffs_mount+0x6dc :mount(c159f300,d6afdd14,4,1,202) at mount+0x6a :syscall(2f,2f,2f,0,bfbffde0) at syscall+0x23c :syscall_with_err_pushed() at syscall_with_err_pushed+0x1b :--- syscall (21, FreeBSD ELF, mount), eip = 0x80549d7, esp = 0xbfbffbdc, :ebp = 0xbfbffd48 --- :db : :-- :Anthony Jenkins :http://www.mindspring.com/~abjenkins/ : : : :To Unsubscribe: send mail to [EMAIL PROTECTED] :with unsubscribe freebsd-current in the body of the message : -- Andrew R. Reiter [EMAIL PROTECTED] [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: gcc 3.1 can't compile XFree86-4-Server
Hi,
On Wed, Jul 03, 2002 at 02:15:13PM -0400, Garance A Drosihn wrote:
Fwiw, I am also using the system toolchain (as cvsup'ed late last
night), and not the port.
I can build x11/XFree86-4 with the following patches, which I harvested
from various email's since the gcc 3.1 import. Which ones are really
needed, and why the X11 libraries are built four times during the build
of the meta port, are what I need to figure out next...
Stock -CURRENT just before KSE3, no relevant ports installed before the
build (only cvsup).
Regards,
-Jeremy
--
FreeBSD - Because the best things in life are free...
http://www.freebsd.org/
devel/imake-4:
Maintainer: [EMAIL PROTECTED]
Changes: Makefile
Adds : files/patch-config::cf::FreeBSD.cf files/patch-config::cf::bsdLib.tmpl
Removes: files/patch-d files/patch-xthreads
x11-servers/XFree86-4-Server:
Maintainer: [EMAIL PROTECTED]
Changes:
Adds : files/patch-GL_mesa_src_Imakefile files/patch-OSmesa-Imakefile
files/patch-gcc31
Removes:
x11/XFree86-4-libraries:
Maintainer: [EMAIL PROTECTED]
Changes: files/patch-UIThrStubs.c files/patch-z32 files/patch-z45
Adds : files/patch-bsdLib.rules
Removes:
--- /usr/ports.ref/devel/imake-4/Makefile Thu May 23 10:49:32 2002
+++ devel/imake-4/Makefile Tue Jul 2 00:32:01 2002
@@ -21,6 +21,7 @@
MAINTAINER=[EMAIL PROTECTED]
PREFIX?= ${X11BASE}
+USE_PERL5= yes
.include bsd.port.pre.mk
@@ -127,6 +128,10 @@
# It's a traditional place ;-)
# InstallXserverSetUID=NO : use Xwrapper.
# End of XFree86 configrations
+
+pre-patch:
+ @${PERL} -pi -e 's|\#\!/usr/bin/perl|\#\!${PERL}|g ' \
+ ${WRKSRC}/util/mkhtmlindex.pl
post-install:
@${MKHTMLINDEX} ${PREFIX}/lib/X11/doc/html
--- /usr/ports.ref/devel/imake-4/files/patch-config::cf::FreeBSD.cf Thu Jan 1
02:00:00 1970
+++ devel/imake-4/files/patch-config::cf::FreeBSD.cfWed Jun 26 22:38:58 2002
@@ -0,0 +1,34 @@
+--- cf/FreeBSD.cf.orig Wed Jun 26 15:44:29 2002
cf/FreeBSD.cf Wed Jun 26 16:21:18 2002
+@@ -80,7 +80,6 @@
+ /*
+ * math.h uses _REENTRANT and stdio.h uses _THREAD_SAFE, so define both.
+ */
+-# define SystemMTDefines -D_REENTRANT -D_THREAD_SAFE
+ /*
+ * FreeBSD has tread-safe api but no getpwnam_r yet.
+ */
+@@ -91,8 +90,13 @@
+ # else
+ # define BuildThreadStubLibrary YES
+ # define NeedUIThrStubs YES
+-# define ThreadsCompileFlags -pthread
+-# define ThreadsLibraries-pthread
++# if (OSRelVersion = 500016)
++# define SystemMTDefines-D_REENTRANT -D_THREAD_SAFE
++# define ThreadsLibraries -lc_r
++# else
++# define SystemMTDefines-D_REENTRANT -D_THREAD_SAFE
++# define ThreadsLibraries -pthread
++# endif
+ # define SharedX11Reqs $(LDPRELIB) $(XTHRSTUBLIB)
+ # define SharedXtReqs$(LDPRELIB) $(XLIBONLY) $(SMLIB) $(ICELIB)
+$(XTHRSTUBLIB)
+ # endif
+@@ -151,6 +154,7 @@
+ # define CcCmdcc
+ # define CplusplusCmd c++
+ #endif
++#define CplusplusLibC -lstdc++
+
+ #define CppCmd/usr/bin/cpp
+ #define PreProcessCmd CppCmd
--- /usr/ports.ref/devel/imake-4/files/patch-config::cf::bsdLib.tmplThu Jan 1
02:00:00 1970
+++ devel/imake-4/files/patch-config::cf::bsdLib.tmpl Wed Jun 26 22:38:18 2002
@@ -0,0 +1,13 @@
+--- cf/bsdLib.tmpl.origWed Jun 26 16:19:42 2002
cf/bsdLib.tmpl Wed Jun 26 16:20:34 2002
+@@ -39,7 +39,9 @@
+ #define XawClientLibs $(XAWLIB) $(XMULIBONLY) $(XTOOLLIB) $(XPMLIB) $(XLIB)
+ #endif
+
+-#define CplusplusLibC
++#ifndef CplusplusLibC
++#define CplusplusLibC $(CXX)
++#endif
+ #define FrescoSysLibs CplusplusLibC MathLibrary
+
+ /* Allow for libpthread, as overridden by OS definitions */
--- /usr/ports.ref/devel/imake-4/files/patch-d Tue Jun 12 16:59:11 2001
+++ devel/imake-4/files/patch-d Wed Jun 26 22:01:35 2002
@@ -1,19 +0,0 @@
cf/FreeBSD.cf.orig Fri May 4 05:12:35 2001
-+++ cf/FreeBSD.cf Mon Jun 4 19:31:27 2001
-@@ -444,14 +444,14 @@
- /* The GCC strength-reduce bug is fixed for FreeBSD 2.1.5 and later */
- #ifndef DefaultGcc2i386Opt
- #if OSMajorVersion 2 || (OSMajorVersion == 2 OSMinorVersion 1) ||
(OSMajorVersion == 2 OSMinorVersion == 1 OSTeenyVersion = 5)
--#define DefaultGcc2i386Opt -O2
-+#define DefaultGcc2i386Opt
- #endif
- #endif
-
- #ifdef i386Architecture
- # define OptimizedCDebugFlags DefaultGcc2i386Opt
- #else
--# define OptimizedCDebugFlags -O
-+# define OptimizedCDebugFlags
- #endif
-
- #ifndef PreIncDir
--- /usr/ports.ref/devel/imake-4/files/patch-xthreads Tue Jun 12 16:59:11 2001
+++ devel/imake-4/files/patch-xthreads Wed Jun 26 22:02:08 2002
@@ -1,25 +0,0 @@
cf/FreeBSD.cf.orig Thu Jun 7 16:25:47 2001
-+++ cf/FreeBSD.cf Thu Jun 7 16:28:30 2001
-@@ -80,7 +80,6 @@
- /*
- * math.h uses _REENTRANT and stdio.h uses _THREAD_SAFE, so define both.
- */
--# define
Re: what does it take to rsh as root now days?
David O'Brien [EMAIL PROTECTED] wrote: I can rlogin to a -CURRENT box as root. However `rsh box id' comes back with: Jul 3 00:11:33 box rshd[4916]: root@dragon as rootk: permission denied (authentication error). cmd='id' man pam_rhosts should explain that. -- cheers, Jorg .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: panic at boot in ffs_valloc
I'm also suddenly having a panics - every 5 minutes actually, since my latest cvsup a few hours ago. They seem to be related to some ufs and ffs calls.. I'm not able to read my core dumps for some reason (gdb says kernel symbol 'cpuhead' not found.) and I don't have the time to scratch a backtrace down by hand just now. The panicstring is: bremfree: bp 0xc77e8670 not locked Sincerely, Rasmus Skaasrup On Wed, 3 Jul 2002, Andrew R. Reiter wrote: :I cvsup'd and built world+kernel a few hours ago and was happy to see :KDE working again, but I got a spontaneous reboot while trying to track :down a segfault in a mozilla build component. I boot -v'ed and as :soon as the login prompt came up I hit a panic. I'm guessing the :backgorund fsck had something to do with it. I'll hand-copy the trace :here; any debugging info needed while my box is stuck at the debugger, :lemme know: I don't have the output to show people since I was trying to reproduce but couldnt, but i got essentially the same panic, but it came only from a syscall to open() that called ufs_create() - ufs_makeinode - ffs_valloc() - panic. I can try and reproduce (tho, mine occured when just running cscope) and get a dump. Cheers, Andrew :FreeBSD/i386 (foo) (ttyv0) : :login: mode = 041777, inum = 12871, fs = /usr :panic: ffs_valloc: dup alloc :cpuid = 0; lapic.id = :Debugger(panic) :Stopped at Debugger+0x46: xchgl %ebx,in_Debugger.0 :db trace :Debugger(c02d9eda) at Debugger+0x46 :panic(c02e9a21,c02e9a00,43ff,3247,c41c58d4) at panic+0xd6 :ffs_valloc(c4284100,8100,c159a180,d6afd6f0) at ffs_valloc+0x141 :ufs_makeinode(8100,c4284100,d6afda20,d6afda34) at ufs_makeinode+0x58 :ufs_create(d6afd94c,d6afda68,c0248a68,d6afd94c,c0346b78) at ufs_create+0x26 :ufs_vnoperate(d6afd94c) at ufs_vnoperate+0x13 :ffs_snapshot(c41b7600,80b2ba0,d6afda94,c41db700,c0346bf0) at :ffs_snapshot+0x2a0 :ffs_mount(c41b7600,c4421200,bfbffcc0,d6afdbf8,c159f300) at ffs_mount+0x48 :vfs_mount(c159f300,c41b2eb0,c4421200,1211000,bfbffcc0) at ffs_mount+0x6dc :mount(c159f300,d6afdd14,4,1,202) at mount+0x6a :syscall(2f,2f,2f,0,bfbffde0) at syscall+0x23c :syscall_with_err_pushed() at syscall_with_err_pushed+0x1b :--- syscall (21, FreeBSD ELF, mount), eip = 0x80549d7, esp = 0xbfbffbdc, :ebp = 0xbfbffd48 --- :db : :-- :Anthony Jenkins :http://www.mindspring.com/~abjenkins/ : : : :To Unsubscribe: send mail to [EMAIL PROTECTED] :with unsubscribe freebsd-current in the body of the message : -- Andrew R. Reiter [EMAIL PROTECTED] [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
KSE /VM question
Unfortunatly thre is a codepath in the KSE system that has not
been tested, due to a bug in the UVM system. Jeff fixed the UVM
problem for me ysesterday but that means that the following
stack trace (representing the code path in question) is now
used and teh resulting panic happens...
Is there a VM expert here that understands the mapping system who I can
tap to help me figure out what I did wrong..
This is a clasic case of one bug hiding another..
Debugger(c030265c) at Debugger+0x45
panic(c0328ee0,1d,1,c0b889d8,1) at panic+0x74
vm_page_free_toq(c0b889d8,c0b889d8,40,c0b889d8,cca32c14) at
vm_page_free_toq+0xd0
vm_page_free(c0b889d8,c0b889d8,0) at vm_page_free+0x15
pmap_dispose_thread(c2a25000,cca32c4c,c02b2fed,c2a25000,b8) at
pmap_dispose_thread+0x84
thread_fini(c2a25000,b8) at thread_fini+0x28
zone_drain(c0ede000) at zone_drain+0x29d
zone_foreach(c02b2d50,cca32d08,c02b0924,c03542c0,1) at zone_foreach+0x2f
uma_reclaim(c03542c0,1,c03296c2,287,c03542c0) at uma_reclaim+0x12
vm_pageout_scan(0,c1cf10c0,cca32d34,c019066c,0) at vm_pageout_scan+0x30
vm_pageout(0,cca32d48,c1cf10c0,c02b13f4,0) at vm_pageout+0x22d
fork_exit(c02b13f4,0,cca32d48) at fork_exit+0xd8
fork_trampoline() at fork_trampoline+0x37
db gdb
Next trap will enter GDB remote protocol mode
db s
Stopped at Debugger+0x4e: leave
db x/s 0xc0328ee0
vm_object_print_pages_cmd+0x3c4:vm_page_free: invalid wire count
(%d), pindex: 0x%lx
if (m-wire_count != 0) {
if (m-wire_count 1) {
panic(vm_page_free: invalid wire count (%d),
pindex: 0x%lx,
m-wire_count, (long)m-pindex);
}
panic(vm_page_free: freeing wired page\n);
}
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: KSE status report
You were possibly on the right track but we got the answer already :-) there was a debug statement left in queue.h that was breaking some of the queues in libc_r possibly where the thread was taken off the run queue. Now the very important thing is that you keep looking and hacking :-) Looks like I'm out of this one, I got up this morning, cvsup'd and built world just to make sure it was fresh, then I quit getting the crashes. I d'no if the issue was fixed by something someone else did or what... - -Erik [EMAIL PROTECTED] [http://math.smsu.edu/~erik] The opinions expressed by me are not necessarily opinions. In all probability, they are random rambling, and to be ignored. Failure to ignore may result in severe boredom or confusion. Shake well before opening. Keep Refrigerated. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: gcc 3.1 can't compile XFree86-4-Server
On Wed, Jul 03, 2002 at 08:56:02PM +0200, Jeremy Lea wrote: I can build x11/XFree86-4 with the following patches, which I harvested from various email's since the gcc 3.1 import. Which ones are really needed, and why the X11 libraries are built four times during the build of the meta port, are what I need to figure out next... Some one needs to do thru these and really deal with them. * The patch to use -O0 (or remove -O) is wrong, and a test case should be submitted to the GCC people. * The weak problem has been fixed in the FSF sources -- I could merge a a patch to our system GCC from the FSF sources. * Someone needs to talk with the XFree86 people to get them to stop using `cc' on C++ code. This is not just a FreeBSD issue for them. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: KSE status report
On Wed, 3 Jul 2002, Erik Greenwald wrote: Looks like I'm out of this one, I got up this morning, cvsup'd and built world just to make sure it was fresh, then I quit getting the crashes. I d'no if the issue was fixed by something someone else did or what... It was solved, but thanks for trying and welcome to the club of people willing to get their fingers dirty :-) To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: gcc 3.1 can't compile XFree86-4-Server
Hi,
On Wed, Jul 03, 2002 at 01:10:08PM -0700, David O'Brien wrote:
Some one needs to do thru these and really deal with them.
I didn't say they were right, just that they worked ;-)
* The patch to use -O0 (or remove -O) is wrong, and a test case should be
submitted to the GCC people.
I think Maxim has already done this.
* The weak problem has been fixed in the FSF sources -- I could merge a
a patch to our system GCC from the FSF sources.
Please, unless we are due for a complete upgrade soon... Do you know
when 3.1.1 is due?
* Someone needs to talk with the XFree86 people to get them to stop using
`cc' on C++ code. This is not just a FreeBSD issue for them.
They don't. They have all of the right macros in place, it's just that
we didn't have a macro defined for C++ shared libraries. I don't think
we're doing the right thing for the static library cases yet.
At the moment I'm trying to go through all of the XFree86-4 ports and
figure out:
1. What the patches actually do...
2. If we can use one shared ${WRKSRC}, since the ports build multiple
copies of all of the libraries, and they use the wrong (unpatched)
versions of the config files in some cases.
Regards,
-Jeremy
--
FreeBSD - Because the best things in life are free...
http://www.freebsd.org/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: gcc 3.1 can't compile XFree86-4-Server
Jeremy Lea [EMAIL PROTECTED] writes:
1. What the patches actually do...
2. If we can use one shared ${WRKSRC}, since the ports build multiple
copies of all of the libraries, and they use the wrong (unpatched)
versions of the config files in some cases.
While you're at it:
Index: FreeBSD.cf
===
RCS file: /sec/xfree86/cvs/xc/config/cf/FreeBSD.cf,v
retrieving revision 3.116
diff -u -r3.116 FreeBSD.cf
--- FreeBSD.cf 4 Jun 2002 22:50:55 - 3.116
+++ FreeBSD.cf 3 Jul 2002 21:19:14 -
@@ -48,6 +48,7 @@
#define HasSnprintfYES
#define HasBSD44SocketsYES
#define HasDlopen YES
+#define HasSetProcTitleYES
#ifndef HasLibCrypt
# define HasLibCrypt YES
#endif
There may be more stuff missing, look through NetBSD.cf and OpenBSD.cf
to see what they have that we don't.
DES
--
Dag-Erling Smorgrav - [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: ASUS CUSL2 panic on acpi
Here's a me too.. running on an ASUS A7V266-E Fatal trap 12: page fault while in kernel mode fault virtual address = 0x16 fault code = supervisor read, page not present instruction pointer = 0x8:0xc04f9aca stack pointer = 0x10:0xc054ea14 frame pointer = 0x10:0xc054ea34 code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags= interrupt enabled, resume, IOPL = 0 current process = 0 (swapper) kernel: type 12 trap, code=0 Stopped at AcpiExReadDataFromField+0x5a: movzbl 0x16(%eax),%eax I had a movb 0x16(%eax),%al db trace AcpiExReadDataFromField(c0f00400,c25da200,c054ea50,c25e50c0,0) at AcpiExReadDataFromField+0x5a With ACPI disabled (hint.acpi.0.disable=1) the kernel runs without a problem. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: About GEOM...
On Wed, Jul 03, 2002 at 11:59:47AM +0200, Poul-Henning Kamp wrote: In message [EMAIL PROTECTED], Jul ian Elischer writes: aren't you suppost to be honeymooning from yesterday? I am, I'm not working, only doing things I do for fun :-) Like reading Linux source code? ducks for cover 8-) -- | / o / /_ _ FreeBSD core team secretary |/|/ / / /( (_) Bulte [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: additional queue macro
On Wed, 3 Jul 2002, Neal Fachan wrote: We've got local changes (which I've attached) where the name is *_FOREACH_REMOVE. We didn't add reverse removable iterators. Also, the temp variable is the second argument. I can't think of a way of doing it without having the externally declare the temporary variable. A I like it and you've even done thge man page.. *_FOREACH_REMOVE however suggests that it is going to try remove something.. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: gcc 3.1 can't compile XFree86-4-Server
On Wed, Jul 03, 2002 at 08:08:28PM +0300, Maxim Sobolev wrote:
In file included from translate.c:779:
../../../../extras/Mesa/src/trans_tmp.h: In function `trans_1_GLdouble_1ub_elt':
../../../../extras/Mesa/src/trans_tmp.h:124: could not find a spill register
(insn 96 94 97 (set (subreg:SF (reg:QI 75) 0)
(plus:SF (reg:SF 8 st(0) [76])
(reg:SF 9 st(1) [80]))) 525 {*fop_sf_comm_nosse} (insn_list 87 (nil)
)
(expr_list:REG_DEAD (reg:SF 8 st(0) [76])
(nil)))
../../../../extras/Mesa/src/trans_tmp.h:124: Internal compiler error in failed_r
eload, at reload1.c:5050
Please submit a full bug report,
with preprocessed source if appropriate.
See URL:http://www.gnu.org/software/gcc/bugs.html for instructions.
*** Error code 1
...
Please investigate fix.
Ok, ok, fixed. Please stop CC'ing me on GCC bug reports. :-)
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: KSE status report
On Wednesday, July 3, 2002, at 04:13 PM, Julian Elischer wrote: On Wed, 3 Jul 2002, Erik Greenwald wrote: Looks like I'm out of this one, I got up this morning, cvsup'd and built world just to make sure it was fresh, then I quit getting the crashes. I d'no if the issue was fixed by something someone else did or what... It was solved, but thanks for trying and welcome to the club of people willing to get their fingers dirty :-) Well, I feel cheated. Damn thing never crashed on me. :-) (pushes harder) Cheers, Jerry Hicks [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: KSE status report
hey don't give up yet.. there's still a couple of crashing bugs hiding in there you could have your chance yet.. On Wed, 3 Jul 2002, W Gerald Hicks wrote: On Wednesday, July 3, 2002, at 04:13 PM, Julian Elischer wrote: On Wed, 3 Jul 2002, Erik Greenwald wrote: Looks like I'm out of this one, I got up this morning, cvsup'd and built world just to make sure it was fresh, then I quit getting the crashes. I d'no if the issue was fixed by something someone else did or what... It was solved, but thanks for trying and welcome to the club of people willing to get their fingers dirty :-) Well, I feel cheated. Damn thing never crashed on me. :-) (pushes harder) Cheers, Jerry Hicks [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
panic: vm_page_free: freeing wired page
Julian,
You may have fixed over the last few, but I haven't
had a chance to cvsup new sources.
--
Steve
http://troutmask.apl.washington.edu/~kargl/
panic: vm_page_free: freeing wired page
panic: from debugger
Uptime: 39m56s
Dumping 128 MB
16 32 48 64 80 96 112
---
#0 0xc019c5cb in doadump ()
(kgdb) bt
#0 0xc019c5cb in doadump ()
#1 0xc019caa8 in boot (howto=260)
#2 0xc019ccab in panic ()
#3 0xc01369e2 in db_panic ()
#4 0xc0136971 in db_command (last_cmdp=0xc02cc800, cmd_table=0xc02cc620,
aux_cmd_tablep=0xc02c5ff4, aux_cmd_tablep_end=0xc02c5ff8)
#5 0xc0136a68 in db_command_loop ()
#6 0xc01394b8 in db_trap (type=3, code=0) at /usr/src/sys/ddb/db_trap.c:76
#7 0xc026d2a0 in kdb_trap (type=3, code=0, regs=0xcaeefb18)
at /usr/src/sys/i386/i386/db_interface.c:214
#8 0xc027cb34 in trap (frame=
{tf_fs = 24, tf_es = 16, tf_ds = 16, tf_edi = -880287744, tf_esi = 256, tf_ebp =
-890307740, tf_isp = -890307772, tf_ebx = 0, tf_edx = 0, tf_ecx = -890308068, tf_eax =
18, tf_trapno = 3, tf_err = 0, tf_eip = -1071196883, tf_cs = 8, tf_eflags = 662,
tf_esp = -1070861153, tf_ss = -1070963908})
at /usr/src/sys/i386/i386/trap.c:667
#9 0xc026d52d in Debugger (msg=0xc02a633c panic)
#10 0xc019cc94 in panic (fmt=0xc02b8ba0 vm_page_free: freeing wired page\n)
#11 0xc024a5e1 in vm_page_free_toq (m=0xc09eb7c0)
#12 0xc0249c34 in vm_page_free (m=0xc09eb7c0)
#13 0xc0278885 in pmap_dispose_thread (td=0xc1e1)
#14 0xc01a6be3 in thread_fini (mem=0xc1e1, size=184)
#15 0xc024f985 in zone_drain (zone=0xc0bb9000)
#16 0xc02504b5 in zone_foreach (zfunc=0xc024f6b0 zone_drain)
#17 0xc02517a7 in uma_reclaim ()
#18 0xc024cc41 in vm_pageout_scan (pass=0)
#19 0xc024da52 in vm_pageout ()
#20 0xc01897dc in fork_exit (callout=0xc024d7f0 vm_pageout, arg=0x0,
frame=0xcaeefd48)
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Recommended MP development machines...
Hi, I know everyone says they all work but i'd like some recommendations on MP machines for -CURRENT work. I'll be ordering one this week. Thanks, George -- George V. Neville-Neil [EMAIL PROTECTED] Neville-Neil Consulting www.neville-neil.com I learn only to be contented. inscription at Ryoan-ji in Kyoto, Japan To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Recommended MP development machines...
* George V. Neville-Neil [EMAIL PROTECTED] [020703 19:43] wrote: Hi, I know everyone says they all work but i'd like some recommendations on MP machines for -CURRENT work. I'll be ordering one this week. I got a dual AMD 1900 from monarchcomputer.com, it was pretty decently priced at the time and they seem to have decent service. -Alfred To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Recommended MP development machines...
On Wed, Jul 03, 2002 at 07:43:22PM -0700, George V. Neville-Neil wrote: I know everyone says they all work but i'd like some recommendations on MP machines for -CURRENT work. I'll be ordering one this week. There is but _1_ dual system to get -- Tyan Thunder K7 (code name Guinness). http://www.tyan.com/products/html/thunderk7.html. It comes in multiple flavors, but mine is the dual-channel Ultra160, dual-3com 10/100, 5-64bit PCI, 1 AGP version. You can cheap out and not get the non-SCSI S2462NG model. Match this bad-boy up with a pair of fast Athlon `MP' (not `XP') CPU's and it is a totally solid system. Various FreeBSD committers also have this system. There is a newer [more economic] version called the Thunder K7X. http://www.tyan.com/products/html/thunderk7x.html To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Recommended MP development machines...
On Wed, Jul 03, 2002 at 11:50:00PM -0400, Chuck Robey wrote: (2) a fixed onboard usb port. The K7 had a broken on-board usb (the AMD chipset had a PCI contention bug for the usb port, so the tin back panel of the board blocked out the usb, and the K7 came with a PCI usb card, which ate up one of your PCI slots. Strange, my UCB works. I don't have a back panel (was an early release mobo), but I have used a USB Zip drive with this mobo. I haven't been able to get my USB printer working; but that seemed more due to our USB support than hardware. I think the K7 had only AGP; the K7X has AGP-Pro; doesn't mean much yet, but if you're a gaming maven, maybe it'll be important pretty quickly now. Mine has AGP-pro. Not saying the K7X isn't better. Just that maybe the Thunder K7 isn't so bad. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
error in /usr/src/gnu/usr.bin/binutils/doc/
Sources checked out today, 3AM EST. makeinfo --no-validate -I /usr/src/gnu/usr.bin/binutils/doc/../../../../contrib/binutils/gas/doc -I /usr/src/gnu/usr.bin/binutils/doc/../../../../contrib/binutils/ld -I /usr/src/gnu/usr.bin/binutils/doc/../../../../contrib/binutils/bfd/doc -I /usr/src/gnu/usr.bin/binutils/doc/../../../../contrib/binutils/binutils -I /usr/src/gnu/usr.bin/binutils/doc/../../../../contrib/gdb/gdb/doc -I /usr/src/gnu/usr.bin/binutils/doc/../../../../contrib/gdb/gdb/mi -I /usr/src/gnu/usr.bin/binutils/doc/../../../../contrib/libreadline/doc --no-split -I /usr/src/gnu/usr.bin/binutils/doc -I /usr/src/gnu/usr.bin/binutils/doc/../../../../contrib/binutils /usr/src/gnu/usr.bin/binutils/doc/../../../../contrib/binutils/binutils/binutils.texi -o binutils.info ln -sf /usr/src/gnu/usr.bin/binutils/doc/../../../../contrib/gdb/gdb/doc/all-cfg.texi gdb-cfg.texi echo @set GDBVN `sed q /usr/src/gnu/usr.bin/binutils/doc/../../../../contrib/gdb/gdb/version.in` GDBvn.texi cp /usr/src/gnu/usr.bin/binutils/doc/../../../../contrib/libreadline/doc/hsuser.texinfo inc-hist.texinfo patch -b .orig /usr/src/gnu/usr.bin/binutils/doc/inc-hist.diff makeinfo: Removing output file `gdbint.info' due to errors; use --force to preserve. *** Error code 2 Hmm... Looks like a unified diff to me... The text leading up to this was: -- |$FreeBSD: src/gnu/usr.bin/binutils/doc/inc-hist.diff,v 1.4 2002/07/01 07:58:18 sheldonh Exp $ | |--- inc-hist.texinfo.orig Wed Apr 11 08:20:01 2001 |+++ inc-hist.texinfo Wed Apr 11 08:21:57 2001 -- Patching file inc-hist.texinfo using Plan A... Hunk #1 succeeded at 26. Hunk #2 succeeded at 39. done 1 error *** Error code 2 1 error *** Error code 2 1 error *** Error code 2 1 error *** Error code 2 1 error *** Error code 2 1 error *** Error code 2 1 error Doing a simple 'make' in the directory is fine, so I guess the buildworld is pulling different stunts. I'd make the effort to track it, but I'm too tired, maybe someone else will catch it in the morning or so. -- Munish Chopra The FreeBSD NVIDIA Driver Initiative http://nvidia.netexplorer.org To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
