On 06/06/2016 11:43 AM, Paolo Bonzini wrote: > > > On 06/06/2016 17:41, John Snow wrote: >> On 06/06/2016 11:05 AM, Paolo Bonzini wrote: >>> For ATAPI, you have to blacklist all versions up to 2.2 inclusive. >>> >>> This gives: >>> >>> - QEMU / QEMU CD-ROM / 0.8. (this is IDE and SCSI) >>> - QEMU / QEMU CD-ROM / 0.9. (this is IDE and SCSI) >>> - QEMU / QEMU CD-ROM / 0.10 (this is SCSI only) >>> - QEMU / QEMU CD-ROM / 0.11 (this is SCSI only) >>> - QEMU / QEMU DVD-ROM / 0.8. (this is IDE only) >>> - QEMU / QEMU DVD-ROM / 0.9. (this is IDE only) >>> - QEMU / QEMU DVD-ROM / 0.10 (this is IDE only) >>> - QEMU / QEMU DVD-ROM / 0.11 (this is IDE only) >>> - QEMU / QEMU DVD-ROM / 0.12 (this is IDE only) >>> - QEMU / QEMU DVD-ROM / 0.13 (this is IDE only) >>> - QEMU / QEMU DVD-ROM / 0.14 (this is IDE only) >>> - QEMU / QEMU DVD-ROM / 0.15 (this is IDE only) >>> - QEMU / QEMU DVD-ROM / 1.0 (this is IDE only) >>> - QEMU / QEMU DVD-ROM / 1.1 (this is IDE only) >>> - QEMU / QEMU DVD-ROM / 1.2 (this is IDE only) >>> - QEMU / QEMU DVD-ROM / 1.3 (this is IDE only) >>> - QEMU / QEMU DVD-ROM / 1.4 (this is IDE only) >>> - QEMU / QEMU DVD-ROM / 1.5 (this is IDE only) >>> - QEMU / QEMU DVD-ROM / 1.6 (this is IDE only) >>> - QEMU / QEMU DVD-ROM / 1.7 (this is IDE only) >>> - QEMU / QEMU DVD-ROM / 2.0 (this is IDE only) >>> - QEMU / QEMU DVD-ROM / 2.1 (this is IDE only) >>> - QEMU / QEMU DVD-ROM / 2.2 (this is IDE only) >>> >> >> If this bug is caused by a missing VPD response, Paolo's version history >> here is correct.... for upstream versions. >> >> Various downstreams may have backported the VPD fix to older versions, >> we need to be careful not to block those, too ... so targeting the core >> behavior seems like the more strictly correct, easily maintainable solution. > > I think this is not practical. I'm okay with the big hammer if an > algorithmic fix is not feasible; but otherwise it does seem a better > idea than blacklisting based on inquiry data... > > Thanks, > > Paolo > You think the more practical solution is a SCSI driver that can hang because of an incorrect/missing response and to maintain a carefully curated blacklist to work around this behavior? >> Why not just dynamically blacklist devices that fail to respond to VPD >> inquiries? > -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
