Re: hot plug on ICH9 with AHCI on

["Владимир Дашевский" <vladimir.dashevsky@gmail.com>]

Tejun!

Tejun Heo пишет:
>> I think you are not right here. If we are talking about EMI problems I
>> can say that the strategy of many retries is worse than one read of port
>> present status. EMI noise occurs at the time while software tries to
>> re-establish connection with empty link because there is no link
>> terminatiion. It's just like a car engine that has lost its muffler. It
>> produces lots of noise. It is better to turn the link off as soon as we
>> know there is no device on the port. That's why retries should last only
>> until that state is reported by hardware. And I think hardware reports
>> that state much faster than in 15 or even 5 seconds. In ICH9 it reports
>> this just immediately.
>>     
>
> 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.

> I don't know of a practical downside to lingering for limited amount
> of time.  If you know one, please let me know.
>
>   
Ok.

>> Ok. So, one more question. How can I know exactly when device deletion
>> has completed after sending this command? For example, consider that
>> there some data in cache that needs 3 seconds to be sync-ed to disk. How
>> can I know that I must wait for 3 seconds before a can actually remove
>> the drive? Should I check the presence of some other filename in
>> /sys/block/sdX/ or do something else?
>>     
>
> 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?
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?


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. 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.

Best regards, Vladimir Dashevsky