Re: My network is dead because of this program :(
In the last episode (May 15), Brian O'Shea said: On Tue, May 15, 2001 at 10:44:32PM -0400, Matthew Emmerton wrote: [...] After going to single user mode, cause I can't kill the offending program once it is running in multiuser mode (even kill -9 won't work ... Probably because the program is forking and you can't kill it's children fast enough. A handy way to kill forkbombs like this is su username -c kill -9 -1, which will kill all the processes owned by that user at once. -- Dan Nelson [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: cvs commit: src Makefile.inc1
On Tue, May 15, 2001 at 05:02:25PM -0600, Warner Losh wrote:
In message [EMAIL PROTECTED] Maxim Sobolev writes:
: Perhaps we could rip off the code that dumps keymap file into a
: little utility on its own and use this utility to bootstrap
: sysinstall. I could look into this direction if there aren't better
: ideas.
I think your idea of just defining PASTE is the best way to go. I
came up with it independently after trying a number of different ideas
on how to get around this.
FWIW, my gross hack to usr.sbin/kbdcontrol also worked:
Index: Makefile
===
RCS file: /home/ncvs/src/usr.sbin/kbdcontrol/Makefile,v
retrieving revision 1.8
diff -u -p -r1.8 Makefile
--- Makefile2001/03/26 14:40:28 1.8
+++ Makefile2001/05/16 07:19:20
@@ -3,6 +3,7 @@
PROG= kbdcontrol
SRCS= kbdcontrol.c lex.l
CFLAGS+= -I${.CURDIR}
+CFLAGS+=-I${.CURDIR}/../../sys
MAN= kbdcontrol.1 kbdmap.5
MLINKS= kbdmap.5 keymap.5
DPADD= ${LIBL}
Cheers,
--
Ruslan Ermilov Oracle Developer/DBA,
[EMAIL PROTECTED] Sunbay Software AG,
[EMAIL PROTECTED] FreeBSD committer,
+380.652.512.251Simferopol, Ukraine
http://www.FreeBSD.org The Power To Serve
http://www.oracle.com Enabling The Information Age
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: cvs commit: src Makefile.inc1
In message [EMAIL PROTECTED] Ruslan Ermilov writes: : FWIW, my gross hack to usr.sbin/kbdcontrol also worked: I tend to dislike adding ../../sys to the includes list since they might not be compatible with the host's sys files used to build libc. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: cvs commit: src Makefile.inc1
Warner Losh wrote: In message [EMAIL PROTECTED] Maxim Sobolev writes: : There is at least one easy way - we can check if PASTE : is defined and define it to be NOP if it isn't. This would allow : to use kbdcontrol as a bootstrap tool on 4-STABLE. : : See attached patch. Heh. I came up with this independently. It works. I hope I didn't step on any toes by commiting it. ;) Great minds think alike, you know. 8-) -Maxim To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: cvs commit: src Makefile.inc1
On Tue, 15 May 2001, Ruslan Ermilov wrote:
On Tue, May 15, 2001 at 05:42:04PM +0300, Peter Pentchev wrote:
[...]
Can't you teach sysinstall/Makefile to use the kbdcontrol in
${.OBJDIR}/../kbdcontrol/kbdcontrol instead, and make it somehow
depend on kbdcontrol being built beforehand?
Doing it this way would break cross-platform builds.
Even running kbdcontrol might break cross-platform builds. Consider
running it on a host platform of Linux. It might fail attempting to
do a keyboard ioctl in its initalization. However, kbdcontrol -L
might work because it doesn't actually do any keyboard control.
Bruce
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: cvs commit: src Makefile.inc1
On Wed, May 16, 2001 at 06:47:12PM +1000, Bruce Evans wrote:
On Tue, 15 May 2001, Ruslan Ermilov wrote:
On Tue, May 15, 2001 at 05:42:04PM +0300, Peter Pentchev wrote:
[...]
Can't you teach sysinstall/Makefile to use the kbdcontrol in
${.OBJDIR}/../kbdcontrol/kbdcontrol instead, and make it somehow
depend on kbdcontrol being built beforehand?
Doing it this way would break cross-platform builds.
Even running kbdcontrol might break cross-platform builds. Consider
running it on a host platform of Linux. It might fail attempting to
do a keyboard ioctl in its initalization. However, kbdcontrol -L
might work because it doesn't actually do any keyboard control.
I think that cross-platform means compilation between i386 and alpha (and
possibly others) not different OS's:-) (Although admittedly you can build
Debian CDs on FreeBSD with linux emulation way better than you can build
say a -STABLE release on a -CURRENT box... )
--
Regards:
Szilveszter ADAM
Szeged University
Szeged Hungary
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
evil ATA
Welp, this is the n-dozenth time that the ATA driver has wedged large parts of my entire system because it feels it needs to reset my CD-R when I'm trying to start burning a CD. I get the good old acd0: WRITE_BIG command timeout - resetting ata3: resetting devices .. and then, like always, tons of random applications lock up thereafter, including the burncd (stuck in physstr and cannot be killed, at all), Window Maker, my panel, etc. etc. etc. Oh, and the sleep(2)-related system calls don't sleep for the right time anymore; they just freeze. All sorts of stuff like this. Is there _any_ hope for not having such horrible behavior? Am I at the very least not the only person to have seen it? This is the _only_ problem I've had with -current lockups this entire year. -- Brian Fundakowski Feldman \ FreeBSD: The Power to Serve! / [EMAIL PROTECTED]`--' To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: evil ATA
It seems Brian F. Feldman wrote: Welp, this is the n-dozenth time that the ATA driver has wedged large parts of my entire system because it feels it needs to reset my CD-R when I'm trying to start burning a CD. I get the good old acd0: WRITE_BIG command timeout - resetting ata3: resetting devices .. and then, like always, tons of random applications lock up thereafter, including the burncd (stuck in physstr and cannot be killed, at all), Window Maker, my panel, etc. etc. etc. Oh, and the sleep(2)-related system calls don't sleep for the right time anymore; they just freeze. All sorts of stuff like this. Is there _any_ hope for not having such horrible behavior? Am I at the very least not the only person to have seen it? This is the _only_ problem I've had with -current lockups this entire year. I have never ever seen this behavior... I can understand why the process that uses the failing device can hang or do irratic things, but I have trouble understanding the rest... A dmesg would be nice :) -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
RE: evil ATA
Welp, this is the n-dozenth time that the ATA driver has wedged large parts of my entire system because it feels it needs to reset my CD-R when I'm trying to start burning a CD. I get the good old acd0: WRITE_BIG command timeout - resetting ata3: resetting devices .. I don't know this case, but I've seen such behavior with non dma-capable hdd on udma controller. take a look at sysctl hw.atamodes (may look like 'dma,---,---,dma') and try change it (sysctl -w hw.atamodes=dma,---,---,pio) to PIO mode. it might help. Buki Is there _any_ hope for not having such horrible behavior? Am I at the very least not the only person to have seen it? This is the _only_ problem I've had with -current lockups this entire year. -- Brian Fundakowski Feldman \ FreeBSD: The Power to Serve! / [EMAIL PROTECTED]`--' To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Shouldn't wchar.h get copied somewhere during build?
Looks as if /usr/src/include/wchar.h isn't getting copied to a place where it actually gets used during the build. From this morning's -CURRENT (CVSup trivia follows the log): stage 4: populating /usr/obj/usr/src/i386/usr/include ... stage 4: building libraries ... === libbind ... === libc ... rm -f .depend mkdep -f .depend -a-DLIBC_RCS -DSYSLIBC_RCS -I/usr/src/lib/libc/include -D__DBINTERFACE_PRIVATE -DINET6 -I/common/C/obj/usr/src/lib/libc -DPOSIX_MISTAKE -I/usr/src/lib/libc/../libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -DYP -DHESIOD -I/usr/obj/usr/src/i386/usr/include -I/usr/src/lib/libc/i386 /usr/src/lib/libc/../libc/i386/gen/_setjmp.S /usr/src/lib/libc/../libc/i386/gen/alloca.S /usr/src/lib/libc/../libc/i386/gen/fabs.S /usr/src/lib/libc/../libc/i386/gen/modf.S /usr/src/lib/libc/../libc/i386/gen/rfork_thread.S /usr/src/lib/libc/../libc/i386/gen/setjmp.S /usr/src/lib/libc/../libc/i386/gen/sigsetjmp.S /usr/src/lib/libc/../libc/i386/net/htonl.S /usr/src/lib/libc/../libc/i386/net/htons.S /usr/src/lib/libc/../libc/i386/net/ntohl.S /usr/src/lib/libc/../libc/i386/net/ntohs.S /usr/src/lib/libc/../libc/i386/sys/Ovfork.S /usr/src/lib/libc/../libc/i386/sys/brk.S /usr/src/lib/libc/../libc/i386/sys/cerror.S /usr/src/lib/libc/../libc/i386/sys/exect.S /usr/src/lib/libc/../libc! /i386/sys/fork.S /usr/src/lib/libc/../libc/i386/sys/pipe.S /usr/src/lib/libc/../libc/i386/sys/ptrace.S /usr/src/lib/libc/../libc/i386/sys/reboot.S /usr/src/lib/libc/../libc/i386/sys/rfork.S /usr/src/lib/libc/../libc/i386/sys/sbrk.S /usr/src/lib/libc/../libc/i386/sys/setlogin.S /usr/src/lib/libc/../libc/i386/sys/sigreturn.S /usr/src/lib/libc/../libc/i386/sys/syscall.S read.S write.S open.S close.S wait4.S link.S unlink.S chdir.S fchdir.S mknod.S chmod.S chown.S getfsstat.S getpid.S mount.S unmount.S setuid.S getuid.S geteuid.S recvmsg.S sendmsg.S recvfrom.S accept.S getpeername.S getsockname.S access.S chflags.S fchflags.S sync.S kill.S getppid.S dup.S getegid.S profil.S ktrace.S getgid.S acct.S sigaltstack.S ioctl.S revoke.S symlink.S readlink.S execve.S umask.S chroot.S msync.S vadvise.S munmap.S mprotect.S madvise.S mincore.S getgroups.S setgroups.S getpgrp.S setpgid.S setitimer.S swapon.S getitimer.S getdtablesize.S dup2.S fcntl.S select.S fsync.S setpriority.S socket.S c! onnect.S getpriority.S bind.S setsockopt.S listen.S gettimeofday.S getrusage.S getsockopt.S readv.S writev.S settimeofday.S fchown.S fchmod.S setreuid.S setregid.S rename.S flock.S mkfifo.S sendto.S shutdown.S socketpair.S mkdir.S rmdir.S utimes.S adjtime.S setsid.S quotactl.S nfssvc.S statfs.S fstatfs.S getfh.S sysarch.S rtprio.S semsys.S msgsys.S shmsys.S ntp_adjtime.S setgid.S setegid.S seteuid.S stat.S fstat.S lstat.S pathconf.S fpathconf.S getrlimit.S setrlimit.S getdirentries.S __syscall.S __sysctl.S mlock.S munlock.S undelete.S futimes.S getpgid.S poll.S clock_gettime.S clock_settime.S clock_getres.S nanosleep.S minherit.S issetugid.S lchown.S getdents.S lchmod.S netbsd_lchown.S lutimes.S netbsd_msync.S nstat.S nfstat.S nlstat.S fhstatfs.S fhopen.S fhstat.S modnext.S modstat.S modfnext.S modfind.S kldload.S kldunload.S kldfind.S kldnext.S kldstat.S kldfirstmod.S getsid.S setresuid.S setresgid.S aio_return.S aio_suspend.S aio_cancel.S aio_error.S aio_read.S aio_write.S! lio_listio.S __getcwd.S sched_setparam.S sched_getparam.S sched_setscheduler.S sched_getscheduler.S sched_yield.S sched_get_priority_max.S sched_get_priority_min.S sched_rr_get_interval.S utrace.S sendfile.S kldsym.S jail.S sigprocmask.S sigsuspend.S sigaction.S sigpending.S __acl_get_file.S __acl_set_file.S __acl_get_fd.S __acl_set_fd.S __acl_delete_file.S __acl_delete_fd.S __acl_aclcheck_file.S __acl_aclcheck_fd.S extattrctl.S extattr_set_file.S extattr_get_file.S extattr_delete_file.S aio_waitcomplete.S getresuid.S getresgid.S kqueue.S kevent.S __cap_get_proc.S __cap_set_proc.S __cap_get_fd.S __cap_get_file.S __cap_set_fd.S __cap_set_file.S extattr_set_fd.S extattr_get_fd.S extattr_delete_fd.S __setugid.S _getlogin.S _exit.S /usr/src/lib/libc/../libc/i386/stdlib/abs.S /usr/src/lib/libc/../libc/i386/stdlib/div.S /usr/src/lib/libc/../libc/i386/stdlib/labs.S /usr/src/lib/libc/../libc/i386/stdlib/ldiv.S /usr/src/lib/libc/../libc/i386/string/bcmp.S /usr/src/lib/libc/../libc/i! 386/string/bcopy.S /usr/src/lib/libc/../libc/i386/string/bzero.S /usr/src/lib/libc/../libc/i386/string/ffs.S /usr/src/lib/libc/../libc/i386/string/index.S /usr/src/lib/libc/../libc/i386/string/memchr.S /usr/src/lib/libc/../libc/i386/string/memcmp.S /usr/src/lib/libc/../libc/i386/string/memcpy.S /usr/src/lib/libc/../libc/i386/string/memmove.S /usr/src/lib/libc/../libc/i386/string/memset.S /usr/src/lib/libc/../libc/i386/string/rindex.S /usr/src/lib/libc/../libc/i386/string/strcat.S /usr/src/lib/libc/../libc/i386/string/strchr.S /usr/src/lib/libc/../libc/i386/string/strcmp.S /usr/src/lib/libc/../libc/i386/string/strcpy.S
Re: Shouldn't wchar.h get copied somewhere during build?
[Yeah, I talk to myself, too dhw] Forgot to add: dhcp-133[7] cd /usr/obj dhcp-133[8] find . -name wchar.h -print dhcp-133[9] cd ../src dhcp-133[10] find . -name wchar.h -print ./include/wchar.h dhcp-133[11] After all, that's the part that inspired the Subject:. Cheers, david -- David H. Wolfskill [EMAIL PROTECTED] As a computing professional, I believe it would be unethical for me to advise, recommend, or support the use (save possibly for personal amusement) of any product that is or depends on any Microsoft product. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: cvs commit: src Makefile.inc1
On Wed, 16 May 2001, Warner Losh wrote: In message [EMAIL PROTECTED] Ruslan Ermilov writes: : FWIW, my gross hack to usr.sbin/kbdcontrol also worked: I tend to dislike adding ../../sys to the includes list since they might not be compatible with the host's sys files used to build libc. I'd like to remove all the existing ones. They are a hack to handle the case where you haven't bootstrapped properly. They intentionally give sys includes which may be incompatible with the host ones, in case the host ones are out of date relative to the src tree. This depends on only a few headers like sys/user.h being out of date, and sometimes helps mainly for headers like sys/user.h which declare system structures that are groped in by userland. But it is just a bug in general. Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Shouldn't wchar.h get copied somewhere during build?
Already fixed in src/include/Makefile,v 1.134. On Wed, May 16, 2001 at 07:46:04AM -0700, David Wolfskill wrote: Looks as if /usr/src/include/wchar.h isn't getting copied to a place where it actually gets used during the build. From this morning's -CURRENT (CVSup trivia follows the log): stage 4: populating /usr/obj/usr/src/i386/usr/include ... stage 4: building libraries ... === libbind ... === libc ... rm -f .depend mkdep -f .depend -a-DLIBC_RCS -DSYSLIBC_RCS -I/usr/src/lib/libc/include -D__DBINTERFACE_PRIVATE -DINET6 -I/common/C/obj/usr/src/lib/libc -DPOSIX_MISTAKE -I/usr/src/lib/libc/../libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -DYP -DHESIOD -I/usr/obj/usr/src/i386/usr/include -I/usr/src/lib/libc/i386 /usr/src/lib/libc/../libc/i386/gen/_setjmp.S /usr/src/lib/libc/../libc/i386/gen/alloca.S /usr/src/lib/libc/../libc/i386/gen/fabs.S /usr/src/lib/libc/../libc/i386/gen/modf.S /usr/src/lib/libc/../libc/i386/gen/rfork_thread.S /usr/src/lib/libc/../libc/i386/gen/setjmp.S /usr/src/lib/libc/../libc/i386/gen/sigsetjmp.S /usr/src/lib/libc/../libc/i386/net/htonl.S /usr/src/lib/libc/../libc/i386/net/htons.S /usr/src/lib/libc/../libc/i386/net/ntohl.S /usr/src/lib/libc/../libc/i386/net/ntohs.S /usr/src/lib/libc/../libc/i386/sys/Ovfork.S /usr/src/lib/libc/../libc/i386/sys/brk.S /usr/src/lib/libc/../libc/i386/sys/cerror.S /usr/src/lib/libc/../libc/i386/sys/exect.S /usr/src/lib/libc/../libc! /i386/sys/fork.S /usr/src/lib/libc/../libc/i386/sys/pipe.S /usr/src/lib/libc/../libc/i386/sys/ptrace.S /usr/src/lib/libc/../libc/i386/sys/reboot.S /usr/src/lib/libc/../libc/i386/sys/rfork.S /usr/src/lib/libc/../libc/i386/sys/sbrk.S /usr/src/lib/libc/../libc/i386/sys/setlogin.S /usr/src/lib/libc/../libc/i386/sys/sigreturn.S /usr/src/lib/libc/../libc/i386/sys/syscall.S read.S write.S open.S close.S wait4.S link.S unlink.S chdir.S fchdir.S mknod.S chmod.S chown.S getfsstat.S getpid.S mount.S unmount.S setuid.S getuid.S geteuid.S recvmsg.S sendmsg.S recvfrom.S accept.S getpeername.S getsockname.S access.S chflags.S fchflags.S sync.S kill.S getppid.S dup.S getegid.S profil.S ktrace.S getgid.S acct.S sigaltstack.S ioctl.S revoke.S symlink.S readlink.S execve.S umask.S chroot.S msync.S vadvise.S munmap.S mprotect.S madvise.S mincore.S getgroups.S setgroups.S getpgrp.S setpgid.S setitimer.S swapon.S getitimer.S getdtablesize.S dup2.S fcntl.S select.S fsync.S setpriority.S socket.S c! onnect.S getpriority.S bind.S setsockopt.S listen.S gettimeofday.S getrusage.S getsockopt.S readv.S writev.S settimeofday.S fchown.S fchmod.S setreuid.S setregid.S rename.S flock.S mkfifo.S sendto.S shutdown.S socketpair.S mkdir.S rmdir.S utimes.S adjtime.S setsid.S quotactl.S nfssvc.S statfs.S fstatfs.S getfh.S sysarch.S rtprio.S semsys.S msgsys.S shmsys.S ntp_adjtime.S setgid.S setegid.S seteuid.S stat.S fstat.S lstat.S pathconf.S fpathconf.S getrlimit.S setrlimit.S getdirentries.S __syscall.S __sysctl.S mlock.S munlock.S undelete.S futimes.S getpgid.S poll.S clock_gettime.S clock_settime.S clock_getres.S nanosleep.S minherit.S issetugid.S lchown.S getdents.S lchmod.S netbsd_lchown.S lutimes.S netbsd_msync.S nstat.S nfstat.S nlstat.S fhstatfs.S fhopen.S fhstat.S modnext.S modstat.S modfnext.S modfind.S kldload.S kldunload.S kldfind.S kldnext.S kldstat.S kldfirstmod.S getsid.S setresuid.S setresgid.S aio_return.S aio_suspend.S aio_cancel.S aio_error.S aio_read.S aio_write.S! lio_listio.S __getcwd.S sched_setparam.S sched_getparam.S sched_setscheduler.S sched_getscheduler.S sched_yield.S sched_get_priority_max.S sched_get_priority_min.S sched_rr_get_interval.S utrace.S sendfile.S kldsym.S jail.S sigprocmask.S sigsuspend.S sigaction.S sigpending.S __acl_get_file.S __acl_set_file.S __acl_get_fd.S __acl_set_fd.S __acl_delete_file.S __acl_delete_fd.S __acl_aclcheck_file.S __acl_aclcheck_fd.S extattrctl.S extattr_set_file.S extattr_get_file.S extattr_delete_file.S aio_waitcomplete.S getresuid.S getresgid.S kqueue.S kevent.S __cap_get_proc.S __cap_set_proc.S __cap_get_fd.S __cap_get_file.S __cap_set_fd.S __cap_set_file.S extattr_set_fd.S extattr_get_fd.S extattr_delete_fd.S __setugid.S _getlogin.S _exit.S /usr/src/lib/libc/../libc/i386/stdlib/abs.S /usr/src/lib/libc/../libc/i386/stdlib/div.S /usr/src/lib/libc/../libc/i386/stdlib/labs.S /usr/src/lib/libc/../libc/i386/stdlib/ldiv.S /usr/src/lib/libc/../libc/i386/string/bcmp.S /usr/src/lib/libc/../libc/i! 386/string/bcopy.S /usr/src/lib/libc/../libc/i386/string/bzero.S /usr/src/lib/libc/../libc/i386/string/ffs.S /usr/src/lib/libc/../libc/i386/string/index.S /usr/src/lib/libc/../libc/i386/string/memchr.S /usr/src/lib/libc/../libc/i386/string/memcmp.S /usr/src/lib/libc/../libc/i386/string/memcpy.S /usr/src/lib/libc/../libc/i386/string/memmove.S /usr/src/lib/libc/../libc/i386/string/memset.S /usr/src/lib/libc/../libc/i386/string/rindex.S /usr/src/lib/libc/../libc/i386/string/strcat.S
Re: cvs commit: src Makefile.inc1
On Thu, May 17, 2001 at 12:51:59AM +1000, Bruce Evans wrote: On Wed, 16 May 2001, Warner Losh wrote: In message [EMAIL PROTECTED] Ruslan Ermilov writes: : FWIW, my gross hack to usr.sbin/kbdcontrol also worked: I tend to dislike adding ../../sys to the includes list since they might not be compatible with the host's sys files used to build libc. I'd like to remove all the existing ones. They are a hack to handle the case where you haven't bootstrapped properly. They intentionally give sys includes which may be incompatible with the host ones, in case the host ones are out of date relative to the src tree. This depends on only a few headers like sys/user.h being out of date, and sometimes helps mainly for headers like sys/user.h which declare system structures that are groped in by userland. But it is just a bug in general. I would probably volunteer for doing this. -- Ruslan Ermilov Oracle Developer/DBA, [EMAIL PROTECTED] Sunbay Software AG, [EMAIL PROTECTED] FreeBSD committer, +380.652.512.251Simferopol, Ukraine http://www.FreeBSD.org The Power To Serve http://www.oracle.com Enabling The Information Age To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: cvs commit: src Makefile.inc1
On Wed, 16 May 2001, Szilveszter Adam wrote: On Wed, May 16, 2001 at 06:47:12PM +1000, Bruce Evans wrote: Even running kbdcontrol might break cross-platform builds. Consider running it on a host platform of Linux. It might fail attempting to do a keyboard ioctl in its initalization. However, kbdcontrol -L might work because it doesn't actually do any keyboard control. I think that cross-platform means compilation between i386 and alpha (and possibly others) not different OS's:-) (Although admittedly you can build I have higher standards :-). Debian CDs on FreeBSD with linux emulation way better than you can build say a -STABLE release on a -CURRENT box... ) I just tried a Linux fdisk binary built in 1997 under FreeBSD-current. It seemed to run perfectly except it couldn't determine the disk geometry automatically. Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: evil ATA
Greetings: If the formatting of this msg is mucked, I apologize -- this is the only mailer available to me at the moment (ISP problems, and I'm not going to email from work). Welp, this is the n-dozenth time that the ATA driver has wedged large parts of my entire system because it feels it needs to reset my CD-R when I'm trying to start burning a CD. I get the good old acd0: WRITE_BIG command timeout - resetting ata3: resetting devices .. I don't get this on CD drives, but I do get a lot of ata command timeouts on other ata drives. The worst offender is my quantum bigfoot (a slow ugly drive) -- for a while the system was almost unusable. It was being attached in WDMA2 mode, but if I knock it down to PIO4 or PIO3 it purrs like a kitten. (Of course I should get rid of it anyway, because when it is cold it won't spin up on its own -- I have to pull it out, give it a good ole twist in the air and put it back in real quick-like..) I don't know this case, but I've seen such behavior with non dma-capable hdd on udma controller. take a look at sysctl hw.atamodes (may look like 'dma,---,---,dma') and try change it (sysctl -w hw.atamodes=dma,---,---,pio) to PIO mode. it might help. Buki I noticed a few days ago that a new command was added to -current, called atacontrol. This command provides a real handy way to smack the ata controller into a slower mode. I presume it does something like the above. Cheers, Phil -- -- Phil Knaack __ Get your own FREE, personal Netscape Webmail account today at http://webmail.netscape.com/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Cross-platform make world/release?
Greetings, Short question: is FreeBSD capable of cross-platform make world and release (e.g. build of Alpha world/release on x86 and vice versa)? TIA, Eugene To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: cvs commit: src Makefile.inc1
On Wed, 16 May 2001, Warner Losh wrote: In message [EMAIL PROTECTED] Ruslan Ermilov writes: : FWIW, my gross hack to usr.sbin/kbdcontrol also worked: I tend to dislike adding ../../sys to the includes list since they might not be compatible with the host's sys files used to build libc. I'd like to remove all the existing ones. They are a hack to handle the case where you haven't bootstrapped properly. They intentionally give sys includes which may be incompatible with the host ones, in case the host ones are out of date relative to the src tree. This depends on only a few headers like sys/user.h being out of date, and sometimes helps mainly for headers like sys/user.h which declare system structures that are groped in by userland. But it is just a bug in general. I have -I../../sys in src/usr.sbin/digictl/Makefile. I put it there because the digi ioctl interface header isn't actually installed anywhere. There's no good reason for this except that I couldn't think of a good place (/usr/include/sys/digi/ ?). I cribbed the idea from the vinum(8) build. How should this be done - and where should I install digiio.h if that's what's required ? Cheers. Bruce -- Brian [EMAIL PROTECTED]brian@[uk.]FreeBSD.org http://www.Awfulhak.org brian@[uk.]OpenBSD.org Don't _EVER_ lose your sense of humour ! To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Cross-platform make world/release?
On Wed, May 16, 2001 at 08:52:44AM -0700, Eugene M. Kim wrote: Greetings, Short question: is FreeBSD capable of cross-platform make world and release (e.g. build of Alpha world/release on x86 and vice versa)? Hello, Cross-platform world should work rather easily. (have not tried it since I don't have an Alpha lying around here:-P) See in particular the Makefiles right under src/ there is a good explanation on top in comments of what vars you can set and what they do. As for release, well that's tricky. In theory it should work also but in praxis the study of src/release/Makefile has proven to be some pain at times... note that I have not tried this one either... what I *did* try was however to build 4.3-RELEASE on a -CURRENT box (same platform) and to my great dismay I had to discover that even after loading the bin distribution from the ftp into the release chroot(2), it took heavy amounts of tinkering to get things going... the make world succeeded though, so I assume that most anything would have gone well from that point... in any case, if you want to do a release, study the Makefiles closely and understand what they do. -- Regards: Szilveszter ADAM Szeged University Szeged Hungary To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: cvs commit: src Makefile.inc1
In message [EMAIL PROTECTED] Brian Somers writes: : How should this be done - and where should I install digiio.h if : that's what's required ? I think that ppi device sets the standard here. It installs into /usr/include/dev/ppi/ppi*.h. digiio should likely do the same. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
RE: panic: sleeping process owns a mutex
On 16-May-01 Bob Bishop wrote: Hi, This while building world, with a kernel cvsup at Fri Apr 27 04:06:40 BST 2001 kern/kern_synch.c:386 sleeping with vr0 locked from pci/if_vr.c:1315 abridged backtrace: panic() propagate_priority() _mtx_lock_sleep() vr_intr() ithread_loop() fork_exit() fork_trampoline() Well, I think the best thing to do for now will be to back out all the ethernet driver locking until we figure out how we are actually going to lock them. The original locks that went in starting with fxp many months ago weren't quite right but have been mostly harmless up to this point. There are some cases where we sleep with locks however, which can lead to problems. -- 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: panic: sleeping process owns a mutex
Oh, I'd like you to think twice about this. Massive amounts of driver rototilling should be avoided at this point. On Wed, 16 May 2001, John Baldwin wrote: On 16-May-01 Bob Bishop wrote: Hi, This while building world, with a kernel cvsup at Fri Apr 27 04:06:40 BST 2001 kern/kern_synch.c:386 sleeping with vr0 locked from pci/if_vr.c:1315 abridged backtrace: panic() propagate_priority() _mtx_lock_sleep() vr_intr() ithread_loop() fork_exit() fork_trampoline() Well, I think the best thing to do for now will be to back out all the ethernet driver locking until we figure out how we are actually going to lock them. The original locks that went in starting with fxp many months ago weren't quite right but have been mostly harmless up to this point. There are some cases where we sleep with locks however, which can lead to problems. -- 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 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Memory Issue on a Sony Vaio Z505LE
I was curious whether the memory limitation on the Sony VAIO Z505 machines was a hardware limitation. I just tried adding a 256MB module to my machine. The BIOS seem to mostly recognize it. It did see 320MB of RAM, but had problems when testing all of it. FreeBSD current boots but gives me: Too many holes in the physical address space, giving up and comes up with 64MB of RAM. Is this something that can be worked around, or have I run up against an actual hardware limit on the machine? barry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: evil ATA
On 16-May-01 (15:14:50/GMT) Phil Knaack wrote: on udma controller. take a look at sysctl hw.atamodes (may look like 'dma,---,---,dma') and try change it to PIO mode. I noticed a few days ago that a new command was added to -current, called atacontrol. This command provides a real handy way... Maybe I am missing some important information, but on my -CURRENT box (FreeBSD 5.0-CURRENT #17: Sat Apr 28 03:30:53 CEST 2001) I'm unable to find hw.atamodes :-( # sysctl -a | grep -i hw.ata hw.ata.ata_dma: 1 hw.ata.wc: 0 hw.ata.tags: 0 hw.ata.atapi_dma: 0 On the other (FreeBSD 4.3-STABLE #3: Wed Apr 25 10:14:54 CEST 2001) box they are in the right place: # sysctl -a | grep -i hw.ata hw.ata.ata_dma: 1 hw.ata.wc: 0 hw.ata.tags: 0 hw.atamodes: pio,---,---,---, Ciao, Riccardo. PS: It is safer a world this days? I wouldn't like to loose all files and rest only with lost+found as on HEADS-UP of same days ago... To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: evil ATA
In article [EMAIL PROTECTED], Riccardo Torrini [EMAIL PROTECTED] wrote: Maybe I am missing some important information, but on my -CURRENT box (FreeBSD 5.0-CURRENT #17: Sat Apr 28 03:30:53 CEST 2001) I'm unable to find hw.atamodes :-( It has been replaced by the atacontrol(8) command. PS: It is safer a world this days? I wouldn't like to loose all files and rest only with lost+found as on HEADS-UP of same days ago... Actually, I found that to be a very cleansing experience. ;-) John -- John Polstra [EMAIL PROTECTED] John D. Polstra Co., Inc.Seattle, Washington USA Disappointment is a good sign of basic intelligence. -- Chögyam Trungpa To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: evil ATA
In the last episode (May 16), John Polstra said: PS: It is safer a world this days? I wouldn't like to loose all files and rest only with lost+found as on HEADS-UP of same days ago... Actually, I found that to be a very cleansing experience. ;-) Me too; I would probably have never updated my /etc directory if it hadn't been for that bug. It also gave me a chance to resize my 32MB / partition that would fill up every time I did an installworld... -- Dan Nelson [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
RE: panic: sleeping process owns a mutex
On 16-May-01 Matthew Jacob wrote: Oh, I'd like you to think twice about this. Massive amounts of driver rototilling should be avoided at this point. Well, it's causing panics in some cases. Those are bad. Basically I would be reverting earlier changes. On Wed, 16 May 2001, John Baldwin wrote: On 16-May-01 Bob Bishop wrote: Hi, This while building world, with a kernel cvsup at Fri Apr 27 04:06:40 BST 2001 kern/kern_synch.c:386 sleeping with vr0 locked from pci/if_vr.c:1315 abridged backtrace: panic() propagate_priority() _mtx_lock_sleep() vr_intr() ithread_loop() fork_exit() fork_trampoline() Well, I think the best thing to do for now will be to back out all the ethernet driver locking until we figure out how we are actually going to lock them. The original locks that went in starting with fxp many months ago weren't quite right but have been mostly harmless up to this point. There are some cases where we sleep with locks however, which can lead to problems. -- 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 -- 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
PATCH: /usr/src/usr.bin/login
This patch adds the prompt and passwd_prompt fields to the
/etc/login.conf, which makes lgoin more like getty in its ability
to be configured.
Sorry, no documentation at this time, and no support for %h and
other getty psecific things.
Terry Lambert
[EMAIL PROTECTED]
---
Any opinions in this posting are my own and not those of my present
or previous employers.
-
RCS file: /home/cvs/FreeBSD/src/usr.bin/login/login.c,v
retrieving revision 1.51.2.5
diff -u -r1.51.2.5 login.c
--- login.c 2001/02/13 13:05:20 1.51.2.5
+++ login.c 2001/05/17 00:28:57
@@ -116,6 +116,8 @@
#defineTTYGRPNAME tty /* name of group to own ttys */
#defineDEFAULT_BACKOFF 3
#defineDEFAULT_RETRIES 10
+#defineDEFAULT_PROMPT login:
+#define DEFAULT_PASSWD_PROMPT Password:
/*
* This bounds the time given to login. Not a define so it can
@@ -128,7 +130,7 @@
struct passwd *pwd;
intfailures;
-char *term, *envinit[1], *hostname, *username, *tty;
+char *term, *envinit[1], *hostname, *username, *tty, *prompt, passwd_prompt;
charfull_hostname[MAXHOSTNAMELEN];
#ifndef NO_PAM
static char **environ_pam;
@@ -257,6 +259,8 @@
* Get login-retries login-backoff from default class
*/
lc = login_getclass(NULL);
+ prompt = login_getcapstr(lc, prompt, DEFAULT_PROMPT, DEFAULT_PROMPT);
+ passwd_prompt = login_getcapstr(lc, passwd_prompt, DEFAULT_PASSWD_PROMPT,
+DEFAULT_PASSWD_PROMPT);
retries = login_getcapnum(lc, login-retries, DEFAULT_RETRIES,
DEFAULT_RETRIES);
backoff = login_getcapnum(lc, login-backoff, DEFAULT_BACKOFF,
DEFAULT_BACKOFF);
login_close(lc);
@@ -651,7 +655,7 @@
rval = 1;
salt = pwd != NULL ? pwd-pw_passwd : xx;
- p = getpass(Password:);
+ p = getpass(passwd_prompt);
ep = crypt(p, salt);
if (pwd) {
@@ -819,7 +823,7 @@
static char nbuf[NBUFSIZ];
for (;;) {
- (void)printf(login: );
+ (void)printf(prompt);
for (p = nbuf; (ch = getchar()) != '\n'; ) {
if (ch == EOF) {
badlogin(username);
-
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
world broken yet again
cc -O2 -fno-strength-reduce -pipe -march=pentiumpro -DHAS_CGETENT -DENCRYPTION -DDES_ENCRYPTION -DAUTHENTICATION -DSRA -I/usr/src/secure/lib/libtelnet/../../../crypto/telnet -I/usr/obj/usr/src/i386/usr/include -c /usr/src/secure/lib/libtelnet/../../../crypto/telnet/libtelnet/pk.c -o pk.o /usr/src/secure/lib/libtelnet/../../../crypto/telnet/libtelnet/pk.c: In function `getseed': /usr/src/secure/lib/libtelnet/../../../crypto/telnet/libtelnet/pk.c:146: `i' undeclared (first use in this function) /usr/src/secure/lib/libtelnet/../../../crypto/telnet/libtelnet/pk.c:146: (Each undeclared identifier is reported only once /usr/src/secure/lib/libtelnet/../../../crypto/telnet/libtelnet/pk.c:146: for each function it appears in.) /usr/src/secure/lib/libtelnet/../../../crypto/telnet/libtelnet/pk.c: In function `pk_encode': /usr/src/secure/lib/libtelnet/../../../crypto/telnet/libtelnet/pk.c:235: warning: passing arg 1 of `des_cbc_encrypt' from incompatible pointer type /usr/src/secure/lib/libtelnet/../../../crypto/telnet/libtelnet/pk.c:235: warning: passing arg 2 of `des_cbc_encrypt' from incompatible pointer type /usr/src/secure/lib/libtelnet/../../../crypto/telnet/libtelnet/pk.c: In function `pk_decode': /usr/src/secure/lib/libtelnet/../../../crypto/telnet/libtelnet/pk.c:272: warning: passing arg 1 of `des_cbc_encrypt' from incompatible pointer type /usr/src/secure/lib/libtelnet/../../../crypto/telnet/libtelnet/pk.c:272: warning: passing arg 2 of `des_cbc_encrypt' from incompatible pointer type *** Error code 1 Stop in /usr/src/secure/lib/libtelnet. *** Error code 1 -- Michael D. Harnois[EMAIL PROTECTED] Redeemer Lutheran Church Washburn, Iowa Believe those who are seeking the truth. Doubt those who find it. -- Andre Gide To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: world broken yet again
In article [EMAIL PROTECTED]
Michael Harnois [EMAIL PROTECTED] wrote:
/usr/src/secure/lib/libtelnet/../../../crypto/telnet/libtelnet/pk.c: In function
`getseed':
/usr/src/secure/lib/libtelnet/../../../crypto/telnet/libtelnet/pk.c:146: `i'
undeclared (first use in this function)
/usr/src/secure/lib/libtelnet/../../../crypto/telnet/libtelnet/pk.c:146: (Each
undeclared identifier is reported only once
/usr/src/secure/lib/libtelnet/../../../crypto/telnet/libtelnet/pk.c:146: for each
function it appears in.)
/usr/src/secure/lib/libtelnet/../../../crypto/telnet/libtelnet/pk.c: In function
`pk_encode':
/usr/src/secure/lib/libtelnet/../../../crypto/telnet/libtelnet/pk.c:235: warning:
passing arg 1 of `des_cbc_encrypt' from incompatible pointer type
/usr/src/secure/lib/libtelnet/../../../crypto/telnet/libtelnet/pk.c:235: warning:
passing arg 2 of `des_cbc_encrypt' from incompatible pointer type
/usr/src/secure/lib/libtelnet/../../../crypto/telnet/libtelnet/pk.c: In function
`pk_decode':
/usr/src/secure/lib/libtelnet/../../../crypto/telnet/libtelnet/pk.c:272: warning:
passing arg 1 of `des_cbc_encrypt' from incompatible pointer type
/usr/src/secure/lib/libtelnet/../../../crypto/telnet/libtelnet/pk.c:272: warning:
passing arg 2 of `des_cbc_encrypt' from incompatible pointer type
*** Error code 1
Stop in /usr/src/secure/lib/libtelnet.
*** Error code 1
At least the 'i undeclared' error can be corrected by the next patch:
Index: src/crypto/telnet/libtelnet/pk.c
===
RCS file: /scratch/CVS/src/crypto/telnet/libtelnet/pk.c,v
retrieving revision 1.4
diff -b -u -r1.4 pk.c
--- src/crypto/telnet/libtelnet/pk.c2001/05/16 18:32:46 1.4
+++ src/crypto/telnet/libtelnet/pk.c2001/05/17 03:10:50
@@ -142,6 +142,7 @@
seed[i] = (lrand48() 0xff);
}
#else
+ int i;
srandomdev();
for (i = 0; i seedsize; i++) {
seed[i] = random() 0xff;
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: panic: sleeping process owns a mutex
John Baldwin wrote: On 16-May-01 Matthew Jacob wrote: Oh, I'd like you to think twice about this. Massive amounts of driver rototilling should be avoided at this point. Well, it's causing panics in some cases. Those are bad. Basically I would b e reverting earlier changes. For most of the drivers it is farly low impact. Simply replace things like this: #define FOO_LOCK(sc) mtx_lock(sc-sc_mtx); #define FOO_UNLOCK(sc) mtx_unlock(sc-sc_mtx); with: #if 0 #define FOO_LOCK(sc) mtx_lock(sc-sc_mtx); #define FOO_UNLOCK(sc) mtx_unlock(sc-sc_mtx); #else #define FOO_LOCK(sc) #define FOO_UNLOCK(sc) #endif That should at least discourage more cut/paste of the same broken locking logic into new drivers. On Wed, 16 May 2001, John Baldwin wrote: On 16-May-01 Bob Bishop wrote: Hi, This while building world, with a kernel cvsup at Fri Apr 27 04:06:40 BS T 2001 kern/kern_synch.c:386 sleeping with vr0 locked from pci/if_vr.c:1315 abridged backtrace: panic() propagate_priority() _mtx_lock_sleep() vr_intr() ithread_loop() fork_exit() fork_trampoline() Well, I think the best thing to do for now will be to back out all the ethernet driver locking until we figure out how we are actually going to lock them. The original locks that went in starting with fxp many months ago weren't quite right but have been mostly harmless up to this point. There are some cas es where we sleep with locks however, which can lead to problems. -- 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 -- 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 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
