From owner-freebsd-current Tue Oct 13 14:31:30 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id OAA29968 for freebsd-current-outgoing; Tue, 13 Oct 1998 14:31:30 -0700 (PDT) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from highwind.com (hurricane.highwind.com [209.61.45.50]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id OAA29958 for ; Tue, 13 Oct 1998 14:31:21 -0700 (PDT) (envelope-from info@highwind.com) Received: (from info@localhost) by highwind.com (8.8.6/8.8.6) id RAA06806; Tue, 13 Oct 1998 17:30:58 -0400 (EDT) Date: Tue, 13 Oct 1998 17:30:58 -0400 (EDT) Message-Id: <199810132130.RAA06806@highwind.com> From: HighWind Software Information To: current@FreeBSD.ORG Subject: Recent 3.0's are Depressing Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG After lots of work a few months ago, we got all of our software working great under FreeBSD 3.0. In fact, it STILL works great.. That is, under: % uname -a FreeBSD zonda.highwind.com 3.0-19980831-SNAP FreeBSD 3.0-19980831-SNAP #0: Mon Aug 31 14:03:19 GMT 1998 root@make.ican.net:/usr/src/sys/compile/GENERIC i386 However, under the newer FreeBSD's it doesn't seem to work. Our application goes into 100% user space CPU and makes no progress. 3583 typhoond CALL sigprocmask(0x3,0) 3583 typhoond RET sigprocmask 0 3583 typhoond CALL sigprocmask(0x1,0) 3583 typhoond RET sigprocmask 0 3583 typhoond CALL gettimeofday(0x1574f4c,0) 3583 typhoond RET gettimeofday 0 3583 typhoond CALL setitimer(0x1,0x1574f54,0) 3583 typhoond RET setitimer 0 3583 typhoond CALL sigprocmask(0x3,0) 3583 typhoond RET sigprocmask 0 3583 typhoond CALL sigprocmask(0x1,0) 3583 typhoond RET sigprocmask 0 3583 typhoond CALL gettimeofday(0x1554f4c,0) 3583 typhoond RET gettimeofday 0 3583 typhoond CALL setitimer(0x1,0x1554f54,0) 3583 typhoond RET setitimer 0 (I'm fairly sure this is from uthread_kern.c) We are an "aout" binary and have even tried STATICALLY linking with our libc_r. It still goes into this loop. Any ideas what could have happened to cause this. It WAS working fine. Now, after a little progress, we get into an infinite loop. Typhoon uses lots of disk and network I/O. What could we have tripped on? Seems to me, statically linking in libc_r would have eliminated any of the recent changes in libc_r from blame. I'm a bit lost as to what to do. I guess we could upgrade our FreeBSD machine and begin banging our heads against the wall. I'm wondering if anyone on this list would have a guess as to what new changes to the kernel may have caused this. -Rob To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message