Bug 213759 - CD tray ejected on hibernate resume
Summary: CD tray ejected on hibernate resume
Status: RESOLVED CODE_FIX
Alias: None
Product: SCSI Drivers
Classification: Unclassified
Component: Other (show other bugs)
Hardware: x86-64 Linux
: P1 normal
Assignee: scsi_drivers-other
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2021-07-16 22:37 UTC by computerpro_58
Modified: 2021-09-15 03:55 UTC (History)
11 users (show)

See Also:
Kernel Version: 5.10.48
Tree: Mainline
Regression: Yes


Attachments

Description computerpro_58 2021-07-16 22:37:05 UTC
After resuming from hibernation (shutdown-disk), CD tray (which is empty and untouched) is ejected on resume. I use a LUKS-encrypted root partition, and the tray is always ejected before my distro NixOS (cryptsetup) prompts for my key.

I bi-sect'd the problem commit down to this one:

From: ManYi Li <limanyi@uniontech.com>
To: axboe@kernel.dk, jejb@linux.ibm.com, martin.petersen@oracle.com
Cc: linux-kernel@vger.kernel.org, linux-scsi@vger.kernel.org,
	ManYi Li <limanyi@uniontech.com>
Subject: [PATCH] sr: Fix get the error media event code
Date: Fri, 11 Jun 2021 17:44:02 +0800
Message-ID: <20210611094402.23884-1-limanyi@uniontech.com> (raw)

Eject the specified slot or media through a mechanical switch on the Drive,
med->media_event_code is 3 not 1 in the sr_get_events().

If disk_flush_events() and sr_block_open() are called,
clearing is 1 or 3 in the sr_check_events(),then it report
DISK_EVENT_MEDIA_CHANGE not DISK_EVENT_EJECT_REQUEST.

If disk_flush_events() and sr_block_open() aren't called,
clearing is 0 in the sr_check_events(),then it doesn't
report any event.

Signed-off-by: ManYi Li <limanyi@uniontech.com>
---
 drivers/scsi/sr.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/scsi/sr.c b/drivers/scsi/sr.c
index 482a07b662a9..94c254e9012e 100644
--- a/drivers/scsi/sr.c
+++ b/drivers/scsi/sr.c
@@ -220,6 +220,8 @@ static unsigned int sr_get_events(struct scsi_device *sdev)
 		return DISK_EVENT_EJECT_REQUEST;
 	else if (med->media_event_code == 2)
 		return DISK_EVENT_MEDIA_CHANGE;
+	else if (med->media_event_code == 3)
+		return DISK_EVENT_EJECT_REQUEST;
 	return 0;
 }


That commit was backported onto a number of kernels, so I can reproduce this on a number of different kernels (master, stable, LTS). I'm not sure if this is a bug in the CD-reader (tossing back an incorrect status), or if the bug is within this driver?
Comment 1 xalomo4655 2021-07-17 21:58:03 UTC
Also seeing this problem on resume from suspend on a completely different system than the above user's system.

Can we please get this fixed ASAP? Its a very annoying issue. Thank you.
Comment 3 limanyi@uniontech.com 2021-07-20 05:24:51 UTC
Seeing this problem on Linux 5.14-rc2, CD tray (which is empty and untouched) is ejected on resume from hibernation.I'm looking for the root cause of the problem.
Comment 4 Todd Lyons 2021-07-23 15:51:31 UTC
Glad to see this isn't just me with the DVD-ROM tray snapping out on wake. I first noticed it with 5.13.2. Hope to see this squashed soon. Thank you.
Comment 5 Jonne Ransijn 2021-07-24 09:42:45 UTC
The description for media event code 3 reads:

MediaRemoval
The media has been removed from the specified slot,
and the Drive is unable to access the media without user intervention.
This applies to media changers only.

This seems like a reasonable status notification after the disk drive detected no disk in the drive.
How else could the the drive signal that the user removed a disk while the kernel is suspended? The disk drive is (presumably) stateless, it doesn't remember if it used to have a disk inserted.
This doesn't seem like a bug in the disk drive.

I'm pretty sure 'DISK_EVENT_EJECT_REQUEST' is not the correct event in this case.
It seems more reasonable to send a 'DISK_EVENT_MEDIA_CHANGE'.

Also, the description for media event code 4:

MediaChanged
The user has requested that the media in the specified slot be loaded.
This applies to media changers only.

Should probably send a 'DISK_EVENT_MEDIA_CHANGE' for that as well then.
Comment 6 limanyi@uniontech.com 2021-07-24 10:31:18 UTC
I agree to send a 'DISK_EVENT_MEDIA_CHANGE' instead of 'DISK_EVENT_EJECT_REQUEST' when media event code is 3.
Comment 7 limanyi@uniontech.com 2021-07-26 11:01:30 UTC
1. modify the file /lib/udev/rules.d/60-cdrom_id.rules:
-ENV{DISK_EJECT_REQUEST}=="?*", RUN+="cdrom_id --eject-media $devnode", GOTO="cdrom_end"
+#ENV{DISK_EJECT_REQUEST}=="?*", RUN+="cdrom_id --eject-media $devnode", GOTO="cdrom_end"

2. systemctl restart udev.service

I find that CD tray isn`t ejected on resume. I think that the kernel should not send 'DISK_EVENT_EJECT_REQUEST' when media event code is 3.


This patch solves this problem:
diff --git a/drivers/scsi/sr.c b/drivers/scsi/sr.c
index 94c254e9012e..a6d3ac0a6cbc 100644
--- a/drivers/scsi/sr.c
+++ b/drivers/scsi/sr.c
@@ -221,7 +221,7 @@ static unsigned int sr_get_events(struct scsi_device *sdev)
        else if (med->media_event_code == 2)
                return DISK_EVENT_MEDIA_CHANGE;
        else if (med->media_event_code == 3)
-               return DISK_EVENT_EJECT_REQUEST;
+               return DISK_EVENT_MEDIA_CHANGE;
        return 0;
 }
Comment 8 vkuznets 2021-07-27 14:55:25 UTC
FWIW I'm seeing the same issue with Hyper-V Generation 2 VMs. After 

commit 7dd753ca59d6c8cc09aa1ed24f7657524803c7f3
Author: ManYi Li <limanyi@uniontech.com>
Date:   Fri Jun 11 17:44:02 2021 +0800

    scsi: sr: Return appropriate error code when disk is ejected

DISK_EVENT_EJECT_REQUEST is generated when storvsc driver loads and in case there's a udev rule to do "cdrom_id --eject-media ... " at this time the virtual CDROM goes away.

Patch from https://bugzilla.kernel.org/show_bug.cgi?id=213759#c7 helps.
Comment 10 computerpro_58 2021-08-28 22:40:02 UTC
Can confirm the patch in #7 fixes the issue (in trunk, backported as well). Thanks for the great work @limanyi, issue resolved.
Comment 11 jeffro 2021-09-15 03:55:17 UTC
Also encountering this issue on Ubuntu 18.04 LTS as of last kernel update to 4.15.0.156-generic.  CD tray only ejects after resume from suspend, not on boot (No disk in the drive).  Previous kernel (4.15.0.154-generic) does not exhibit this behavior.

Note You need to log in before you can comment on or make changes to this bug.