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
URL:
Keywords:
Depends on:
Blocks:
 
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


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.

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