From owner-freebsd-current@FreeBSD.ORG Tue Dec 19 19:56:20 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 72BC216A706 for ; Tue, 19 Dec 2006 19:56:20 +0000 (UTC) (envelope-from youshi10@u.washington.edu) Received: from mxout7.cac.washington.edu (mxout7.cac.washington.edu [140.142.32.178]) by mx1.FreeBSD.org (Postfix) with ESMTP id A3BF643CC0 for ; Tue, 19 Dec 2006 19:55:40 +0000 (GMT) (envelope-from youshi10@u.washington.edu) Received: from smtp.washington.edu (smtp.washington.edu [140.142.32.141]) by mxout7.cac.washington.edu (8.13.7+UW06.06/8.13.7+UW06.09) with ESMTP id kBJJtdmk007676 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Tue, 19 Dec 2006 11:55:39 -0800 X-Auth-Received: from [128.208.5.99] (nilakantha.cs.washington.edu [128.208.5.99]) (authenticated authid=youshi10) by smtp.washington.edu (8.13.7+UW06.06/8.13.7+UW06.09) with ESMTP id kBJJtdUP017204 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Tue, 19 Dec 2006 11:55:39 -0800 Message-ID: <458843B8.1060704@u.washington.edu> Date: Tue, 19 Dec 2006 11:55:36 -0800 From: Garrett Cooper User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: freebsd-current@freebsd.org References: <790a9fff0612190915va75678at895efa0bc93ac3a1@mail.gmail.com> In-Reply-To: <790a9fff0612190915va75678at895efa0bc93ac3a1@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-PMX-Version: 5.2.2.285561, Antispam-Engine: 2.5.0.283055, Antispam-Data: 2006.12.19.113932 X-Uwash-Spam: Gauge=IIIIIII, Probability=7%, Report='__CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0, __USER_AGENT 0' Subject: Re: settimeofday function taking 24 - 30 minutes to complete X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Dec 2006 19:56:20 -0000 Scot Hetzel wrote: > While working on implementing the settimeofday function in the > linuxolator, I was using the LTP testcase settimeofday01 to test it. > Running this test caused the system to hang for 24-30 minutes. > > I then decided to rewrite the testcase so that it would run on > FreeBSD, and it also hung the system for 24-30 minutes. What the > settimeofday01 test was doing is to set the time to a known value (100 > sec, 100 usec) and then use gettimeofday to retrieve the current time. > It then compared the returned value to check if it was within +/- 500 > msec. > > I have since reduced the testcode down to the following testcase that > is causing the hang. > > Any ideals as to what could be causing this hang? > > Scot > > #include > #include > #include > > #define VAL_SEC 100 > #define VAL_MSEC 100 > > int main(int argc, char **argv) > { > struct timeval tp, tp1, save_tv; > long return_test, errno_test; > suseconds_t delta; > > #define TEST(SCALL) \ > do { \ > errno = 0; \ > return_test = SCALL; \ > errno_test = errno; \ > } while (0) > > /* Save the current time values */ > if ((gettimeofday(&save_tv, (struct timezone *)&tp1)) == -1) { > printf("BROK: gettimeofday failed. errno=%d\n", errno); > exit(1); > } else { > printf("INFO: Saved current time\n"); > } > > tp.tv_sec = VAL_SEC; > tp.tv_usec = VAL_MSEC; > > /* Hang occurs here */ > TEST(settimeofday(&tp, NULL)); > if (return_test == -1) { > printf("FAIL: Error Setting Time, errno=%d\n", > errno_test); > } else { > printf("INFO: settimeofday completed sucessfully\n"); > } > > /* restore the original time values. */ > if ((settimeofday(&save_tv, NULL)) == -1) { > printf("WARN: FATAL COULD NOT RESET THE CLOCK\n"); > printf("FAIL: Error Setting Time, errno=%d (%d, %d)\n", > errno, tp.tv_sec, tp.tv_usec); > } else { > printf("INFO: Reset time to original value\n"); > } > > return(0); > } > Not sure about why it takes so long to complete, but it seems as if the system is 'hanging' because it probably is using up all of your CPU resources in the while loop under your TEST macro. Maybe the near 100% CPU usage is effecting kernel operations as well, i.e. slowing it down to stone age speeds? sleep(3)/nanosleep(2) to the rescue? -Garrett