As reported by Maciej Józefczyk, one can't boot a QEMU vm off a storage device hanging on an lsi53c895a controller. The problem was introduced by my series adding SCSI device enumeration with REPORT_LUNS command.
This series fixes the issue.
Roman Kagan (2): blockcmd: start REPORT_LUNS with the smallest buffer Revert "lsi-scsi: reset in case of a serious problem"
src/hw/blockcmd.c | 4 +++- src/hw/lsi-scsi.c | 2 -- 2 files changed, 3 insertions(+), 3 deletions(-)
A number of emulated SCSI devices in QEMU incorrectly return an error to REPORT_LUNS command when the size of the data returned is smaller than the allocation length passed in.
To work it around, start with the smallest allocation length possible: for 1 entry. This is a slight pessimization because it would require another REPORT_LUNS iteration if the target has more than a single LUN, but this appears to have negligible impact on boot times, and makes REPORT_LUNS enumeration work for more QEMU devices (lsi53c895a, mptsas1068).
Reported-by: Maciej Józefczyk maciej.jozefczyk@corp.ovh.com Signed-off-by: Roman Kagan rkagan@virtuozzo.com --- src/hw/blockcmd.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/src/hw/blockcmd.c b/src/hw/blockcmd.c index 324188d..98c06ce 100644 --- a/src/hw/blockcmd.c +++ b/src/hw/blockcmd.c @@ -215,7 +215,9 @@ static u64 scsilun2u64(struct scsi_lun *scsi_lun) int scsi_rep_luns_scan(struct drive_s *tmp_drive, scsi_add_lun add_lun) { int ret = -1; - u32 maxluns = 511; + /* start with the smallest possible buffer, otherwise some devices in QEMU + * may (incorrectly) error out on returning less data than fits in it */ + u32 maxluns = 1; u32 nluns, i; struct cdb_report_luns cdb = { .command = CDB_CMD_REPORT_LUNS,
This reverts commit 11277846e819b9eef3db5ac833a6a47f95f5ef15.
It was originally introduced to deal with the case when REPORT_LUNS caused an error in QEMU implementation of lsi53c895a and left it in a "confused" state making further interaction impossible.
However the remedy was worse than the disease: the reset was controller-wide causing all luns to reset, losing all in-flight requests; upon that all luns lit up unit_attention condition, so that any non-informational request would fail with check_condition status. As a result, the lun enumeration succeeded and I saw the respective entries in the boot menu during my testing, but the read from those luns ended with an error and booting failed, which I didn't bother to test.
So this reverts to the original error handling behavior. The problem with the failing REPORT_LUNS is addressed in the preceding patch, by making it unlikely to fail.
Reported-by: Maciej Józefczyk maciej.jozefczyk@corp.ovh.com Signed-off-by: Roman Kagan rkagan@virtuozzo.com --- src/hw/lsi-scsi.c | 2 -- 1 file changed, 2 deletions(-)
diff --git a/src/hw/lsi-scsi.c b/src/hw/lsi-scsi.c index 846bb0b..5233251 100644 --- a/src/hw/lsi-scsi.c +++ b/src/hw/lsi-scsi.c @@ -116,8 +116,6 @@ lsi_scsi_process_op(struct disk_op_s *op) u8 sist0 = inb(iobase + LSI_REG_SIST0); u8 sist1 = inb(iobase + LSI_REG_SIST1); if (sist0 || sist1) { - /* serious problem, can't continue w/o reset */ - outb(LSI_ISTAT0_SRST, iobase + LSI_REG_ISTAT0); goto fail; } if (dstat & 0x04) {
On Thu, Jun 08, 2017 at 12:58:06PM +0300, Roman Kagan wrote:
As reported by Maciej Józefczyk, one can't boot a QEMU vm off a storage device hanging on an lsi53c895a controller. The problem was introduced by my series adding SCSI device enumeration with REPORT_LUNS command.
This series fixes the issue.
Thanks. I committed this series.
-Kevin
-
Kevin O'Connor -
Roman Kagan