* [Qemu-devel] cmdide0:1:0: lost interrupt on NetBSD 7
@ 2015-11-07 13:29 Mark Cave-Ayland
2015-11-09 16:45 ` John Snow
0 siblings, 1 reply; 2+ messages in thread
From: Mark Cave-Ayland @ 2015-11-07 13:29 UTC (permalink / raw)
To: qemu-devel; +Cc: John Snow
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.
^ permalink raw reply [flat|nested] 2+ messages in thread
* Re: [Qemu-devel] cmdide0:1:0: lost interrupt on NetBSD 7
2015-11-07 13:29 [Qemu-devel] cmdide0:1:0: lost interrupt on NetBSD 7 Mark Cave-Ayland
@ 2015-11-09 16:45 ` John Snow
0 siblings, 0 replies; 2+ messages in thread
From: John Snow @ 2015-11-09 16:45 UTC (permalink / raw)
To: Mark Cave-Ayland, qemu-devel
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
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2015-11-09 16:45 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2015-11-07 13:29 [Qemu-devel] cmdide0:1:0: lost interrupt on NetBSD 7 Mark Cave-Ayland
2015-11-09 16:45 ` John Snow
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.