From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:50231) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZvpZa-0007lp-KT for qemu-devel@nongnu.org; Mon, 09 Nov 2015 11:45:39 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZvpZW-0001mk-Rf for qemu-devel@nongnu.org; Mon, 09 Nov 2015 11:45:38 -0500 Received: from mx1.redhat.com ([209.132.183.28]:33397) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZvpZW-0001mg-IQ for qemu-devel@nongnu.org; Mon, 09 Nov 2015 11:45:34 -0500 References: <563DFCA3.6060200@ilande.co.uk> From: John Snow Message-ID: <5640CDAC.7020702@redhat.com> Date: Mon, 9 Nov 2015 11:45:32 -0500 MIME-Version: 1.0 In-Reply-To: <563DFCA3.6060200@ilande.co.uk> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] cmdide0:1:0: lost interrupt on NetBSD 7 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , 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 > 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 > Reviewed-by: Markus Armbruster > 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