Bug 213759 - CD tray ejected on hibernate resume
Summary: CD tray ejected on hibernate resume
Status: NEW
Alias: None
Product: SCSI Drivers
Classification: Unclassified
Component: Other (show other bugs)
Hardware: x86-64 Linux
: P1 normal
Assignee: scsi_drivers-other
Depends on:
Reported: 2021-07-16 22:37 UTC by computerpro_58
Modified: 2021-07-24 10:31 UTC (History)
6 users (show)

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


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

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)
 	else if (med->media_event_code == 2)
+	else if (med->media_event_code == 3)
 	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:

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:

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.

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