From owner-freebsd-emulation@FreeBSD.ORG Tue Aug 16 21:07:44 2011 Return-Path: Delivered-To: freebsd-emulation@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3DE0C1065674 for ; Tue, 16 Aug 2011 21:07:44 +0000 (UTC) (envelope-from spawk@acm.poly.edu) Received: from acm.poly.edu (acm.poly.edu [128.238.9.200]) by mx1.freebsd.org (Postfix) with ESMTP id D58628FC1A for ; Tue, 16 Aug 2011 21:07:43 +0000 (UTC) Received: (qmail 68391 invoked from network); 16 Aug 2011 20:41:01 -0000 Received: from unknown (HELO ?10.50.50.200?) (spawk@64.147.100.2) by acm.poly.edu with CAMELLIA256-SHA encrypted SMTP; 16 Aug 2011 20:41:01 -0000 Message-ID: <4E4AD5D6.6090803@acm.poly.edu> Date: Tue, 16 Aug 2011 16:40:54 -0400 From: Boris Kochergin User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:5.0) Gecko/20110701 Thunderbird/5.0 MIME-Version: 1.0 To: freebsd-emulation@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Funny sleep behavior with 8.2-R/amd64 on Linux KVM X-BeenThere: freebsd-emulation@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of Emulators of other operating systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Aug 2011 21:07:44 -0000 Hi. I have KVM running on a Linux machine: # uname -a Linux [censored] 2.6.18-238.19.1.el5 #1 SMP Fri Jul 15 07:31:24 EDT 2011 x86_64 x86_64 x86_64 GNU/Linux I created it as follows: virt-install --name [censored] --vcpus 2 --ram 2048 --disk path=/var/lib/libvirt/images/[censored]/[censored],size=10,sparse=false --cdrom=/xen/iso/FreeBSD-8.2-RELEASE-amd64-disc1.iso --network bridge:br0 --network bridge:br1 --vnc --noautoconsole --hvm --accelerate --os-variant=freebsd7 --os-type unix Everything seems fine except one thing: it looks like the system, when asked to sleep, sleeps for three times as long as it was asked to: # time sleep 1 0.000u 0.000s 0:03.02 0.0% 0+0k 0+0io 0pf+0w This is also evident in increased top(1) update delays, delays between ping(8) sending packets, and so forth. Any thoughts?