From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Iy6VE-00046l-1q for qemu-devel@nongnu.org; Fri, 30 Nov 2007 09:06:00 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Iy6VC-00044r-Ie for qemu-devel@nongnu.org; Fri, 30 Nov 2007 09:05:59 -0500 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Iy6VC-00044c-7S for qemu-devel@nongnu.org; Fri, 30 Nov 2007 09:05:58 -0500 Received: from tapir.sajinet.com.pe ([66.139.79.212]) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1Iy6VB-0007qZ-7I for qemu-devel@nongnu.org; Fri, 30 Nov 2007 09:05:57 -0500 Date: Fri, 30 Nov 2007 08:12:12 -0600 From: Carlo Marcelo Arenas Belon Subject: Re: [Qemu-devel] PATCH: ide.c: send irq for WIN_DIAGNOSE Message-ID: <20071130141212.GB28369@tapir> References: <20071129150747.GA9687@tapir> <375D8547-0185-445A-9C24-FE51C1CB86AA@adacore.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <375D8547-0185-445A-9C24-FE51C1CB86AA@adacore.com> Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org On Thu, Nov 29, 2007 at 05:46:08PM +0100, Tristan Gingold wrote: > On Nov 29, 2007, at 4:07 PM, Carlo Marcelo Arenas Belon wrote: > >On Thu, Nov 29, 2007 at 02:05:36PM +0100, Tristan Gingold wrote: > > >> The pending interrupt condition shall be set by: > >> ??? the completion of a command; or > >> > >>This patch sends an irq for WIN_DIAGNOSE (and WIN_SRST) > > > >DEVICE RESET or DEVICE DIAGNOSTIC in T13/1153D revision 18 don't > >ask for an > >irq. > > Well, not just after the command is executed. But according to 9.5.1 > of 1153D: > > l) After completing the above steps, Device 0 shall assert INTRQ if > nIEN is cleared to zero. > > So the IRQ is asserted at the end of diagnostic. right my bad, missed that on my copy of ATA-4 while looking for a match to your description of the mis-implementation, but why are you asserting one also for the reset? If I am reading the spec and the code right, the patch should be instead : Index: hw/ide.c =================================================================== RCS file: /sources/qemu/qemu/hw/ide.c,v retrieving revision 1.72 diff -u -r1.72 ide.c --- hw/ide.c 18 Nov 2007 01:44:37 -0000 1.72 +++ hw/ide.c 30 Nov 2007 14:02:33 -0000 @@ -2042,6 +2053,7 @@ ide_set_signature(s); s->status = 0x00; /* NOTE: READY is _not_ set */ s->error = 0x01; + ide_set_irq(s); break; case WIN_SRST: if (!s->is_cdrom) > >what is the use case you are trying to solve? which guest OS? > > The OS timeout during diagnostic. is there a way to reproduce that timeout on the guest OS you are using? if using Linux and smartctl, you will get a timeout but not because of this but because SMART is not supported (which might be also a bug, but at least not this bug) Carlo