Re: hot plug on ICH9 with AHCI on

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

[-- Attachment #1: Type: text/plain, Size: 4265 bytes --]

Tejun!
> No it won't show up and I can't really answer all your linux related
> questions.  Sorry.  :-P
>   
Nice system...
>
>>> 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.
>>     
>
> Yeah, it can be tricky but highend machine usually go with sas and
> consumer grade machines don't really care, so there just aren't too
> many ahci machines with enclosure support.  Well, not here anyway.
>
>   
As for me, there is a lot of tasks where the main issue is a reliablity 
and not nesessary a performance.
SAS cannot be used for RAID anyway, it's closer to RAED. I guess that 
software RAID can be the best solution for every case where reliablity 
and online scalability is needed.
>>> 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.
>>     
>
> I don't think the design you described would fit into upstream kernel
> too well but if you have it working it's some place to start.  Just
> refresh in on top of the current devel kernel and let's see what can
> be done.
>   
Sorry, I am not so close to linux kernel to perform a jump from my 
current kernel
(2.6.25) to latest one. I am sending you the sources of kernel module 
which performs all LEDs EM functions.
The code is simple and relatively small. I have brushed it up to be more 
readable.

If you decide it useful and will change user API for this (eg, move proc 
interface to sys interface) then let me know.
I would like to design this software so that module could be used with 
older kernels and have the same behavior as newer kenels will have. this 
will help to spread this technology among machines where kernel cannot 
be upgraded for some reasons.

Usage notes:
1. Use 'make' to make driver module.
2. Use 'make reload' to (re)install driver into a system
3. Use 'echo X > /proc/ahci_em0/ledsN' to set state of leds for porn N 
(N is 0 to 5 for ICH9).
X is one of the:
'N' - normal state (leds off)
'L' - locate state (4Hz blinking)
'R' - rebuild state (1Hz blinking)
'F' - failure state (solid + beep)
'P' - predicted failure state (two 4Hz blinks in 1 second )
'H' - hot spare ( two 4Hz blinks in 4 seconds).
My enclosure has only one state LED (besides activity LED) so I 
developed blink patterns as described here:
http://en.wikipedia.org/wiki/IBPI


Best regards, Vladimir Dashevsky


[-- Attachment #2: ahci_em.tar.gz --]
[-- Type: application/gzip, Size: 4973 bytes --]