Bug 12898 - External drive on eSATA are not considered as removable/hotplug
Summary: External drive on eSATA are not considered as removable/hotplug
Alias: None
Product: IO/Storage
Classification: Unclassified
Component: Serial ATA (show other bugs)
Hardware: All Linux
: P1 normal
Assignee: Tejun Heo
Depends on:
Reported: 2009-03-20 07:06 UTC by Patrice Vetsel
Modified: 2011-01-01 18:01 UTC (History)
1 user (show)

See Also:
Kernel Version: 2.6.28-11-generic
Tree: Mainline
Regression: ---


Description Patrice Vetsel 2009-03-20 07:06:06 UTC
Latest working kernel version: don't know
Earliest failing kernel version: 2.6.28-11
Distribution: Ubuntu
Hardware Environment:  MSI  Eclipse SLI  + Intel Core i7 940
Software Environment: Gnome 2.26
Problem Description:
When you plug an external hdd drive connected by usb or firewire, Gnome automount the drive.
If you use eSATA, the kernel set it as not hotplugeable so Gnome don't mount it.

In fact Gnome using hal.

Here is bug reported on Ubuntu :
and bug reported on hal on freedesktop :
Comment 1 Tejun Heo 2009-03-20 07:12:34 UTC
Currently, the only controller which has a way to tell the kernel whether a port is external or not is ahci.  Unfortunately, there doesn't seem to be many machines which actually use the facility.  I haven't seen any yet.  The only workable solution seems to be developing eSATA whitelist on the hal side.
Comment 2 Tejun Heo 2009-03-20 07:13:57 UTC
Rejecting as INVALID.  If someone has a machine with working ahci external port marking, I have patches to test but given that most other controllers don't have such feature, I think we need hal whitelisting one way or the other.
Comment 3 Patrice Vetsel 2009-03-20 07:24:53 UTC
Thanks Tejun Heo.
Comment 4 Phillip Susi 2011-01-01 17:30:28 UTC
I also developed a patch to have the ahci driver export the external bit and it seems to work well on my Dell Netbook.  I am hoping that this patch can be applied and help to resolve this issue finally.  Can this bug be reopened please?

For machines where the bit is not reliable, a persistent udev rule seems the way to go.
Comment 5 Phillip Susi 2011-01-01 18:01:01 UTC
FYI I added an attribute "ahci_port_external" to the host device that returns 0 or 1.  It has been pointed out that the underlying bit is already exposed in ahci_port_cmd, but this is an attribute of the scsi_host device rather than the host device, which is a sibling of, rather than parent of the scsi target device.  This arrangement makes it impossible for udev to identify the attribute as being associated with the disk device, and is a totally broken arrangement according to Kay Sievers.  If this were fixed, and udev gained bitwise comparison support, then this could be accomplished without adding new attributes, but would cause existing attributes to move around.  It seems like this would be the better fix, but is far more involved and likely to cause breakage.

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