Re: -current freezes when I try to connect to it.
On Fri, 1 Sep 2000, Justin Ovens [[EMAIL PROTECTED]] wrote: What would cause freebsd -current to lock up when i telnet, ftp, or ssh to it? Somthing with inetd? chgsbsize breakage from a few days ago? -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Justin Ovens ([EMAIL PROTECTED]) System/Network Administrator http://www.lostworld.net http://resume.lostworld.net -- Personal Resume. *** aztec.rcinfo.net can't find resume.lostworld.net: Non-existent host/domain - 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
Restricting ftpd commands (fwd)
The following got no response on -security two weeks ago. Perhaps -current will have more opinions. -- Forwarded message -- I have found quite a few commands that ftpd shouldn't necessarily be responding to if the user hasn't logged in. In total, the following commands are taught to not talk to strangers: TYPE, STRU, MODE, ALLO, ABOR, SITE IDLE, SYST, REST. Many of these were obtained from OpenBSD. See http://www.fxp.org/~jedgar/ftpcmd.y.diff for the diff. - 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
Re: ppp
On Wed, 2 Aug 2000, Piotr [iso-8859-1] Woniak wrote: Hi, Below I have part of ppp.log. Could you tell me what the fifth line does mean? What is CD? Carrier Detect? When I try to connect using ATDT12345 I get message 'BUSY'. -- Aug 2 11:57:11 sec ppp[205]: tun0: Phase: bundle: Establish Aug 2 11:57:11 sec ppp[205]: tun0: Phase: deflink: closed - opening Aug 2 11:57:11 sec ppp[205]: tun0: Phase: deflink: Connected! Aug 2 11:57:11 sec ppp[205]: tun0: Phase: deflink: opening - carrier Aug 2 11:57:12 sec ppp[205]: tun0: Phase: deflink: /dev/cuaa1 doesn't support CD -- what does it mean?? Aug 2 11:57:12 sec ppp[205]: tun0: Phase: deflink: carrier - ready -- Piotr Wozniak Any relation? :) - 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
Re: -current buildkernel problems.
On Wed, 2 Aug 2000, Rex A. Roof wrote: ok, here's the output from uname -a FreeBSD shaolin.wccnet.org 5.0-CURRENT FreeBSD 5.0-CURRENT #2: Thu Apr 27 19:04:53 EDT 2000 [EMAIL PROTECTED]:/usr/src/sys/compile/SHAOLIN i386 usually, in the past, I've found the best way to upgrade (and, what I thought was the proper way) was to make a new kernel, reboot on it, and then build world is that not the right away? Not according to the handbook. The above is used under OpenBSD though. - 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
Re: HEADS UP: /etc/rc.shutdown calls local scripts now
On Thu, 6 Jul 2000, David Scheidt wrote: On Thu, 6 Jul 2000, Linh Pham wrote: : : Can we have little green "[ OK ]"s as well? :) : : j/k : :I hope you are joking... LOL... We don't want Linux emulation to go in :that direction. HP/UX does something like this. I find it rather useful, but that may be because I have boxes that take almost an hour to boot Many Linux distributions do this too. It seems about as useful as a car's idiot light(s)... IMO, I would prefer to see useful information during boot than that eye-candy. ----- 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
Re: MAKEDEV warning with sysinstall ?
On Tue, 9 May 2000, Sheldon Hearn wrote: On Mon, 08 May 2000 15:41:55 EST, Erik de Zeeuw wrote: I ran MAKEDEV all, but the message still appear. The messages I found about this on the archives says to do a 'ls -l /dev | grep ^b', and to remake all devices listed, but there's no device listed when I'm doing the 'ls -l /dev | grep ^b'. I'm not sure what that'll score you. Try this: cd /dev for i in `ls`; do if test -b $i; then echo $i; fi; done Hmmm... find /dev -type b -print - 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
Re: MAKEDEV warning
On Tue, 18 Apr 2000, Ted Sikora wrote: After building a new kernel yesterday after a cvsup the following appeared. Apr 17 23:07:42 telecast /kernel: WARNING: run /dev/MAKEDEV before 2000-06-01 to get rid of block devices I did a MAKEDEV all and the message still persists. ls -l /dev | grep ^b and remake/remove those devices as appropriate - 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
Re: reproducable system crash in 4.0-STABLE
On Fri, 24 Mar 2000, Alan Clegg wrote:
I know this is not "current", but it was last week, so give me a break.
On a dual PII system, access to /dev/smb0 (system management bus) by
wmhm (/usr/ports/sysutils/wmhm) or gkrellm (/usr/ports/sysutils/gkrellm)
causes an immediate system panic.
I have the following in dmesg:
smbus0: System Management Bus on bti2c0
smb0: SMBus general purpose I/O on smbus0
and I have system dumps available to whoever wants.
I got similiar panics when I was working on my {wm}lmmon ports. You need:
device intpm
in your kernel config (or use the /dev/io method).
I reported this when I found it a few months ago, but no one seemed to
care. The system shouldn't panic if the device isn't present in the
kernel, but...
-----
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
Re: Upgrade to current from 3.3-RELEASE
On Tue, 29 Feb 2000, Aaron Hughes wrote: I cvsup upgraded my /src dir to 'release=cvs tag=.' which I believe to be 4.0-CURRENT. I successfully completed a 'make -j10 buildworld', however, when I ran make -j10 installworld' I received the following error: Please read src/UPDATING: COMMON ITEMS: *snip* To update from 3.x to 4.0 stable cd /usr/src make buildworld cd sbin/mknod make install follow directions to build/install a kernel follow rebuild disk /dev entries above[*] reboot in single user cd /usr/src make -DNOINFO installworld make installworld NOTE: 'make -DNOINFO installworld' above - 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
Re: NO_DESCRYPT patch
On Sat, 26 Feb 2000, Kris Kennaway wrote: This is something which has been requested a fair bit..it will disable the building of the DES CRYPT libraries even if you have the crypto sources installed, so you can e.g. get OpenSSL/OpenSSH without having to deal with the pitfalls of libdescrypt. It seems to work fine for me..if I hear any other positive feedback I'll commit it. Works for me... /etc/make.conf: CFLAGS= -O -pipe COPTFLAGS= -O -pipe NO_DESCRYPT=YES RSAREF= YES USA_RESIDENT= YES The resulting libs after installworld: jedgar@earth:~$ ll /usr/lib/*crypt* lrwxr-xr-x 1 root wheel 11 Feb 26 22:12 /usr/lib/libcrypt.a - libscrypt.a lrwxr-xr-x 1 root wheel 12 Feb 26 22:12 /usr/lib/libcrypt.so - libscrypt.so lrwxr-xr-x 1 root wheel 14 Feb 26 22:12 /usr/lib/libcrypt.so.2 - libscrypt.so.2 lrwxr-xr-x 1 root wheel 13 Feb 26 22:12 /usr/lib/libcrypt_p.a - libscrypt_p.a -r--r--r-- 1 root wheel 1088060 Feb 26 22:16 /usr/lib/libcrypto.a lrwxr-xr-x 1 root wheel 14 Feb 26 22:16 /usr/lib/libcrypto.so - libcrypto.so.1 -r--r--r-- 1 root wheel 651156 Feb 26 22:16 /usr/lib/libcrypto.so.1 -r--r--r-- 1 root wheel 1161880 Feb 26 22:16 /usr/lib/libcrypto_p.a -r--r--r-- 1 root wheel8632 Feb 26 22:12 /usr/lib/libscrypt.a lrwxr-xr-x 1 root wheel 14 Feb 26 22:12 /usr/lib/libscrypt.so - libscrypt.so.2 -r--r--r-- 1 root wheel5084 Feb 26 22:12 /usr/lib/libscrypt.so.2 -r--r--r-- 1 root wheel9278 Feb 26 22:12 /usr/lib/libscrypt_p.a jedgar@earth:~$ - 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
Re: Is openssl/openssh working right yet for others?
On Fri, 25 Feb 2000, Ray Kohler wrote: I know that openssl and openssh were under heavy construction (yesterday?), but since the commits have stopped (for now), I was wondering is anyone else is able to build it. Going to /usr/src/secure and running make produces a problem due to a missing buildinf.h, which should be automatically generated (in *should* be automatically generated as a depends target, but isn't for some reason. Try 'make depend' in /usr/src/secure before building. - 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
Re: kdelibs port broken?
On Tue, 22 Feb 2000, William Woods wrote: On 22-Feb-00 Will Andrews wrote: On Tue, Feb 22, 2000 at 07:40:55AM -0800, William Woods wrote: ON that subject, has anyone tried compiling the KDE port with the new QT145 port? In my original tests, Qt 1.45 works fine with the KDE ports. Do you have any problems with it? Yea, after I compiled QT145, I couldent compile KDE. I am not sure of the exact error, it was a few days ago and I went back to 142, but It wouldent comile. Did you change the depends under USE_QT in bsd.port.mk to use qt.3 (provided by qt145) instead of qt.2 (provided by qt142)? I'm using qt145/kde under -CURRENT and -STABLE (under OLDGCC *and* NEWGCC) without problems. - 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
Re: cvs commit: src/usr.sbin/pkg_install/delete main.csrc/usr.sbin/pkg_install/info main.c
On Mon, 17 Jan 2000, Dan Moschuk wrote:
dan 2000/01/17 17:45:54 PST
Modified files:
usr.sbin/pkg_install/delete main.c
usr.sbin/pkg_install/info main.c
Log:
Fix a bug in previous commit where pkg_{delete,info} foo-1.0/ would segfault.
Noticed first by: kris
Is it just me, or does: 'pkg_delete foo-1.0/' now just spin in the
while() loop around line 92 of src/usr.sbin/pkg_install/delete/main.c ?
-
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
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
Re: libstdc++.so.3
On Sun, 30 Jan 2000, Edwin Culp wrote: I make a new world today after reinstalling xinstall and thought that along with recompiling my applications that are having problems that I assume started with the c++ compiler change, but I have recompiled several applications and still have the errors. If someone would tell me what I am doing wrong. This is from the latest version of mysql that I just compiled. Error: /usr/libexec/ld-elf.so.1: /usr/lib/libstdc++.so.3: Undefined symbol "_vt$9exception" Please read the first 2124 entry of 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
Re: Hrmm whats missing ?
On Sat, 22 Jan 2000, TrouBle wrote: Jan 22 16:00:14 angelsguardian ftpd[7395]: auth_pam: Permission denied Jan 22 16:00:14 angelsguardian ftpd[7395]: auth_pam: Permission denied You didn't run mergemaster/update /etc; in particular, install/update pam.conf (note the auth_pam above). - 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
Re: libGGI
On Sat, 15 Jan 2000, Andres wrote: hi, I apologize if this is not the right list to post to, but i didn't know where else to do it so here goes: is anyone interested/currently working on a libGGI port ? or currently using libGGI on FreeBSD ? Actually the correct list would be [EMAIL PROTECTED] since you are wanting to port an application...and see http://www.FreeBSD.org/cgi/query-pr.cgi?pr=15938 for a recent port submission for libggi. - 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
Softupdates panic?
The following backtrace comes from a panic I just had on my laptop
that appears to be softupdates-related. Sources are from yesterday,
re-cvsup'ing shows no new fs-related sources updated. At the time I was
in the middle of compiling the Window Maker port (actually compiling the
jpeglib dependency).
ffs_softdep.c version below, others available upon request (along with
kernel.debug/vmcore info):
$FreeBSD: src/sys/contrib/softupdates/ffs_softdep.c,v 1.47 2000/01/11
06:52:35 mckusick Exp $
ata-pci0: Intel PIIX4 ATA-33 controller port 0x3000-0x300f at device 1.1
on pci0
ata-pci0: Busmastering DMA supported
ata0 at 0x01f0 irq 14 on ata-pci0
ad0: FUJITSU MHA2021AT/8210 ATA-3 disk at ata0 as master
ad0: 2067MB (4233600 sectors), 4200 cyls, 16 heads, 63 S/T, 512 B/S
ad0: 16 secs/int, 1 depth queue, WDMA2
Script started on Wed Jan 12 12:25:45 2000
root@pluto:~# gdb -k /sys/compile/PLUTO/kernel.debug /var/crash/vmcore.0
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"...
IdlePTD 3149824
initial pcb at 28b660
panicstr: from debugger
panic messages:
---
panic: flush_pagedep_deps: flush 3 failed
panic: from debugger
Uptime: 23h19m6s
dumping to dev #ad/0x30001, offset 131072
dump ata0: resetting devices .. done
64 63 62 61 60 59 58 57 56 55 54 53 52 51 50 49 48 47 46 45 44 43 42 41 40 39 38 37 36
35 34 33 32 31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6
5 4 3 2 1
---
#0 boot (howto=260) at ../../kern/kern_shutdown.c:304
304 dumppcb.pcb_cr3 = rcr3();
(kgdb) bt
#0 boot (howto=260) at ../../kern/kern_shutdown.c:304
#1 0xc01373a5 in panic (fmt=0xc0235bf4 "from debugger")
at ../../kern/kern_shutdown.c:554
#2 0xc011c419 in db_panic (addr=-1071552339, have_addr=0, count=-1,
modif=0xc72a18d0 "") at ../../ddb/db_command.c:433
#3 0xc011c3b9 in db_command (last_cmdp=0xc025e8b8, cmd_table=0xc025e718,
aux_cmd_tablep=0xc02878cc) at ../../ddb/db_command.c:333
#4 0xc011c47e in db_command_loop () at ../../ddb/db_command.c:455
#5 0xc011e507 in db_trap (type=3, code=0) at ../../ddb/db_trap.c:71
#6 0xc0216651 in kdb_trap (type=3, code=0, regs=0xc72a19d8)
at ../../i386/i386/db_interface.c:158
#7 0xc0222088 in trap (frame={tf_fs = 16, tf_es = 16, tf_ds = 16,
tf_edi = 276254, tf_esi = 256, tf_ebp = -953542112, tf_isp = -953542140,
tf_ebx = -1071353856, tf_edx = 0, tf_ecx = 0, tf_eax = 18,
tf_trapno = 3, tf_err = 0, tf_eip = -1071552339, tf_cs = 8,
tf_eflags = 582, tf_esp = -1071302401, tf_ss = -1071410141})
at ../../i386/i386/trap.c:531
#8 0xc02168ad in Debugger (msg=0xc0239423 "panic") at machine/cpufunc.h:64
#9 0xc013739c in panic (fmt=0xc0247000 "flush_pagedep_deps: flush 3 failed")
at ../../kern/kern_shutdown.c:552
#10 0xc01d01f2 in flush_pagedep_deps (pvp=0xc7391ea0, mp=0xc0ffd800,
diraddhdp=0xc11246a4) at ../../ufs/ffs/ffs_softdep.c:4248
#11 0xc01cfaf8 in softdep_sync_metadata (ap=0xc72a1b6c)
at ../../ufs/ffs/ffs_softdep.c:3934
---Type return to continue, or q return to quit---
#12 0xc01d3a6c in ffs_fsync (ap=0xc72a1b6c) at ../../ufs/ffs/ffs_vnops.c:249
#13 0xc01cab08 in ffs_truncate (vp=0xc7391ea0, length=1024, flags=4,
cred=0xc1006400, p=0xc6d6e100) at vnode_if.h:537
#14 0xc01d6277 in ufs_direnter (dvp=0xc7391ea0, tvp=0xc7378180,
dirp=0xc72a1cb8, cnp=0xc72a1f04, newdirbp=0x0)
at ../../ufs/ufs/ufs_lookup.c:842
#15 0xc01da137 in ufs_makeinode (mode=33188, dvp=0xc7391ea0, vpp=0xc72a1ef0,
cnp=0xc72a1f04) at ../../ufs/ufs/ufs_vnops.c:2159
#16 0xc01d7994 in ufs_create (ap=0xc72a1e10) at ../../ufs/ufs/ufs_vnops.c:183
#17 0xc01da1c1 in ufs_vnoperate (ap=0xc72a1e10)
at ../../ufs/ufs/ufs_vnops.c:2283
#18 0xc0166b1c in vn_open (ndp=0xc72a1edc, fmode=1538, cmode=420)
at vnode_if.h:106
#19 0xc0162de1 in open (p=0xc6d6e100, uap=0xc72a1f80)
at ../../kern/vfs_syscalls.c:994
#20 0xc0222956 in syscall (frame={tf_fs = 47, tf_es = 47, tf_ds = 47,
tf_edi = 1, tf_esi = 135000800, tf_ebp = -1077939148,
tf_isp = -953540652, tf_ebx = -1, tf_edx = 134975904,
tf_ecx = -1077939096, tf_eax = 5, tf_trapno = 12, tf_err = 2,
tf_eip = 134692812, tf_cs = 31, tf_eflags = 663, tf_esp = -1077939192,
tf_ss = 47}) at ../../i386/i386/trap.c:1055
#21 0xc0216f56 in Xint0x80_syscall ()
#22 0x8056afd in ?? ()
#23 0x804b9e5 in ?? ()
---Type return to continue, or q return to quit---
#24 0x804a94c in ?? ()
#25 0x804a785 in ?? ()
#26 0x804a8a2 in ?? ()
#27 0x8051ac6 in ?? ()
#28 0x8051a32 in ?? ()
#29 0x80480f9 in ?? ()
(kgdb)
root@pluto:~#
Script done on Wed Jan 12 12:25:56
Re: multiple cd devices
On Fri, 31 Dec 1999, Chuck Robey wrote: On Fri, 31 Dec 1999, Brian Fundakowski Feldman wrote: The way certain devices, like cd with its monotonically increasing counter where devices are probed in order and assigned device based on precedence and not hardwiring/controller connection, work is consistent between the kernel and MAKEDEV. If you have 2 cd devices, you have cd0 and cd1, so MAKEDEV accepts "cd2" for "two cd devices". All CD devices work that way. Disks don't, because there is potential for hard-wiring there, and will often be gaps. Why are "certain" devices wildly different than all other ones? I've never encountered that kind of syntax before, and I can't see that it's documented anywhere at all. Certainly, MAKEDEV itself (in it's comments) treats cd* just like all the others, specifying that the number following is a unit number, and *not* a quantity. I don't know when this happened, but it's surely not obvious. Not one word in the handbook, either. In fact, according to cd(4), you *can* specify the unit number: ... Prior to FreeBSD 2.1, the first device found will be attached as cd0 the next, cd1, etc. Beginning in FreeBSD 2.1 it is possible to specify what cd unit a device should come on line as; refer to scsi(4) for details on kernel configura- tion. That makes this odd setup even odder. Can't understand why this was done. FWIW, bin/13768 asks the same questions. - 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
Re: sysinstall: is it really at the end of its lifecycle?
On Wed, 15 Dec 1999, Wilko Bulte wrote: On Tue, Dec 14, 1999 at 05:28:32PM -0600, Chris Costello wrote: On Tue, Dec 14, 1999, Donn Miller wrote: Maybe we could call it "sysconfig", in honor of the old /etc/sysconfig file that was superceded bt /etc/rc.conf. That's not very creative! I had "Trident" in mind. Only problem is that the name is used by a company that makes video card chips and another company that makes chewing gum. Call it Inuit. (rationale: Inuit feed on pinguins (right?)) When I first saw 'Inuit', I thought it was 'Tuit'...therefore we, when distributing on CD's, can claim that we are providing a 'round-tuit'. /me ducks - 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
Re: libc_r.so.3 and compat3x
On Tue, 30 Nov 1999, David O'Brien wrote: that it requires libc_r.so.3; unfortunately, compat3x does not contain this lib. Any chance of having it added to compat3x? Yes. The PR is assigned to me, but David already has it on his TODO list. Compat3x is updated late to make sure the latest libraries are in. Until 3.4-REL (when libc*.so.3 will be added to compat3x), you can download the bin.?? files from a 3-STABLE snapshot and grab them. That's kinda hefty for a small port :) I have it marked as broken for -current until the lib is in compat3x. - Chris D. Faulhaber | You can ISO9001 certify the process of System/Network Administrator,| shooting yourself in the foot, so long Reality Check Information, Inc. | as the process is documented and reliably [EMAIL PROTECTED] | produces the proper result. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: libc_r.so.3 and compat3x
On Wed, 1 Dec 1999, David O'Brien wrote: On Wed, Dec 01, 1999 at 07:49:19AM -0500, Chris D. Faulhaber wrote: That's kinda hefty for a small port :) I have it marked as broken for -current until the lib is in compat3x. Why? Many of us still have libc*.so.3 from when that was the version in -CURRENT until a month ago. For those who (re)install -current from scratch. I guess I'll add a hook that checks for libc_r.so.3 and inform them that lib is necessary. - Chris D. Faulhaber | You can ISO9001 certify the process of System/Network Administrator, | shooting yourself in the foot, so long Reality Check Information, Inc. | as the process is documented and reliably [EMAIL PROTECTED]| produces the proper result. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: make buildworld problem...
On Thu, 28 Oct 1999, Marcel Moolenaar wrote:
Peter Jeremy wrote:
(/me wonders how many MORE times we are going to have to say this because
of the signal changes...)
A very large number I suspect.
IMHO, the correct solution is to for the entire make world process to
be re-worked.
That's what I'm currently doing. If I have a stripped down make process
ready for public viewing, I'll let you all know. A thread on the subject
can be found in the -arch archives.
As an interim hack, would the following patch, which verifies
kern.osreldate = 400011, suffice?
Index: Makefile.inc0
===
RCS file: /home/ncvs/src/Makefile.inc0,v
retrieving revision 1.18
diff -u -r1.18 Makefile.inc0
--- Makefile.inc0 1999/08/28 01:35:58 1.18
+++ Makefile.inc0 1999/10/29 12:41:18
@@ -15,6 +15,11 @@
MAKEOBJDIRPREFIX?=/usr/obj
#
+# Check kern.osreldate to ensure kernel will support building world
+#
+OSRELDATE= `/sbin/sysctl -a | grep osreldate | awk '{ print $$2; }'`
+
+#
# Variables passed to make work better if they are set as environment
# variables instead of command line options.
#
@@ -106,6 +111,13 @@
# support if the current object format is elf on i386.
#
buildworld :
+ @if [ ${OSRELDATE} -lt "400011" ]; then \
+ echo; \
+ echo "The current kernel does not support building world. Please
+read"; \
+ echo "the 19990929 entry in ${.CURDIR}/UPDATING for more
+information."; \
+ echo; \
+ exit 1; \
+ fi
@cd ${.CURDIR}; ${MK_ENV} ${MAKE} buildworld
.if${MACHINE_ARCH} == "i386" ${OBJFORMAT} == "elf" defined(WANT_AOUT)
@cd ${.CURDIR}; ${LEGACY_ENV} ${XMAKE} legacy-build
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: Abit's BP6 and 'lmmon' or 'chm'
On Mon, 11 Oct 1999, Nickolay Dudorov wrote:
Does anybody successfully use ports/sysutils/{lmmon|chm}
with the Abit's BP6 motherboard ?
After 'make install'-ing ports and adding
controller smbus0
controller iicbus0
controller iicbb0
controller intpm0
device smb0 at smbus?
to kernel config file (and config, make depend, make, make install,
reboot the new kernel) I only receive:
IOCTL: device not configured
from lmmon and chm.
This is due to the intpm controller not configuring the motherboards PM
controller, not because the software.
I emailed Takanori Watanabe a while back concerning this MB. His thoughts
were that: 1) He hadn't heard of the driver working in an SMP environment;
2) It may be due to the controller using an unconfigured ISA interface.
Anyone else wish to comment?
-
Chris D. Faulhaber [EMAIL PROTECTED] | All the true gurus I've met never
System/Network Administrator,| claimed they were one, and always
Reality Check Information, Inc. | pointed to someone better.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: shell script trouble
On Fri, 8 Oct 1999, Pascal Hofstee wrote: su-2.03# /usr/local/sbin/postfix reload postfix-script: fatal: the Postfix mail system is not running I Know the mail system IS running on Postfix though: su-2.03# ps -aux | egrep postfix postfix 205 0.0 0.7 928 612 ?? I 5:01PM 0:00.26 qmgr -l -t fifo postfix 1585 0.0 0.5 872 508 ?? I11:39PM 0:00.02 pickup -l -t fif postfix 1809 0.0 0.8 952 724 ?? I12:11AM 0:00.02 smtpd -n smtp -t postfix 1810 0.0 0.7 928 680 ?? I12:11AM 0:00.02 cleanup -t unix postfix 1811 0.0 0.6 900 584 ?? I12:11AM 0:00.02 trivial-rewrite postfix 1812 0.0 0.8 956 712 ?? I12:11AM 0:00.02 local -t unix There are some of Postfix's daemons running above, but you seem to be missing: root 286 0.0 0.8 872 220 ?? Is 29Sep99 0:10.23 /usr/local/libexec/postfix/master Which is the actual process that listens on port 25. Since 'postfix reload' cannot communicate with master, it says that postfix is not running. Next step, find out where your master is? - Chris D. Faulhaber [EMAIL PROTECTED] | All the true gurus I've met never System/Network Administrator,| claimed they were one, and always Reality Check Information, Inc. | pointed to someone better. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: CVSup core dumps
On Mon, 4 Oct 1999, John Polstra wrote: I've seen a few reports that CVSup has suddenly started dumping core on a segmentation violation under -current, but I need more information. For starters, I would like to know whether the static binary (ports/net/cvsup-bin) works or not under the very latest -current on the i386. Could somebody please check that and report back to the list? I can't sacrifice my i386 -current machine to the cause right now. It works here with world/kernel built this morning from sources cvsup'd at 0100 EDT from cvsup6.freebsd.org. - what is the output from "cvsup -v"? earth:~# cvsup -v CVSup client, GUI version Software version: REL_16_0 Protocol version: 16.0 http://www.polstra.com/projects/freeware/CVSup/ Report problems to [EMAIL PROTECTED] earth:~# - is "cvsup" a static binary or is it dynamically linked? earth:~# file /usr/local/bin/cvsup /usr/local/bin/cvsup: FreeBSD/i386 compact demand paged executable earth:~# ldd /usr/local/bin/cvsup ldd: /usr/local/bin/cvsup: not a dynamic executable (same on all versions) - did you build it, or did you simply install a binary? no problems with the one retreived using /usr/ports/net/cvsup-bin: earth:/usr/ports/distfiles# md5 cvsup-freebsd-ix86-aout-16.0.tar.gz MD5 (cvsup-freebsd-ix86-aout-16.0.tar.gz) = 57c25981d3c1d82a79b9ae18aaea715b earth:/usr/ports/distfiles# nor from one pkg_add 'ed from ftp://ftp.freebsd.org/pub/FreeBSD/packages/All/cvsup-bin-16.0.tgz : earth:~# md5 cvsup-bin-16.0.tgz MD5 (cvsup-bin-16.0.tgz) = 3e60e196c8ed9f7dac3f145bd72ac536 earth:~# Note, you are going to have trouble getting much out of the core dumps from the binaries, because they're a.out. I've placed an unstripped ELF binary here if you'd like to help out by getting a stack trace: http://www.freebsd.org/~jdp/cvsup-16.0.gz This one works without fault also. - Chris D. Faulhaber [EMAIL PROTECTED] | All the true gurus I've met never System/Network Administrator, | claimed they were one and always Reality Check Information, Inc. | pointed to someone better. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
aha driver disabled?
After cvsupping yesterday (last cvsup was at the beginning of the month),
I found that my AHA-1542CP was no longer being seen/probed. I've traced
it down to the following:
RCS file: /home/ncvs/src/sys/i386/isa/isa_compat.h,v
Working file: src/sys/i386/isa/isa_compat.h
head: 1.12
description:
revision 1.12
date: 1999/09/07 08:42:47; author: dfr; state: Exp; lines: +1 -6
Change isa_get/set_flags() to device_get/set_flags().
- * $FreeBSD: src/sys/i386/isa/isa_compat.h,v 1.11 1999/09/03 19:15:13
peter Exp $
+ * $FreeBSD: src/sys/i386/isa/isa_compat.h,v 1.12 1999/09/07 08:42:47 dfr
Exp $
*/
#include "vt.h"
@@ -99,7 +99,6 @@
extern struct isa_driver vtdriver;
extern struct isa_driver advdriver;
-extern struct isa_driver ahadriver;
extern struct isa_driver wdcdriver;
extern struct isa_driver msedriver;
extern struct isa_driver ardriver;
@@ -311,10 +310,6 @@
#if NADV 0
{ INTR_TYPE_CAM, advdriver },
#endif
-#endif
-
-#if NAHA 0
- { INTR_TYPE_CAM, ahadriver },
#endif
If I reverse the above, the card seems to work fine again. I'm just
wondering if this was intentional and/or if the driver will be reenabled
again [soon].
-----
Chris D. Faulhaber [EMAIL PROTECTED] | All the true gurus I've met never
System/Network Administrator, | claimed they were one and always
Reality Check Information, Inc. | pointed to someone better.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: breakage in this morning's build
On Mon, 30 Aug 1999, Mike Muir wrote: Pascal Hofstee wrote: I am suffering from the exact same problem here as well ... (tried about 4 times now ... without success) Mines a little (little) different: install -c -s -o root -g wheel -m 555 rm /usr/obj/usr/src/tmp/bin rm: /usr/obj/usr/src/bin/rm: Inappropriate ioctl for device *** Error code 1 Stop in /usr/src/bin/rm. *** Error code 1 I got that using -j4 and the previous error without -j. I appears that the /usr/obj/usr/src/bin/rm directory is being removed during the install somehow... - Chris D. Faulhaber [EMAIL PROTECTED] | All the true gurus I've met never System/Network Administrator,| claimed they were one, and always Reality Check Information, Inc. | pointed to someone better. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Kensington mouse (was: Re: Unusable PS/2 mouse)
On Wed, 21 Jul 1999, Kazutaka YOKOTA wrote: On Tue, 20 Jul 1999, Warner Losh wrote: I had problems with the my Kensignton mouse in a box, but some fixes were made to -current that fixed the problems. A workaround is to set flags 0x20 (the NOIDPROBE) which forces it to behave as if it were a plain old 2 button (or in my case 3 button) mouse. For my Kensington (on -stable) I used 'flags 0x10' (NOCHECKSYNC) to kill the out of sync messages. The only side effect I've seen is that the cursor speed is faster [than with using the serial port connector]. Which model is it? Kensington sells quite a number of mouse/trackball products. The model Warner talked about is "Kensington Mouse in a Box Scroll". It has a wheel between two buttons. Is that the one you are talking about? (The problem regarding "Kensington Mouse in a Box Scroll" was fixed in both -CURRENT and -STABLE about a week ago.) If not, would you give -v option to the boot command when you boot the kernel and send me /var/run/dmesg.out, so that I can diagnose what the psm driver is doing to the mouse? My apologies, I was inferring that I also had a "Kensington Mouse in a Box Scroll" (Model: MOSUI) ... After removing the flags from psm, the mouse is working great. This is stable cvsupped last weekend (July 15th or so). Excellent work! Thanks, Chris - Chris D. Faulhaber [EMAIL PROTECTED] | All the true gurus I've met never System/Network Administrator,| claimed they were one, and always Reality Check Information, Inc. | pointed to someone better. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
RE: CDR says: Attempt to query device size failed...
On 13-Feb-99 Ben Stuyts wrote: I've been getting the following message, usually within a minute or so after booting. It shows up only once, and doesn't seem to interfere with normal operation of the CDR: (cd1:ahc0:0:5:0): READ CD RECORDED CAPACITY. CDB: 25 0 0 0 0 0 0 0 0 0 (cd1:ahc0:0:5:0): NOT READY asc:4,0 (cd1:ahc0:0:5:0): Logical unit not ready, cause not reportable cd1 at ahc0 bus 0 target 5 lun 0 cd1: PHILIPS CDD2600 1.06 Removable CD-ROM SCSI-2 device cd1: 3.300MB/s transfers cd1: Attempt to query device size failed: NOT READY, Logical unit not ready, cause not reportable This is not a new error. It has been happening for several months now, but I never got around to reporting this. Any idea what the problem is? There is no CD in the drive, which makes the device 'not ready' and therefore unable to query device size. If you put a CD in the drive and reboot, you shouldn't get this error. Thanks, Ben - Chris To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: CDR says: Attempt to query device size failed...
On 13-Feb-99 Ben Stuyts wrote: On Sat, 13 Feb 1999, Chris D. Faulhaber wrote: cd1: Attempt to query device size failed: NOT READY, Logical unit not ready, cause not reportable There is no CD in the drive, which makes the device 'not ready' and therefore unable to query device size. If you put a CD in the drive and reboot, you shouldn't get this error. Correct. I forgot to mention in my original post that I also have another cdrom player in my system, and it doesn't generate this error. (cd0: MATSHITA CD-ROM CR-506 8S05 Removable CD-ROM SCSI-2 device) That's why I thought it was odd. Thanks for the reply! Ben Interesting, this happens to both my CDR and regular CD: cd0 at ahc0 bus 0 target 3 lun 0 cd0: MATSHITA CD-ROM CR-508 XS03 Removable CD-ROM SCSI-2 device cd0: 10.0MB/s transfers (10.0MHz, offset 15) cd0: Attempt to query device size failed: NOT READY, Medium not present cd1 at ahc0 bus 0 target 5 lun 0 cd1: PHILIPS CDD2600 1.07 Removable CD-ROM SCSI-2 device cd1: 3.300MB/s transfers cd1: Attempt to query device size failed: NOT READY, Logical unit not ready, cause not reportable It may simply be the way the different devices report that the device is not ready/no medium present in the sense data... ...if no one else has any good ideas, I may just get a trace of the bus this evening and see exactly what is being reported (and when). - Chris To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
