qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] PATCH: ide.c: send irq for WIN_DIAGNOSE


From: Carlo Marcelo Arenas Belon
Subject: Re: [Qemu-devel] PATCH: ide.c: send irq for WIN_DIAGNOSE
Date: Fri, 30 Nov 2007 08:12:12 -0600
User-agent: Mutt/1.4.1i

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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]