Bug 213759
| Summary: | CD tray ejected on hibernate resume | ||
|---|---|---|---|
| Product: | SCSI Drivers | Reporter: | computerpro_58 |
| Component: | Other | Assignee: | scsi_drivers-other |
| Status: | RESOLVED CODE_FIX | ||
| Severity: | normal | CC: | almaza24map, bugzilla.kernel, cousinmarc, jetlag0515, jonneransijn1998, limanyi, linux-scsi, s2, trlyons, ucelsanicin, vkuznets, xalomo4655 |
| Priority: | P1 | ||
| Hardware: | x86-64 | ||
| OS: | Linux | ||
| Kernel Version: | 5.10.48 | Subsystem: | |
| Regression: | Yes | Bisected commit-id: | |
|
Description
computerpro_58
2021-07-16 22:37:05 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. I'm the author of this patch: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?h=v5.14-rc2&id=7dd753ca59d6c8cc09aa1ed24f7657524803c7f3 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. 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. 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. I agree to send a 'DISK_EVENT_MEDIA_CHANGE' instead of 'DISK_EVENT_EJECT_REQUEST' when media event code is 3. 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;
}
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. Can confirm the patch in #7 fixes the issue (in trunk, backported as well). Thanks for the great work @limanyi, issue resolved. 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. After today's Ubuntu 18.04 LTS kernel update to 4.15.0.158-generic the CD tray eject problem still persists. |