Re: cvs commit: src/usr.sbin/named Makefile
-On [20010129 07:25], [EMAIL PROTECTED] ([EMAIL PROTECTED]) wrote: >In article <[EMAIL PROTECTED]> you wrote: > It seems to me that the same kind of libisc dependency >must be provided for 'libexec/named-xfer', because it now stops >buildworld with the 'isc_movefile' unresolved message. Correct, fixed. > At the same time it seems to me that now 'lib/libbind' >contains many files/functions which are also present in the >newly created 'lib/libisc'. Is it right ? Could be. I have to look at that. I focused on getting the import done very quickly due to some security stuff coming out later. 3- and 4-STABLE will follow sooner than normal after I've done my make worlds and other tests on them today/tomorrow. -- Jeroen Ruigrok van der Werven VIA Net.Works The Netherlands BSD: Technical excellence at its best Network- and systemadministrator D78D D0AD 244D 1D12 C9CA 7152 035C 1138 546A B867 Misery loves company... To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: buildworld failed with named-xfer.
Konnichiwa wa MATSUDA-san, -On [20010129 07:40], Munehiro Matsuda ([EMAIL PROTECTED]) wrote: >Buildworld failed with following error: > >cc -O -pipe -I/usr/src/libexec/named-xfer/../../contrib/bind/port/freebsd/include >-I/usr/src/libexec/named-xfer/../../contrib/bind/bin/named >-I/usr/src/libexec/named-xfer/../../contrib/bind/include -I.-o named-xfer >named-xfer.o db_glue.o ns_glue.o tmp_version.o >/usr/obj/usr/src/libexec/named-xfer/../../lib/libbind/libbind.a >named-xfer.o: In function `main': >named-xfer.o(.text+0xe4a): undefined reference to `isc_movefile' >named-xfer.o(.text+0xede): undefined reference to `isc_movefile' >named-xfer.o(.text+0xf54): undefined reference to `isc_movefile' >/usr/obj/usr/src/libexec/named-xfer/../../lib/libbind/libbind.a(logging.o)(.text+0x98): > undefined reference to `isc_movefile' >/usr/obj/usr/src/libexec/named-xfer/../../lib/libbind/libbind.a(logging.o)(.text+0xca): > undefined reference to `isc_movefile' >*** Error code 1 Thanks, applied the patch. The BIND import was kind of rushed due to the security stuff being released today. -- Jeroen Ruigrok van der Werven VIA Net.Works The Netherlands BSD: Technical excellence at its best Network- and systemadministrator D78D D0AD 244D 1D12 C9CA 7152 035C 1138 546A B867 Misery loves company... To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: /etc/shells #include syntax support patch
/etc/shells is such a simple file, I don't see much of point in polluting it. There is not much of difference having a port install: target edit /etc/shells verses editing /usr/local/etc/shells. It should just edit /etc/shells. -Matt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
buildworld failed
Latest -CURRENT died with this error messages: -- /usr/src/lib/libc_r/uthread/uthread_aio_suspend.c: In function `_aio_suspend': /usr/src/lib/libc_r/uthread/uthread_aio_suspend.c:45: warning: passing arg 1 of `__sys_aio_suspend' discards qualifiers from pointer target type /usr/src/lib/libc_r/uthread/uthread_aio_suspend.c:45: incompatible type for argument 3 of `__sys_aio_suspend' *** Error code 1 cc -fpic -DPIC -O -pipe -mcpu=i686 -march=i686 -DLIBC_RCS -DSYSLIBC_RCS -I/usr/src/lib/libc_r/../libc/include -DPTHREAD_KERNEL -D_THREAD_SAFE -I/usr/src/lib/libc_r/uthread -I/usr/src/lib/libc_r/../../include -D_LOCK_DEBUG -D_PTHREADS_INVARIANTS -I/usr/obj/usr/src/i386/usr/include -c /usr/src/lib/libc_r/uthread/uthread_attr_getdetachstate.c -o uthread_attr_getdetachstate.So /usr/src/lib/libc_r/uthread/uthread_aio_suspend.c: In function `_aio_suspend': /usr/src/lib/libc_r/uthread/uthread_aio_suspend.c:45: warning: passing arg 1 of `__sys_aio_suspend' discards qualifiers from pointer target type /usr/src/lib/libc_r/uthread/uthread_aio_suspend.c:45: incompatible type for argument 3 of `__sys_aio_suspend' *** Error code 1 2 errors *** Error code 2 1 error *** Error code 2 1 error *** Error code 2 1 error *** Error code 2 1 error -- /john To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: /etc/shells #include syntax support patch
On Sun, 28 Jan 2001 23:53:50 -0500 "Louis A. Mamakos" <[EMAIL PROTECTED]> wrote: LM> It doesn't seem unreasonable to have a single file with a list of allowable LM> shells. One thing - it is kind of cute having the allowable shells match the mounted shells. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: /etc/shells #include syntax support patch
On Sun, 28 Jan 2001 22:19:29 -0800 (PST) John Baldwin <[EMAIL PROTECTED]> wrote: JB> People whine about the problem though, so having no solution doesn't JB> help either. Since #include is syntatically a comment, it shouldn't JB> mess up other programs, though the idea is that they will all use the JB> API in libc and not be reading the file themselves. However, I do JB> think that doing it through nsswitch might be the best solution. Everything in the tree uses the API apart from adduser.perl. Do many ports use /etc/shells ? On the security issue, I rather like the idea that a none root port administrator is possible, this doesn't really need multiple shells files though so nsswitch works for me. I can't set it up though (no -current box). To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
buildworld failed with named-xfer.
Hi,
Buildworld failed with following error:
cc -O -pipe -I/usr/src/libexec/named-xfer/../../contrib/bind/port/freebsd/include
-I/usr/src/libexec/named-xfer/../../contrib/bind/bin/named
-I/usr/src/libexec/named-xfer/../../contrib/bind/include -I.-o named-xfer
named-xfer.o db_glue.o ns_glue.o tmp_version.o
/usr/obj/usr/src/libexec/named-xfer/../../lib/libbind/libbind.a
named-xfer.o: In function `main':
named-xfer.o(.text+0xe4a): undefined reference to `isc_movefile'
named-xfer.o(.text+0xede): undefined reference to `isc_movefile'
named-xfer.o(.text+0xf54): undefined reference to `isc_movefile'
/usr/obj/usr/src/libexec/named-xfer/../../lib/libbind/libbind.a(logging.o)(.text+0x98):
undefined reference to `isc_movefile'
/usr/obj/usr/src/libexec/named-xfer/../../lib/libbind/libbind.a(logging.o)(.text+0xca):
undefined reference to `isc_movefile'
*** Error code 1
Stop in /usr/src/libexec/named-xfer.
Following patch seems to work.
--- Makefile.ctmWed May 24 03:17:07 2000
+++ MakefileMon Jan 29 15:34:18 2001
@@ -12,4 +12,14 @@
named-xfer.c db_glue.c ns_glue.c tmp_version.c
MAN8= named-xfer.8
+.if exists(${.OBJDIR}/../../lib/libisc)
+LIBISCDIR:=${.OBJDIR}/../../lib/libisc
+.else
+LIBISCDIR!=cd ${.CURDIR}/../../lib/libisc; make -V .OBJDIR
+.endif
+LIBISC:= ${LIBISCDIR}/libisc.a
+
+DPADD+= ${LIBISC}
+LDADD+= ${LIBISC}
+
.include
Thanks,
Haro
=--
_ _Munehiro (haro) Matsuda
-|- /_\ |_|_| Business Incubation Dept., Kubota Corp.
/|\ |_| |_|_| 1-3 Nihonbashi-Muromachi 3-Chome
Chuo-ku Tokyo 103-8310, Japan
Tel: +81-3-3245-3318 Fax: +81-3-3245-3315
Email: [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: cvs commit: src/usr.sbin/named Makefile
In article <[EMAIL PROTECTED]> you wrote: > asmodai 2001/01/28 15:21:00 PST > > Modified files: >usr.sbin/named Makefile > Log: > Add static dependency on libisc.a to get isc_movefile() on which named > now depends. This keeps named the same as before the import, that is: only > linking against libc dynamically, at a little space increase, which might > be due to the source code changes anyway. Very neglectable space > difference. > > Some people might dub it a hack. It will do for now at least. > > Revision ChangesPath > 1.26 +12 -1 src/usr.sbin/named/Makefile It seems to me that the same kind of libisc dependency must be provided for 'libexec/named-xfer', because it now stops buildworld with the 'isc_movefile' unresolved message. At the same time it seems to me that now 'lib/libbind' contains many files/functions which are also present in the newly created 'lib/libisc'. Is it right ? N.Dudorov To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: /etc/shells #include syntax support patch
On 29-Jan-01 Louis A. Mamakos wrote: >> On Sun, Jan 28, 2001 at 10:13:49AM +0100, Steve O'Hara-Smith wrote: >> >Hi, >> > >> >Asbestos suit on, round two. >> > >> >The patch below changes getusershell to support a #include syntax >> > in /etc/shells. >> >> I guess this is what I object to. I don't particularly like having a >> new directive in a configuration file which lots of applications read >> directly. >> >> I would rather that a separate configuration file be read, for example, >> with a list of shells(5) format files to consult. >> >> In current, this could be an optional thing, activated in nsswitch.conf, >> e.g. make a ports source for shells, and activate it with: >> shells: files ports >> >> or whatever you would like to call the source. > > Does this capability really need to exist (e.g., supporting many files)? It > would seem like the additional complexity would be not what you want for > what's > essentially a security policy mechansim. Who gets to own these included > files? > What should their permissions be allowed to be? > > It doesn't seem unreasonable to have a single file with a list of allowable > shells. > > Is this #include capability going to be added for other files that ports > modify such as /etc/master.passwd and /etc/group? > > I dunno; maybe it's just me, but this really seems like a solution way out > of proportion to the "problem" People whine about the problem though, so having no solution doesn't help either. Since #include is syntatically a comment, it shouldn't mess up other programs, though the idea is that they will all use the API in libc and not be reading the file themselves. However, I do think that doing it through nsswitch might be the best solution. > louie -- John Baldwin <[EMAIL PROTECTED]> -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/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: DEVFS newbie...
On 29-Jan-01 John Indra wrote: > I noticed that DEVFS has been the default in GENERIC kernel. I have been > -CURRENT tracker for the past couple of months and things like DEVFS is > still new to me. Thus, a couple of questions arise and I am very glad if > someone want to explain it to me, or maybe point to docs that I should read. > > 1. Say I want to use DEVFS, what should I change? /etc/fstab? Should I nuke > the current /dev? Just put it in your kernel config, init(8) will mount it for you automagically. > 2. If something change to the source tree's MAKEDEV, what should I do? Nothing. With DEVFS, each driver in the kernel creates its own entries automatically, so MAKEDEV isn't used. > Thanks... > > /john -- John Baldwin <[EMAIL PROTECTED]> -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/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: DEVFS newbie...
In message <[EMAIL PROTECTED]>, John Indra writes: >I noticed that DEVFS has been the default in GENERIC kernel. I have been >-CURRENT tracker for the past couple of months and things like DEVFS is >still new to me. Thus, a couple of questions arise and I am very glad if >someone want to explain it to me, or maybe point to docs that I should read. > >1. Say I want to use DEVFS, what should I change? Nothing. Just add DEVFS to your kernel config file. -- 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
stange console problem
On a current from last Sunday I recompiled a new kernel with just makeoptions DEBUG=-g and options DDB added to GENERIC and when I boot I see the first few spins of the loader booting the kernel and then all video output stops. After the boot finishs I get a login prompt but no keyboard response or video after that. I am able to ssh into the box, and all seems well from the "inside". If I recompile GENERIC it works just fine. Here is a dmesg, I noticed a few things but nothing I know how to fix.. Chad Copyright (c) 1992-2001 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 5.0-CURRENT #2: Sun Jan 28 23:17:40 MST 2001 [EMAIL PROTECTED]:/usr/src/sys/compile/DEBUG Timecounter "i8254" frequency 1193182 Hz CPU: Pentium II/Pentium II Xeon/Celeron (367.50-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x660 Stepping = 0 Features=0x183f9ff real memory = 134152192 (131008K bytes) avail memory = 125595648 (122652K bytes) Preloaded elf kernel "kernel" at 0xc04e7000. Pentium Pro MTRR support enabled WARNING: Driver mistake: destroy_dev on 154/0 Using $PIR table, 6 entries at 0xc00fded0 apm0: on motherboard apm0: found APM BIOS v1.2, connected at v1.2 npx0: on motherboard npx0: INT 16 interface pcib0: at pcibus 0 on motherboard pci0: on pcib0 pcib1: at device 1.0 on pci0 pci1: on pcib1 pci1: at 0.0 (no driver attached) isab0: at device 7.0 on pci0 isa0: on isab0 atapci0: port 0xf000-0xf00f at device 7.1 on pci0 ata0: at 0x1f0 irq 14 on atapci0 ata1: at 0x170 irq 15 on atapci0 uhci0: port 0xe000-0xe01f at device 7.2 on pci0 pci_cfgintr_virgin: using routable PCI-only interrupt 11 pci_cfgintr: 0:7 INTD routed to irq 11 usb0: on uhci0 usb0: USB revision 1.0 uhub0: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 2 ports with 2 removable, self powered pci0: at 7.3 (no driver attached) xl0: <3Com 3c905B-TX Fast Etherlink XL> port 0xe400-0xe47f mem 0xe500-0xe57f irq 11 at device 9.0 on pci0 xl0: Ethernet address: 00:10:4b:6e:0a:87 miibus0: on xl0 xlphy0: <3Com internal media interface> on miibus0 xlphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto sc0: on isa0 sc0: VGA <16 virtual consoles, flags=0x0> vga0: at port 0x3c0-0x3df iomem 0xa-0xb on isa0 sio0: <16550A-compatible COM port> at port 0x3f8-0x407 irq 4 on isa0 sio0: type 16550A fdc0: at port 0x3f2-0x3f5,0x3f7 irq 6 drq 2 on isa0 ppc0: at port 0x378-0x387 irq 7 on isa0 ppc0: Generic chipset (NIBBLE-only) in COMPATIBLE mode plip0: on ppbus0 lpt0: on ppbus0 lpt0: Interrupt-driven port ppi0: on ppbus0 sio1: <16550A-compatible COM port> at port 0x2f8-0x307 irq 3 on isa0 sio1: type 16550A sbc0: at port 0x220-0x22f,0x331-0x332,0x388-0x38b irq 5 drq 1,5 on isa0 pcm0: on sbc0 xl0 XXX: driver didn't initialize queue mtx lp0 XXX: driver didn't initialize queue mtx gif0 XXX: driver didn't initialize queue mtx gif1 XXX: driver didn't initialize queue mtx gif2 XXX: driver didn't initialize queue mtx gif3 XXX: driver didn't initialize queue mtx lo0 XXX: driver didn't initialize queue mtx ppp0 XXX: driver didn't initialize queue mtx faith0 XXX: driver didn't initialize queue mtx ad0: 6187MB [13410/15/63] at ata0-master UDMA33 Mounting root from ufs:/dev/ad0s4a To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: /etc/shells #include syntax support patch
> On Sun, Jan 28, 2001 at 10:13:49AM +0100, Steve O'Hara-Smith wrote: > > Hi, > > > > Asbestos suit on, round two. > > > > The patch below changes getusershell to support a #include syntax > > in /etc/shells. > > I guess this is what I object to. I don't particularly like having a > new directive in a configuration file which lots of applications read > directly. > > I would rather that a separate configuration file be read, for example, > with a list of shells(5) format files to consult. > > In current, this could be an optional thing, activated in nsswitch.conf, > e.g. make a ports source for shells, and activate it with: > shells: files ports > > or whatever you would like to call the source. Does this capability really need to exist (e.g., supporting many files)? It would seem like the additional complexity would be not what you want for what's essentially a security policy mechansim. Who gets to own these included files? What should their permissions be allowed to be? It doesn't seem unreasonable to have a single file with a list of allowable shells. Is this #include capability going to be added for other files that ports modify such as /etc/master.passwd and /etc/group? I dunno; maybe it's just me, but this really seems like a solution way out of proportion to the "problem" louie To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: kernel threading: the first steps [patch]
On 2001-Jan-27 00:33:23 -0800, Root Dude <[EMAIL PROTECTED]> wrote: >I've broken the proc structure into 4 structures. Leaving aside the issue of whether or your efforts were a waste of time, I have some comments on the ordering of fields. Since the fields are being re-arranged anyway, I'd like to suggest that the implementation characteristics be taken into account. I'm mainly thinking of padding between fields here. A second, far less important issue is the interaction between field order and code size on the IA32. Given that most structure references are base+offset, there's an extra 3-byte overhead in accessing fields more than 127 bytes from the pointer - there's no direct speed penalty except on the 80386, but there is an indirect penalty for larger code (ie bigger cache footprint). This suggests that fields with a high static reference count should be towards the front of structures. Peter To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: sh can't be exec'd
On Sun, Jan 28, 2001 at 18:15 +0200, Paul Allenby wrote: > "Rogier R. Mulhuijzen wrote:" > > > > >For the last week, each kernel built with fresh source code ^^^ > > >cannot exec sh. I've seen a lot of emails about this, but > > >most were about the "correct" way to rebuild a system. > > >Is this a problem affecting only me? Dumb question: You do build both world and kernel when you update your sources? And if it fails the way you do it, you fall back to the official method described in UPDATING before yelling "it's broken"? There must be a reason when a thousand answers are about how to update a system (and not just one part of it). > > I haven't had any trouble. > > > > How do you rebuild your system? What is the exact error you > > get? And (at the risk of sounding stupid) what's the output > > of ls -l /bin/sh? > > cd /usr/src/sys/i386/conf;config XXX;cd ../../compile/XXX; make depend; make I miss the "install" target here, unless it's so obvious for you that you don't mention it. Just like "buildworld" and "installworld". Maybe you should try one safe run of the suggested form. Cutting corners is not very efficient when problems keep you from simply running your new system. :) virtually yours 82D1 9B9C 01DC 4FB4 D7B4 61BE 3F49 4F77 72DE DA76 Gerhard Sittig true | mail -s "get gpg key" [EMAIL PROTECTED] -- If you don't understand or are scared by any of the above ask your parents or an adult to help you. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
DEVFS newbie...
I noticed that DEVFS has been the default in GENERIC kernel. I have been -CURRENT tracker for the past couple of months and things like DEVFS is still new to me. Thus, a couple of questions arise and I am very glad if someone want to explain it to me, or maybe point to docs that I should read. 1. Say I want to use DEVFS, what should I change? /etc/fstab? Should I nuke the current /dev? 2. If something change to the source tree's MAKEDEV, what should I do? Thanks... /john To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Fixed: LyX 1.1.5.2 dumping core
On Sun, Jan 28, 2001 at 01:28:03PM -0600, Patrick Hartling wrote: > ldd was telling me that it had both libc.so.3 and libc.so.5 which seemed > very bad to me. When I recomipled LyX to see if that would fix things, > I noticed that ld was giving a warning about libc.so.3 and libc.so.5 > potentially conflicting. It hadn't ever been a problem before, but it > doesn't seem like the safest arrangment. With the symlink in place, ldd > reports that only libc.so.5 is being used, and everything seems to be > okay. Something that LyX is linking to is depending on libc v3. You should rebuild all of the dependencies, and then rebuild LyX. - alex To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: /etc/shells #include syntax support patch
On Sun, Jan 28, 2001 at 10:13:49AM +0100, Steve O'Hara-Smith wrote: > Hi, > > Asbestos suit on, round two. > > The patch below changes getusershell to support a #include syntax > in /etc/shells. I guess this is what I object to. I don't particularly like having a new directive in a configuration file which lots of applications read directly. I would rather that a separate configuration file be read, for example, with a list of shells(5) format files to consult. In current, this could be an optional thing, activated in nsswitch.conf, e.g. make a ports source for shells, and activate it with: shells: files ports or whatever you would like to call the source. -- Jacques Vidrine / [EMAIL PROTECTED] / [EMAIL PROTECTED] / [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: sh can't be exec'd
On Sun, Jan 28, 2001 at 06:15:46PM +0200, Paul Allenby wrote: > "Rogier R. Mulhuijzen wrote:" > > > > > > >For the last week, each kernel built with fresh source code > > >cannot exec sh. I've seen a lot of emails about this, but > > >most were about the "correct" way to rebuild a system. > > >Is this a problem affecting only me? > > > > I haven't had any trouble. > > > > How do you rebuild your system? What is the exact error you get? > > And (at the risk of sounding stupid) what's the output of ls -l /bin/sh? > > > > cd /usr/src/sys/i386/conf;config XXX;cd ../../compile/XXX; make depend; make > > No errors, just the usual prompt for a path to a shell, as if one > had booted single user. > > 526188 sh, without resorting to a fixit disc. You shouldn't update only the kernel. See the Handbook about make world. -- 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: new gensetdefs breaks booting
Jake Burkholder wrote: > > > Bruce Evans wrote: > > > > > > The new gensetdefs gives unbootable kernels on i386's. They hang before > > > printing anything. > > > > I verified that the output of gensetdefs.pl is identical to that of > > gensetdefs(1). Does the kernel boot if gensetdefs(1) is used? > > > > Its not identical here, gensetdefs.pl uses .quad for the size of > the linker set (?), which should be .long for x86. Also, I'm not > sure if the calculation for pointer size is correct, all the numbers > seemed 3 times too big in setdefs.h. Ok, thanks. The commit has been reverted for all platforms except ia64. I think I messed up my testing, but may easily have committed the wrong gensetdefs.pl. I'll check it out... -- Marcel Moolenaar mail: [EMAIL PROTECTED] / [EMAIL PROTECTED] tel: (408) 447-4222 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Segfaults and dmesg
Hi,
I wonder if anyone noticed that segfault messages are no longer appended
to the dmesg output. For me it looks like serious POLA violation. The
following script highlights the problem:
--- kaboom.sh ---
#!/bin/sh
dmesg -a > dmesg.old
cat > tst.c << EOF
#include
main () { return strlen((char *)NULL); }
EOF
cc tst.c -o tst
./tst
dmesg -a > dmesg.new
diff -d dmesg.old dmesg.new
rm -f dmesg.old tst.c tst dmesg.new
--
On a 4-STABLE system:
max@vic$ ./kaboom.sh
./kaboom.sh: line 7: 12717 Segmentation fault ./tst
345a345
> pid 12717 (tst), uid 1001: exited on signal 11
max@vic$
Whereas on a 5-CURRENT:
max@notebook$ ./kaboom.sh
./kaboom.sh: line 7: 333 Segmentation fault ./tst
max@notebook$
Please fix.
-Maxim
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: new gensetdefs breaks booting
> Bruce Evans wrote: > > > > The new gensetdefs gives unbootable kernels on i386's. They hang before > > printing anything. > > I verified that the output of gensetdefs.pl is identical to that of > gensetdefs(1). Does the kernel boot if gensetdefs(1) is used? > Its not identical here, gensetdefs.pl uses .quad for the size of the linker set (?), which should be .long for x86. Also, I'm not sure if the calculation for pointer size is correct, all the numbers seemed 3 times too big in setdefs.h. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: new gensetdefs breaks booting
Bruce Evans wrote: > > The new gensetdefs gives unbootable kernels on i386's. They hang before > printing anything. I verified that the output of gensetdefs.pl is identical to that of gensetdefs(1). Does the kernel boot if gensetdefs(1) is used? -- Marcel Moolenaar mail: [EMAIL PROTECTED] / [EMAIL PROTECTED] tel: (408) 447-4222 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Hanging on boot (Was: Interesting "man" error. Current today.)
>I also have a problem with my laptop that built world at the same >time. Because >of the above, I decided to restart it to put the kernel and programs in >sync to >see if that was causing the error. Murphy caught me in the act and my laptop >now hangs on boot:-( I haven't tried rebooting any of the other machines, >yet.) Yup same here, boot hangs. Module preloading gives garbage for module names. I was able to boot with /boot/kernel.old/kernel though... Trying to find more clues. DocWilco To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: man broken
Bruce Evans <[EMAIL PROTECTED]> writes: > man(1) was broken in rev.1.39 of src/gnu/usr.bin/man/man/man.c: Argh! I didn't test it with LC_* unset. Will fix. DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Fixed: LyX 1.1.5.2 dumping core
Jeroen Ruigrok van der Werven <[EMAIL PROTECTED]> wrote: } -On [20010127 22:30], Patrick Hartling ([EMAIL PROTECTED]) wrote: } >Making a symlink from /usr/lib/libc.so.5 to /usr/lib/libc.so.3 seems to } >have fixed my LyX problems. I'm guessing libc.so.5 and libc.so.3 were } >causing conflicts, especially with the recent changes to libc, but I'm no } >expert. Whatever the case, I can get back to work on my thesis now. :) } } Have you tried recompiling LyX with the new libc? I did try that initially, but the problems persisted until I made the symlink and relinked the executable. } That should normally clear any problems. } } I suspect from what you said above, that when you do ldd `which lyx` it } will report lyx being linked against libc.so.3, but for some reason is } trying to use the higher version libc. ldd was telling me that it had both libc.so.3 and libc.so.5 which seemed very bad to me. When I recomipled LyX to see if that would fix things, I noticed that ld was giving a warning about libc.so.3 and libc.so.5 potentially conflicting. It hadn't ever been a problem before, but it doesn't seem like the safest arrangment. With the symlink in place, ldd reports that only libc.so.5 is being used, and everything seems to be okay. -Patrick Patrick L. Hartling | Research Assistant, VRAC [EMAIL PROTECTED] | 2624 Howe Hall -- (515)294-4916 http://www.137.org/patrick/ | http://www.vrac.iastate.edu/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Interesting "man" error. Current today.
With this morning's make world, I get the following error with man. I've checked
six different machines with slightly different cvsup and build times and using
different cvsup locations. They all coincide.
FreeBSD dsl.mexcomusa.net 5.0-CURRENT FreeBSD 5.0-CURRENT #0: Fri Jan 19
07:52:22 PST 2001 [EMAIL PROTECTED]:/usr/src/sys/compile/WIC
i386
compiled this morning:
/usr/local/etc/openldap # ls -l /usr/bin/man
-r-sr-xr-x 1 man wheel 27768 Jan 28 07:11 /usr/bin/man
ERROR:
/usr/local/etc/openldap # man slapd.conf
Formatting page, please wait...Syntax error: "(" unexpected (expecting ")")
Failed.
pclose: Device not configured
Formatting page, please wait...Syntax error: "(" unexpected (expecting ")")
Failed.
pclose: Undefined error: 0
Syntax error: "(" unexpected (expecting ")")
Error executing formatting or display command.
system command exited with status 512
No manual entry for slapd.conf
I also have a problem with my laptop that built world at the same time. Because
of the above, I decided to restart it to put the kernel and programs in sync to
see if that was causing the error. Murphy caught me in the act and my laptop
now hangs on boot:-( I haven't tried rebooting any of the other machines, yet.)
I get:
FreeGSD/i386 bootstra loader, Revision 1.0
([EMAIL PROTECTED], Sun Jan 28 05:29:35 PST 2001)
/boot/kernel/kernel text=0x19af2a data=0x44224+0x1ba34
syms=[0x4+0x2b6c0+0x4+0x3344c]
I had to right this and bring it to the office to send the email so there could
be errors in the typing.
I now have my laptop cvsuping again with an old kernel.
Thanks,
ed
--
EnContacto.Net - InternetSalon.Org - CafeMania.Net
--
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: panic on last night's kernel
Hi,
Jake Burkholder wrote:
>Could you try this patch and let me know if it changes anything?
>
>Index: i386/isa/intr_machdep.c
>===
>RCS file: /home/ncvs/src/sys/i386/isa/intr_machdep.c,v
>retrieving revision 1.46
>diff -u -r1.46 intr_machdep.c
>--- i386/isa/intr_machdep.c 2001/01/21 19:25:06 1.46
>+++ i386/isa/intr_machdep.c 2001/01/27 18:51:12
>@@ -704,6 +704,7 @@
>if ((idesc->ih_flags & INTR_FAST) == 0) {
>mtx_enter(&sched_lock, MTX_SPIN);
>if (ithd->it_proc->p_stat == SWAIT) {
>+ ithd->it_proc->p_intr_nesting_level = 0;
>ithd->it_proc->p_stat = SRUN;
>setrunqueue(ithd->it_proc);
>/*
Yup, that does it. Thanks!
--
Bob Bishop (0118) 977 4017 international code +44 118
[EMAIL PROTECTED]fax (0118) 989 4254
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
new gensetdefs breaks booting
The new gensetdefs gives unbootable kernels on i386's. They hang before printing anything. Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: sh can't be exec'd
"Rogier R. Mulhuijzen wrote:" > > > >For the last week, each kernel built with fresh source code > >cannot exec sh. I've seen a lot of emails about this, but > >most were about the "correct" way to rebuild a system. > >Is this a problem affecting only me? > > I haven't had any trouble. > > How do you rebuild your system? What is the exact error you get? > And (at the risk of sounding stupid) what's the output of ls -l /bin/sh? > cd /usr/src/sys/i386/conf;config XXX;cd ../../compile/XXX; make depend; make No errors, just the usual prompt for a path to a shell, as if one had booted single user. 526188 sh, without resorting to a fixit disc. Thanks for your reply! Paul To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: sh can't be exec'd
>For the last week, each kernel built with fresh source code >cannot exec sh. I've seen a lot of emails about this, but >most were about the "correct" way to rebuild a system. >Is this a problem affecting only me? I haven't had any trouble. How do you rebuild your system? What is the exact error you get? And (at the risk of sounding stupid) what's the output of ls -l /bin/sh? DocWilco To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
I've got a feeling
..somebody's trying to sneak in our frat and it ain't gonna be nothing like that!! As a member of the same subscriber club YOU JUST GOTTA SEE THIS FRAT MOVIE at http://www.frat-movie.com I personally think each and every one of us must see it! SUPPORT BLACK MOVIES! This one IS A MUST SEE! 1Luv Grob To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
sh can't be exec'd
Hi all For the last week, each kernel built with fresh source code cannot exec sh. I've seen a lot of emails about this, but most were about the "correct" way to rebuild a system. Is this a problem affecting only me? Paul To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: about ppp..
On Fri, 26 Jan 2001, Julian Elischer wrote: > how 'current' are your systems? > when did this behaviour start? > (i.e. before or after the latest round of netgraph changes?) it is before new netgraph... i think the new netgraph cause the same problem as well.. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Fixed: LyX 1.1.5.2 dumping core
-On [20010127 22:30], Patrick Hartling ([EMAIL PROTECTED]) wrote: >Making a symlink from /usr/lib/libc.so.5 to /usr/lib/libc.so.3 seems to >have fixed my LyX problems. I'm guessing libc.so.5 and libc.so.3 were >causing conflicts, especially with the recent changes to libc, but I'm no >expert. Whatever the case, I can get back to work on my thesis now. :) Have you tried recompiling LyX with the new libc? That should normally clear any problems. I suspect from what you said above, that when you do ldd `which lyx` it will report lyx being linked against libc.so.3, but for some reason is trying to use the higher version libc. -- Jeroen Ruigrok van der Werven VIA Net.Works The Netherlands BSD: Technical excellence at its best Network- and systemadministrator D78D D0AD 244D 1D12 C9CA 7152 035C 1138 546A B867 Misery loves company... To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: kernel threading: the first steps [patch]
BTW Mark, your mail server is somehow incompatible with my ISP.. error message follows: Hi. This is the qmail-send program at syncopation-01.iinet.net.au. I'm afraid I wasn't able to deliver your message to the following addresses. This is a permanent error; I've given up. Sorry it didn't work out. <[EMAIL PROTECTED]>: Connected to 196.7.18.141 but sender was rejected. Remote host said: 550 5.0.0 Access denied -- __--_|\ Julian Elischer / \ [EMAIL PROTECTED] ( OZ) World tour 2000-2001 ---> X_.---._/ v To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: kernel threading: the first steps [patch]
Mark Murray wrote: > > > > This is the single most flagrant lack of cooperation I have experienced > > > while working with the FreeBSD Project. I'm truly dumbfounded. > > > > It's not a lack of co-operation.. it's a lack of communication. I didn't > > see an any lists that anyone was doing this yet and thought I'd get > > the ball rolling to promote discussion.. I'm dumfounded to discover that you've > > done work here already as I thought I'd have heard of it. I'm sad you > > take it as an insult. All I want is to start discussion, and I was doing > > it as a way of clarifying my thoughts as to what wqas needed. > > Um, Julian - I have known about this for a good couple of months. I > can't remember specifically _how_ I know; suffice to say there has > been a fair bit of dialogue on the lists and Jason's progress-page > has a good overview. > > http://people.freebsd.org/~jasone/smp/ Ok so I had another look and I was mostly right the first time.. That is the SMP page. This is kernel support for threading.. A differnt issue. There is no mention on the SMP progress page of ANYONE splitting the process structure. Looking around his site I found the 'kse' page http://people.freebsd.org/~jasone/kse previously I only knew of http://people.freebsd.org/~jasone/refs/freebsd_kse/freebsd_kse.html >From the newly found page I see that indeed he has reported having done this.. But I didn't know about that page before. I sent a mail on the topic on November 26 to -arch (where threading conversation was based) and with JasonE specifically CC'd. So he cannot claim that he wasn't informed. (others reponded to the mail so I know it went out). (He didn't respond) If he had bothered to answer my mail with the fact that he had just done this a few days before, I would have been delighted. Since I was the person that was instrumental in pusing the KSE model forward, I find it strange that Jason didn't let me know what was going on. I only found this page because I figured that there must be something there that I didn't know about, after others (the first being phk) told me that "Hey Jason's already done that". I'm on -arch, -current and -smp and I didn't see any comments on this. Blaming me is the wrong direction to point the finger.. we just need to ensure that all players know what is currently being discussed where. In any case it was only a 5 hour hack so if I've duplicated his work I've only wasted 5 hours of my time. I'm pleased that Jason did this and I'm trying to find out where I can get a copy of his work to look at. > > M > -- > Mark Murray > Warning: this .sig is umop ap!sdn > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-current" in the body of the message -- __--_|\ Julian Elischer / \ [EMAIL PROTECTED] ( OZ) World tour 2000-2001 ---> X_.---._/ v To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: kernel threading: the first steps [patch]
> > This is the single most flagrant lack of cooperation I have experienced > > while working with the FreeBSD Project. I'm truly dumbfounded. > > It's not a lack of co-operation.. it's a lack of communication. I didn't > see an any lists that anyone was doing this yet and thought I'd get > the ball rolling to promote discussion.. I'm dumfounded to discover that you've > done work here already as I thought I'd have heard of it. I'm sad you > take it as an insult. All I want is to start discussion, and I was doing > it as a way of clarifying my thoughts as to what wqas needed. Um, Julian - I have known about this for a good couple of months. I can't remember specifically _how_ I know; suffice to say there has been a fair bit of dialogue on the lists and Jason's progress-page has a good overview. http://people.freebsd.org/~jasone/smp/ M -- Mark Murray Warning: this .sig is umop ap!sdn To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: kernel threading: the first steps [patch]
Jason Evans wrote: > > On Sat, Jan 27, 2001 at 12:33:23AM -0800, Root Dude wrote: > > > > Here's a first step. > > This is very disappointing, Julian. You've duplicated work that I've > already done, and if you've been paying attention at all, you know that it > was already done. Even if you haven't been paying attention, I find it > particularly telling that you never even sent me email about this. I didn't even know I was going to do it, How could I let you know I was going to :-) ... it only took 5 hours while sitting in economy class.. you couldn't tell, but I sent it from the passenger lounge at singapore airport. > > This is the single most flagrant lack of cooperation I have experienced > while working with the FreeBSD Project. I'm truly dumbfounded. It's not a lack of co-operation.. it's a lack of communication. I didn't see an any lists that anyone was doing this yet and thought I'd get the ball rolling to promote discussion.. I'm dumfounded to discover that you've done work here already as I thought I'd have heard of it. I'm sad you take it as an insult. All I want is to start discussion, and I was doing it as a way of clarifying my thoughts as to what wqas needed. > > Jason Jason,. how would I know you have done this? As the person who was leading the discussion on arch, I assumed that if anyone did it they would mention it at least and that I would hear about it.. I assumed that since no-one mentionned anything about it, that they were waiting until the SMP locking was a litlle more settled before starting. I've been paying attention in smp, arch and current, and seen no mention of it, and I sent an email on this 3 months ago that no-one really responded to.. Is there another list I should be on that I don't know about? And anyhow, It only took about 5 hours on a plane.. I was amazed at how little work it was and how quick it was.. I was doing it only as a thought exercise but to my amazement it actually worked !! If you've already done this, then 'great' but you could have answered my previous email asking if anyone was doing it yet.. You can hardly say that you didn't know I was interested in it (BTW The comments I made on your doc still stand, though I noticed the last I looked that the doc had'nt changed..) -- __--_|\ Julian Elischer / \ [EMAIL PROTECTED] ( OZ) World tour 2000-2001 ---> X_.---._/ v To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
ps -j broken
I'm running -current source from 26th Jan 2001 on an alpha and getting the following error: # ps -j ps: sess: keyword not found USER PID PPID PGID JOBC STAT TT TIME COMMAND root 367 364 3671 DWp00:00.02 msu (su2) root 368 367 3681 DW+ p00:00.14 -csh (tcsh) [...] A verification with i386 and 7th Jan Source: # ps -j ps: sess: keyword not found USER PID PPID PGID JOBC STAT TT TIME COMMAND root 48574 2792 485741 S pg0:00.16 /tcsh root 48577 48574 485771 R+pg0:00.01 ps -j [...] -- 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
/etc/shells #include syntax support patch
Hi,
Asbestos suit on, round two.
The patch below changes getusershell to support a #include syntax
in /etc/shells. It is against RELENG_4 and may require a bit of fiddling
to apply to -current (because of nsdispatch()).
Everything that I can find is using it (well adduser.perl has the
same support written in perl) including sendmail although I cannot see why
sendmail isn't using it's built in fallback code, but it isn't somewhere
I haven't found HASGETUSERSHELL is being set or assumed. I'm not looking
anymore.
The changes are confined to adduser.perl, getusershell.c and shells.
BTW: is there a reason for the avoidance of my in adduser.perl ?
Index: etc/shells
===
RCS file: /home/ncvs/src/etc/shells,v
retrieving revision 1.3.2.1
diff -u -r1.3.2.1 shells
--- etc/shells 2000/07/10 08:47:17 1.3.2.1
+++ etc/shells 2001/01/27 16:32:01
@@ -1,4 +1,4 @@
-# $FreeBSD: src/etc/shells,v 1.3.2.1 2000/07/10 08:47:17 obrien Exp $
+# $FreeBSD: src/etc/shells,v 1.3 1999/08/27 23:23:45 peter Exp $
#
# List of acceptable shells for chpass(1).
# Ftpd will not allow users to connect who are not using
@@ -7,3 +7,4 @@
/bin/sh
/bin/csh
/bin/tcsh
+#include /usr/local/etc/shells
Index: lib/libc/gen/getusershell.c
===
RCS file: /home/ncvs/src/lib/libc/gen/getusershell.c,v
retrieving revision 1.3
diff -u -r1.3 getusershell.c
--- lib/libc/gen/getusershell.c 1999/11/04 04:16:28 1.3
+++ lib/libc/gen/getusershell.c 2001/01/28 08:57:29
@@ -45,6 +45,7 @@
#include
#include
#include
+#include
/*
* Local shells should NOT be added here. They should be added in
@@ -52,8 +53,9 @@
*/
static char *okshells[] = { _PATH_BSHELL, _PATH_CSHELL, NULL };
-static char **curshell, **shells, *strings;
+static char **curshell, **shells;
static char **initshells __P((void));
+static int shellslots = 0;
/*
* Get a list of shells from _PATH_SHELLS, if it exists.
@@ -74,66 +76,87 @@
void
endusershell()
{
-
- if (shells != NULL)
+ char **sp;
+ if (shells != NULL) {
+ for (sp = shells; *sp; sp++) {
+ free (*sp);
+ }
free(shells);
+ }
shells = NULL;
- if (strings != NULL)
- free(strings);
- strings = NULL;
+ shellslots = 0;
curshell = NULL;
}
void
setusershell()
{
-
curshell = initshells();
}
static char **
-initshells()
+readshellfile (char *path)
{
- register char **sp, *cp;
register FILE *fp;
- struct stat statb;
+ static int sp;
+ register char *cp;
+ void *new;
+ char buf[MAXPATHLEN];
+ char *st;
+ int newslots;
- if (shells != NULL)
- free(shells);
- shells = NULL;
- if (strings != NULL)
- free(strings);
- strings = NULL;
- if ((fp = fopen(_PATH_SHELLS, "r")) == NULL)
- return (okshells);
- if (fstat(fileno(fp), &statb) == -1) {
- (void)fclose(fp);
- return (okshells);
- }
- if ((strings = malloc((u_int)statb.st_size)) == NULL) {
- (void)fclose(fp);
- return (okshells);
+ if (shellslots == 0) {
+ sp = 0;
}
- shells = calloc((unsigned)statb.st_size / 3, sizeof (char *));
- if (shells == NULL) {
- (void)fclose(fp);
- free(strings);
- strings = NULL;
- return (okshells);
- }
- sp = shells;
- cp = strings;
- while (fgets(cp, MAXPATHLEN + 1, fp) != NULL) {
+ if ((fp = fopen(path, "r")) == NULL)
+ return (NULL);
+ while (fgets(buf, MAXPATHLEN + 1, fp) != NULL) {
+ cp = buf;
while (*cp != '#' && *cp != '/' && *cp != '\0')
cp++;
- if (*cp == '#' || *cp == '\0')
+ if (*cp == '#' || *cp == '\0') {
+ if (!strncmp (cp, "#include", 8)) {
+ cp++;
+ while (*cp != '#' && *cp != '/' && *cp != '\0')
+ cp++;
+ if (*cp == '/') {
+ char *fn = cp;
+ while (!isspace((unsigned char)*cp) && *cp !=
+'#' && *cp != '\0')
+ cp++;
+ *cp++ = '\0';
+ readshellfile (fn);
+ }
+ }
continue;
- *sp++ = cp;
+ }
+ if (sp >= (shellslots - 1)) {
+ newslots = shellslots ? 2*shellslots : 8;
+ new = re
Re: kernel threading: the first steps [patch]
Poul-Henning Kamp wrote: > > In message <[EMAIL PROTECTED]>, Root Dude writes: > > > >Here's a first step. > > > >I've broken the proc structure into 4 structures. [...] > > Uhm Julian, > > You are aware that other people are working on this stuff too ? well considering that I was int he discussions and since then no-one has said anything, no as far as I know, no-one is currently working on this... if htey are then hey shuld have mentionned it to dan eischen and me since we were leading the discussions. > > -- > 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. -- __--_|\ Julian Elischer / \ [EMAIL PROTECTED] ( OZ) World tour 2000-2001 ---> X_.---._/ v To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: about ppp..
Idea Receiver wrote: > > One of my current machines here are running PPPoE.. > for some reason, it will some times become extramly lag of its PPPoE > connection. (for example, from 25ns ping time become 2500ns ping > time). And will back to normal in few mins.. > However, i do not see the same problem on my 4.2 stable system. how 'current' are your systems? when did this behaviour start? (i.e. before or after the latest round of netgraph changes?) > > is this a known problem or just me? plz help! > > thx.. > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-current" in the body of the message -- __--_|\ Julian Elischer / \ [EMAIL PROTECTED] ( OZ) World tour 2000 ---> X_.---._/ from Perth, presently in: Budapest v To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
man broken
man(1) was broken in rev.1.39 of src/gnu/usr.bin/man/man/man.c:
$ man ls
Syntax error: "(" unexpected (expecting ")")
Error executing formatting or display command.
system command exited with status 512
Syntax error: "(" unexpected (expecting ")")
Error executing formatting or display command.
system command exited with status 512
No manual entry for man
$ man -d ls
...
trying command: (cd /usr/share/man ; /usr/bin/zcat /usr/share/man/man1/ls.1.gz |
/usr/bin/tbl | /usr/bin/groff -S -Wall -mtty-char -mandoc(null) | /usr/bin/col | less
-i)
Bruce
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
