Error on gnu/usr.bin/binutils/gdb?
Error occured at buildworld on my box... - ... ===> gnu/usr.bin/binutils/doc rm -f gdb-cfg.texi inc-hist.texi inc-hist.texi.orig as.info ld.info annotate.info gasp.info gdb.info gdbint.info stabs.info as.info.gz ld.info.gz annotate.info.gz gasp.info.gz gdb.info.gz gdbint.info.gz stabs.info.gz ===> gnu/usr.bin/binutils/gdb ".depend", line 2654: Need an operator ".depend", line 2655: Need an operator ".depend", line 2656: Need an operator ".depend", line 2657: Need an operator ".depend", line 2658: Need an operator ".depend", line 2659: Need an operator ".depend", line 2660: Need an operator ".depend", line 2661: Need an operator ".depend", line 2662: Need an operator ".depend", line 2673: Need an operator make: fatal errors encountered -- cannot continue *** Error code 1 Stop in /usr/src/gnu/usr.bin/binutils. *** Error code 1 Stop in /usr/src/gnu/usr.bin. *** Error code 1 Stop in /usr/src/gnu. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. -- Jun Kuriyama <[EMAIL PROTECTED]> // FreeBSD Project To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: unknown:
> > IF and ONLY IF the PNPBIOS code is causing your machine to fail, do the > > following: > > > > - Send me FULL DETAILS; this will need to include the trap messages and, > >if the trap is in the kernel, a DDB traceback. > > > > The described situation actually occured to me tonight (5-28-2000) while > trying to install. > Rather than check the list for a solution, I went back to the 4.0 boot disks > (which worked really well) and changed them to setup a snapshot > (5.0-2528-CURRENT). > > If you so desire (which presumably is the case), I can just boot up the > current floppies and try to send you the information you request. I can't imagine not being interested in working out what's going wrong, so please, if you could, do so. Let me know what your hardware is as well, please. -- \\ Give a man a fish, and you feed him for a day. \\ Mike Smith \\ Tell him he should learn how to fish himself, \\ [EMAIL PROTECTED] \\ and he'll hate you for a lifetime. \\ [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: /dev/lkm
Kent Hauser wrote: > > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-current" in the body of the message Heh. Well, I can probaby answer the question you meant to ask. Yes, /dev/lkm is gone. See kldload(2) and kldload(8) etc. Cheers, -Peter -- Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] "All of this is for nothing if we don't go to the stars" - JMS/B5 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
/dev/lkm
To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: "fetch | sh" panics system
Christian Weisgerber <[EMAIL PROTECTED]> wrote: > The following, completely innocuous command line > $ fetch -o - http://sites.inka.de/mips/unix/freebsd/xterm.shar | sh > executed as a non-priviledged user, reproducibly panics the machine. Some people have mailed that this particular command line just works on their machines. I'm not surprised. Still there must be some sort of problem, which happens to be triggered accidentally on my box for this unlikely case. I updated to yesterday's -CURRENT, and the problem persists. This is perfectly reproducible. I'll happily provide more details on my configuration, if anybody can give me a clue what might sensibly affect this. -- Christian "naddy" Weisgerber [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Looking for testers for if_dc patches
On Wed, May 31, 2000 at 12:30:51PM +0200, Wilko Bulte wrote: > On Tue, May 30, 2000 at 09:29:46AM -0700, Bill Paul wrote: > May 31 10:56:38 p6 /kernel: dc0: port > 0xec00-0xec7f m > em 0xfdfffc00-0xfdfffc7f irq 9 at device 3.0 on pci0 > May 31 10:56:38 p6 /kernel: dc0: Ethernet address: 00:00:f8:75:3c:6a > May 31 10:56:38 p6 /kernel: miibus0: on dc0 > May 31 10:56:38 p6 /kernel: dcphy0: on > miibus > 0 > May 31 10:56:38 p6 /kernel: dcphy0: 10baseT, 10baseT-FDX, 100baseTX, > 100baseTX- > FDX, auto Similar here on alpha with Adaptec 6911A without the watchdog timeouts. But after rereading the original mail I asume I'm on the wrong train as my card has an additional tranceiver which is not detected and the patch is for the internal one. -- B.Walter COSMO-Project http://www.cosmo-project.de [EMAIL PROTECTED] Usergroup[EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
RE: kerneld for -current
> > is there any interest in ``kerneld'' (a-la Linux) for > FreeBSD? i've got > > some working prototype > > Could you summerize what it offers and does? from RedHat documentation: Red Hat Linux includes kerneld, the Kernel Daemon, which automatically loads some software and hardware support into memory as it is needed, and unloads it when it is no longer being used. thanks, emax To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Looking for testers for if_dc patches
Just to see if if_dc has kept working on a machine that had it working before (Alpha Miata GL): works just fine with the patches applied. Wilko [goes back to digging up the Miata MX5] -- Wilko Bulte 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
Re: Looking for testers for if_dc patches
On Tue, May 30, 2000 at 09:29:46AM -0700, Bill Paul wrote: > > On Tue, May 30, 2000 at 12:28:25AM -0700, Bill Paul wrote: > > > Several people have reported problems with if_dc botching autonegotiation > > > on 21143 NICs with non-MII media, such as the DEC/Compaq DE500-BA and > > > the built-in 10/100 ethernet on some alphas. As my first official act > > > as a BSDi/WC employee, I sat down and tried to fix this. I produced > > > some patches for if_dc.c/if_dcreg.h and dcphy.c, which are sitting at > > > http://people.freebsd.org/~wpaul/dc_test. To apply them, do the following: > > > > [...] > > cc -c -O -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing >-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -ansi -g >-nostdinc -I- -I. -I../.. -I../../../include -D_KERNEL -include opt_global.h -elf >-mno-fp-regs -ffixed-8 -Wa,-mev56 ../../pci/if_dc.c > > ../../pci/if_dc.c: In function `dc_init': > > ../../pci/if_dc.c:2697: structure has no member named `dc_flgs' > > *** Error code 1 > > > > Stop in /var/d7/src-2000-05-28/src/sys/compile/CICELY9. > > > > This is on 5.0-CURRENT as of 28th May on alpha > > Grrr. Typo on my part, sorry. It should be flags, not flgs. I just fixed > the patch file. You can download it again, or just correct the typo manually. Hi Bill, I applied your patches to -current without incidents. I have a testbox (Digital dual P6) that gives: May 31 10:56:38 p6 /kernel: dc0: port 0xec00-0xec7f m em 0xfdfffc00-0xfdfffc7f irq 9 at device 3.0 on pci0 May 31 10:56:38 p6 /kernel: dc0: Ethernet address: 00:00:f8:75:3c:6a May 31 10:56:38 p6 /kernel: miibus0: on dc0 May 31 10:56:38 p6 /kernel: dcphy0: on miibus 0 May 31 10:56:38 p6 /kernel: dcphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX- FDX, auto May 31 10:56:38 p6 /kernel: dc0: supplying EUI64: 00:00:f8:ff:fe:75:3c:6a May 31 10:56:38 p6 /kernel: isab0: at device 7 ... May 31 10:56:39 p6 /kernel: dc0: starting DAD for fe80:0001::0200:f8ff:fe75:3c6a May 31 10:56:39 p6 /kernel: dc0: DAD complete for fe80:0001::0200:f8ff:fe75:3c6a - no duplicates found May 31 10:56:43 p6 /kernel: dc0: watchdog timeout May 31 10:57:18 p6 last message repeated 3 times May 31 10:57:58 p6 /kernel: dc0: watchdog timeout May 31 10:58:53 p6 login: ROOT LOGIN (root) ON ttyv0 May 31 10:58:56 p6 login: ROOT LOGIN (root) ON ttyv0 May 31 10:59:57 p6 /kernel: dc0: watchdog timeout May 31 11:03:27 p6 /kernel: dc0: watchdog timeout This box can also house an Alpha Miata MX5 mainboard, the Intel & Alpha boards use the same PCI riser card that also contains the 21143 chip. The patches don't seem to help on this particular hardware. I will try to give the Alpha a spin too, later today. BTW: ifconfig-ing to use 10baseT/UTP does not help either. The media bulkhead is a 10baseT/10base2 one. if_de has no problems: May 31 11:12:21 p6 /kernel: de0: port 0xec00-0xec7 f mem 0xfdfffc00-0xfdfffc7f irq 9 at device 3.0 on pci0 May 31 11:12:21 p6 /kernel: de0: DEC 21142 [10-100Mb/s] pass 1.1 May 31 11:12:21 p6 /kernel: de0: address 00:00:f8:75:3c:6a May 31 11:12:21 p6 /kernel: de0: supplying EUI64: 00:00:f8:ff:fe:75:3c:6a May 31 11:12:21 p6 /kernel: isab0: at device ... May 31 11:12:21 p6 /kernel: de0: enabling 10baseT port Rather than repeating please see also: To: FreeBSD-alpha mailing list <[EMAIL PROTECTED]> Subject: dc driver for embedded ethernet on Miata MX5 problems Message-ID: <[EMAIL PROTECTED]> and PR: alpha/17833: dc driver for embedded ethernet on Miata MX5 problems Thanks for your efforts, please let me know if you want me to try something particular. -- Wilko Bulte 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
Re: ftp(1) breakage w/ passive mode?
> On Wed, 31 May 2000 10:14:33 +0900
> [EMAIL PROTECTED] said:
itojun> isn't there some issue in getipnodebyname(), instead of getaddrinfo()?
itojun> (NOTE: I'm not really up-to-date with the current status of freebsd4
itojun> lib/libc/net)
itojun> if you can tell me repeatable example of getaddrinfo() failure,
itojun> that would be helpful...
Yes, it's a FreeBSD specific issue. Current getaddrinfo() is using
getipnodebyname_multi(). This was introduced by fixing search order.
There is a limitation that struct hostent cannot hold two address
families at once. So, the host has both A RR and RR, A RR is
converted into mapped address and getaddrinfo() returns only AF_INET6.
This problem was known at introducing getipnodebyname_multi(). But,
priority of fixing search order was higher than this problem in that
time. So, this problem is remained.
I think previous my patch is best workaround to solve this problem as
far as getaddrinfo() use getipnodeby_multi(). But, it is still
workaround.
There is one more problem. getipnodebyname() cannot handle scope-id.
To solve above problems, we should consider that getaddrinfo() don't
use getipnodebyname(). Actually, KAME, NetBSD-current, and
OpenBSD-current don't use getipnodebyname() any more and use res_*N()
calls. I ported it from NetBSD-current version of getaddrinfo.c and
it is running on my boxes. And, it was committed to KAME/FreeBSD4
version of getaddrinfo.c. But, I don't use NIS and NIS code is not
tested yet. I attach the patch to don't use getipnodebyname_multi().
BTW, there is search order problem in current getipnodebyname(), too.
If getipnodebyname() is called with `AI_ALL|AI_V4MAPPED', this is
occur. I attach the patch to solve this problem, too. It also use
res_*N() calls.
Index: lib/libc/net/getaddrinfo.c
diff -u lib/libc/net/getaddrinfo.c.orig lib/libc/net/getaddrinfo.c
--- lib/libc/net/getaddrinfo.c.orig Thu Apr 20 12:31:08 2000
+++ lib/libc/net/getaddrinfo.c Fri May 5 22:02:17 2000
@@ -37,6 +37,9 @@
* - Return values. There are nonstandard return values defined and used
* in the source code. This is because RFC2553 is silent about which error
* code must be returned for which situation.
+ * - freeaddrinfo(NULL). RFC2553 is silent about it. XNET 5.2 says it is
+ * invalid.
+ * current code - SEGV on freeaddrinfo(NULL)
* Note:
* - We use getipnodebyname() just for thread-safeness. There's no intent
* to let it do PF_UNSPEC (actually we never pass PF_UNSPEC to
@@ -45,6 +48,41 @@
* when globbing NULL hostname (to loopback, or wildcard). Is it the right
* thing to do? What is the relationship with post-RFC2553 AI_ADDRCONFIG
* in ai_flags?
+ * - (post-2553) semantics of AI_ADDRCONFIG itself is too vague.
+ * (1) what should we do against numeric hostname (2) what should we do
+ * against NULL hostname (3) what is AI_ADDRCONFIG itself. AF not ready?
+ * non-loopback address configured? global address configured?
+ * - To avoid search order issue, we have a big amount of code duplicate
+ * from gethnamaddr.c and some other places. The issues that there's no
+ * lower layer function to lookup "IPv4 or IPv6" record. Calling
+ * gethostbyname2 from getaddrinfo will end up in wrong search order, as
+ * follows:
+ * - The code makes use of following calls when asked to resolver with
+ * ai_family = PF_UNSPEC:
+ * getipnodebyname(host, AF_INET6);
+ * getipnodebyname(host, AF_INET);
+ * This will result in the following queries if the node is configure to
+ * prefer /etc/hosts than DNS:
+ * lookup /etc/hosts for IPv6 address
+ * lookup DNS for IPv6 address
+ * lookup /etc/hosts for IPv4 address
+ * lookup DNS for IPv4 address
+ * which may not meet people's requirement.
+ * The right thing to happen is to have underlying layer which does
+ * PF_UNSPEC lookup (lookup both) and return chain of addrinfos.
+ * This would result in a bit of code duplicate with _dns_ghbyname() and
+ * friends.
+ */
+/*
+ * diffs with other KAME platforms:
+ * - other KAME platforms already nuked FAITH ($GAI), but as FreeBSD
+ * 4.0-RELEASE supplies it, we still have the code here.
+ * - EAI_RESNULL support
+ * - AI_ADDRCONFIG support is supplied
+ * - EDNS0 support is not available due to resolver differences
+ * - some of FreeBSD style (#define tabify and others)
+ * - AI_ADDRCONFIG is turned on by default.
+ * - classful IPv4 numeric (127.1) is allowed.
*/
#include
@@ -62,6 +100,7 @@
#include
#include
#include
+#include
#if defined(__KAME__) && defined(INET6)
# define FAITH
@@ -108,6 +147,7 @@
};
struct explore {
+ int e_af;
int e_socktype;
int e_protocol;
const char *e_protostr;
@@ -118,10 +158,21 @@
};
static const struct explore explore[] = {
- { SOCK_DGRAM, IPPROTO_UDP, "udp", 0x07 },
- { SOCK_S
Problem building a snapshot for current, no more "more"
In attempting to build a snapshot for current, I came across the following problem in the release.4 target of the Makefile in /usr/src/release. ... cc -static -o boot_crunch boot_crunch.o sh.lo find.lo sed.lo test.lo rm.lo pwd.lo ppp.lo sysinstall.lo newfs.lo minigzip.lo cpio.lo fsck.lo ifconfig.lo route.lo slattach.lo mount_nfs.lo dhclient.lo arp.lo hostname.lo pccardc.lo pccardd.lo usbd.lo usbdevs.lo -ll -ledit -lutil -lkvm -lmd -lcrypt -lftpio -lz -lnetgraph -ldialog -lncurses -lmytinfo -L/usr/src/release/libdisk/obj -ldisk -lipx dhclient.lo: In function `script_init': dhclient.lo(.text+0x416b): warning: mktemp() possibly used unsafely; consider using mkstemp() strip boot_crunch crunchgen: /usr/src/release/fixit_crunch.conf: more: warning: could not find source directory crunchgen: /usr/src/release/fixit_crunch.conf: more: warning: could not find any .o files crunchgen: /usr/src/release/fixit_crunch.conf: more: error: no objpaths specified or calculated crunchgen: /usr/src/release/fixit_crunch.conf: more: ignoring program because of errors Run "make -f fixit_crunch.mk objs exe" to build crunched binary. *** Error code 1 Stop in /usr/src/release. Note that the crunchgen could not find the sources for "more." Does this have something to do with the replacement of "more" by "less" recently? I am not sure what the correct fix is. Someone with more understanding of what is going on might want to address this. For example, should one replace "more" by "less" (and "lesskey" and "lessecho") ? I have not tried this and tested whether things would still fit on the floppy. George Dinolt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: kerneld for -current
On Tue, May 30, 2000 at 10:17:22AM -0400, Yevmenkin, Maksim N, CSCIO wrote: > is there any interest in ``kerneld'' (a-la Linux) for FreeBSD? i've got > some working prototype Could you summerize what it offers and does? -- -- David ([EMAIL PROTECTED]) Disclaimer: Not speaking for FreeBSD, just expressing my own opinion. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
