Tejun!
No it won't show up and I can't really answer all your linux related questions. Sorry. :-P
Nice system...
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.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.
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.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.
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 system3. 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:
ahci_em.tar.gz
Description: application/gzip
