[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Qemu-devel] cmdide0:1:0: lost interrupt on NetBSD 7
From: |
Mark Cave-Ayland |
Subject: |
[Qemu-devel] cmdide0:1:0: lost interrupt on NetBSD 7 |
Date: |
Sat, 07 Nov 2015 13:29:07 +0000 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Icedove/31.8.0 |
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 <address@hidden>
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 <address@hidden>
Reviewed-by: Markus Armbruster <address@hidden>
Message-id: address@hidden
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.
- [Qemu-devel] cmdide0:1:0: lost interrupt on NetBSD 7,
Mark Cave-Ayland <=