| Message ID | abf81ec4f8b6139fffc609df519856ff8dc01d0d.1571834862.git.msuchanek@suse.de (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | Fix cdrom autoclose. | expand |
On 10/23/19 2:52 PM, Michal Suchanek wrote: > The WMware ESXi cdrom identifies itself as: > sr 0:0:0:0: [sr0] scsi3-mmc drive: vendor: "NECVMWarVMware SATA CD001.00" > model: "VMware SATA CD001.00" > with the following get_capabilities print in sr.c: > sr_printk(KERN_INFO, cd, > "scsi3-mmc drive: vendor: \"%s\" model: \"%s\"\n", > cd->device->vendor, cd->device->model); > > So the model looks like reliable identification while vendor does not. > > The drive claims to have a tray and claims to be able to close it. > However, the UI has no notion of a tray - when medium is ejected it is > dropped in the floor and the user must select a medium again before the > drive can be re-loaded. On the kernel side the tray_move call to close > the tray succeeds but the drive state does not change as a result of the > call. > > The drive does not in fact emulate the tray state. There are two ways to > get the medium state. One is the SCSI status: > > Physical drive: > > Fixed format, current; Sense key: Not Ready > Additional sense: Medium not present - tray open > Raw sense data (in hex): > 70 00 02 00 00 00 00 0a 00 00 00 00 3a 02 00 00 > 00 00 > > Fixed format, current; Sense key: Not Ready > Additional sense: Medium not present - tray closed > Raw sense data (in hex): > 70 00 02 00 00 00 00 0a 00 00 00 00 3a 01 00 00 > 00 00 > > VMware ESXi: > > Fixed format, current; Sense key: Not Ready > Additional sense: Medium not present > Info fld=0x0 [0] > Raw sense data (in hex): > f0 00 02 00 00 00 00 0a 00 00 00 00 3a 00 00 00 > 00 00 > > So the tray state is not reported here. Other is medium status which the > kernel prefers if available. Adding a print here gives: > > cdrom: get_media_event success: code = 0, door_open = 1, medium_present = 0 > > door_open is interpreted as open tray. This is fine so long as tray_move > would close the tray when requested or report an error which never > happens on VMware ESXi servers (5.5 and 6.5 tested). > > This is a popular virtualization platform so a workaround is worthwhile. > > Signed-off-by: Michal Suchanek <msuchanek@suse.de> > --- > drivers/scsi/sr.c | 6 ++++++ > 1 file changed, 6 insertions(+) > > diff --git a/drivers/scsi/sr.c b/drivers/scsi/sr.c > index 4664fdf75c0f..8090c5bdec09 100644 > --- a/drivers/scsi/sr.c > +++ b/drivers/scsi/sr.c > @@ -867,6 +867,7 @@ static void get_capabilities(struct scsi_cd *cd) > unsigned int ms_len = 128; > int rc, n; > > + static const char *model_vmware = "VMware"; > static const char *loadmech[] = > { > "caddy", > @@ -922,6 +923,11 @@ static void get_capabilities(struct scsi_cd *cd) > buffer[n + 4] & 0x20 ? "xa/form2 " : "", /* can read xa/from2 */ > buffer[n + 5] & 0x01 ? "cdda " : "", /* can read audio data */ > loadmech[buffer[n + 6] >> 5]); > + if (!strncmp(cd->device->model, model_vmware, strlen(model_vmware))) { > + buffer[n + 6] &= ~(0xff << 5); > + sr_printk(KERN_INFO, cd, > + "VMware ESXi bug workaround: tray -> caddy\n"); > + } > if ((buffer[n + 6] >> 5) == 0) > /* caddy drives can't close tray... */ > cd->cdi.mask |= CDC_CLOSE_TRAY; > This looks something which should be handled via a blacklist flag, not some inline hack which everyone forgets about it... Cheers, Hannes
On Wed, Oct 23, 2019 at 04:13:15PM +0200, Hannes Reinecke wrote: > On 10/23/19 2:52 PM, Michal Suchanek wrote: > > The WMware ESXi cdrom identifies itself as: > > sr 0:0:0:0: [sr0] scsi3-mmc drive: vendor: "NECVMWarVMware SATA CD001.00" > > model: "VMware SATA CD001.00" > > with the following get_capabilities print in sr.c: > > sr_printk(KERN_INFO, cd, > > "scsi3-mmc drive: vendor: \"%s\" model: \"%s\"\n", > > cd->device->vendor, cd->device->model); > > > > So the model looks like reliable identification while vendor does not. > > > > The drive claims to have a tray and claims to be able to close it. > > However, the UI has no notion of a tray - when medium is ejected it is > > dropped in the floor and the user must select a medium again before the > > drive can be re-loaded. On the kernel side the tray_move call to close > > the tray succeeds but the drive state does not change as a result of the > > call. > > > > The drive does not in fact emulate the tray state. There are two ways to > > get the medium state. One is the SCSI status: > > > > Physical drive: > > > > Fixed format, current; Sense key: Not Ready > > Additional sense: Medium not present - tray open > > Raw sense data (in hex): > > 70 00 02 00 00 00 00 0a 00 00 00 00 3a 02 00 00 > > 00 00 > > > > Fixed format, current; Sense key: Not Ready > > Additional sense: Medium not present - tray closed > > Raw sense data (in hex): > > 70 00 02 00 00 00 00 0a 00 00 00 00 3a 01 00 00 > > 00 00 > > > > VMware ESXi: > > > > Fixed format, current; Sense key: Not Ready > > Additional sense: Medium not present > > Info fld=0x0 [0] > > Raw sense data (in hex): > > f0 00 02 00 00 00 00 0a 00 00 00 00 3a 00 00 00 > > 00 00 > > > > So the tray state is not reported here. Other is medium status which the > > kernel prefers if available. Adding a print here gives: > > > > cdrom: get_media_event success: code = 0, door_open = 1, medium_present = 0 > > > > door_open is interpreted as open tray. This is fine so long as tray_move > > would close the tray when requested or report an error which never > > happens on VMware ESXi servers (5.5 and 6.5 tested). > > > > This is a popular virtualization platform so a workaround is worthwhile. > > > > Signed-off-by: Michal Suchanek <msuchanek@suse.de> > > --- > > drivers/scsi/sr.c | 6 ++++++ > > 1 file changed, 6 insertions(+) > > > > diff --git a/drivers/scsi/sr.c b/drivers/scsi/sr.c > > index 4664fdf75c0f..8090c5bdec09 100644 > > --- a/drivers/scsi/sr.c > > +++ b/drivers/scsi/sr.c > > @@ -867,6 +867,7 @@ static void get_capabilities(struct scsi_cd *cd) > > unsigned int ms_len = 128; > > int rc, n; > > > > + static const char *model_vmware = "VMware"; > > static const char *loadmech[] = > > { > > "caddy", > > @@ -922,6 +923,11 @@ static void get_capabilities(struct scsi_cd *cd) > > buffer[n + 4] & 0x20 ? "xa/form2 " : "", /* can read xa/from2 */ > > buffer[n + 5] & 0x01 ? "cdda " : "", /* can read audio data */ > > loadmech[buffer[n + 6] >> 5]); > > + if (!strncmp(cd->device->model, model_vmware, strlen(model_vmware))) { > > + buffer[n + 6] &= ~(0xff << 5); > > + sr_printk(KERN_INFO, cd, > > + "VMware ESXi bug workaround: tray -> caddy\n"); > > + } > > if ((buffer[n + 6] >> 5) == 0) > > /* caddy drives can't close tray... */ > > cd->cdi.mask |= CDC_CLOSE_TRAY; > > > This looks something which should be handled via a blacklist flag, not > some inline hack which everyone forgets about it... AFAIK we used to have a blacklist but don't have anymore. So either it has to be resurrected for this one flag or an inline hack should be good enough. Thanks Michal
On Wed, 2019-10-23 at 18:23 +0200, Michal Suchánek wrote: > On Wed, Oct 23, 2019 at 04:13:15PM +0200, Hannes Reinecke wrote: > > On 10/23/19 2:52 PM, Michal Suchanek wrote: > > > The WMware ESXi cdrom identifies itself as: > > > sr 0:0:0:0: [sr0] scsi3-mmc drive: vendor: "NECVMWarVMware SATA CD001.00" > > > model: "VMware SATA CD001.00" > > > with the following get_capabilities print in sr.c: > > > sr_printk(KERN_INFO, cd, > > > "scsi3-mmc drive: vendor: \"%s\" model: \"%s\"\n", > > > cd->device->vendor, cd->device->model); > > > > > > So the model looks like reliable identification while vendor does not. > > > > > > The drive claims to have a tray and claims to be able to close it. > > > However, the UI has no notion of a tray - when medium is ejected it is > > > dropped in the floor and the user must select a medium again before the > > > drive can be re-loaded. On the kernel side the tray_move call to close > > > the tray succeeds but the drive state does not change as a result of the > > > call. > > > > > > The drive does not in fact emulate the tray state. There are two ways to > > > get the medium state. One is the SCSI status: > > > > > > Physical drive: > > > > > > Fixed format, current; Sense key: Not Ready > > > Additional sense: Medium not present - tray open > > > Raw sense data (in hex): > > > 70 00 02 00 00 00 00 0a 00 00 00 00 3a 02 00 00 > > > 00 00 > > > > > > Fixed format, current; Sense key: Not Ready > > > Additional sense: Medium not present - tray closed > > > Raw sense data (in hex): > > > 70 00 02 00 00 00 00 0a 00 00 00 00 3a 01 00 00 > > > 00 00 > > > > > > VMware ESXi: > > > > > > Fixed format, current; Sense key: Not Ready > > > Additional sense: Medium not present > > > Info fld=0x0 [0] > > > Raw sense data (in hex): > > > f0 00 02 00 00 00 00 0a 00 00 00 00 3a 00 00 00 > > > 00 00 > > > > > > So the tray state is not reported here. Other is medium status which the > > > kernel prefers if available. Adding a print here gives: > > > > > > cdrom: get_media_event success: code = 0, door_open = 1, medium_present = 0 > > > > > > door_open is interpreted as open tray. This is fine so long as tray_move > > > would close the tray when requested or report an error which never > > > happens on VMware ESXi servers (5.5 and 6.5 tested). > > > > > > This is a popular virtualization platform so a workaround is worthwhile. > > > > > > Signed-off-by: Michal Suchanek <msuchanek@suse.de> > > > --- > > > drivers/scsi/sr.c | 6 ++++++ > > > 1 file changed, 6 insertions(+) > > > > > > diff --git a/drivers/scsi/sr.c b/drivers/scsi/sr.c > > > index 4664fdf75c0f..8090c5bdec09 100644 > > > --- a/drivers/scsi/sr.c > > > +++ b/drivers/scsi/sr.c > > > @@ -867,6 +867,7 @@ static void get_capabilities(struct scsi_cd *cd) > > > unsigned int ms_len = 128; > > > int rc, n; > > > > > > + static const char *model_vmware = "VMware"; > > > static const char *loadmech[] = > > > { > > > "caddy", > > > @@ -922,6 +923,11 @@ static void get_capabilities(struct scsi_cd *cd) > > > buffer[n + 4] & 0x20 ? "xa/form2 " : "", /* can read xa/from2 */ > > > buffer[n + 5] & 0x01 ? "cdda " : "", /* can read audio data */ > > > loadmech[buffer[n + 6] >> 5]); > > > + if (!strncmp(cd->device->model, model_vmware, strlen(model_vmware))) { > > > + buffer[n + 6] &= ~(0xff << 5); > > > + sr_printk(KERN_INFO, cd, > > > + "VMware ESXi bug workaround: tray -> caddy\n"); > > > + } > > > if ((buffer[n + 6] >> 5) == 0) > > > /* caddy drives can't close tray... */ > > > cd->cdi.mask |= CDC_CLOSE_TRAY; > > > > > > > This looks something which should be handled via a blacklist flag, not > > some inline hack which everyone forgets about it... > > AFAIK we used to have a blacklist but don't have anymore. So either it > has to be resurrected for this one flag or an inline hack should be good > enough. > I agree with Hannes. We should have a blacklist flag for this. Putting inline code in the sr driver that special cases on a particular device model string is not clean. The "VMware ESXi bug workaround" message is not particularly descriptive either. -Ewan
On Wed, Oct 23, 2019 at 02:52:46PM +0200, Michal Suchanek wrote: > > The drive claims to have a tray and claims to be able to close it. > However, the UI has no notion of a tray - when medium is ejected it is > dropped in the floor and the user must select a medium again before the > drive can be re-loaded. On the kernel side the tray_move call to close > the tray succeeds but the drive state does not change as a result of the > call. > > The drive does not in fact emulate the tray state. There are two ways to > get the medium state. One is the SCSI status: Given that this is a buggy software emulation we should not add more than 100 lines of kernel code to work around it. Ask VMware to fix their mess instead.
On 10/23/19 6:23 PM, Michal Suchánek wrote: > On Wed, Oct 23, 2019 at 04:13:15PM +0200, Hannes Reinecke wrote: >> On 10/23/19 2:52 PM, Michal Suchanek wrote: >>> The WMware ESXi cdrom identifies itself as: >>> sr 0:0:0:0: [sr0] scsi3-mmc drive: vendor: "NECVMWarVMware SATA CD001.00" >>> model: "VMware SATA CD001.00" >>> with the following get_capabilities print in sr.c: >>> sr_printk(KERN_INFO, cd, >>> "scsi3-mmc drive: vendor: \"%s\" model: \"%s\"\n", >>> cd->device->vendor, cd->device->model); >>> >>> So the model looks like reliable identification while vendor does not. >>> >>> The drive claims to have a tray and claims to be able to close it. >>> However, the UI has no notion of a tray - when medium is ejected it is >>> dropped in the floor and the user must select a medium again before the >>> drive can be re-loaded. On the kernel side the tray_move call to close >>> the tray succeeds but the drive state does not change as a result of the >>> call. >>> >>> The drive does not in fact emulate the tray state. There are two ways to >>> get the medium state. One is the SCSI status: >>> >>> Physical drive: >>> >>> Fixed format, current; Sense key: Not Ready >>> Additional sense: Medium not present - tray open >>> Raw sense data (in hex): >>> 70 00 02 00 00 00 00 0a 00 00 00 00 3a 02 00 00 >>> 00 00 >>> >>> Fixed format, current; Sense key: Not Ready >>> Additional sense: Medium not present - tray closed >>> Raw sense data (in hex): >>> 70 00 02 00 00 00 00 0a 00 00 00 00 3a 01 00 00 >>> 00 00 >>> >>> VMware ESXi: >>> >>> Fixed format, current; Sense key: Not Ready >>> Additional sense: Medium not present >>> Info fld=0x0 [0] >>> Raw sense data (in hex): >>> f0 00 02 00 00 00 00 0a 00 00 00 00 3a 00 00 00 >>> 00 00 >>> >>> So the tray state is not reported here. Other is medium status which the >>> kernel prefers if available. Adding a print here gives: >>> >>> cdrom: get_media_event success: code = 0, door_open = 1, medium_present = 0 >>> >>> door_open is interpreted as open tray. This is fine so long as tray_move >>> would close the tray when requested or report an error which never >>> happens on VMware ESXi servers (5.5 and 6.5 tested). >>> >>> This is a popular virtualization platform so a workaround is worthwhile. >>> >>> Signed-off-by: Michal Suchanek <msuchanek@suse.de> >>> --- >>> drivers/scsi/sr.c | 6 ++++++ >>> 1 file changed, 6 insertions(+) >>> >>> diff --git a/drivers/scsi/sr.c b/drivers/scsi/sr.c >>> index 4664fdf75c0f..8090c5bdec09 100644 >>> --- a/drivers/scsi/sr.c >>> +++ b/drivers/scsi/sr.c >>> @@ -867,6 +867,7 @@ static void get_capabilities(struct scsi_cd *cd) >>> unsigned int ms_len = 128; >>> int rc, n; >>> >>> + static const char *model_vmware = "VMware"; >>> static const char *loadmech[] = >>> { >>> "caddy", >>> @@ -922,6 +923,11 @@ static void get_capabilities(struct scsi_cd *cd) >>> buffer[n + 4] & 0x20 ? "xa/form2 " : "", /* can read xa/from2 */ >>> buffer[n + 5] & 0x01 ? "cdda " : "", /* can read audio data */ >>> loadmech[buffer[n + 6] >> 5]); >>> + if (!strncmp(cd->device->model, model_vmware, strlen(model_vmware))) { >>> + buffer[n + 6] &= ~(0xff << 5); >>> + sr_printk(KERN_INFO, cd, >>> + "VMware ESXi bug workaround: tray -> caddy\n"); >>> + } >>> if ((buffer[n + 6] >> 5) == 0) >>> /* caddy drives can't close tray... */ >>> cd->cdi.mask |= CDC_CLOSE_TRAY; >>> >> This looks something which should be handled via a blacklist flag, not >> some inline hack which everyone forgets about it... > > AFAIK we used to have a blacklist but don't have anymore. So either it > has to be resurrected for this one flag or an inline hack should be good > enough. > But we do have one for generic scsi; cf drivers/scsi/scsi_devinfo.c. And this pretty much falls into the category of SCSI quirks, so I'd prefer have it hooked into that. Cheers, Hannes
On Wed, Oct 23, 2019 at 07:23:07PM -0700, Christoph Hellwig wrote: > On Wed, Oct 23, 2019 at 02:52:46PM +0200, Michal Suchanek wrote: > > > > The drive claims to have a tray and claims to be able to close it. > > However, the UI has no notion of a tray - when medium is ejected it is > > dropped in the floor and the user must select a medium again before the > > drive can be re-loaded. On the kernel side the tray_move call to close > > the tray succeeds but the drive state does not change as a result of the > > call. > > > > The drive does not in fact emulate the tray state. There are two ways to > > get the medium state. One is the SCSI status: > > Given that this is a buggy software emulation we should not add more > than 100 lines of kernel code to work around it. Ask VMware to fix > their mess instead. And never hear back from them. Not to mention the installed base of already buggy servers. Thanks Michal
On Thu, Oct 24, 2019 at 07:46:57AM +0200, Hannes Reinecke wrote: > On 10/23/19 6:23 PM, Michal Suchánek wrote: > > On Wed, Oct 23, 2019 at 04:13:15PM +0200, Hannes Reinecke wrote: > >> On 10/23/19 2:52 PM, Michal Suchanek wrote: > >>> The WMware ESXi cdrom identifies itself as: > >>> sr 0:0:0:0: [sr0] scsi3-mmc drive: vendor: "NECVMWarVMware SATA CD001.00" > >>> model: "VMware SATA CD001.00" > >>> with the following get_capabilities print in sr.c: > >>> sr_printk(KERN_INFO, cd, > >>> "scsi3-mmc drive: vendor: \"%s\" model: \"%s\"\n", > >>> cd->device->vendor, cd->device->model); > >>> > >>> So the model looks like reliable identification while vendor does not. > >>> > >>> The drive claims to have a tray and claims to be able to close it. > >>> However, the UI has no notion of a tray - when medium is ejected it is > >>> dropped in the floor and the user must select a medium again before the > >>> drive can be re-loaded. On the kernel side the tray_move call to close > >>> the tray succeeds but the drive state does not change as a result of the > >>> call. > >>> > >>> The drive does not in fact emulate the tray state. There are two ways to > >>> get the medium state. One is the SCSI status: > >>> > >>> Physical drive: > >>> > >>> Fixed format, current; Sense key: Not Ready > >>> Additional sense: Medium not present - tray open > >>> Raw sense data (in hex): > >>> 70 00 02 00 00 00 00 0a 00 00 00 00 3a 02 00 00 > >>> 00 00 > >>> > >>> Fixed format, current; Sense key: Not Ready > >>> Additional sense: Medium not present - tray closed > >>> Raw sense data (in hex): > >>> 70 00 02 00 00 00 00 0a 00 00 00 00 3a 01 00 00 > >>> 00 00 > >>> > >>> VMware ESXi: > >>> > >>> Fixed format, current; Sense key: Not Ready > >>> Additional sense: Medium not present > >>> Info fld=0x0 [0] > >>> Raw sense data (in hex): > >>> f0 00 02 00 00 00 00 0a 00 00 00 00 3a 00 00 00 > >>> 00 00 > >>> > >>> So the tray state is not reported here. Other is medium status which the > >>> kernel prefers if available. Adding a print here gives: > >>> > >>> cdrom: get_media_event success: code = 0, door_open = 1, medium_present = 0 > >>> > >>> door_open is interpreted as open tray. This is fine so long as tray_move > >>> would close the tray when requested or report an error which never > >>> happens on VMware ESXi servers (5.5 and 6.5 tested). > >>> > >>> This is a popular virtualization platform so a workaround is worthwhile. > >>> > >>> Signed-off-by: Michal Suchanek <msuchanek@suse.de> > >>> --- > >>> drivers/scsi/sr.c | 6 ++++++ > >>> 1 file changed, 6 insertions(+) > >>> > >>> diff --git a/drivers/scsi/sr.c b/drivers/scsi/sr.c > >>> index 4664fdf75c0f..8090c5bdec09 100644 > >>> --- a/drivers/scsi/sr.c > >>> +++ b/drivers/scsi/sr.c > >>> @@ -867,6 +867,7 @@ static void get_capabilities(struct scsi_cd *cd) > >>> unsigned int ms_len = 128; > >>> int rc, n; > >>> > >>> + static const char *model_vmware = "VMware"; > >>> static const char *loadmech[] = > >>> { > >>> "caddy", > >>> @@ -922,6 +923,11 @@ static void get_capabilities(struct scsi_cd *cd) > >>> buffer[n + 4] & 0x20 ? "xa/form2 " : "", /* can read xa/from2 */ > >>> buffer[n + 5] & 0x01 ? "cdda " : "", /* can read audio data */ > >>> loadmech[buffer[n + 6] >> 5]); > >>> + if (!strncmp(cd->device->model, model_vmware, strlen(model_vmware))) { > >>> + buffer[n + 6] &= ~(0xff << 5); > >>> + sr_printk(KERN_INFO, cd, > >>> + "VMware ESXi bug workaround: tray -> caddy\n"); > >>> + } > >>> if ((buffer[n + 6] >> 5) == 0) > >>> /* caddy drives can't close tray... */ > >>> cd->cdi.mask |= CDC_CLOSE_TRAY; > >>> > >> This looks something which should be handled via a blacklist flag, not > >> some inline hack which everyone forgets about it... > > > > AFAIK we used to have a blacklist but don't have anymore. So either it > > has to be resurrected for this one flag or an inline hack should be good > > enough. > > > But we do have one for generic scsi; cf drivers/scsi/scsi_devinfo.c. > And this pretty much falls into the category of SCSI quirks, so I'd > prefer have it hooked into that. But generic scsi does not know about cdrom trays, does it? Thanks Michal
On 10/24/19 10:56 AM, Michal Suchánek wrote: > On Thu, Oct 24, 2019 at 07:46:57AM +0200, Hannes Reinecke wrote: >> On 10/23/19 6:23 PM, Michal Suchánek wrote: >>> On Wed, Oct 23, 2019 at 04:13:15PM +0200, Hannes Reinecke wrote: [ .. ]>>>> This looks something which should be handled via a blacklist flag, not >>>> some inline hack which everyone forgets about it... >>> >>> AFAIK we used to have a blacklist but don't have anymore. So either it >>> has to be resurrected for this one flag or an inline hack should be good >>> enough. >>> >> But we do have one for generic scsi; cf drivers/scsi/scsi_devinfo.c. >> And this pretty much falls into the category of SCSI quirks, so I'd >> prefer have it hooked into that. > > But generic scsi does not know about cdrom trays, does it? > No, just about 'flags'. What you _do_ with those flags is up to you. Or, rather, the driver. Just define a 'tray detection broken' flag, and evaluate it in sr.c. Where is the problem with that? Cheers, Hannes
On Thu, Oct 24, 2019 at 11:41:38AM +0200, Hannes Reinecke wrote: > On 10/24/19 10:56 AM, Michal Suchánek wrote: > > On Thu, Oct 24, 2019 at 07:46:57AM +0200, Hannes Reinecke wrote: > >> On 10/23/19 6:23 PM, Michal Suchánek wrote: > >>> On Wed, Oct 23, 2019 at 04:13:15PM +0200, Hannes Reinecke wrote: > [ .. ]>>>> This looks something which should be handled via a blacklist > flag, not > >>>> some inline hack which everyone forgets about it... > >>> > >>> AFAIK we used to have a blacklist but don't have anymore. So either it > >>> has to be resurrected for this one flag or an inline hack should be good > >>> enough. > >>> > >> But we do have one for generic scsi; cf drivers/scsi/scsi_devinfo.c. > >> And this pretty much falls into the category of SCSI quirks, so I'd > >> prefer have it hooked into that. > > > > But generic scsi does not know about cdrom trays, does it? > > > No, just about 'flags'. What you _do_ with those flags is up to you. > Or, rather, the driver. > Just define a 'tray detection broken' flag, and evaluate it in sr.c. > > Where is the problem with that? And how do you set the flag? The blacklist lists exact manufacturer and model while this rule only depends on model because manufacturer is bogus. Also the blacklist itself is deprecated: /* * scsi_static_device_list: deprecated list of devices that require * settings that differ from the default, includes black-listed (broken) * devices. The entries here are added to the tail of scsi_dev_info_list * via scsi_dev_info_list_init. * * Do not add to this list, use the command line or proc interface to add * to the scsi_dev_info_list. This table will eventually go away. */ Thanks Michal
On Wed, Oct 23, 2019 at 07:23:07PM -0700, Christoph Hellwig wrote: > On Wed, Oct 23, 2019 at 02:52:46PM +0200, Michal Suchanek wrote: > > > > The drive claims to have a tray and claims to be able to close it. > > However, the UI has no notion of a tray - when medium is ejected it is > > dropped in the floor and the user must select a medium again before the > > drive can be re-loaded. On the kernel side the tray_move call to close > > the tray succeeds but the drive state does not change as a result of the > > call. > > > > The drive does not in fact emulate the tray state. There are two ways to > > get the medium state. One is the SCSI status: > > Given that this is a buggy software emulation we should not add more > than 100 lines of kernel code to work around it. Ask VMware to fix > their mess instead. Where do you see 100 lines of code? The patch has exactly 4. Thanks Michal
diff --git a/drivers/scsi/sr.c b/drivers/scsi/sr.c index 4664fdf75c0f..8090c5bdec09 100644 --- a/drivers/scsi/sr.c +++ b/drivers/scsi/sr.c @@ -867,6 +867,7 @@ static void get_capabilities(struct scsi_cd *cd) unsigned int ms_len = 128; int rc, n; + static const char *model_vmware = "VMware"; static const char *loadmech[] = { "caddy", @@ -922,6 +923,11 @@ static void get_capabilities(struct scsi_cd *cd) buffer[n + 4] & 0x20 ? "xa/form2 " : "", /* can read xa/from2 */ buffer[n + 5] & 0x01 ? "cdda " : "", /* can read audio data */ loadmech[buffer[n + 6] >> 5]); + if (!strncmp(cd->device->model, model_vmware, strlen(model_vmware))) { + buffer[n + 6] &= ~(0xff << 5); + sr_printk(KERN_INFO, cd, + "VMware ESXi bug workaround: tray -> caddy\n"); + } if ((buffer[n + 6] >> 5) == 0) /* caddy drives can't close tray... */ cd->cdi.mask |= CDC_CLOSE_TRAY;
The WMware ESXi cdrom identifies itself as: sr 0:0:0:0: [sr0] scsi3-mmc drive: vendor: "NECVMWarVMware SATA CD001.00" model: "VMware SATA CD001.00" with the following get_capabilities print in sr.c: sr_printk(KERN_INFO, cd, "scsi3-mmc drive: vendor: \"%s\" model: \"%s\"\n", cd->device->vendor, cd->device->model); So the model looks like reliable identification while vendor does not. The drive claims to have a tray and claims to be able to close it. However, the UI has no notion of a tray - when medium is ejected it is dropped in the floor and the user must select a medium again before the drive can be re-loaded. On the kernel side the tray_move call to close the tray succeeds but the drive state does not change as a result of the call. The drive does not in fact emulate the tray state. There are two ways to get the medium state. One is the SCSI status: Physical drive: Fixed format, current; Sense key: Not Ready Additional sense: Medium not present - tray open Raw sense data (in hex): 70 00 02 00 00 00 00 0a 00 00 00 00 3a 02 00 00 00 00 Fixed format, current; Sense key: Not Ready Additional sense: Medium not present - tray closed Raw sense data (in hex): 70 00 02 00 00 00 00 0a 00 00 00 00 3a 01 00 00 00 00 VMware ESXi: Fixed format, current; Sense key: Not Ready Additional sense: Medium not present Info fld=0x0 [0] Raw sense data (in hex): f0 00 02 00 00 00 00 0a 00 00 00 00 3a 00 00 00 00 00 So the tray state is not reported here. Other is medium status which the kernel prefers if available. Adding a print here gives: cdrom: get_media_event success: code = 0, door_open = 1, medium_present = 0 door_open is interpreted as open tray. This is fine so long as tray_move would close the tray when requested or report an error which never happens on VMware ESXi servers (5.5 and 6.5 tested). This is a popular virtualization platform so a workaround is worthwhile. Signed-off-by: Michal Suchanek <msuchanek@suse.de> --- drivers/scsi/sr.c | 6 ++++++ 1 file changed, 6 insertions(+)