Date: Wed, 26 Sep 2012 11:42:48 -0700 From: Jim Harris <jimharris@freebsd.org> To: Paul Maulberger <Paul.Maulberger@gmx.de> Cc: freebsd-scsi@freebsd.org Subject: Re: Intel C600 SAS Controller + locate LED (SGPIO) Message-ID: <CAJP=Hc9LWx-a5d%2B6TKoJ050DRuStsMYJFEJfHi4FJbXZa-J6NA@mail.gmail.com> In-Reply-To: <20120926181723.327430@gmx.net> References: <20120923140816.144270@gmx.net> <CAJP=Hc__5sCNOxtHETMtJv70FPDi-8SoC6=ZQnYxKp-m9PuR%2Bw@mail.gmail.com> <20120926093759.299750@gmx.net> <CAJP=Hc-iDtgmYTEZpTC97JYNwqbUyWgr4h-xvc%2BKBS1Xn9sTWg@mail.gmail.com> <20120926181723.327430@gmx.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, Sep 26, 2012 at 11:17 AM, Paul Maulberger <Paul.Maulberger@gmx.de> wrote: > Hi Folks, > > I do not share Jim's opinion. I think the fault led should be access-able by the userspace. > > I have a special system monitor daemon which although checks the S.M.A.R.T. information of the hard drive. If information X is above value Y the system monitor daemon informs the admin and sets the fault led. > > In this case the driver could not set the fault led because it does not know "my" value Y. > > As the fault led is rarely set the userspace and the driver should have shared access to the led. Also a conflict could be easily solved: > > solution a: The last one wins. > > solution b: If the driver sets the fault led the userspace could not clear it. > > What do you think? I'm OK with giving error LED userspace access based on your scenario. You only mentioned wanting to use the locate LEDs in your original post, so I assumed you were trying to get isci to match ahci behavior rather than having a specific need for accessing the error LEDs. But I'd like the patch to be modified to store current value of both error and locate onoff in the ISCI_LED object. This ensures that current error LED value is maintained when the locate callback is invoked, and vice versa. If you could also test simultaneous writes to error and locate LEDs on same port, I would appreciate it. The system I have here does not have separate LEDs for locate and error. Thanks, -Jim > Regards > Paul > > -------- Original-Nachricht -------- >> Datum: Wed, 26 Sep 2012 08:57:13 -0700 >> Von: Jim Harris <jimharris@freebsd.org> >> An: Paul Maulberger <Paul.Maulberger@gmx.de> >> CC: freebsd-scsi@freebsd.org >> Betreff: Re: Intel C600 SAS Controller + locate LED (SGPIO) > >> On Wed, Sep 26, 2012 at 2:37 AM, Paul Maulberger <Paul.Maulberger@gmx.de> >> wrote: >> > Hi Jim, >> > >> > your patch is working very well. Thanks a lot! >> > >> > To support the locate and the fault led I extended your patch a little >> bit. Like the ahci driver every port has now a locate and a fault led >> device. >> >> Hi Paul, >> >> I am reluctant to add LEDs for error, even though I know AHCI driver >> does this today. I don't see the need for userspace to manipulate >> both locate and error LEDs - it seems locate is sufficient. I'd >> prefer to keep error LED reserved for future use in the driver. >> >> But I will add "locate" to the LED name, just to make it more clear. >> >> > # ls -al /dev/led >> > total 1 >> > dr-xr-xr-x 2 root wheel 512 Sep 26 08:39 . >> > dr-xr-xr-x 11 root wheel 512 Sep 26 10:39 .. >> > crw------- 1 root wheel 0, 47 Sep 26 08:43 ahcich0.fault >> > crw------- 1 root wheel 0, 46 Sep 26 08:44 ahcich0.locate >> > crw------- 1 root wheel 0, 49 Sep 26 08:39 ahcich1.fault >> > crw------- 1 root wheel 0, 48 Sep 26 08:39 ahcich1.locate >> > crw------- 1 root wheel 0, 51 Sep 26 08:39 ahcich2.fault >> > crw------- 1 root wheel 0, 50 Sep 26 08:39 ahcich2.locate >> > crw------- 1 root wheel 0, 53 Sep 26 08:39 ahcich3.fault >> > crw------- 1 root wheel 0, 52 Sep 26 08:39 ahcich3.locate >> > crw------- 1 root wheel 0, 55 Sep 26 08:39 ahcich4.fault >> > crw------- 1 root wheel 0, 54 Sep 26 08:39 ahcich4.locate >> > crw------- 1 root wheel 0, 57 Sep 26 08:44 ahcich5.fault >> > crw------- 1 root wheel 0, 56 Sep 26 08:44 ahcich5.locate >> > crw------- 1 root wheel 0, 36 Sep 26 08:39 igb0 >> > crw------- 1 root wheel 0, 37 Sep 26 08:39 igb1 >> > crw------- 1 root wheel 0, 38 Sep 26 08:39 isci.bus0.port0.fault >> > crw------- 1 root wheel 0, 39 Sep 26 08:39 isci.bus0.port0.locate >> > crw------- 1 root wheel 0, 40 Sep 26 08:42 isci.bus0.port1.fault >> > crw------- 1 root wheel 0, 41 Sep 26 08:42 isci.bus0.port1.locate >> > crw------- 1 root wheel 0, 42 Sep 26 08:39 isci.bus0.port2.fault >> > crw------- 1 root wheel 0, 43 Sep 26 08:39 isci.bus0.port2.locate >> > crw------- 1 root wheel 0, 44 Sep 26 08:39 isci.bus0.port3.fault >> > crw------- 1 root wheel 0, 45 Sep 26 08:39 isci.bus0.port3.locate >> > >> > By the way the main board X9DRi-F has only one bus. The X9DR3-F has 2 >> buses. >> > >> > The patch (compared to 9.1 RC1) is attached. >> > >> > Is it possible to commit this patch into 9.1 or is it too late? >> >> I think it is too late. The changes here are very low risk, but it is >> a new feature and not a bug fix so not really appropriate for 9.1 at >> this point. >> >> Thank you for testing the patch! >> >> Regards, >> >> -Jim >> >> >> > Regards >> > Paul >> > >> > Hint: If anybody is using a SC825TQ chassis and no led is blinking check >> ALL jumper settings of your backplane (Appendix C of >> http://www.supermicro.com/manuals/chassis/2U/SC825.pdf). Our backplane was wrongly configured by >> factory (mixture of sgpio and i2c settings). >> > >> >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAJP=Hc9LWx-a5d%2B6TKoJ050DRuStsMYJFEJfHi4FJbXZa-J6NA>