Re: [Freeipmi-devel] Re: Software Deliverables

[Anand Babu]

Hi Robin,
,----[ address@hidden ]
| OK since we only need to initialize the cache once at node install
| time, then I can live with the 40 seconds.  I'll make sure the cache
| initialization gets added to one of our post-install customization
| scripts.
`----
Thanks.

,----
| I just tried out the sensors command for the first time and here are a
| a couple of things I've encountered:
| 
| 1) I don't really like the syntax of the -s "SENSORS LIST" e.g.
| sensors -s "44 45 46 47"
| Why space delimited and in quotes?  My first guess at the syntax was:
| sensors -s 44,45,46,47
| which got me:
| sensors: error: Invalid argument [44,45,46,47] to --sensors option
`----
I can support n1,n2,n4... notation. I will include this change for
Alpha5-QA1 release.

,----[ address@hidden ]
| 2) I'd like the sensors command to exit with a non-zero return code if
| any of the sensors are in "ALERT" status.  Ideally there should be
| some non-zero return code for an actual failure to execute the command
| properly and a different return code for successful execution but one
| or more sensors with an ALERT status.
`----
I initially thought about it. My concern is, few sensors always report
ALERT. I can add "ignored sensors list" support and let the user
eliminate unwanted sensors. 

Like,
;; sensors-conf.scm config file
; Ignore the following sensors completely
(sensors-set-ignore-list!  52 100 101 102 103 104 105 106 107)

OR

; Ignore exit status for the following sensors
(sensors-set-ignore-exit-list!  52 100 101 102 103 104 105 106 107)


One good example is PCI slots:
If they are not populated OR if device has failed, sensors reports as ALERT.

SAMPLE OUTPUT ON TIGER4 (SINGLE CPU):
-------------------------------------
debian-ia64:~/ab# sensors | grep ALERT
12: Proc Bd +1.2V (Voltage): 1.22 V (low=1.18/nom=1.20/high=1.21) [ALERT]
52: HSC SCSI BP Temp (Temperature): 0.00 C (low=12.00/nom=28.00/high=38.00) 
[ALERT]
69: Pwr Supply 2 (Power Supply): [ALERT]
93: Proc 2 Status (Processor): [ALERT]
94: Proc 3 Status (Processor): [ALERT]
95: Proc 4 Status (Processor): [ALERT]
100: PCI HP Slot 1 (Slot Connector): [ALERT]
101: PCI HP Slot 2 (Slot Connector): [ALERT]
102: PCI HP Slot 3 (Slot Connector): [ALERT]
103: PCI HP Slot 4 (Slot Connector): [ALERT]
104: PCI HP Slot 5 (Slot Connector): [ALERT]
105: PCI HP Slot 6 (Slot Connector): [ALERT]
106: PCI HP Slot 7 (Slot Connector): [ALERT]
107: PCI HP Slot 8 (Slot Connector): [ALERT]
debian-ia64:~/ab# 

Thanks
-ab

> Hi Robin,
> I initially thought of using "IPMI - Broadcast Get Device ID" to
> dynamically discover newly installed devices on the system. But even
> Intel's ISM doesn't use this functionality. All SDR Repository records
> are updated only through the firmware upgrade process provided by
> Intel. 
> 
> Installing/Removing components like power-supply, fan, processor will
> not affect the cache. SDR Repository already includes all possible
> entries based on system's maximum capability. i.e. Even if the system
> has just 1 or 2 PROCs installed , SDR Repository will have records for
> all 4 processors.
> 
> Ignoring Un-installed Devices:
> You may also find this option useful. For example, In a quad-processor
> system, If you know for sure, you have only 2 processors installed,
> You can safely choose to ignore those sensors like this, 
> 
>    ;; sensors-conf.scm
>    (sensors-ignored-list "94 95")
> 
> -ab
> 
> ,----[ Robin Goldstone <address@hidden> ]
> | AB,
> | 
> | Please confirm that I should only need to initialize the SDR cache one
> | time when the node is first installed.  I was planning to
> | re-initialize the cache every time the node boots e.g. in rc.local.  I
> | was under the impression that if new hardware was installed, or even
> | replacement of an existing piece of hardware like a fan or power
> | supply, that the SDR data might change and thus the cache would be
> | invalidated.  Is that not a possibility I need to be concerned with?
> | 
> | -Robin
> `----
> 
> On Wednesday 17 March 2004 03:38 am, Anand Babu wrote:
> > ,----[ Joseph Ruscio <address@hidden> ]
> >
> > | I know there is a valid reason for this delay. I'm assuming its
> > | because of the KCS controller is slow
> >
> > `----
> > Yes, your reason is valid.
> > KCS controller is byte oriented and slow. To pull all 134 SDR records,
> > it takes around 43 secs. We can't bring it down further.
> >
> > Creation of "SDR Repository Cache" can be handled once during the
> > installation time. (Just running "sensors" in the post-inst script
> > with output redirected to "/dev/null" should initialize the cache).
> 
> 
> 
> _______________________________________________
> Freeipmi-devel mailing list
> address@hidden
> http://mail.nongnu.org/mailman/listinfo/freeipmi-devel
> 
> 
> -- 
>  _.|_ 
> (_||_)
> Free as in Freedom <www.gnu.org>
> 



-- 
 _.|_ 
(_||_)
Free as in Freedom <www.gnu.org>