2.6.25 semantic change in bay handling?

48feb3c419508487becfb9ea3afcc54c3eac6d80 appears to flag a device as detached if an acpi eject request is received. In 2.6.24 and earlier, an eject request merely sent an event to userland which could then cleanly unmount the device and let the user know when it was safe to remove the drive. Removing the device would then send another acpi request that triggered the actual hotplug and bus rescan.

This seems like a regression - it's no longer possible to ensure that a bay device is cleanly unmounted. Was this really the desired behaviour?

It should be noted that not all hardware sends the eject request at all (Thinkpads do, but Dell and HP laptops don't), so we can't depend on receiving this when dealing with a bay event.

Quoted 6 lines · Matthew Garrett

48feb3c419508487becfb9ea3afcc54c3eac6d80 appears to flag a device as detached if an acpi eject request is received. In 2.6.24 and earlier, an eject request merely sent an event to userland which could then cleanly unmount the device and let the user know when it was safe to remove the drive. Removing the device would then send another acpi request that triggered the actual hotplug and bus rescan.

What second acpi request are you referring to?

Quoted 2 lines

This seems like a regression - it's no longer possible to ensure that a bay device is cleanly unmounted. Was this really the desired behaviour?

I'm thinking about his for several days now and looking for a proper solution how to ensure that userland has the possibility to cleanly unmount a device. But it's definitely no regression. Before...systems with a bay in a dock stations simply froze hard in certain circumstances. It was pure luck that it worked for one major kernel version or so.

The only sane way for me seems that userland has to be involved before actually triggering any event or removing any device. Something like "savely remove this piece of hardware".

For this to archive, we would need another sysfs entry flagging a bay device as "on dock station", so that userland knows what to unmount/eject before a dock event. Userspace relying on the bay event on the device is not a proper solution. The device may have been gone before userland finishes his work, or as you mention, there's no bay event.

Quoted 3 lines

It should be noted that not all hardware sends the eject request at all (Thinkpads do, but Dell and HP laptops don't), so we can't depend on receiving this when dealing with a bay event.

I don't think we depend on the event. If the device gets removed without an appropriate event, the behaviour should be the same as before. If not, that wasn't the intentional behaviour.

Quoted 2 lines · Holger Macht

Quoted 1 line · Matthew Garrett

48feb3c419508487becfb9ea3afcc54c3eac6d80 appears to flag a device as

Quoted 2 lines

Quoted 1 line

detached if an acpi eject request is received. In 2.6.24 and earlier, an eject request merely sent an event to userland which could then cleanly unmount the device and let the user know when it was safe to remove the drive. Removing the device would then send another acpi request that triggered the actual hotplug and bus rescan.

What second acpi request are you referring to?

For bay devices, the sequence is an optional eject request (before removal, and not implemented on all hardware) followed by either a bus or device check request (after removal).

Quoted 6 lines

Quoted 1 line

This seems like a regression - it's no longer possible to ensure that a bay device is cleanly unmounted. Was this really the desired behaviour?

I'm thinking about his for several days now and looking for a proper solution how to ensure that userland has the possibility to cleanly unmount a device. But it's definitely no regression. Before...systems with a bay in a dock stations simply froze hard in certain circumstances. It was pure luck that it worked for one major kernel version or so.

Ah. I think the issue here is that you're trying to treat bays in docks in the same way as internal bays. These should probably be different callbacks.

Quoted 3 lines

The only sane way for me seems that userland has to be involved before actually triggering any event or removing any device. Something like "savely remove this piece of hardware".

That's what the eject request is for.

Quoted 5 lines

For this to archive, we would need another sysfs entry flagging a bay device as "on dock station", so that userland knows what to unmount/eject before a dock event. Userspace relying on the bay event on the device is not a proper solution. The device may have been gone before userland finishes his work, or as you mention, there's no bay event.

Yes. The user can, of course, do bad things. That doesn't mean we should avoid the opportunity to cleanly unmount filesystems when the user doesn't behave pathologically.

Quoted 4 lines

Quoted 1 line

It should be noted that not all hardware sends the eject request at all (Thinkpads do, but Dell and HP laptops don't), so we can't depend on receiving this when dealing with a bay event.

I don't think we depend on the event. If the device gets removed without an appropriate event, the behaviour should be the same as before. If not, that wasn't the intentional behaviour.

What ought to be possible for dock devices is something like "Receive eject request, clean up anything that has to be done in kernel, allow userspace to intervene and tidy up its side of things, let userspace signal completion, complete the undocking sequence". For internal bays, we certainly shouldn't be detaching the device when all we've received is an eject request.

Quoted 2 lines

Quoted 2 lines · Matthew Garrett

Quoted 1 line

48feb3c419508487becfb9ea3afcc54c3eac6d80 appears to flag a device as

That should be 233f112042d0b50170212dbff99c3b34b8773cd3, right?

The original change was from Holder Macht and IIRC it was to avoid machine hard lock up on certain laptops which happens when libata EH goes out to find out what happened when it receives bus/device check after removal. Maybe what should be done instead is that eject request doesn't do anything but tells acpid to unmount and delete the block device by echoing 1 to sysfs delete node.

From my point of view that's fine, but I'd be more interested to know

Hmmm... It would be perfect if we can tell whether DEVICE/BUS CHECK is in which direction (device coming or going away).

Quoted 3 lines · Tejun Heo

Quoted 2 lines

Quoted 2 lines · Matthew Garrett

Quoted 1 line

48feb3c419508487becfb9ea3afcc54c3eac6d80 appears to flag a device as

That should be 233f112042d0b50170212dbff99c3b34b8773cd3, right?

Yeah, my mistake.

Quoted 1 line

The original change was from Holder Macht and IIRC it was to avoid machine hard lock up on certain laptops which happens when libata EH goes out to find out what happened when it receives bus/device check after removal. Maybe what should be done instead is that eject request doesn't do anything but tells acpid to unmount and delete the block device by echoing 1 to sysfs delete node.

From my point of view that's fine, but I'd be more interested to know about the case Holger was having trouble with. For internal bays, at least, we can't guarantee that we'll get an eject request before the device is removed - if that leads to hangs, we probably need to work out a way of being more robust here.

Quoted 1 line

Hmmm... It would be perfect if we can tell whether DEVICE/BUS CHECK is in which direction (device coming or going away).

Yeah, but I can't see an easy way of doing that. It's not enough to keep track of the current state and assume that it's either an insertion or removal as a result - some machines fire bus checks on resume, even if the bay device hasn't been changed.

Quoted 4 lines · Matthew Garrett

Yeah, but I can't see an easy way of doing that. It's not enough to keep track of the current state and assume that it's either an insertion or removal as a result - some machines fire bus checks on resume, even if the bay device hasn't been changed.

All we need is separate out the ejection case out. For suspend, resume, attach or whatever can be handled the same way. The problem occurs because some controllers get very unhappy when certain registers are accessed when there's no device attached to it.

Quoted 2 lines

Right, so you never can rely on receiving a BAY_EVENT. Why not just disregard this case and looking for a common solution?

Oh, I agree - we need to solve this in any case. But for hardware where there is a separate request event before the device is pulled, users already have scripts that prompt them to unmount hardware. These worked in <2.6.25, but they're broken now. It'd be nice to get them working again.

Quoted 6 lines

No. The moment when the bay event is generated, the moment the user pushes the lever on the bay, the user might immediately pull out the device, letting no chance for cleaning up...There must be an event before the user touches anything, to have the time to unmount etc. and then tell "now it's save to remove the bay device". This would also solve the "there's no bay event" case.

Hm. The hardware I have here has a separate "eject request" button and "physical eject" button. Hitting the former sends the request to the OS, and the light then pulses until the OS confirms that the dock can be removed. If the user removes the dock before this happens, that's user error.

The only dock I have with no request button doesn't present as an ACPI dock to begin with. Do Thinkpad docks differ from this?

Not by default. The dock driver immediately undocks unless immediate_undock parameter is set to 0. Any access to the bay inside the dock afterwards might freeze the system.

Actually I was talking about the "bay not in the dock"-case here.

There are those which do simple PCI hotplugging without the involvement of ACPI (many/all HPs AFAIK) and those which present themselves as a dockstation through ACPI (those with a _DCK method). The thinkpad X60 dock I have here has the request button, too.

Quoted 5 lines

Not by default. The dock driver immediately undocks unless immediate_undock parameter is set to 0. Any access to the bay inside the dock afterwards might freeze the system.

Actually I was talking about the "bay not in the dock"-case here.

In that case, the effect differs depending on the hardware. In the ideal universe, Thinkpad users flick out the eject lever and wait for a confirmation that they can pull out the drive. Dell and HP users have to request a safe remove in advance.

Quoted 4 lines

There are those which do simple PCI hotplugging without the involvement of ACPI (many/all HPs AFAIK) and those which present themselves as a dockstation through ACPI (those with a _DCK method). The thinkpad X60 dock I have here has the request button, too.

Right. In that case, it needs to be possible for userspace to indicate that the eject request should not automatically destroy the device. Actually removing the dock should do so in all circumstances.

Just to make clear that we agree on the design, if so, I'll try to provide a patch:

1. Dock event: libata immediately detaches the device

(libata will need another sysfs flag is_on_dock userspace can query)

2. Bay event: libata signals a BAY_EVENT through uevent, userspace writes

    	       1 to /sys/.../device/delete

Quoted 6 lines

Just to make clear that we agree on the design, if so, I'll try to provide a patch:

1. Dock event: libata immediately detaches the device

(libata will need another sysfs flag is_on_dock userspace can query)

Hm. I'm not absolutely certain about this. Do we get a bus check notification after the dock has been removed? If so, I think it ought to be handled the same way as the internal bay (ie, signal userspace and let it clean up and destroy the device - if it fails to do so, then destroy the device when the dock is actually removed, by catching the bus/device check, calling the _STA method on the bay and destroying the device if it's present)

Quoted 2 lines

2. Bay event: libata signals a BAY_EVENT through uevent, userspace writes

    	       1 to /sys/.../device/delete

In the case of an eject request, yes. In the case of a bus or device check, we should call _STA and then delete/hotplug the device as appropriate.

Hi Matthew,

( Please TO or CC [email protected] ! )

Quoted 7 lines

Hm. I'm not absolutely certain about this. Do we get a bus check notification after the dock has been removed? If so, I think it ought to be handled the same way as the internal bay (ie, signal userspace and let it clean up and destroy the device - if it fails to do so, then destroy the device when the dock is actually removed, by catching the bus/device check, calling the _STA method on the bay and destroying the device if it's present)

libata is notified through the dock driver when a dock event occurs, just before the dock driver undocks, giving no time to userspace to clean up. libata doesn't receive an additional acpi bay event.

Quoted 6 lines

Quoted 2 lines

2. Bay event: libata signals a BAY_EVENT through uevent, userspace writes

    	       1 to /sys/.../device/delete

In the case of an eject request, yes. In the case of a bus or device check, we should call _STA and then delete/hotplug the device as appropriate.

Yes.

Quoted 3 lines · Holger Macht

Hi Matthew,

( Please TO or CC [email protected] ! )

Then stop setting Mail-Followup-To: :)

Quoted 8 lines

Quoted 7 lines

Hm. I'm not absolutely certain about this. Do we get a bus check notification after the dock has been removed? If so, I think it ought to be handled the same way as the internal bay (ie, signal userspace and let it clean up and destroy the device - if it fails to do so, then destroy the device when the dock is actually removed, by catching the bus/device check, calling the _STA method on the bay and destroying the device if it's present)

Quoted 3 lines

libata is notified through the dock driver when a dock event occurs, just before the dock driver undocks, giving no time to userspace to clean up. libata doesn't receive an additional acpi bay event.

That's the current situation, I'm not sure it's ideal. But I'll skip

worrying about that until I've actually got some hardware to work out how to do it properly :)

Quoted 8 lines

Quoted 7 lines

Quoted 3 lines

2. Bay event: libata signals a BAY_EVENT through uevent, userspace writes

    	       1 to /sys/.../device/delete

In the case of an eject request, yes. In the case of a bus or device check, we should call _STA and then delete/hotplug the device as appropriate.

Quoted 1 line

Yes.

Excellent. I /think/ the patch I sent earlier basically does this - you'll want to register a separate callback for the dock event in that case, though.

Quoted 4 lines · Tejun Heo

Quoted 2 lines

Quoted 2 lines · Matthew Garrett

Quoted 1 line

48feb3c419508487becfb9ea3afcc54c3eac6d80 appears to flag a device as

That should be 233f112042d0b50170212dbff99c3b34b8773cd3, right?

Yeah, my mistake.

Quoted 6 lines

The original change was from Holder Macht and IIRC it was to avoid machine hard lock up on certain laptops which happens when libata EH goes out to find out what happened when it receives bus/device check after removal. Maybe what should be done instead is that eject request doesn't do anything but tells acpid to unmount and delete the block device by echoing 1 to sysfs delete node.

From my point of view that's fine, but I'd be more interested to know about the case Holger was having trouble with. For internal bays, at least, we can't guarantee that we'll get an eject request before the device is removed - if that leads to hangs, we probably need to work out a way of being more robust here.

Quoted 2 lines

Hmmm... It would be perfect if we can tell whether DEVICE/BUS CHECK is in which direction (device coming or going away).

Yeah, but I can't see an easy way of doing that. It's not enough to keep track of the current state and assume that it's either an insertion or removal as a result - some machines fire bus checks on resume, even if the bay device hasn't been changed.

Right, so you never can rely on receiving a BAY_EVENT. Why not just disregard this case and looking for a common solution?

(cc'ing Holger Macht, copying whole body for him)

Hello, guys.

Quoted 3 lines · Matthew Garrett

Quoted 2 lines · Holger Macht

Quoted 1 line · Matthew Garrett

48feb3c419508487becfb9ea3afcc54c3eac6d80 appears to flag a device as

That should be 233f112042d0b50170212dbff99c3b34b8773cd3, right?

Quoted 22 lines

Quoted 6 lines

Quoted 5 lines

detached if an acpi eject request is received. In 2.6.24 and earlier, an eject request merely sent an event to userland which could then cleanly unmount the device and let the user know when it was safe to remove the drive. Removing the device would then send another acpi request that triggered the actual hotplug and bus rescan.

What second acpi request are you referring to?

For bay devices, the sequence is an optional eject request (before removal, and not implemented on all hardware) followed by either a bus or device check request (after removal).

Quoted 7 lines

Quoted 2 lines

This seems like a regression - it's no longer possible to ensure that a bay device is cleanly unmounted. Was this really the desired behaviour?

I'm thinking about his for several days now and looking for a proper solution how to ensure that userland has the possibility to cleanly unmount a device. But it's definitely no regression. Before...systems with a bay in a dock stations simply froze hard in certain circumstances. It was pure luck that it worked for one major kernel version or so.

Ah. I think the issue here is that you're trying to treat bays in docks in the same way as internal bays. These should probably be different callbacks.

Quoted 6 lines

Quoted 4 lines

The only sane way for me seems that userland has to be involved before actually triggering any event or removing any device. Something like "savely remove this piece of hardware".

That's what the eject request is for.

Quoted 10 lines

Quoted 6 lines

For this to archive, we would need another sysfs entry flagging a bay device as "on dock station", so that userland knows what to unmount/eject before a dock event. Userspace relying on the bay event on the device is not a proper solution. The device may have been gone before userland finishes his work, or as you mention, there's no bay event.

Yes. The user can, of course, do bad things. That doesn't mean we should avoid the opportunity to cleanly unmount filesystems when the user doesn't behave pathologically.

Quoted 8 lines

Quoted 7 lines

Quoted 4 lines

It should be noted that not all hardware sends the eject request at all (Thinkpads do, but Dell and HP laptops don't), so we can't depend on receiving this when dealing with a bay event.

I don't think we depend on the event. If the device gets removed without an appropriate event, the behaviour should be the same as before. If not, that wasn't the intentional behaviour.

Quoted 6 lines

What ought to be possible for dock devices is something like "Receive eject request, clean up anything that has to be done in kernel, allow userspace to intervene and tidy up its side of things, let userspace signal completion, complete the undocking sequence". For internal bays, we certainly shouldn't be detaching the device when all we've received is an eject request.

The original change was from Holder Macht and IIRC it was to avoid machine hard lock up on certain laptops which happens when libata EH goes out to find out what happened when it receives bus/device check after removal. Maybe what should be done instead is that eject request doesn't do anything but tells acpid to unmount and delete the block device by echoing 1 to sysfs delete node.

Hmmm... It would be perfect if we can tell whether DEVICE/BUS CHECK is in which direction (device coming or going away).

Thanks.

No. The moment when the bay event is generated, the moment the user pushes the lever on the bay, the user might immediately pull out the device, letting no chance for cleaning up...There must be an event before the user touches anything, to have the time to unmount etc. and then tell "now it's save to remove the bay device". This would also solve the "there's no bay event" case.

The libata-acpi.c code currently accepts hotplug messages from both the port and the device. This does not match the behaviour of the bay driver, and may result in confusion when two hotplug requests are received for the same device. This patch limits the hotplug notification to removable ACPI devices, which in turn allows it to use the _STA method to determine whether the device has been removed or inserted. On removal, devices are marked as detached. On insertion, a hotplug scan is started. This should avoid lockups caused by the ata layer attempting to scan devices which have been removed. The uevent sending is moved outside the spinlock in order to avoid a warning generated by it firing when interrupts are disabled.

* In case of an ACPI_NOTIFY_DEVICE/BUS_CHECK, evaluate _STA to check if the device has been plugged or unplugged. If plugged, hotplug it, if unplugged, just signal event to userspace
(initial patch by Matthew Garrett <[email protected]>)

Quoted 4 lines · Holger Macht

* In case of an ACPI_NOTIFY_DEVICE/BUS_CHECK, evaluate _STA to check if the device has been plugged or unplugged. If plugged, hotplug it, if unplugged, just signal event to userspace
(initial patch by Matthew Garrett <[email protected]>)

The only issue I can see is that this one doesn't check _EJ0. Unless that's done, you'll (on some hardware) evaluate _STA on the bay itself rather than the device within the bay, which leads to confusion as to whether the device has been inserted. Other than that, looks good. Jeff's sent my patch to Linus, so can you redo this on top and I'll sign it off?

Review

Quoted 3 lines · Holger Macht

(quoted diff) +3 -0

+	if (kobj && !is_dock_event) {
+		sprintf(event_string, "BAY_EVENT=%d", event);
+		kobject_uevent_env(kobj, KOBJ_CHANGE, envp);

I think we want to do the _EJ0 checking before this, otherwise we'll generate two uevents for the same removal on some hardware. Otherwise, looks good.

Handle bay devices in dock stations

* Differentiate between bay devices in dock stations and others:

- When an ACPI_NOTIFY_EJECT_REQUEST appears, just signal uevent to userspace (that is when the optional eject button on a bay device is pressed/pulled) giving the possibility to unmount file systems and to clean up. Also, only send uevent in case we get an EJECT_REQUEST without doing anything else. In other cases, you'll get an add/remove event because libata attaches/detaches the device.

- In case of a dock event, which in turn signals an ACPI_NOTIFY_EJECT_REQUEST, immediately detach the device, because it may already have been gone

* In case of an ACPI_NOTIFY_DEVICE/BUS_CHECK, evaluate _STA to check if the device has been plugged or unplugged. If plugged, hotplug it, if unplugged, just signal event to userspace
(initial patch by Matthew Garrett <[email protected]>)

Signed-off-by Holger Macht <[email protected]>

Quoted 9 lines · Matthew Garrett

Review

Quoted 3 lines · Holger Macht

(quoted diff) +3 -0

+	if (kobj && !is_dock_event) {
+		sprintf(event_string, "BAY_EVENT=%d", event);
+		kobject_uevent_env(kobj, KOBJ_CHANGE, envp);

I think we want to do the _EJ0 checking before this, otherwise we'll generate two uevents for the same removal on some hardware. Otherwise, looks good.

So once again:

Handle bay devices in dock stations

* Differentiate between bay devices in dock stations and others:

- When an ACPI_NOTIFY_EJECT_REQUEST appears, just signal uevent to userspace (that is when the optional eject button on a bay device is pressed/pulled) giving the possibility to unmount file systems and to clean up. Also, only send uevent in case we get an EJECT_REQUEST without doing anything else. In other cases, you'll get an add/remove event because libata attaches/detaches the device.

- In case of a dock event, which in turn signals an ACPI_NOTIFY_EJECT_REQUEST, immediately detach the device, because it may already have been gone

* In case of an ACPI_NOTIFY_DEVICE/BUS_CHECK, evaluate _STA to check if the device has been plugged or unplugged. If plugged, hotplug it, if unplugged, just signal event to userspace
(initial patch by Matthew Garrett <[email protected]>)

Signed-off-by Holger Macht <[email protected]>

---

drivers/ata/libata-acpi.c renamed from drivers/ata/libata-acpi.c.orig +1 -0

@@ -118,8 +118,25 @@ static void ata_acpi_associate_ide_port(
 		ap->pflags |= ATA_PFLAG_INIT_GTM_VALID;
 }
 
+static void ata_acpi_detach_device(struct ata_port *ap, struct ata_device *dev)

drivers/ata/libata-acpi.c renamed from drivers/ata/libata-acpi.c.orig +14 -8

+	}
+
+	ata_port_freeze(ap);
+	ata_port_schedule_eh(ap);
+}
+
 static void ata_acpi_handle_hotplug(struct ata_port *ap, struct ata_device
-				    *dev, u32 event)
+				    *dev, u32 event, int is_dock_event)
 {
 	char event_string[12];
 	char *envp[] = { event_string, NULL };

@@ -135,83 +152,92 @@ static void ata_acpi_handle_hotplug(stru
 		ap = dev->link->ap;
 	ehi = &ap->link.eh_info;
 
-	spin_lock_irqsave(ap->lock, flags);
-
-	if (dev)
+	if (dev) {
+		if (dev->sdev)
+			kobj = &dev->sdev->sdev_gendev.kobj;
 		handle = dev->acpi_handle;
-	else
+	} else {
+		kobj = &ap->dev->kobj;
 		handle = ap->acpi_handle;
+	}
 
 	status = acpi_get_handle(handle, "_EJ0", &tmphandle);
 	if (ACPI_FAILURE(status)) {
-		/* This device is not ejectable */
-		spin_unlock_irqrestore(ap->lock, flags);
+		/* This device does not support hotplug */
 		return;
 	}
 
-	status = acpi_evaluate_integer(handle, "_STA", NULL, &sta);

drivers/ata/libata-acpi.c renamed from drivers/ata/libata-acpi.c.orig +0 -4

 	switch (event) {
 	case ACPI_NOTIFY_BUS_CHECK:
 	case ACPI_NOTIFY_DEVICE_CHECK:
 		ata_ehi_push_desc(ehi, "ACPI event");
-		if (!sta) {
-                /* Device has been unplugged */
-			if (dev)
-				dev->flags |= ATA_DFLAG_DETACH;

The libata-acpi.c code currently accepts hotplug messages from both the port and the device. This does not match the behaviour of the bay driver, and may result in confusion when two hotplug requests are received for the same device. This patch limits the hotplug notification to removable ACPI devices, which in turn allows it to use the _STA method to determine whether the device has been removed or inserted. On removal, devices are marked as detached. On insertion, a hotplug scan is started. This should avoid lockups caused by the ata layer attempting to scan devices which have been removed. The uevent sending is moved outside the spinlock in order to avoid a warning generated by it firing when interrupts are disabled.

Signed-off-by Matthew Garrett <[email protected]>

---

Holger, I'm pretty sure that this deals with the docking station removal case, but don't have the hardware to test. If EJECT_REQUEST is genuinely

the only notification we receive (ie, no BUS_CHECK or DEVICE_CHECK) then we'll need to add a separate callback for docking.

Quoted 6 lines · Matthew Garrett

48feb3c419508487becfb9ea3afcc54c3eac6d80 appears to flag a device as detached if an acpi eject request is received. In 2.6.24 and earlier, an eject request merely sent an event to userland which could then cleanly unmount the device and let the user know when it was safe to remove the drive. Removing the device would then send another acpi request that triggered the actual hotplug and bus rescan.

What second acpi request are you referring to?

Quoted 2 lines

This seems like a regression - it's no longer possible to ensure that a bay device is cleanly unmounted. Was this really the desired behaviour?

I'm thinking about his for several days now and looking for a proper solution how to ensure that userland has the possibility to cleanly unmount a device. But it's definitely no regression. Before...systems with a bay in a dock stations simply froze hard in certain circumstances. It was pure luck that it worked for one major kernel version or so.

The only sane way for me seems that userland has to be involved before actually triggering any event or removing any device. Something like "savely remove this piece of hardware".

For this to archive, we would need another sysfs entry flagging a bay device as "on dock station", so that userland knows what to unmount/eject before a dock event. Userspace relying on the bay event on the device is not a proper solution. The device may have been gone before userland finishes his work, or as you mention, there's no bay event.

Quoted 3 lines

It should be noted that not all hardware sends the eject request at all (Thinkpads do, but Dell and HP laptops don't), so we can't depend on receiving this when dealing with a bay event.

I don't think we depend on the event. If the device gets removed without an appropriate event, the behaviour should be the same as before. If not, that wasn't the intentional behaviour.