Re: GNATS reply?
Michael Lucas wrote: Hello, Shouldn't I get a response email from [EMAIL PROTECTED]? Or is this a casualty of the mail breakage? Would I be better of using the web form, or just waiting until after Linuxworld? Web interface isn't working either. I've got following when tried to submit PR: -Maxim To: [EMAIL PROTECTED] Subject: Mailing list search engine at www.freebsd.org down for repair. Date: Thu, 03 Feb 2000 01:18:59 -0800 Message-ID: [EMAIL PROTECTED] From: "Jordan K. Hubbard" [EMAIL PROTECTED] Hi all, Our primary mail server, using the special type of evil ESP abilities which all critical hardware items possess, took advantage of everyone (including our postmaster) being away at LinuxWorld in New York to exhibit the "F" in "MTBF" with respect to hard drive specifications. We have mail services running again on a backup system but it will take a little while longer until all other mail-related services (like web search) are restored. We apologize for the inconvenience and hope to have this problem fixed shortly. A situation almost exactly like this (disk hardware failure) occurred with freefall during FreeBSDCon '99, incidently, and with this second incident we've certainly gotten the message: All critical freebsd.org assets will use (hardware) RAID arrays for storage in the future and we'll begin implementing that just as soon as we return. Regards, - Jordan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
[HEADS UP] xinstall/setflags (was Re: cvs commit: src/share/mk bsd.lib.mk)
On Fri, Feb 04, 2000 at 11:40:34AM +0200, Ruslan Ermilov wrote:
Might I advice some more time before we actually do something?
What's all this rush-it-in before anyone can actually fix the larger
problem?
I'm positive about this as well.
The main reason for the backout isn't the xinstall problem, as this
is a non-problem (it only affects a small window of -current users).
The reason for adopting a fall back solution it that it is not clear that
setflags/getflags is the best choice of function name for manipulating
file flags as it's a bit too generic a name. Whilst we're debating
this point there's no point in having them as library calls for
4.0. We can return to this point later, maybe when someone else
wants to use them in another tool. On the way, we'll fix the xinstall
problem and give you guys time and space to work the build/install glue
post 4.0. There's no need to rush a fix in.
I'm going to wait until tomorrow evening to commit this so that
everyone gets a chance to read this and understand what's going
on. (That's 24 - 36 hours from now.)
The patch is included as an attachement.
Joe
--
Josef KarthauserFreeBSD: Take the red pill and we'll show you just how
Technical Manager deep the rabbit hole goes. (http://www.uk.freebsd.org)
Pavilion Internet plc. [[EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED]]
Index: bin/ls/Makefile
===
RCS file: /home/ncvs/src/bin/ls/Makefile,v
retrieving revision 1.8
diff -u -r1.8 Makefile
--- bin/ls/Makefile 2000/01/27 21:16:49 1.8
+++ bin/ls/Makefile 2000/02/04 10:42:18
@@ -3,6 +3,7 @@
PROG= ls
-SRCS= cmp.c ls.c print.c util.c
+SRCS= cmp.c setflags.c ls.c print.c util.c
+.PATH: ${.CURDIR}/../../lib/libc/gen
.include bsd.prog.mk
Index: bin/ls/ls.c
===
RCS file: /home/ncvs/src/bin/ls/ls.c,v
retrieving revision 1.31
diff -u -r1.31 ls.c
--- bin/ls/ls.c 2000/01/27 21:16:49 1.31
+++ bin/ls/ls.c 2000/02/04 10:42:18
@@ -74,6 +74,8 @@
*/
#defineSTRBUF_SIZEOF(t)(1 + CHAR_BIT * sizeof(t) / 3 + 1)
+extern char *getflags __P((u_long, char *));
+
static void display __P((FTSENT *, FTSENT *));
static u_quad_t makenines __P((u_long));
static int mastercmp __P((const FTSENT **, const FTSENT **));
Index: bin/rm/Makefile
===
RCS file: /home/ncvs/src/bin/rm/Makefile,v
retrieving revision 1.11
diff -u -r1.11 Makefile
--- bin/rm/Makefile 2000/01/27 21:16:50 1.11
+++ bin/rm/Makefile 2000/02/04 10:42:18
@@ -2,8 +2,10 @@
# $FreeBSD: src/bin/rm/Makefile,v 1.11 2000/01/27 21:16:50 joe Exp $
PROG= rm
+SRCS= rm.c setflags.c
LINKS= ${BINDIR}/rm ${BINDIR}/unlink
MLINKS=rm.1 unlink.1
+.PATH: ${.CURDIR}/../../lib/libc/gen
.include bsd.prog.mk
Index: bin/rm/rm.c
===
RCS file: /home/ncvs/src/bin/rm/rm.c,v
retrieving revision 1.28
diff -u -r1.28 rm.c
--- bin/rm/rm.c 2000/01/27 21:16:50 1.28
+++ bin/rm/rm.c 2000/02/04 10:42:18
@@ -61,6 +61,8 @@
#include sysexits.h
#include unistd.h
+extern char *getflags __P((u_long, char *));
+
int dflag, eval, fflag, iflag, Pflag, vflag, Wflag, stdin_ok;
uid_t uid;
Index: include/unistd.h
===
RCS file: /home/ncvs/src/include/unistd.h,v
retrieving revision 1.34
diff -u -r1.34 unistd.h
--- include/unistd.h2000/02/01 15:55:52 1.34
+++ include/unistd.h2000/02/04 10:42:18
@@ -134,7 +134,6 @@
#endif
int getdomainname __P((char *, int));
int getdtablesize __P((void));
-char *getflags __P((u_long, char *));
int getgrouplist __P((const char *, int, int *, int *));
longgethostid __P((void));
int gethostname __P((char *, int));
@@ -182,7 +181,6 @@
int setdomainname __P((const char *, int));
int setegid __P((gid_t));
int seteuid __P((uid_t));
-int setflags __P((char **, u_long *, u_long *));
int setgroups __P((int, const gid_t *));
voidsethostid __P((long));
int sethostname __P((const char *, int));
Index: lib/libc/gen/Makefile.inc
===
RCS file: /home/ncvs/src/lib/libc/gen/Makefile.inc,v
retrieving revision 1.61
diff -u -r1.61 Makefile.inc
--- lib/libc/gen/Makefile.inc 2000/01/28 07:14:52 1.61
+++ lib/libc/gen/Makefile.inc 2000/02/04 10:42:20
@@ -20,7 +20,7 @@
nlist.c nrand48.c ntp_gettime.c opendir.c \
pause.c popen.c psignal.c pwcache.c raise.c readdir.c rewinddir.c \
scandir.c seed48.c seekdir.c semconfig.c semctl.c semget.c semop.c \
- setdomainname.c setflags.c sethostname.c setjmperr.c setmode.c shmat.c \
+ setdomainname.c sethostname.c setjmperr.c setmode.c shmat.c \
shmctl.c shmdt.c shmget.c siginterrupt.c
Re: libcrypto (DES - MD5)
On Thu, Feb 03, 2000 at 10:09:22AM -0800, Kris Kennaway wrote: AFAIK this has always been the way it works: if you install libdescrypt, the system makes the (mistaken) assumption you want DES passwords all the time. This is true for the initial installation. However, `make world' used to respect the an existing symlink. src/secure/lib/libcrypt/Makefile shows this intention. -- -- David([EMAIL PROTECTED]) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: libcrypto (DES - MD5)
On Thu, Feb 03, 2000 at 10:09:22AM -0800, Kris Kennaway wrote: a proper fix might be to add a login class which determines which of MD5 and DES you should use for new passwords I believe PAM is the more "approved" way to implement this functionality. Before PAM it would be /etc/auth.conf. I wanted to add this functionality over a year ago, but Markm asked me to wait for PAM and that he was working on an implementation using that. -- -- David([EMAIL PROTECTED]) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: libcrypto (DES - MD5)
AFAIK this has always been the way it works: if you install libdescrypt, the system makes the (mistaken) assumption you want DES passwords all the time. This is true for the initial installation. However, `make world' used to respect the an existing symlink. src/secure/lib/libcrypt/Makefile shows this intention. Except at some stage a nasty afterinstall target crept in there. :-/ John -- John Hay -- [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Upgrading 3.4 to 4.0
I've pulled a cvsup update on my 3.4-STABLE machine, and deleted /usr/obj to start afresh. I get the following performing a make upgrade however: [cut] === ranlib sh /usr/src/tools/install.sh -c -s -o root -g wheel -m 555 ranlib /usr/obj/aout/usr/src/i386/usr/libexec/elf === size sh /usr/src/tools/install.sh -c -s -o root -g wheel -m 555 size /usr/obj/aout/usr/src/i386/usr/libexec/elf === strings sh /usr/src/tools/install.sh -c -s -o root -g wheel -m 555 strings /usr/obj/aout/usr/src/i386/usr/libexec/elf === strip sh /usr/src/tools/install.sh -c -o root -g wheel -m 555 maybe_stripped /usr/obj/aout/usr/src/i386/usr/libexec/elf/strip install: mkstemp: /usr/obj/aout/usr/src/i386/usr/libexec/elf/INS@5346 for /usr/obj/aout/usr/src/i386/usr/libexec/elf/strip: Not a directory *** Error code 71 Stop. *** Error code 1 Stop. *** Error code 1 Stop. *** Error code 1 Stop. *** Error code 1 Stop. *** Error code 1 Any ideas? Joe -- Josef KarthauserFreeBSD: Take the red pill and we'll show you just how Technical Manager deep the rabbit hole goes. (http://www.uk.freebsd.org) Pavilion Internet plc. [[EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED]] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Upgrading 3.4 to 4.0
On Fri, 4 Feb 2000, Josef Karthauser wrote: I've pulled a cvsup update on my 3.4-STABLE machine, and deleted /usr/obj to start afresh. I get the following performing a make upgrade however: From /usr/src/Makefile: # upgrade - Upgrade a.out (2.2.x/3.0) system to the new ELF way and is probably not what you want. 3.x - 4.0 is built through the normal 'make world' mechanisms, with the caviats explained in /usr/src/UPDATING - Chris D. Faulhaber - [EMAIL PROTECTED] - [EMAIL PROTECTED] FreeBSD: 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
Unknown panic in yesterday's -current
Hi everyone, I just had a strange panic with yesterday's current: FreeBSD relativity.student.utwente.nl 4.0-CURRENT FreeBSD 4.0-CURRENT #0: Fri Jan 28 16:15:13 CET 2000 root@:/usr/src/sys/compile/RELATIVITY5 i386 A backtrace seems impossible (but I'm inexperienced with kgdb and I'm also currently at work): djb@relativity:RELATIVITY5# gdb -k kernel /var/crash/vmcore.2 GNU gdb 4.18 Copyright 1998 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-unknown-freebsd"... (no debugging symbols found)... SMP -1071755716 cpus IdlePTD 146061567 initial pcb at 291320 panic messages: --- dmesg: cannot read PTD --- cannot read proc pointer at ff84 (kgdb) bt #0 0x0 in ?? () (kgdb) where #0 0x0 in ?? () (kgdb) up No stack. (kgdb) The number of cpu's is supposed to be 2. If some more experienced/enlightened individual wishes to look into this, I have the crashdump on my system and I can provide (ssh) access. Please contact me. The panic seems to have been triggered by the killall command (executed as a user). Regards, Dave Boers. -- Dave Boers djb @ relativity . student . utwente . nl Don't let your schooling interfere with your education. (Mark Twain) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: libcrypto (DES - MD5)
On Thu, Feb 03, 2000 at 10:09:22AM -0800, Kris Kennaway wrote: a proper fix might be to add a login class which determines which of MD5 and DES you should use for new passwords I believe PAM is the more "approved" way to implement this functionality. Before PAM it would be /etc/auth.conf. I wanted to add this functionality over a year ago, but Markm asked me to wait for PAM and that he was working on an implementation using that. You want to work on PAM's, go ahead! M -- Mark Murray Join the anti-SPAM movement: http://www.cauce.org To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: [HEADS UP] xinstall/setflags (was Re: cvs commit: src/share/mk bsd.lib.mk)
Josef Karthauser wrote:
The reason for adopting a fall back solution it that it is not clear that
setflags/getflags is the best choice of function name for manipulating
file flags as it's a bit too generic a name. Whilst we're debating
this point there's no point in having them as library calls for
4.0.
Agreed. When {g|s}etflags is in libc for 4.0-RELEASE, we can't remove
(or rename) them later without bumping libc's version number, because
it basicly is an (backward) incompatible interface change. If there's
a remote change that the functions are to be removed or renamed, we
should make sure it's done before -RELEASE.
The patch looks good, but contains style (ordering) bugs :-)
I can't actually test the patch, but assume that's been done.
marcel
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Problems make installworld
Whenever I try to do a 'make installworld' the following error occurs: /usr/libexec/ld-elf.so.1: install: Undefined symbol "setflags" When I do a 'make -k installworld', make continues but the error occurs several times. When I do a simple 'make installworld' the followin happens : install -c -s -o root -g wheel -m 444 -fschg libscrypt.so.2 /usr/lib /usr/libexec/ld-elf.so.1: install: Undefined symbol "setflags" *** Error code 1 Stop in /usr/src/lib/libcrypt. *** Error code 1 Stop in /usr/src/lib. *** Error code 1 Stop in /usr/src. *** Error code 1 I really hope someone can help me, cause I want to test the IPv6 things in 4.0 soon (for my thesis) Thanx, Kurt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Problems make installworld
cd src/usr.bin/xinstall make all install cd ../../ make installworld ;) I'm already have some experience in this problem... ;=| bauerWhenever I try to do a 'make installworld' the following error occurs: bauer bauer/usr/libexec/ld-elf.so.1: install: Undefined symbol "setflags" bauer bauerWhen I do a 'make -k installworld', make continues but the error occurs bauerseveral times. bauerWhen I do a simple 'make installworld' the followin happens : bauer bauerinstall -c -s -o root -g wheel -m 444 -fschg libscrypt.so.2 /usr/lib bauer/usr/libexec/ld-elf.so.1: install: Undefined symbol "setflags" bauer*** Error code 1 bauer bauerStop in /usr/src/lib/libcrypt. bauer*** Error code 1 bauer bauerStop in /usr/src/lib. bauer*** Error code 1 bauer bauerStop in /usr/src. bauer*** Error code 1 bauer bauerI really hope someone can help me, cause I want to test the IPv6 things bauerin 4.0 soon (for my thesis) bauer bauerThanx, bauer bauerKurt bauer bauer bauer bauer bauerTo Unsubscribe: send mail to [EMAIL PROTECTED] bauerwith "unsubscribe freebsd-current" in the body of the message bauer Regards, Listopad Alexandr ([EMAIL PROTECTED]), LAA7-RIPE ZGIA, Zaporozhye, Ukraine. http://www.zgia.zp.ua. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: [HEADS UP] xinstall/setflags (was Re: cvs commit: src/share/mkbsd.lib.mk)
On Fri, 4 Feb 2000, Josef Karthauser wrote: On Fri, Feb 04, 2000 at 11:40:34AM +0200, Ruslan Ermilov wrote: Might I advice some more time before we actually do something? What's all this rush-it-in before anyone can actually fix the larger problem? I'm positive about this as well. The main reason for the backout isn't the xinstall problem, as this is a non-problem (it only affects a small window of -current users). The reason for adopting a fall back solution it that it is not clear that setflags/getflags is the best choice of function name for manipulating file flags as it's a bit too generic a name. Whilst we're debating this point there's no point in having them as library calls for 4.0. We can return to this point later, maybe when someone else wants to use them in another tool. On the way, we'll fix the xinstall problem and give you guys time and space to work the build/install glue post 4.0. There's no need to rush a fix in. I'm going to wait until tomorrow evening to commit this so that everyone gets a chance to read this and understand what's going on. (That's 24 - 36 hours from now.) Not everyone reads C like they read, say, Latin. It would be most kind for those people if the changes were accompanied by some directions for what to do if you built in the last week of confusion. Many thanks! The patch is included as an attachement. Joe -- Josef Karthauser FreeBSD: Take the red pill and we'll show you just how Technical Manager deep the rabbit hole goes. (http://www.uk.freebsd.org) Pavilion Internet plc. [[EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED]] -- Marc Schneiders [EMAIL PROTECTED] http://www.gluur.net [EMAIL PROTECTED] 3:40PM up 1:22, 3 users, load averages: 0.00, 0.00, 0.00 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Can't get ISA PCnet card to work with 20000127-current
On Thu, Feb 03, 2000 at 12:45:45PM -0500, "Matthew N. Dodd" [EMAIL PROTECTED] wrote: Get me a copy of your boot output and the output of 'pnpinfo'. Sorry for the delay, I had other things to cover first. For the record, got the cards working by brutally removing some PnP related includes and so on in the kernel source. I still don't have even a bit of clue what I did, but the changes removed PnP support, at least partially. Note, the cards are some sort of Tulip ones, that's all info I got. Here's the info: Copyright (c) 1992-2000 The FreeBSD Project. Copyright (c) 1982, 1986, 1989, 1991, 1993 The Regents of the University of California. All rights reserved. FreeBSD 4.0-2127-CURRENT #0: Wed Feb 2 22:47:51 EET 1994 root@:/usr/src/sys/compile/Mari Timecounter "i8254" frequency 1193134 Hz CPU: i486DX (486-class CPU) real memory = 16777216 (16384K bytes) avail memory = 13692928 (13372K bytes) Preloaded elf kernel "kernel" at 0xc02a4000. Preloaded userconfig_script "/boot/kernel.conf" at 0xc02a409c. VESA: v1.2, 2048k memory, flags:0x0, mode table:0xc00c50eb (c00050eb) VESA: S3 Incorporated. 86C801/805 npx0: math processor on motherboard npx0: INT 16 interface isa0: ISA bus on motherboard atkbdc0: keyboard controller (i8042) at port 0x60-0x6f on isa0 atkbd0: AT Keyboard irq 1 on atkbdc0 vga0: Generic ISA VGA at port 0x3c0-0x3df iomem 0xa-0xb on isa0 sc0: System console on isa0 sc0: VGA 8 virtual consoles, flags=0x200 ata0 at port 0x1f0 irq 14 on isa0 ata1 at port 0x170 irq 15 on isa0 fdc0: NEC 765 or clone at port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on isa0 fd0: 1440-KB 3.5" drive on fdc0 drive 0 sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0 sio0: type 16450 sio1 at port 0x2f8-0x2ff irq 3 on isa0 sio1: type 16450 ppc0: Parallel port at port 0x378-0x37f irq 7 on isa0 ppc0: Generic chipset (NIBBLE-only) in COMPATIBLE mode ppi0: Parallel I/O on ppbus0 lpt0: Printer on ppbus0 lpt0: Interrupt-driven port plip0: PLIP network interface on ppbus0 unknown0: TNCC-16 PNP at port 0x320-0x337 irq 10 drq 5 on isa0 unknown1: TNCC-16 PNP at port 0x300-0x317 irq 5 drq 3 on isa0 BRIDGE 981214, have 2 interfaces ad0: 1039MB QUANTUM FIREBALL_TM1080A [2112/16/63] at ata0-master using ??? acd0: CDROM NEC CD-ROM DRIVE:283 at ata1-master using ??? Mounting root from ufs:/dev/ad0s1a Checking for Plug-n-Play devices... Card assigned CSN #1 Vendor ID TCI00d0 (0xd0006950), Serial Number 0x3664015a PnP Version 1.0, Vendor Version 0 Device Description: TNCC-16 PNP Logical Device ID: TCI00d0 0xd0006950 #0 Compatible Device ID: PNP828c (8c82d041) I/O Range 0x320 .. 0x320, alignment 0x20, len 0x18 [not 16-bit addr] DMA: channel(s) 5 16-bit, bus master, , , Compatibility mode IRQ: 10 IRQ: High true edge sensitive IRQ: Low true level sensitive End Tag Successfully got 7 resources, 1 logical fdevs -- card select # 0x0001 CSN TCI00d0 (0xd0006950), Serial Number 0x3664015a Logical device #0 IO: 0x0320 0x0320 0x0320 0x0320 0x0320 0x0320 0x0320 0x0320 IRQ 10 0 DMA 5 0 IO range check 0x00 activate 0x01 Card assigned CSN #2 Vendor ID TCI00d0 (0xd0006950), Serial Number 0x3a64015a PnP Version 1.0, Vendor Version 0 Device Description: TNCC-16 PNP Logical Device ID: TCI00d0 0xd0006950 #0 Compatible Device ID: PNP828c (8c82d041) I/O Range 0x300 .. 0x300, alignment 0x20, len 0x18 [not 16-bit addr] DMA: channel(s) 3 16-bit, bus master, , , Compatibility mode IRQ: 5 IRQ: High true edge sensitive IRQ: Low true level sensitive End Tag Successfully got 7 resources, 1 logical fdevs -- card select # 0x0002 CSN TCI00d0 (0xd0006950), Serial Number 0x3a64015a Logical device #0 IO: 0x0300 0x0300 0x0300 0x0300 0x0300 0x0300 0x0300 0x0300 IRQ 5 0 DMA 3 0 IO range check 0x00 activate 0x01 -- Vallo Kallaste [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: [HEADS UP] xinstall/setflags (was Re: cvs commit: src/share/mkbsd.lib.mk)
On Fri, 4 Feb 2000, Marcel Moolenaar wrote: The patch looks good, but contains style (ordering) bugs :-) I can't actually test the patch, but assume that's been done. It also contains style (syntax) bugs. `extern' declarations of functions are not KNF. They are only only necessary to support older/different versions of KR than the one we half support. Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
setproctitle() in FreeBSD 4.0 ...
For some reason, under FreeBSD 4.0, setproctitle() isn't working any
longer:
ps ax | grep sockd | more
40015 ?? Ss 0:00.67 /usr/local/sbin/sockd -lD
40016 ?? S 0:00.02 /usr/local/sbin/sockd -lD
40017 ?? S 0:00.06 /usr/local/sbin/sockd -lD
40018 ?? S 0:00.03 /usr/local/sbin/sockd -lD
40019 ?? S 0:00.06 /usr/local/sbin/sockd -lD
40020 ?? S 0:00.04 /usr/local/sbin/sockd -lD
40021 ?? S 0:00.02 /usr/local/sbin/sockd -lD
40022 ?? S 0:00.02 /usr/local/sbin/sockd -lD
40023 ?? S 0:00.02 /usr/local/sbin/sockd -lD
40024 ?? S 0:00.02 /usr/local/sbin/sockd -lD
40025 ?? S 0:00.02 /usr/local/sbin/sockd -lD
40026 ?? S 0:00.01 /usr/local/sbin/sockd -lD
40027 ?? S 0:00.02 /usr/local/sbin/sockd -lD
40029 ?? S 0:00.01 /usr/local/sbin/sockd -lD
Its checking for and including -lutil for it ... but not giving me
anything ...
Anyone?
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: [EMAIL PROTECTED] secondary: scrappy@{freebsd|postgresql}.org
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: [HEADS UP] xinstall/setflags (was Re: cvs commit: src/share/mk bsd.lib.mk)
On Fri, Feb 04, 2000 at 11:05:01AM +, Josef Karthauser wrote: On Fri, Feb 04, 2000 at 11:40:34AM +0200, Ruslan Ermilov wrote: Might I advice some more time before we actually do something? What's all this rush-it-in before anyone can actually fix the larger problem? I'm positive about this as well. The main reason for the backout isn't the xinstall problem, as this is a non-problem (it only affects a small window of -current users). Hmm, if you apply this patch, then there will be another (not so small) window of -current users, having their /usr/bin/install depending on setflags() in libc. What will happen (if we do nothing with Makefile.inc1) is that at installworld /usr/bin/install will fail right after new libc.so.4 will be installed at the first -fschg, because with the current shape of Makefile.inc1, a host /usr/bin/install will be used at installworld until we install src/usr.bin/xinstall. Please, before you do it, upgrade to -current (you're running 3.4-stable for the moment, right?), with /usr/bin/install depending on setflags() in libc, then apply your patch, make buildworld, and make installworld _without_ DESTDIR, i.e. in / (installworld will work for DESTDIR=/xxx case). The real solution would be to resolve the install-tools issue. But the questions remain: 1) should they be built in a host environment or in -current? 2) and how to proceed in a non-self-hosting case (e.g. building -current world for alpha on i386). Building install-tools in -current environment (with new libraries) may not work with an older (host) kernel. Building them in a host environment may not also work for bootstrapping reasons (e.g., you can't build -current xinstall on a 3.x). The second question is more difficult one, I don't know what to do here. What IMHO should be done ASAP: 1. Add install-tools stage to the Makefile.inc1. These tools should be built in a host environment, linked statically, and only for self-hosting case (BUILD_ARCH == MACHINE_ARCH), and then be used at installworld. 2. Right after we resolve this issue, your patch (provided that you fix errors Bruce pointed out), should be committed to make it possible to compile -current xinstall in a host environment, e.g. from 3.x (IMHO, the most important case). -- Ruslan Ermilov Sysadmin and DBA of the [EMAIL PROTECTED]United Commercial Bank, [EMAIL PROTECTED] FreeBSD committer, +380.652.247.647Simferopol, Ukraine http://www.FreeBSD.org The Power To Serve http://www.oracle.com Enabling The Information Age To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Can't get ISA PCnet card to work with 20000127-current
On Fri, Feb 04, 2000 at 10:49:33AM -0500, "Matthew N. Dodd" [EMAIL PROTECTED] wrote: Sorry for the delay, I had other things to cover first. For the record, got the cards working by brutally removing some PnP related includes and so on in the kernel source. I still don't have even a bit of clue what I did, but the changes removed PnP support, at least partially. Note, the cards are some sort of Tulip ones, that's all info I got. Here's the info: And these cards attach to the 'lnc' driver with your fixes? Yes. Copyright (c) 1992-2000 The FreeBSD Project. Copyright (c) 1982, 1986, 1989, 1991, 1993 The Regents of the University of California. All rights reserved. FreeBSD 4.0-2127-CURRENT #0: Thu Feb 3 23:30:26 EET 2000 vallo@tiiu:/usr/src/sys/compile/Mari Timecounter "i8254" frequency 1193120 Hz CPU: i486DX (486-class CPU) real memory = 16777216 (16384K bytes) avail memory = 13701120 (13380K bytes) Preloaded elf kernel "kernel" at 0xc02a2000. Preloaded userconfig_script "/boot/kernel.conf" at 0xc02a209c. VESA: v1.2, 2048k memory, flags:0x0, mode table:0xc00c50eb (c00050eb) VESA: S3 Incorporated. 86C801/805 npx0: math processor on motherboard npx0: INT 16 interface isa0: ISA bus on motherboard atkbdc0: keyboard controller (i8042) at port 0x60-0x6f on isa0 atkbd0: AT Keyboard irq 1 on atkbdc0 vga0: Generic ISA VGA at port 0x3c0-0x3df iomem 0xa-0xb on isa0 sc0: System console on isa0 sc0: VGA 8 virtual consoles, flags=0x200 ata0 at port 0x1f0 irq 14 on isa0 ata1 at port 0x170 irq 15 on isa0 fdc0: NEC 765 or clone at port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on isa0 fd0: 1440-KB 3.5" drive on fdc0 drive 0 sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0 sio0: type 16450 sio1 at port 0x2f8-0x2ff irq 3 on isa0 sio1: type 16450 lnc0 at port 0x300-0x317 irq 5 drq 3 on isa0 lnc0: PCnet-ISA+ address 00:80:5a:01:64:3a lnc1 at port 0x320-0x337 irq 10 drq 5 on isa0 lnc1: PCnet-ISA+ address 00:80:5a:01:64:36 ppc0: Parallel port at port 0x378-0x37f irq 7 on isa0 ppc0: Generic chipset (NIBBLE-only) in COMPATIBLE mode ppi0: Parallel I/O on ppbus0 lpt0: Printer on ppbus0 lpt0: Interrupt-driven port plip0: PLIP network interface on ppbus0 BRIDGE 981214, have 4 interfaces -- index 1 lnc0 type 6 phy 0 addrl 6 addr 00.80.5a.01.64.3a -- index 2 lnc1 type 6 phy 0 addrl 6 addr 00.80.5a.01.64.36 ad0: 1039MB QUANTUM FIREBALL_TM1080A [2112/16/63] at ata0-master using ??? acd0: CDROM NEC CD-ROM DRIVE:283 at ata1-master using ??? Mounting root from ufs:/dev/ad0s1a -- Vallo Kallaste [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: proposed patch (build loader without forth)
approved
Hi,
would it be ok to commit the following patch to
/usr/src/sys/boot/i386/loader/Makefile so that we can build
a smaller loader without Forth support, which is still useful
to boot a picobsd kernel ?
cheers
luigi
rizzo# diff -ubwr Makefile.40RC Makefile
--- Makefile.40RC Tue Nov 23 16:30:48 1999
+++ MakefileFri Feb 4 17:26:26 2000
@@ -16,6 +16,7 @@
HAVE_PNP= yes
HAVE_ISABUS= yes
+.if !defined(NOFORTH)
# Enable BootForth
BOOT_FORTH=yes
CFLAGS+= -DBOOT_FORTH -I${.CURDIR}/../../ficl -I${.CURDIR}/../../ficl/
i386
@@ -23,6 +24,7 @@
LIBFICL= ${.OBJDIR}/../../ficl/libficl.a
.else
LIBFICL= ${.CURDIR}/../../ficl/libficl.a
+.endif
.endif
# Always add MI sources
---+-
Luigi RIZZO, [EMAIL PROTECTED] . Dip. di Ing. dell'Informazione
http://www.iet.unipi.it/~luigi/ . Universita` di Pisa
TEL/FAX: +39-050-568.533/522 . via Diotisalvi 2, 56126 PISA (Italy)
Mobile +39-347-0373137
---+-
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: Creative SB AWE64 recording does not work
On Tue, Feb 01, 2000 at 09:07:49PM -0800, Brian Beattie wrote: A kernel, current, sources cvsuped today. When I try to record from line, (source does not seem to matter), I get full scale white noise. The remainder of the system is from about a week ago, I will try a buildworld/installworld later. I have the same problem with world built yesterday (same card). It's sort of a loud buzzing/hissing noise that gets recorded, regardless of the input. section from dmesg --- sbc0: Creative SB AWE64 at port 0x220-0x22f,0x330-0x331,0x388-0x38b irq 5 drq 1,5 on isa0 sbc0: setting card to irq 5, drq 1, 5 pcm0: SB DSP 4.16 on sbc0 unknown0: Game at port 0x200-0x207 on isa0 unknown1: WaveTable at port 0x620-0x623 on isa0 --- Here's mine: isa_probe_children: probing PnP devices sbc0: Creative SB AWE64 at port 0x220-0x22f,0x330-0x331,0x388-0x38b irq 5 drq 1,5 on isa0 sbc0: setting card to irq 5, drq 1, 5 pcm1: SB DSP 4.16 on sbc0 pcm: setmap 8000, 2000; 0xc807e000 - 8000 pcm: setmap a000, 2000; 0xc808 - a000 unknown0: Game at port 0x200-0x207 on isa0 unknown1: WaveTable at port 0x620-0x623 on isa0 -- Christopher Masto Senior Network Monkey NetMonger Communications [EMAIL PROTECTED][EMAIL PROTECTED]http://www.netmonger.net Free yourself, free your machine, free the daemon -- http://www.freebsd.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Can't get ISA PCnet card to work with 20000127-current
On Fri, 4 Feb 2000, Vallo Kallaste wrote: lnc0 at port 0x300-0x317 irq 5 drq 3 on isa0 lnc0: PCnet-ISA+ address 00:80:5a:01:64:3a lnc1 at port 0x320-0x337 irq 10 drq 5 on isa0 lnc1: PCnet-ISA+ address 00:80:5a:01:64:36 Humm... Well, I guess its time to convert if_lnc to newbus though I doubt that it will happen before 4.0-R. -- | Matthew N. Dodd | '78 Datsun 280Z | '75 Volvo 164E | FreeBSD/NetBSD | | [EMAIL PROTECTED] | 2 x '84 Volvo 245DL| ix86,sparc,pmax | | http://www.jurai.net/~winter | This Space For Rent | ISO8802.5 4ever | To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Can't get ISA PCnet card to work with 20000127-current
On Fri, 4 Feb 2000, Vallo Kallaste wrote: Sorry for the delay, I had other things to cover first. For the record, got the cards working by brutally removing some PnP related includes and so on in the kernel source. I still don't have even a bit of clue what I did, but the changes removed PnP support, at least partially. Note, the cards are some sort of Tulip ones, that's all info I got. Here's the info: And these cards attach to the 'lnc' driver with your fixes? -- | Matthew N. Dodd | '78 Datsun 280Z | '75 Volvo 164E | FreeBSD/NetBSD | | [EMAIL PROTECTED] | 2 x '84 Volvo 245DL| ix86,sparc,pmax | | http://www.jurai.net/~winter | This Space For Rent | ISO8802.5 4ever | To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Creative SB AWE64 recording does not work
On Fri, 4 Feb 2000, Christopher Masto wrote: On Tue, Feb 01, 2000 at 09:07:49PM -0800, Brian Beattie wrote: A kernel, current, sources cvsuped today. When I try to record from line, (source does not seem to matter), I get full scale white noise. The remainder of the system is from about a week ago, I will try a buildworld/installworld later. I have the same problem with world built yesterday (same card). It's sort of a loud buzzing/hissing noise that gets recorded, regardless of the input. Yes that is wat I get, regardless of any of the settings, input selection, gain, etc... all I get is loud white noise. section from dmesg --- sbc0: Creative SB AWE64 at port 0x220-0x22f,0x330-0x331,0x388-0x38b irq 5 drq 1,5 on isa0 sbc0: setting card to irq 5, drq 1, 5 pcm0: SB DSP 4.16 on sbc0 unknown0: Game at port 0x200-0x207 on isa0 unknown1: WaveTable at port 0x620-0x623 on isa0 --- Here's mine: isa_probe_children: probing PnP devices sbc0: Creative SB AWE64 at port 0x220-0x22f,0x330-0x331,0x388-0x38b irq 5 drq 1,5 on isa0 sbc0: setting card to irq 5, drq 1, 5 pcm1: SB DSP 4.16 on sbc0 pcm: setmap 8000, 2000; 0xc807e000 - 8000 pcm: setmap a000, 2000; 0xc808 - a000 unknown0: Game at port 0x200-0x207 on isa0 unknown1: WaveTable at port 0x620-0x623 on isa0 -- Christopher Masto Senior Network Monkey NetMonger Communications [EMAIL PROTECTED][EMAIL PROTECTED]http://www.netmonger.net Free yourself, free your machine, free the daemon -- http://www.freebsd.org/ Brian Beattie| The only problem with [EMAIL PROTECTED] | winning the rat race ... www.aracnet.com/~beattie | in the end you're still a rat To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: [HEADS UP] xinstall/setflags (was Re: cvs commit: src/share/
On 04-Feb-00 Ruslan Ermilov wrote: On Fri, Feb 04, 2000 at 11:05:01AM +, Josef Karthauser wrote: On Fri, Feb 04, 2000 at 11:40:34AM +0200, Ruslan Ermilov wrote: Might I advice some more time before we actually do something? What's all this rush-it-in before anyone can actually fix the larger problem? I'm positive about this as well. The main reason for the backout isn't the xinstall problem, as this is a non-problem (it only affects a small window of -current users). Hmm, if you apply this patch, then there will be another (not so small) window of -current users, having their /usr/bin/install depending on setflags() in libc. What will happen (if we do nothing with Makefile.inc1) is that at installworld /usr/bin/install will fail right after new libc.so.4 will be installed at the first -fschg, because with the current shape of Makefile.inc1, a host /usr/bin/install will be used at installworld until we install src/usr.bin/xinstall. Umm, setflags() has not been in libc very long, so that is yet another small window of -current users. Besides, these are *-current* users, if they can't deal with -current, they shouldn't be running it. The upgrade path from -stable to -current is not affected by this patch. Please, before you do it, upgrade to -current (you're running 3.4-stable for the moment, right?), with /usr/bin/install depending on setflags() in libc, then apply your patch, make buildworld, and make installworld _without_ DESTDIR, i.e. in / (installworld will work for DESTDIR=/xxx case). The real solution would be to resolve the install-tools issue. But the questions remain: 1) should they be built in a host environment or in -current? 2) and how to proceed in a non-self-hosting case (e.g. building -current world for alpha on i386). Building install-tools in -current environment (with new libraries) may not work with an older (host) kernel. Building them in a host environment may not also work for bootstrapping reasons (e.g., you can't build -current xinstall on a 3.x). It is already pretty much a given that you need a -current kernel to do installworld due to the signal changes. So, assume that the -current kernel is present. You can then statically build copies of xinstall, sh, install-info, and any other tools used during installworld at the beginning of installworld. The second question is more difficult one, I don't know what to do here. What IMHO should be done ASAP: 1. Add install-tools stage to the Makefile.inc1. These tools should be built in a host environment, linked statically, and only for self-hosting case (BUILD_ARCH == MACHINE_ARCH), and then be used at installworld. I don't think this needs to be in 4.0. xinstall is *NOT* broken for -stable. (I just upgraded a -stable machine to -current a couple of days ago and my only problem was with install-info, I had *zero* problems with xinstall. 2. Right after we resolve this issue, your patch (provided that you fix errors Bruce pointed out), should be committed to make it possible to compile -current xinstall in a host environment, e.g. from 3.x (IMHO, the most important case). I think his patch can go in now. Since the names of the functions is up to date, it is best to not have them in libc, otherwise we'll have to bump libc's version number after we do finally settle on the appropriate names, which would be a Bad Thing(tm). -- John Baldwin [EMAIL PROTECTED] -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.cslab.vt.edu/~jobaldwi/pgpkey.asc "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
proposed patch (build loader without forth)
Hi,
would it be ok to commit the following patch to
/usr/src/sys/boot/i386/loader/Makefile so that we can build
a smaller loader without Forth support, which is still useful
to boot a picobsd kernel ?
cheers
luigi
rizzo# diff -ubwr Makefile.40RC Makefile
--- Makefile.40RC Tue Nov 23 16:30:48 1999
+++ MakefileFri Feb 4 17:26:26 2000
@@ -16,6 +16,7 @@
HAVE_PNP= yes
HAVE_ISABUS= yes
+.if !defined(NOFORTH)
# Enable BootForth
BOOT_FORTH=yes
CFLAGS+= -DBOOT_FORTH -I${.CURDIR}/../../ficl -I${.CURDIR}/../../ficl/i386
@@ -23,6 +24,7 @@
LIBFICL= ${.OBJDIR}/../../ficl/libficl.a
.else
LIBFICL= ${.CURDIR}/../../ficl/libficl.a
+.endif
.endif
# Always add MI sources
---+-
Luigi RIZZO, [EMAIL PROTECTED] . Dip. di Ing. dell'Informazione
http://www.iet.unipi.it/~luigi/ . Universita` di Pisa
TEL/FAX: +39-050-568.533/522 . via Diotisalvi 2, 56126 PISA (Italy)
Mobile +39-347-0373137
---+-
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
current and diskless...
Is it possible to boot current diskless? I'd say (from the times I tried it in 3.1 or something) to use netboot, but that fails because it can't boot an ELF kernel. Should I build an aout kernel, and how do I do that for current? Can I do it another way? One might say that with the rc.diskless files in /etc, that it should work somehow... Greetings mark -- Nice testing in little China... To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: [HEADS UP] xinstall/setflags (was Re: cvs commit: src/share/
On Fri, Feb 04, 2000 at 01:22:49PM -0500, John Baldwin wrote: On 04-Feb-00 Ruslan Ermilov wrote: On Fri, Feb 04, 2000 at 11:05:01AM +, Josef Karthauser wrote: On Fri, Feb 04, 2000 at 11:40:34AM +0200, Ruslan Ermilov wrote: Might I advice some more time before we actually do something? What's all this rush-it-in before anyone can actually fix the larger problem? I'm positive about this as well. The main reason for the backout isn't the xinstall problem, as this is a non-problem (it only affects a small window of -current users). Hmm, if you apply this patch, then there will be another (not so small) window of -current users, having their /usr/bin/install depending on setflags() in libc. What will happen (if we do nothing with Makefile.inc1) is that at installworld /usr/bin/install will fail right after new libc.so.4 will be installed at the first -fschg, because with the current shape of Makefile.inc1, a host /usr/bin/install will be used at installworld until we install src/usr.bin/xinstall. Umm, setflags() has not been in libc very long, so that is yet another small window of -current users. Besides, these are *-current* users, if they can't deal with -current, they shouldn't be running it. The upgrade path from -stable to -current is not affected by this patch. Could you please provide then *right* instructions for UPDATING? Please, before you do it, upgrade to -current (you're running 3.4-stable for the moment, right?), with /usr/bin/install depending on setflags() in libc, then apply your patch, make buildworld, and make installworld _without_ DESTDIR, i.e. in / (installworld will work for DESTDIR=/xxx case). The real solution would be to resolve the install-tools issue. But the questions remain: 1) should they be built in a host environment or in -current? 2) and how to proceed in a non-self-hosting case (e.g. building -current world for alpha on i386). Building install-tools in -current environment (with new libraries) may not work with an older (host) kernel. Building them in a host environment may not also work for bootstrapping reasons (e.g., you can't build -current xinstall on a 3.x). It is already pretty much a given that you need a -current kernel to do installworld due to the signal changes. So, assume that the -current kernel is present. You can then statically build copies of xinstall, sh, install-info, and any other tools used during installworld at the beginning of installworld. The second question is more difficult one, I don't know what to do here. What IMHO should be done ASAP: 1. Add install-tools stage to the Makefile.inc1. These tools should be built in a host environment, linked statically, and only for self-hosting case (BUILD_ARCH == MACHINE_ARCH), and then be used at installworld. I don't think this needs to be in 4.0. xinstall is *NOT* broken for -stable. (I just upgraded a -stable machine to -current a couple of days ago and my only problem was with install-info, I had *zero* problems with xinstall. *Sigh* If this would be in 4.0, you wouldn't have this install-info problem when upgrading from 3.x to 4.0. 2. Right after we resolve this issue, your patch (provided that you fix errors Bruce pointed out), should be committed to make it possible to compile -current xinstall in a host environment, e.g. from 3.x (IMHO, the most important case). I think his patch can go in now. Since the names of the functions is up to date, it is best to not have them in libc, otherwise we'll have to bump libc's version number after we do finally settle on the appropriate names, which would be a Bad Thing(tm). I'm not objecting about this patch, I really want install-tools issue be resolved before 4.0-release. -- Ruslan Ermilov Sysadmin and DBA of the [EMAIL PROTECTED]United Commercial Bank, [EMAIL PROTECTED] FreeBSD committer, +380.652.247.647Simferopol, Ukraine http://www.FreeBSD.org The Power To Serve http://www.oracle.com Enabling The Information Age To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: [HEADS UP] xinstall/setflags (was Re: cvs commit: src/share/
On Fri, 4 Feb 2000, John Baldwin wrote: 2. Right after we resolve this issue, your patch (provided that you fix errors Bruce pointed out), should be committed to make it possible to compile -current xinstall in a host environment, e.g. from 3.x (IMHO, the most important case). I think his patch can go in now. Since the names of the functions is up to date, it is best to not have them in libc, otherwise we'll have to bump libc's version number after we do finally settle on the appropriate names, which would be a Bad Thing(tm). This has an easy solution. One, get rid of setflags usage by reverting the Makefiles somewhat. Two, remove setflags from the headers. Three, make libc have an _XXX_setflags and __weak_reference() it to setflags. This won't break anyone, or make apps not be able to use [gs]etflags. Of course, this would all be done at the same time :) -- John Baldwin [EMAIL PROTECTED] -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.cslab.vt.edu/~jobaldwi/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ -- Brian Fundakowski Feldman \ FreeBSD: The Power to Serve! / [EMAIL PROTECTED]`--' To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: [HEADS UP] xinstall/setflags (was Re: cvs commit: src/share/
On 05-Feb-00 Matthew Dillon wrote: :This has an easy solution. One, get rid of setflags usage by reverting :the Makefiles somewhat. Two, remove setflags from the headers. Three, :make libc have an _XXX_setflags and __weak_reference() it to setflags. :This won't break anyone, or make apps not be able to use [gs]etflags. : :Of course, this would all be done at the same time :) An even easier solution would be to get rid of setflags entirely and put it back in the original sources that embedded it. Umm, that's bascially what Joe's currently proposed patch does. /me sighs -Matt -- John Baldwin [EMAIL PROTECTED] -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.cslab.vt.edu/~jobaldwi/pgpkey.asc "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: 4.0-20000204-SNAP install catching sig 11
http://www.bitwizard.nl/sig11/ -- Danny J. Zerkel [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Problems make installworld
I'm experiencing the same problems but the proposed solution of "make -k -DNOFSCHG installworld " doesn't allow the following "make installworld" to succeed. The error messages remain unchanged. I cvsup'd about 24 hours ago. cheers On 4 Feb 00, at 17:44, Ruslan Ermilov wrote: On Fri, Feb 04, 2000 at 03:17:49PM +0100, Kurt Bauer wrote: Whenever I try to do a 'make installworld' the following error occurs: /usr/libexec/ld-elf.so.1: install: Undefined symbol "setflags" That is the case I was talking about when I fixed bsd.lib.mk's PRECIOUSLIB breakage. Unfortunately, you are one of those guys, who had their /usr/bin/install linked with libutil, cvsupped the latest -current (with fixed bsd.lib.mk), and ran make installworld. The solution for you is: 1. make -k -DNOFSCHG installworld (this will allow you to install new libc.so.4). Both -k and -DNOFSCHG are required. 2. make a normal installworld. Please let me know whether it works for you. A quicker solution would be to copy (by hands) new libc.so.4 from /usr/obj to /usr/lib, and go to the step 2 above. But I really like you test step1, step2 algorithm, because we might want to upgrade UPDATING instructions. When I do a 'make -k installworld', make continues but the error occurs several times. When I do a simple 'make installworld' the followin happens : install -c -s -o root -g wheel -m 444 -fschg libscrypt.so.2 /usr/lib /usr/libexec/ld-elf.so.1: install: Undefined symbol "setflags" *** Error code 1 Stop in /usr/src/lib/libcrypt. *** Error code 1 Stop in /usr/src/lib. *** Error code 1 Stop in /usr/src. *** Error code 1 I really hope someone can help me, cause I want to test the IPv6 things in 4.0 soon (for my thesis) Thanx, Kurt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message -- Ruslan ErmilovSysadmin and DBA of the [EMAIL PROTECTED] United Commercial Bank, [EMAIL PROTECTED]FreeBSD committer, +380.652.247.647 Simferopol, Ukraine http://www.FreeBSD.orgThe Power To Serve http://www.oracle.com Enabling The Information Age To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message -- Dan Langille - DVL Software Limited [I'm looking for more work] The FreeBSD Diary - http://www.freebsddiary.org/ NZ FreeBSD User Group - http://www.nzfug.nz.freebsd.org/ The Racing System - http://www.racingsystem.com/ unix @ home - http://www.unixathome.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Problems make installworld
On Sat, Feb 05, 2000 at 07:41:56PM +1300, Dan Langille wrote: I'm experiencing the same problems but the proposed solution of "make -k -DNOFSCHG installworld " doesn't allow the following "make installworld" to succeed. The error messages remain unchanged. I cvsup'd about 24 hours ago. Hmm, I have received successful reports from some people. You are doing something different. We are talking about DESTDIR=/ case, and the latest bsd.lib.mk with unbroken PRECIOUSLIB feature. -DNOFSCHG is required to install without -fschg new shared libraries, in particular, libc.so.4 with setflags. -k is required since there is no such a beast like NOFSCHG for bsd.prog.mk. So, on the first pass you should have *all* new libraries installed, and some programs like /bin/rcp (which are installed with flags) not installed. On the second pass everything will be installed, since we at this point we already have the new /usr/bin/install and new libc.so.4. cheers On 4 Feb 00, at 17:44, Ruslan Ermilov wrote: On Fri, Feb 04, 2000 at 03:17:49PM +0100, Kurt Bauer wrote: Whenever I try to do a 'make installworld' the following error occurs: /usr/libexec/ld-elf.so.1: install: Undefined symbol "setflags" That is the case I was talking about when I fixed bsd.lib.mk's PRECIOUSLIB breakage. Unfortunately, you are one of those guys, who had their /usr/bin/install linked with libutil, cvsupped the latest -current (with fixed bsd.lib.mk), and ran make installworld. The solution for you is: 1. make -k -DNOFSCHG installworld (this will allow you to install new libc.so.4). Both -k and -DNOFSCHG are required. 2. make a normal installworld. Please let me know whether it works for you. A quicker solution would be to copy (by hands) new libc.so.4 from /usr/obj to /usr/lib, and go to the step 2 above. But I really like you test step1, step2 algorithm, because we might want to upgrade UPDATING instructions. When I do a 'make -k installworld', make continues but the error occurs several times. When I do a simple 'make installworld' the followin happens : install -c -s -o root -g wheel -m 444 -fschg libscrypt.so.2 /usr/lib /usr/libexec/ld-elf.so.1: install: Undefined symbol "setflags" *** Error code 1 Stop in /usr/src/lib/libcrypt. *** Error code 1 Stop in /usr/src/lib. *** Error code 1 Stop in /usr/src. *** Error code 1 I really hope someone can help me, cause I want to test the IPv6 things in 4.0 soon (for my thesis) Thanx, Kurt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message -- Ruslan Ermilov Sysadmin and DBA of the [EMAIL PROTECTED]United Commercial Bank, [EMAIL PROTECTED] FreeBSD committer, +380.652.247.647Simferopol, Ukraine http://www.FreeBSD.org The Power To Serve http://www.oracle.com Enabling The Information Age To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message -- Dan Langille - DVL Software Limited [I'm looking for more work] The FreeBSD Diary - http://www.freebsddiary.org/ NZ FreeBSD User Group - http://www.nzfug.nz.freebsd.org/ The Racing System - http://www.racingsystem.com/ unix @ home - http://www.unixathome.org/ -- Ruslan Ermilov Sysadmin and DBA of the [EMAIL PROTECTED]United Commercial Bank, [EMAIL PROTECTED] FreeBSD committer, +380.652.247.647Simferopol, Ukraine http://www.FreeBSD.org The Power To Serve http://www.oracle.com Enabling The Information Age To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Problems make installworld
On 5 Feb 00, at 9:28, Ruslan Ermilov wrote: On Sat, Feb 05, 2000 at 07:41:56PM +1300, Dan Langille wrote: I'm experiencing the same problems but the proposed solution of "make -k -DNOFSCHG installworld " doesn't allow the following "make installworld" to succeed. The error messages remain unchanged. I cvsup'd about 24 hours ago. Hmm, I have received successful reports from some people. You are doing something different. We are talking about DESTDIR=/ case, and the latest bsd.lib.mk with unbroken PRECIOUSLIB feature. -DNOFSCHG is required to install without -fschg new shared libraries, in particular, libc.so.4 with setflags. -k is required since there is no such a beast like NOFSCHG for bsd.prog.mk. So, on the first pass you should have *all* new libraries installed, and some programs like /bin/rcp (which are installed with flags) not installed. On the second pass everything will be installed, since we at this point we already have the new /usr/bin/install and new libc.so.4. OK. I'll cvsup to be sure I have the latest. And try the whole process again. FWIW: I'm following the instructions mentioned by Jim Bloom in the UPDATING thread (msg id = [EMAIL PROTECTED]). cheers cd /usr/src make buildworld make installworld cd /usr/src/usr.bin/xinstall make install cd /usr/src make installworld -- Dan Langille - DVL Software Limited [I'm looking for more work] The FreeBSD Diary - http://www.freebsddiary.org/ NZ FreeBSD User Group - http://www.nzfug.nz.freebsd.org/ The Racing System - http://www.racingsystem.com/ unix @ home - http://www.unixathome.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Suggestions for Gigabit cards for -CURRENT
Of all the gin joints in all the towns in all the world, Kenneth D. Merry had to walk into mine and say: Talking of the XMAC II, there's one other thing I forgot to mention earlier. The FreeBSD sk driver does jumbo frames, but the SysKonnect drivers don't. At least, not yet. The XMAC II's receive FIFO is 8K. By default, the chip operates in 'store and forward' mode in order to perform error checking on received frames (it has to get the entire frame in the FIFO in order to do a CRC on it, I think). This is fine for normal frames, but if you want to handle jumbograms larger than 8192 bytes, you have to put the chip into 'streaming' mode, otherwise any frame larger than 8192 bytes will be truncated. To get 'streaming' mode to work, you have to disable all of the RX error checking. That is unfortunate, since it means you can't do checksum offloading with jumbo frames. Uhm. I'm not sure about that. The 8K FIFO limitation is in the XMAC II, not in the GEnesis controller. And I believe it's the GEnesis that actually does the hardware checksumming stuff. Oh, and the XMAC appears to have a 4K TX FIFO, not 2K. My mistake. FWIW, of the three gigabit ethernet implementations I've seen anything of (Alteon, Intel, SysKonnect), none have implemented all of the hooks necessary for a seamless zero copy receive implementation. Alteon comes the closest, but they don't support splitting out the headers (yet), which is a requirement for us. The only way to do zero copy receive with our VM architecture (that I know of) is page flipping, i.e. receive the page in the kernel, and then trade it for the user's page. You can't do it on anything less than page-sized granularity, and things have to be page aligned. (The IO-Lite stuff from Rice is an exception to all this.) The nice thing about the Alteon boards, though, is that you can modify the firmware, and so header splitting is an option there. It would even be possible to split the headers off of IPv6 packets, or any other protocol that you have knowlege of. If you can actually modify the firmware to do this then you have a lot more guru points than I do. :) I've looked at the Alteon firmware code but it's all quite opaque to me. -Bill -- = -Bill Paul(212) 854-6020 | System Manager, Master of Unix-Fu Work: [EMAIL PROTECTED] | Center for Telecommunications Research Home: [EMAIL PROTECTED] | Columbia University, New York City = "It is not I who am crazy; it is I who am mad!" - Ren Hoek, "Space Madness" = To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
