From patchwork Fri Nov 20 19:08:03 2009 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Kevin O'Connor X-Patchwork-Id: 38936 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Received: from lists.gnu.org (lists.gnu.org [199.232.76.165]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by ozlabs.org (Postfix) with ESMTPS id 27EC91007D1 for ; Sat, 21 Nov 2009 06:09:56 +1100 (EST) Received: from localhost ([127.0.0.1]:36563 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NBYrh-0004aQ-BO for incoming@patchwork.ozlabs.org; Fri, 20 Nov 2009 14:09:53 -0500 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NBYq4-0003wa-Ng for qemu-devel@nongnu.org; Fri, 20 Nov 2009 14:08:12 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1NBYpy-0003sF-IM for qemu-devel@nongnu.org; Fri, 20 Nov 2009 14:08:11 -0500 Received: from [199.232.76.173] (port=56744 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NBYpy-0003s4-7p for qemu-devel@nongnu.org; Fri, 20 Nov 2009 14:08:06 -0500 Received: from imta-38.everyone.net ([216.200.145.38]:45372 helo=omta0110.mta.everyone.net) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1NBYpx-0005iL-Lh for qemu-devel@nongnu.org; Fri, 20 Nov 2009 14:08:05 -0500 Received: from dm0201.mta.everyone.net (sj1-slb03-gw2 [172.16.1.96]) by omta0110.mta.everyone.net (Postfix) with ESMTP id 3DE7363957E; Fri, 20 Nov 2009 11:08:04 -0800 (PST) X-Eon-Dm: dm0201 Received: by dm0201.mta.everyone.net (EON-AUTHRELAY2 - cfedc2a1) id dm0201.4b04799c.4de64d; Fri, 20 Nov 2009 11:08:03 -0800 X-Eon-Sig: AQHOS7NLBukT0mgdVAIAAAAD,b59a4084d2c11c5592607896c0227670 Date: Fri, 20 Nov 2009 14:08:03 -0500 From: Kevin O'Connor To: Avi Kivity Message-ID: <20091120190803.GA22484@morn.localdomain> References: <4B02A35B.10801@redhat.com> <20091118051920.GA9691@morn.localdomain> <20091120180351.GA21458@morn.localdomain> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20091120180351.GA21458@morn.localdomain> User-Agent: Mutt/1.5.19 (2009-01-05) X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 3) Cc: qemu-devel , KVM list Subject: [Qemu-devel] Re: SeaBIOS cdrom regression with Vista X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org Errors-To: qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org On Fri, Nov 20, 2009 at 01:03:51PM -0500, Kevin O'Connor wrote: > I've looked into this, and it looks like the cdrom is left in an odd > state. At this point, I think SeaBIOS is tickling a bug outside of > seabios (eg, in Vista or qemu). I would appreciate it someone with > cdrom knowledge of qemu could help. [...] > SeaBIOS has a different ata drive detection mechanism than bochs - it > needs it in order to work on real hardware. So, this explains why > bochs bios doesn't show this issue. (Seabios tries to send an > "identify packet device" and then an "identify device" command to > detect a drive; bochs bios looks for a signature in the ata registers > after an ata reset.) It looks like I spoke too soon. It appears the SeaBIOS init can leave the ATA controller in an interrupts disabled state. This appears to confuse Vista. So, this is a SeaBIOS bug - I'll implement a fix. The patch below enables Vista to see the cdrom (though, it's not a real fix). -Kevin --- a/src/ata.c +++ b/src/ata.c @@ -237,6 +237,7 @@ send_cmd(struct drive_s *drive_g, struct ata_pio_command *cmd) return -4; } if (!(status & ATA_CB_STAT_DRQ)) { + outb(ATA_CB_DC_HD15, iobase2+ATA_CB_DC); dprintf(6, "send_cmd : DRQ not set (status %02x)\n", status); return -5; }