From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1N3yRa-00057a-83 for qemu-devel@nongnu.org; Fri, 30 Oct 2009 16:51:34 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1N3yRV-00056X-MU for qemu-devel@nongnu.org; Fri, 30 Oct 2009 16:51:33 -0400 Received: from [199.232.76.173] (port=50388 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1N3yRV-00056S-Ec for qemu-devel@nongnu.org; Fri, 30 Oct 2009 16:51:29 -0400 Received: from e31.co.us.ibm.com ([32.97.110.149]:58909) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1N3yRV-0005VK-2F for qemu-devel@nongnu.org; Fri, 30 Oct 2009 16:51:29 -0400 Received: from d03relay05.boulder.ibm.com (d03relay05.boulder.ibm.com [9.17.195.107]) by e31.co.us.ibm.com (8.14.3/8.13.1) with ESMTP id n9UKiZ4o028037 for ; Fri, 30 Oct 2009 14:44:35 -0600 Received: from d03av02.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.195.168]) by d03relay05.boulder.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id n9UKp5Xr171014 for ; Fri, 30 Oct 2009 14:51:10 -0600 Received: from d03av02.boulder.ibm.com (loopback [127.0.0.1]) by d03av02.boulder.ibm.com (8.14.3/8.13.1/NCO v10.0 AVout) with ESMTP id n9UKmxLx001425 for ; Fri, 30 Oct 2009 14:48:59 -0600 Message-ID: <4AEB51B7.2030708@us.ibm.com> Date: Fri, 30 Oct 2009 15:51:03 -0500 From: Anthony Liguori MIME-Version: 1.0 References: <4AEB1F84.4010400@siemens.com> <4AEB25B1.8040709@us.ibm.com> <4AEB3F4F.4060407@web.de> <4AEB41A2.1060401@us.ibm.com> <4AEB45F5.4040204@web.de> <4AEB488B.4070603@us.ibm.com> <4AEB4D52.6000906@web.de> In-Reply-To: <4AEB4D52.6000906@web.de> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit Subject: [Qemu-devel] Re: Regression due to "Fall back to network boot..." List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Jan Kiszka Cc: qemu-devel Jan Kiszka wrote: > It's tunable: Customize -> Console Options -> BANNER_TIMEOUT > Ah, I missed that. >> Maybe we could wait until 0.13 and then introduce the FW cfg interface >> to gpxe? I've already talked to some of the gpxe devs about it and they >> seem pretty receptive. That would let us define how long the timeout was. >> >> The advantage of leaving in the timeout is that it lets a user access >> the gPXE menu even if it's not set to be bootable. You see this on bare >> metal all of the time with gPXE. >> > > Yeah, you see this or even much longer netboot related timeouts these > days everywhere. Specifically when every damn NIC adds its own delay to > the boot, you quickly wait half a minute or more on this stage. Granted, > it's by far not that bad with qemu and gpxe, but this delay is a > regression from the nice speed we just gained a few months ago. > > OK, compromise until we have a proper FW interface: BANNER_TIMEOUT=3. > That leaves us with a fair chance to break in but keeps the delay > regression low > I'm okay with BANNER_TIMEOUT=0 until we get a proper FW interface. -- Regards, Anthony Liguori