> > The commit message of this commit says it's a workaround for a problem > > with lsi: > > > >> - when a read is aborted due to a mark/EOF/EOD/EOM, the len reported to > >> controller can be 0. LSI controller emulation doesn't know how to manage > >> this. A workaround found is to call the completion routine with > >> SCSI_REASON_DONE just after calling it with SCSI_REASON_DATA with len=0. > > > > Are you sure that it's not needed any more? > > > Don't ask me. I didn't do the patch, and my knowledge of lsi HBA > internals is scanty. > Nic, can you comment here?
Back to this topic... On my current WIP code, currently based on qemu upstream commit f711df67d611e4762966a249742a5f7499e19f99, I've just observed the following behaviour: Use -cdrom /dev/cdrom (which points to /dev/sr0) No disk in the drive, scsi-disk kicks in. test-unit-ready properly says there's no medium, so far so good. Now, my (buggy) guest code tries to do a READ_10. At this point, qemu hangs. What happens is that my scsi complete callback get called with reason 1 (DATA) and arg 0. I then perform no data copy, and call back sdev->info->read_data() which eventually calls me back again with reason 1 and arg 0, etc... in a loop. I haven't had a chance yet to look at what's happening in the guts of scsi-disk, but here, either I'm supposed to special case DATA with 0 bytes requested in my HBA driver, or there's a bug in scsi-disk. I can work around it by doing a cancel_io in that case and then completing the request is if reason had been 0 (DONE) but that's of course just a band-aid. I'll let you know what I find out when I get a chance to look at this again (hopefully soon). Cheers, Ben.