From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([2001:4830:134:3::10]:55133)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <mark.cave-ayland@ilande.co.uk>) id 1Zv3Ys-0003tp-GQ
	for qemu-devel@nongnu.org; Sat, 07 Nov 2015 08:29:43 -0500
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <mark.cave-ayland@ilande.co.uk>) id 1Zv3Yp-0003Ka-Ak
	for qemu-devel@nongnu.org; Sat, 07 Nov 2015 08:29:42 -0500
Received: from s16892447.onlinehome-server.info ([82.165.15.123]:50514)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <mark.cave-ayland@ilande.co.uk>) id 1Zv3Yp-0003KT-4J
	for qemu-devel@nongnu.org; Sat, 07 Nov 2015 08:29:39 -0500
Message-ID: <563DFCA3.6060200@ilande.co.uk>
Date: Sat, 07 Nov 2015 13:29:07 +0000
From: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Subject: [Qemu-devel] cmdide0:1:0: lost interrupt on NetBSD 7
List-Id: <qemu-devel.nongnu.org>
List-Unsubscribe: <https://lists.nongnu.org/mailman/options/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.nongnu.org/archive/html/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <https://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: qemu-devel <qemu-devel@nongnu.org>
Cc: John Snow <jsnow@redhat.com>

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.