[ltp] T430 Ultrabay hotswap EJECT_REQUEST event
Kevin Locke
linux-thinkpad@linux-thinkpad.org
Wed, 16 Dec 2015 01:16:20 -0800
On Wed, 2015-12-16 at 08:56 +0100, Paul Seelig wrote:
> I once created the Debian based 'ultrabay-scripts' (which in turn took
> their inspiration and part of the code from the mentioned sites) for
> device swapping, albeit never used them on a T430 but only on T60 and
> T61. Maybe they can provide some insight?
>
> Please have a look here:
>
> https://github.com/wmlive/ultrabay-scripts
>
> Ready made packages for Debian can be fetched from here:
>
> http://wmlive.rumbero.org/repo/
This is great! Thanks for taking the time to maintain and package
these scripts. Have you considered/attempted to get the package into
the official repositories? It would be great to see it more widely
available.
If I may make one suggestion: I'd prefer tp-smapi-dkms as a
Recommends rather than Depends, since it's not useful on the T430 and
so that I don't have to install dkms and kernel headers which I'm not
using. But otherwise the packaging and repository worked very well.
After playing with the scripts a bit, I'm still not having any luck
getting an automatic undock and I'm a bit confused about how the
scripts are supposed to work. It looks like the udev rules listen
for
ENV{EVENT}=="undock", KERNEL=="dock.1", ACTION=="change",
SUBSYSTEM=="platform", ATTR{type}=="ata_bay"
rather than
ENV{BAY_EVENT}=="3", ACTION=="change", SUBSYSTEM=="scsi"
My understanding was that BAY_EVENT 0x3 is EJECT_REQUEST (user
request, via switch/button) while the undock event is fired once the
device has been removed from the dock, at which point it is too late
to unmount filesystems and prepare for undocking. In testing it just
now, it appears that the undock event is fired in response to
# echo 1 > /sys/devices/platform/dock.1/undock
at which point the drive is disconnected. So it appears to be
necessary to call ultrabay_eject to initiate the undocking, but then
why would it be called again as a RUN script? Perhaps I'm confused?
However, I did find this rule to be instructive:
SUBSYSTEMS=="block", DEVPATH=="/devices/pci0000:00/0000:00:1f.2/ata2/host1/target1:0:0/1:0:0:0",
ENV{UDISKS_SYSTEM_INTERNAL}="0"
Unfortunately, it looks like support for the UDISKS_SYSTEM_INTERNAL
property was removed in udisks 1.90 and later.[1] I can't find any
discussion about the reason, and the original bug[2] was not reopened,
so I'm not sure how to interpret it.
Thanks again for your efforts on making this less painful, they are
appreciated!
Kevin
1. http://cgit.freedesktop.org/udisks/commit/?id=5de2f4381b5d2b1d76a9ea31b28b86e7ead43599
2. https://bugs.freedesktop.org/show_bug.cgi?id=22879
--
Kevin Locke | kevin@kevinlocke.name | XMPP: kevin@kevinlocke.name
| https://kevinlocke.name | IRC: kevinoid on freenode