From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([208.118.235.92]:39546)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <jan.kiszka@siemens.com>) id 1Sbz7h-0004ez-J3
	for qemu-devel@nongnu.org; Tue, 05 Jun 2012 15:08:58 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <jan.kiszka@siemens.com>) id 1Sbz7c-0000wX-DG
	for qemu-devel@nongnu.org; Tue, 05 Jun 2012 15:08:57 -0400
Received: from goliath.siemens.de ([192.35.17.28]:17027)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <jan.kiszka@siemens.com>) id 1Sbz7c-0000w2-3J
	for qemu-devel@nongnu.org; Tue, 05 Jun 2012 15:08:52 -0400
Message-ID: <4FCE593E.5020708@siemens.com>
Date: Tue, 05 Jun 2012 21:08:46 +0200
From: Jan Kiszka <jan.kiszka@siemens.com>
MIME-Version: 1.0
References: <4FA17998.9040001@siemens.com>
	<1B2F3665-DC41-4553-800E-D14A0F876553@suse.de>
	<4FA27754.1070005@siemens.com>
In-Reply-To: <4FA27754.1070005@siemens.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Subject: Re: [Qemu-devel] Sporadic AHCI boot failures
List-Id: <qemu-devel.nongnu.org>
List-Unsubscribe: <https://lists.nongnu.org/mailman/options/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.nongnu.org/archive/html/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <https://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Alexander Graf <agraf@suse.de>
Cc: Avi Kivity <avi@redhat.com>, Marcelo Tosatti <mtosatti@redhat.com>, qemu-devel <qemu-devel@nongnu.org>, Gerd Hoffmann <kraxel@redhat.com>

On 2012-05-03 14:17, Jan Kiszka wrote:
> On 2012-05-02 18:26, Alexander Graf wrote:
>>
>>
>> On 02.05.2012, at 20:14, Jan Kiszka <jan.kiszka@siemens.com> wrote:
>>
>>> Hi,
>>>
>>> I'm running a Win7 VM over AHCI, rebooting quite frequently. Depending
>>> on host system load, I'm facing a lot of sporadic boot failures (disk
>>> not found), obviously in SeaBIOS. Could it be that some timeout in the
>>> init code bites us here? AHCI_LINK_TIMEOUT or AHCI_RESET_TIMEOUT? Just a
>>> guess, I haven't debugged this yet.
>>
>> Hm, I'd be surprised if that's the problem.
>>
>> Do things work again after system_reset on the monitor? Maybe the reset function is just broken and we finish some asynchronous stuff after reset?
> 
> The problem both occurs after power on as well as reset. Sometimes it
> takes multiple system_reset calls to get the system booting.

Think I found it: There is bug in the new in-kernel PIT userspace code
that lets Seabios detect some 4..7 MHz CPU. So all the timeouts finish
way too early. This also affects IDE and possible other stuff in the
bios that depends on timeouts.

Digging into this...

Jan

-- 
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux