All of lore.kernel.org
 help / color / mirror / Atom feed
From: Tejun Heo <tj@kernel.org>
To: "Владимир Дашевский" <vladimir.dashevsky@gmail.com>
Cc: Jeff Garzik <jgarzik@pobox.com>, linux-ide@vger.kernel.org
Subject: Re: hot plug on ICH9 with AHCI on
Date: Mon, 23 Mar 2009 01:41:08 +0900	[thread overview]
Message-ID: <49C66A24.5000804@kernel.org> (raw)
In-Reply-To: <49C6623D.7080305@gmail.com>

Hello,

Владимир Дашевский wrote:
>> Not all EMIs are one-shot events.  Some can span seconds.  Links don't
>> always come up right after failures.  Sometimes they require more than
>> one hardresets to get back to working order.  Link status report is
>> not reliable.  Sometimes they report offline for a while after certain
>> events.  If you know how to work around the above problems under a
>> second, I'm all ears but I doubt it unless it involves an additional
>> mechanical switch.
>>   
> Well, for example, USB devices have a pull-up resistor on their D+ line.
> DC bias can be used for detection of device presence without mechanical
> switch.

SATA is not USB and onlineness detection isn't that simple.  Also,
have you tried to run a system on a USB device over flaky connection?

>> The echo to delete node is synchronous.  It will return after the
>> device is completely removed but please note that "removing" in this
>> sense only covers the device itself.  It will flush the request queue
>> and spin the drive down but won't do anything about filesystems.  You
>> need to unmount first.  hal and desktop stuff already do the right
>> thing for devices marked removable.
>>   
> Ok, but two more questions:
> 1. Is there any generic mechanism of notifiing processes which had
> previously opened device being deleted of this event? What will happen
> to such processes? Is it possible to check who are those who uses the
> drive at the moment?

-EIO will happen, fuser, but if you want something intelligent, hal +
dbus.

> 2. If the drive was deleted is it possible to start it back without
> physical re-connection? Can I simulate status change og that port to
> force the driver to auto-detect block device?

I don't really follow what you're trying to achieve but if you want
some fancy snapshotting + remapping trick, the best place would be dm.

> PS: as for this:
>> I'll be happy to improve EH behavior but you need to come up with
>> better reasons.
>>   
> I can tell that for me enclosure management support is quite a good
> reason.

How is that in any way exclusive against longer detach delay?

> Unfortunately, there is no this support in official kernel. I have
> seen only limited support of activity LED in kernel 2.6.28.
> However, I am using Debian where the latest kernel is only
> 2.6.26. As a result I had to write a simple ahci_em module which
> register simple proc interface to send LED states to all ICH9
> ports. However, final goal is to integrate this module with mdadm to
> have proper indication of RAID state.

The biggest obstacle is that there aren't too many enclosure devices
floating around.  What kind of device are you using?

-- 
tejun

  reply	other threads:[~2009-03-22 16:40 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-03-18 22:12 hot plug on ICH9 with AHCI on Владимир Дашевский
2009-03-20  2:04 ` Tejun Heo
2009-03-20  9:55   ` Владимир Дашевский
     [not found]     ` <49C39933.4020501@kernel.org>
2009-03-20 15:31       ` Владимир Дашевский
2009-03-22 12:51       ` Владимир Дашевский
2009-03-22 15:08         ` Tejun Heo
2009-03-22 16:07           ` Владимир Дашевский
2009-03-22 16:41             ` Tejun Heo [this message]
2009-03-22 18:26               ` Владимир Дашевский
2009-03-23  2:04                 ` Tejun Heo
2009-03-23 11:38                   ` Владимир Дашевский
2009-03-23 12:01                     ` Tejun Heo
2009-03-24  8:26                       ` Владимир Дашевский

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=49C66A24.5000804@kernel.org \
    --to=tj@kernel.org \
    --cc=jgarzik@pobox.com \
    --cc=linux-ide@vger.kernel.org \
    --cc=vladimir.dashevsky@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.