Re: hot plug on ICH9 with AHCI on

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

Tejun!
> Hello,
>
> Владимир Дашевский wrote:
>   
>>>> 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?
>>>   
>>>       
>> Well, I cannot argue with you here. All that I wanted to say is that I
>> would prefer more optimistic software behavior if the hardware really
>> supports device connection status.
>>     
>
> I really don't follow your train of thoughts here.  Are you saying
> that the driver should be optimistic about the reliability about
> status reported by the hardware even when it is inherently imprecise
> (please read the spec) and real world experiments prove that?
>   
No. I ment that driver should performs better if the hardware supports 
some features for that. Consider two different cases.
1. hardware derives port population status by sensing the carrier in the 
data link. In this case it is possible that some EMI noise can damage 
link integrity so strongly that not data bits but also a carrier will be 
lost for a short time. This will lead to 'port is not present' status 
however noone has actually removed the drive.
2. Hardware implements some feature like pull-up resistor in USB, or 
special shorter 'present' contact as in PCI or CPCI connectors, or it 
simply senses some dc current through power lines etc. In this case port 
status is robust over EMI noise and be used to inform driver of actual 
connection.
My thought was to improve driver behavior in case 2, either autodetected 
by PCI IDs or manually overriden by some configure script.
>>> -EIO will happen, fuser, but if you want something intelligent, hal +
>>> dbus.
>>>   
>>>       
>> Sorry, I missed the sense of this sentence.
>>     
>
> -EIO will happen to any processes trying to do IO on the removed
> device.  fuser will find out who's using the block device but if you
> want something more intelligent, look at hal + dbus.
>   
Hm, I tried to write fuser /dev/sda and got empty output. It seems that 
file system does not open sda. How it works?
>> I tried this deletion with fdisk and see that fdisk does not even
>> comply for device failure. It just starts to print empty partition
>> table and so on. So the question is how to properly close any
>> activity concerned with device being deleted if I do not know
>> exactly what is that activity? Are the most typical programs which
>> are allowed to use raw block devices aware of unexpected block
>> device loss?
>>     
> Please take a look at how desktop guys are handling the issue.  It's
> not something which can be handled in kernel proper.
>   
Ok.
>   
>>> 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.
>>>   
>>>       
>> Well, I didn't think of any tricks. I just deleted the drive as you
>> taught me and tried to get it back without moving myself in front of the
>> server. :-)
>> However, I think that some call to rescan scsi devices will be useful.
>>     
>
> Ah.. in that case, you can do
>
>  # echo - - - > /sys/class/scsi_host/hostN/scan
>   
well, it works but it takes of about 10 seconds to finish scan for 
deleted drive. is this ok?
Probably, that's because drive goes down after deletion and it starts to 
spin up during this scan.
>>> The biggest obstacle is that there aren't too many enclosure devices
>>> floating around.  What kind of device are you using?
>>>   
>>>       
>> I don't know exactly what device are you talking about. I was talking
>> about LED message types that are supported in ICH9.
>> As for my server, ICH9 provides SGPIO interface that is routed to
>> 4-drive hot-swap backplane based on AMI MG9071 chip. However, this
>> information isn't needed to program ICH9 since the LED message mechanism
>> is supported in it. Other message types are not supported. And it is
>> very strange that linux ahci still does not support this functionality
>> since it was first introduced in ICH8 (datasheet first release in June
>> of 2006).
>>     
>
> Yeah, I know it has been in the spec but without hardware to play with
> it's difficult to add driver features and lack of general availability
> also means lower demand.
>   
Well, I just cannot imagine how software raid can work without clearly 
visible state. One drive mixed up in RAID5 and the whole array can get 
damaged. And it is not so difficult to mix them up because drive names 
may differ from physical slot numbers.

>> PS: My code has about 11Kb of text and supports all useful RAID states:
>> NORMAL, LOCATE, REBUILD, FAILURE, HOTSPARE, PREDICTED FAILURE SOON. I
>> have tested in on my server and it works. I think it can be useful for
>> other implementations of soft RAID systems with hat swap support.
>>     
>
> I think it should be independent from RAID but having general
> enclosure support will be nice.  Care to post the patches?
>
>   
Well, I can provide you with a code which works on my ICH9 Supermicro 
platform. I believe it will also work with both ICH8 and ICH10.
However, since I could not install this module as traditional pci driver 
(the kernel decided not to claim my ahci device since the main driver 
present in the system) I had to rewrite it as a general linux kernel 
module. It justs scan pci devices for AHCI capable ones and remaps their 
ABAR to try enclosure management support. For now, only my ICH9 PCI IDs 
are in my try list. All AHCI EM-capable devices get their associated 
proc interface - /proc/ahci_emX/leds*. This module actually works in 
parallel with kernel ahci driver but I think it will be a conflict with 
it once the kernel driver starts to support em by itself. I guess, the 
best way would be to document some API for controlling the EM, then to 
declare some kernel ahci flag that will indicate full EM presence in the 
kernel. Then I can improve my ahci_em module to skip its installation 
when similar functions are built into the kernel.

My interface is quite simple. You just write a char to leds-controlling 
proc file to set state of leds, for example:
echo r > /proc/ahci_em0/leds0 means you asked for REBUILD state 
indicated in the bay of port 0.
I think that most of users would prefer additional module rather that 
kernel udgrade, for the first time. Also, I am not very close to linux 
kernel to provide a kernel patch.

Thanks.

Best regards, Vladimir Dashevsky