poor handling of eSATA drives

Bug #139748 reported by Damon Lynch
8
Affects Status Importance Assigned to Milestone
GnomeVFS
Won't Fix
Low
gnome-vfs2 (Ubuntu)
Triaged
Low
Ubuntu Desktop Bugs

Bug Description

Binary package hint: gnome-volume-manager

Using both Gutsy and Feisty, When an eSATA drive is connected to the system, in my case via an expresscard adapter, it is not handled in the same manner as a Firewire or USB drive.

Scenario 1: where drive is connected before the machine is powered on

1. It is not mounted automatically. The user must go to the "Computer" and click on the drive in order to mount it. This is inconsistent behavior compared to Firewire or USB drives.

2. If the drive is FAT32, the user is asked to enter a password for security reasons. If the drive is ext3, no password is required (I have not tested an eSATA ext3 drive with Gutsy since I do not have one available, but I did observe this with Feisty).

All connected eSATA drives should be mounted automatically at boot time.

Scenario 2 relates to plugging / unplugging a drive when the machine is already booted. I think that should be a separate bug report.

Revision history for this message
ericc (eric-cheminot) wrote :

I can confirm this on 7.04 and 7.10beta (for scenario 2). My drive is in a SATA caddy (SATA2 controller/AHCI). When pluuged, the event shows up in hal (using 'lshal -m'), but it seems that gnome-volume-manager simply ignores it. The drive is listed in fstab (based on UID) and if I type in "mount /media/backup", the drive gets mounted OK and the icon appears on the desktop. I can then umount the drive using the right-click action. In other words, only automatic mount step seems broken.

Revision history for this message
fsando (stfs) wrote :

I have similar (but worse) experience:
I use feisty on a laptop, I have a Samsung Sata2 drive formatted as ext3 in an external usb/esata box. When connected via usb there are no problems. When connected as esata via Delock Express Card the following happens:
When hotplugging it is not detected at all ('lshal -m' shows nothing related to un-/plugging).
When I cold start with the drive connected I see in '/var/log/dmesg' a lot of lines referring to 'ata1' and 'sda1' they all seem to indicate that the boot process tries to get access to the drive but fails. My internal drive which is normally mounted as sda is now mounted as sdb.
Will posting my dmesg with and without connected drive help? If so I can do that.

Revision history for this message
Florian Schröck (mael-reverted) wrote :

this problem still exists in gutsy
the worst thing is, that i cannot unplug my eSATA HD safely. if i umount the partition and unplug it, the system hangs for about one minute and there are various error messages in dmesg:
Dec 31 03:52:39 x2 kernel: [34550.804000] ata2: timeout waiting for ADMA IDLE, stat=0x400
Dec 31 03:52:39 x2 kernel: [34550.804000] ata2: timeout waiting for ADMA LEGACY, stat=0x400
Dec 31 03:52:39 x2 kernel: [34550.804000] res c0/00:00:00:00:00/00:00:00:00:00/40 Emask 0x12 (ATA bus error)
Dec 31 03:52:39 x2 kernel: [34550.804000] ata2: hard resetting port
Dec 31 03:52:52 x2 kernel: [34563.652000] ata2: SATA link down (SStatus 0 SControl 300)
Dec 31 03:52:52 x2 kernel: [34563.652000] ata2: failed to recover some devices, retrying in 5 secs
Dec 31 03:52:57 x2 kernel: [34568.656000] ata2: hard resetting port
Dec 31 03:52:57 x2 kernel: [34569.380000] ata2: SATA link down (SStatus 0 SControl 300)
Dec 31 03:52:57 x2 kernel: [34569.380000] ata2.00: limiting speed to UDMA/133:PIO3
Dec 31 03:52:57 x2 kernel: [34569.380000] ata2: failed to recover some devices, retrying in 5 secs
Dec 31 03:53:02 x2 kernel: [34574.384000] ata2: hard resetting port
Dec 31 03:53:03 x2 kernel: [34575.108000] ata2: SATA link down (SStatus 0 SControl 300)
Dec 31 03:53:03 x2 kernel: [34575.108000] ata2.00: disabled
Dec 31 03:53:04 x2 kernel: [34575.612000] sd 2:0:0:0: [sdc] Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE,SUGGEST_OK
Dec 31 03:53:04 x2 kernel: [34575.612000] sd 2:0:0:0: [sdc] Sense Key : Aborted Command [current] [descriptor]
Dec 31 03:53:04 x2 kernel: [34575.612000] Descriptor sense data with sense descriptors (in hex):
Dec 31 03:53:04 x2 kernel: [34575.612000] 72 0b 47 00 00 00 00 0c 00 0a 80 00 00 00 00 00
Dec 31 03:53:04 x2 kernel: [34575.612000] 00 00 00 00
Dec 31 03:53:04 x2 kernel: [34575.612000] sd 2:0:0:0: [sdc] Add. Sense: Scsi parity error
Dec 31 03:53:04 x2 kernel: [34575.612000] end_request: I/O error, dev sdc, sector 0
Dec 31 03:53:04 x2 kernel: [34575.612000] ata2: EH complete
Dec 31 03:53:04 x2 kernel: [34575.612000] ata2.00: detaching (SCSI 2:0:0:0)
Dec 31 03:53:04 x2 kernel: [34575.612000] sd 2:0:0:0: [sdc] Synchronizing SCSI cache
Dec 31 03:53:04 x2 kernel: [34575.616000] sd 2:0:0:0: [sdc] Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK,SUGGEST_OK
Dec 31 03:53:04 x2 kernel: [34575.616000] sd 2:0:0:0: [sdc] Stopping disk
Dec 31 03:53:04 x2 kernel: [34575.616000] sd 2:0:0:0: [sdc] START_STOP FAILED
Dec 31 03:53:04 x2 kernel: [34575.616000] sd 2:0:0:0: [sdc] Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK,SUGGEST_OK

after this the devices is not listed anymore when executing "fdisk -l".

is there a way to "eject" the device (/dev/sdc in my case) manually, so the kernel doesn't try to access it anymore? removing it with "hal-device -r <udi>" doesn't work completly: "fdisk -l" still shows the device and the error described above still occours.

Revision history for this message
Florian Schröck (mael-reverted) wrote :

i found a workaround: the device can be removed using the sysfs:

source: "SCSI - Hot add, remove, rescan of SCSI devices" http://www-941.ibm.com/collaboration/wiki/pages/viewpage.action?pageId=3625

in short:
1. umount all partitions from the device
2. find the right SCSI ID with "cat /proc/scsi/scsi"
3. replace the SCSI ID in the following command (use tab completion ;): "echo 1 |sudo tee -a /sys/bus/scsi/drivers/sd/2\:0\:0\:0/delete"

Revision history for this message
Pedro Villavicencio (pedro) wrote :

Thanks for you report, isn't this related to: http://bugzilla.gnome.org/show_bug.cgi?id=430024 ?

Changed in gnome-volume-manager:
status: New → Incomplete
Revision history for this message
ericc (eric-cheminot) wrote : Re: [Bug 139748] Re: poor handling of eSATA drives

Definitely. The proposed "solution" would be ideal IMO.

On Jan 4, 2008 1:30 PM, Pedro Villavicencio <email address hidden> wrote:

> Thanks for you report, isn't this related to:
> http://bugzilla.gnome.org/show_bug.cgi?id=430024 ?
>
> ** Changed in: gnome-volume-manager (Ubuntu)
> Status: New => Incomplete
>
> --
> poor handling of eSATA drives
> https://bugs.launchpad.net/bugs/139748
> You received this bug notification because you are a direct subscriber
> of the bug.
>

Revision history for this message
Pedro Villavicencio (pedro) wrote :

Great, thanks for the quick response, gnome-vfs issue then reassigning. thanks again.

Changed in gnome-volume-manager:
assignee: nobody → desktop-bugs
importance: Undecided → Low
status: Incomplete → Triaged
Changed in gnome-vfs:
status: Unknown → New
Changed in gnome-vfs:
importance: Unknown → Low
Changed in gnome-vfs:
status: New → Won't Fix
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.