[Qemu-devel] cmdide0:1:0: lost interrupt on NetBSD 7

[Qemu-devel] cmdide0:1:0: lost interrupt on NetBSD 7

[Mark Cave-Ayland]

Whilst testing various images under qemu-system-sparc64, I've noticed a
regression with the new NetBSD 7 release. On boot the kernel hangs just
after detecting the CDROM and eventually outputs "cmdide0:1:0: lost
interrupt" onto the console.

A quick session with git bisect points to the following patch:

9ef2e93f9b1888c7d0deb4a105149138e6ad2e98 is the first bad commit
commit 9ef2e93f9b1888c7d0deb4a105149138e6ad2e98
Author: John Snow <jsnow@redhat.com>
Date:   Thu Sep 17 14:17:05 2015 -0400

    atapi: abort transfers with 0 byte limits

    We're supposed to abort on transfers like this, unless we fill
    Word 125 of our IDENTIFY data with a default transfer size, which
    we don't currently do.

    This is an ATA error, not a SCSI/ATAPI one.
    See ATA8-ACS3 sections 7.17.6.49 or 7.21.5.

    If we don't do this, QEMU will loop forever trying to transfer
    zero bytes, which isn't particularly useful.

    Signed-off-by: John Snow <jsnow@redhat.com>
    Reviewed-by: Markus Armbruster <armbru@redhat.com>
    Message-id: 1442253685-23349-2-git-send-email-jsnow@redhat.com

Reproducing the bug is easy enough using the command line below:

./qemu-system-sparc64 -cdrom NetBSD-7.0-sparc64.iso -boot d -nographic

Testing also shows that NetBSD 6 is apparently unaffected by this change.


ATB,

Mark.

Re: [Qemu-devel] cmdide0:1:0: lost interrupt on NetBSD 7

[John Snow]

On 11/07/2015 08:29 AM, Mark Cave-Ayland wrote:
> Whilst testing various images under qemu-system-sparc64, I've noticed a
> regression with the new NetBSD 7 release. On boot the kernel hangs just
> after detecting the CDROM and eventually outputs "cmdide0:1:0: lost
> interrupt" onto the console.
> 
> A quick session with git bisect points to the following patch:
> 
> 9ef2e93f9b1888c7d0deb4a105149138e6ad2e98 is the first bad commit
> commit 9ef2e93f9b1888c7d0deb4a105149138e6ad2e98
> Author: John Snow <jsnow@redhat.com>
> Date:   Thu Sep 17 14:17:05 2015 -0400
> 
>     atapi: abort transfers with 0 byte limits
> 
>     We're supposed to abort on transfers like this, unless we fill
>     Word 125 of our IDENTIFY data with a default transfer size, which
>     we don't currently do.
> 
>     This is an ATA error, not a SCSI/ATAPI one.
>     See ATA8-ACS3 sections 7.17.6.49 or 7.21.5.
> 
>     If we don't do this, QEMU will loop forever trying to transfer
>     zero bytes, which isn't particularly useful.
> 
>     Signed-off-by: John Snow <jsnow@redhat.com>
>     Reviewed-by: Markus Armbruster <armbru@redhat.com>
>     Message-id: 1442253685-23349-2-git-send-email-jsnow@redhat.com
> 
> Reproducing the bug is easy enough using the command line below:
> 
> ./qemu-system-sparc64 -cdrom NetBSD-7.0-sparc64.iso -boot d -nographic
> 
> Testing also shows that NetBSD 6 is apparently unaffected by this change.
> 
> 
> ATB,
> 
> Mark.
> 

Well, that's interesting ... The condition this patch was added to
protect was PIO transfers with 0 byte transfer limits, which caused an
infinite loop before. (It shouldn't have ever worked!)

That I actually managed to break a guest with this is a little shocking.

I'll debug, thanks.

--js