Linux-PowerEdge Digest, Vol 70, Issue 6

sandeep kumar itallbeginswithme at gmail.com
Wed Apr 7 00:20:41 CDT 2010


i am an electronics enthusiast and new to linux i want to have control
over my hardware usb ports parallel ports vga port using ubuntu please
help to write device drivers and so on what the hell is

On 4/6/10, linux-poweredge-request at dell.com
<linux-poweredge-request at dell.com> wrote:
> Send Linux-PowerEdge mailing list submissions to
> 	linux-poweredge at dell.com
>
> To subscribe or unsubscribe via the World Wide Web, visit
> 	https://lists.us.dell.com/mailman/listinfo/linux-poweredge
> or, via email, send a message with subject or body 'help' to
> 	linux-poweredge-request at dell.com
>
> You can reach the person managing the list at
> 	linux-poweredge-owner at dell.com
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Linux-PowerEdge digest..."
>
>
> Today's Topics:
>
>    1. RE: Help with multipath failover (Brian O'Mahony)
>    2. Problem updating megaraid_sas (John McMonagle)
>    3. Re: Power consumption -- real vs actual (Tom Rockwell)
>    4. RE: Power consumption -- real vs actual (John LLOYD)
>    5. semaphore leaks via RHEL3u5 WS + OMSA 5.1.0-354 +
>       check_openmanage 	3.4.9 + 'high load' (Nick Silkey)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Tue, 6 Apr 2010 13:51:31 +0100
> From: "Brian O'Mahony" <brian.omahony at curamsoftware.com>
> Subject: RE: Help with multipath failover
> To: "linux-poweredge at lists.us.dell.com"
> 	<linux-poweredge at lists.us.dell.com>
> Message-ID:
> 	<86E8DA9E18BC2344BD0218BF23C88DF30142BD90F530 at MAIL06.curamsoftware.com>
> 	
> Content-Type: text/plain; charset="us-ascii"
>
> Sorry for the delay in responding to this. I was away at the end of last
> week.
>
> Anyways, to test I was running a ping from one terminal and then using the
> other terminal to run multipath -ll, and as far as I can see the actual
> multipathing is fine. However the machine isn't in the office and there is
> no-one on site till the morning.
>
> What method would you suggest to measure if the I/O is interrupted? I would
> have thought if the ping was unsuccessful, then so to would be read/writes?
>
> I also have two other quick questions:
>
> 1. Where do you go about deleting multipath configuration? When I use
> multipath -F it tells me the map is in use, so I stopped the service and
> logged out of the node, but the error stays the same.
>
> 2. Is there any tools you would recommend for monitoring read/write access
> to the SAN once it is in production? I just want to be able to monitor,
> preferably in real time, the read/write speeds, and whether there is
> bottlenecks - eg with the network to the SAN.
>
> Thanks for all the help
> B
>
> -----Original Message-----
> From: Shyam_Iyer at Dell.com [mailto:Shyam_Iyer at Dell.com]
> Sent: Wednesday, March 31, 2010 7:51 PM
> To: Brian O'Mahony; criley at erad.com; linux-poweredge at lists.us.dell.com
> Subject: RE: Help with multipath failover
>
>
>
> Well you are testing link failover and not I/O failover then .. (:
>
>
> I would ideally try to do I/O through one path yank out the cable and watch
> the I/O failover to the other path...
> That is probably what you want to ensure if you want to use dm-multipath..
>
> Also, make sure you change the configuration for failback from "immediate"
> to "queue" so that you won't see immediate I/O failures and see the I/O
> safely failover to the other path.
>
> Thanks,
> Shyam Iyer
> Linux Engineering.
>
> -----Original Message-----
> From: linux-poweredge-bounces at dell.com on behalf of Brian O'Mahony
> Sent: Wed 3/31/2010 2:02 PM
> To: 'criley at erad.com'; linux-poweredge-Lists
> Subject: Re: Help with multipath failover
>
> Ping to san ip and yanking a cable....
> ------------------------
> Sent from my BlackBerry Wireless Handheld
>
>
> ----- Original Message -----
> From: Charles Riley <criley at erad.com>
> To: Brian O'Mahony
> Sent: Wed Mar 31 18:34:12 2010
> Subject: Re: Help with multipath failover
>
> How are you determining that it doesn't fail over?
>
> Charles Riley
> eRAD, Inc.
>
>
> ----- "Brian O'Mahony" <brian.omahony at curamsoftware.com> wrote:
>
>> Im connecting a PE2850 to a Equalogic SAN, using multipath. I have a
>> PCI NIC with one connection to the SAN and one from the onboard
>> controller too. The SAN is ona different network, and is at IP
>> 10.10.20.10.
>>
>>
>>
>> Here is the output from the multipath -ll
>>
>> [root at ccvobtest2850 ~]# multipath -ll
>>
>> DubSanGrp01VolCC (36090a048d03f308d51b1f47c000030a6) dm-18
>> EQLOGIC,100E-00
>>
>> [size=500G][features=1 queue_if_no_path][hwhandler=0][rw]
>>
>> \_ round-robin 0 [prio=1][enabled]
>>
>> \_ 3:0:0:0 sdc 8:32 [active][ready]
>>
>> \_ round-robin 0 [prio=1][enabled]
>>
>> \_ 4:0:0:0 sdd 8:48 [active][ready]
>>
>>
>>
>>
>>
>>
>>
>> And here is the multipath.conf:
>>
>> [root at ccvobtest2850 ~]# cat /etc/multipath.conf
>>
>> ## Use user friendly names, instead of using WWIDs as names.
>>
>> defaults {
>>
>> user_friendly_names yes
>>
>> }
>>
>> blacklist {
>>
>> # wwid 26353900f02796769
>>
>> # devnode "^(ram|raw|loop|fd|md|dm-|sr|scd|st)[0-9]*"
>>
>> # devnode "^hd[a-z]"
>>
>> # devnode "^sd[a-b]"
>>
>> }
>>
>> multipaths {
>>
>> multipath {
>>
>> wwid 36090a048d03f308d51b1f47c000030a6
>>
>> alias DubSanGrp01VolCC
>>
>> }
>>
>> }
>>
>> devices {
>>
>> device {
>>
>> vendor "EQLOGIC"
>>
>> product "100E-00"
>>
>> path_grouping_policy failover
>>
>> getuid_callout "/sbin/scsi_id -g -u -s /block/%n"
>>
>> features "1 queue_if_no_path"
>>
>> path_checker readsector0
>>
>> failback immediate
>>
>> path_selector "round-robin 0"
>>
>> rr_min_io 10
>>
>> rr_weight priorities
>>
>> }
>>
>> }
>>
>>
>>
>>
>>
>> However when I unplug the cable to eth1, it doesn't failover. I am
>> testing with a ping to the SAN at 10.10.20.10. As Im pretty new to all
>> this, was wondering if anyone has any pointers on where I am going
>> wrong.
>>
>>
>>
>> Thanks
>>
>> Brian
>>
>>
>>
>> The information in this email is confidential and may be legally
>> privileged.
>> It is intended solely for the addressee. Access to this email by
>> anyone else
>> is unauthorized. If you are not the intended recipient, any
>> disclosure,
>> copying, distribution or any action taken or omitted to be taken in
>> reliance
>> on it, is prohibited and may be unlawful. If you are not the intended
>> addressee please contact the sender and dispose of this e-mail. Thank
>> you.
>> _______________________________________________
>> Linux-PowerEdge mailing list
>> Linux-PowerEdge at dell.com
>> https://lists.us.dell.com/mailman/listinfo/linux-poweredge
>> Please read the FAQ at http://lists.us.dell.com/faq
>
>
> The information in this email is confidential and may be legally privileged.
> It is intended solely for the addressee. Access to this email by anyone else
> is unauthorized. If you are not the intended recipient, any disclosure,
> copying, distribution or any action taken or omitted to be taken in reliance
> on it, is prohibited and may be unlawful. If you are not the intended
> addressee please contact the sender and dispose of this e-mail. Thank you.
>
> _______________________________________________
> Linux-PowerEdge mailing list
> Linux-PowerEdge at dell.com
> https://lists.us.dell.com/mailman/listinfo/linux-poweredge
> Please read the FAQ at http://lists.us.dell.com/faq
>
>
>
> The information in this email is confidential and may be legally privileged.
> It is intended solely for the addressee. Access to this email by anyone else
> is unauthorized. If you are not the intended recipient, any disclosure,
> copying, distribution or any action taken or omitted to be taken in reliance
> on it, is prohibited and may be unlawful. If you are not the intended
> addressee please contact the sender and dispose of this e-mail. Thank you.
>
>
>
>
> ------------------------------
>
> Message: 2
> Date: Tue, 6 Apr 2010 09:46:49 -0500
> From: John McMonagle <johnm at advocap.org>
> Subject: Problem updating megaraid_sas
> To: linux-poweredge at lists.us.dell.com
> Message-ID: <201004060946.49594.johnm at advocap.org>
> Content-Type: text/plain;  charset="utf-8"
>
> Have a pe 2950 that I'm upgrading to debian lenny.
> At the moment using the debian 2.6.26 kernel.
> I will also need the xen 3.4.2 2.6.18 kernel.
>
> I upgraded all the firmware bios etc.
> I noticed that openmanage gives the following  message:
> Firmware Version	5.2.2-0072
> Driver Version	00.00.03.20-rc1
> Minimum Required Driver Version	00.00.03.21
>
> I noticed the xen kernel is even older.
>
> I installed dkms.
> I downloaded the new megaraid_sas rpm from dell.
> Converted it to deb with alien and installed it.
>
> Problem is there seems to be an incompatablity the the kernels
> scsi_cmnd definition.
> Get errors like:
> /var/lib/dkms/megaraid_sas/v00.00.03.21/build/megaraid_sas.c: In
> function ?megasas_make_sgl32?:
> /var/lib/dkms/megaraid_sas/v00.00.03.21/build/megaraid_sas.c:489:
> error: ?struct scsi_cmnd? has no member named ?request_buffer?
>
> Any suggestions?
>
> John
>
> 		
> 		
>
>
>
> ------------------------------
>
> Message: 3
> Date: Tue, 06 Apr 2010 11:28:04 -0400
> From: Tom Rockwell <rockwell at pa.msu.edu>
> Subject: Re: Power consumption -- real vs actual
> To: John LLOYD <jal at mdacorporation.com>
> Cc: "linux-poweredge at dell.com" <linux-poweredge at dell.com>
> Message-ID: <4BBB5304.5080307 at pa.msu.edu>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
> John,
>
> To turn this around a bit, what question are you wanting to answer with
> the power consumption numbers?
>
> Are you trying to size cooling systems?  Size UPS or PDUs?  Evaluating
> operating costs?
>
> I've found the tools are dell.com/calc to be pretty good at reproducing
> what we measure using a power meter.  One caveat is that they give the
> same power for all bins of a XEON CPU --- same for all L, E, X clock
> speeds, which isn't really the case.  This results in overestimates for
> some CPUs.
>
> -Tom
>
>
>
>
> On 4/5/10 12:37 PM, John LLOYD wrote:
>> We're coming up against power consumption issues on some servers, usually
>> 10g (r900) and 11g (r710,r610) boxes.
>>
>> I'll use an R710 as an example.
>>
>> The nameplate rating, used for electrical safety, is 7 amps for an R710
>> (100V to 120V).
>>
>> The power supply rated capacity is 870W (for the high-output version).
>>
>> The enterprise power calculator dell.com/calc  says input power is 431
>> watts, maximum 578 watts.
>>
>> Open Manage reports power consumption (at idle) is 252W.
>>
>>
>> Now, with this surplus of numbers to choose from, I have a few concerns.
>>
>> First, the enterprise calculator shows maximum (578) less than power
>> supply capacity (870) which is a good thing.
>>
>> But, second, the power supply capacity is more than rated input which is
>> 7A * 100V=700VA.  What is the basis for the current rating on the
>> nameplate?
>>
>> (By nameplate I mean the black decal with numerous regulatory logos, input
>> voltage/current ratings, model numbers, etc.)
>>
>> Third, while idle power is less than calculated (and I do understand why),
>> why so much less?  Try as I might, I cannot get my 252W reported by
>> OpenManage up near the 431W calculated, by exercising CPUs or disks.  So,
>> does OpenManage report "input" power or "output" from the power supply,
>> or, something else?  Or is the calculator based on highest-expected values
>> rather than averages?
>>
>> Fourth, the Open Manage mechanism to measure power is based on whatever is
>> built into the chassis.  How accurate (% of actual) could we expect this
>> to be?  5% or 20%?  And is it "input" to the power supply or "input" to
>> the baseboard?
>>
>>
>>
>> FYI, commands were
>>   CPU heater:  dd if=/dev/zero of=/dev/null&     8 to 16 times
>>   disk heater:  tar cf /dev/zero /path/to/big/disks/as/raid-5
>>   measure power:  omreport chassis pwrmonitoring | grep Reading | head -1
>> Config is
>> # SPident
>> CONCLUSION: System is up-to-date!
>>    found    SLE-10-x86_64-SP2 + "online updates"
>> Hardware is R710, two Intel(R) Xeon(R) CPU X5570  @ 2.93GHz, (quad-core)
>> Six 600GB SAS disks.  One Perc 6/I controller.
>> Open Manage is 6.1
>>
>>
>> --John
>>
>>
>>
>>
>>
>>
>>
>> _______________________________________________
>> Linux-PowerEdge mailing list
>> Linux-PowerEdge at dell.com
>> https://lists.us.dell.com/mailman/listinfo/linux-poweredge
>> Please read the FAQ at http://lists.us.dell.com/faq
>
>
>
> ------------------------------
>
> Message: 4
> Date: Tue, 6 Apr 2010 08:30:59 -0700
> From: John LLOYD <jal at mdacorporation.com>
> Subject: RE: Power consumption -- real vs actual
> To: Matthew Geier <matthew at acfr.usyd.edu.au>
> Cc: "linux-poweredge at dell.com" <linux-poweredge at dell.com>
> Message-ID:
> 	<D4ADCF07769283468C6E62E379B586571031084F12 at EVSYVR1.ds.mda.ca>
> Content-Type: text/plain; charset="us-ascii"
>
>
>
>> -----Original Message-----
>> From: Matthew Geier [mailto:matthew at acfr.usyd.edu.au]
>> Sent: Monday, April 05, 2010 5:02 PM
>> To: John LLOYD
>> Cc: linux-poweredge at dell.com
>> Subject: Re: Power consumption -- real vs actual
>>
>> John LLOYD wrote:
>> >
>> > The nameplate rating, used for electrical safety, is 7 amps for an
>> R710 (100V to 120V).
>> >
>> > The power supply rated capacity is 870W (for the high-output
>> version).
>> >
>> > The enterprise power calculator dell.com/calc  says input power is
>> 431 watts, maximum 578 watts.
>> >
>> > Open Manage reports power consumption (at idle) is 252W.
>> >
>> >
>> > Now, with this surplus of numbers to choose from, I have a few
>> concerns.
>> >
>> > First, the enterprise calculator shows maximum (578) less than power
>> supply capacity (870) which is a good thing.
>> >
>> > But, second, the power supply capacity is more than rated input which
>> is 7A * 100V=700VA.  What is the basis for the current rating on the
>> nameplate?
>> >
>>
>>  Watts != VA
>
> Very True.
>
>>
>>  I don't know what the 'Power Factor' is for a  R710 power supply so
>> can't check the figures line up.  Generally the Watts rating is smaller
>> than the VA rating. 7A x 100V is Watts not VA, so the fact that it's
>
>   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>   Very much not true.  The sticker is supposed to be VA.
>
> The line cord is rated for insulation, and current.  Devices are rated for
> VA, everywhere there is a regulatory regime.  So you have to provide a line
> cord that meets the current ratings (almost always very easy in North
> America since there is really only one standard for line cords for 120V
> equipment), and a power supply that meets VA requirements.
>
> My issue is the power rating of the device itself.  Of course VA could be a
> lot higher than watts, e.g. motors, old switchmode power supplies, etc.
> Modern power supplies have to meet efficiency standards, and power-factor
> standards.  The R710 power supplies are probably 0.95 or better PF.
>
> (For the uninitiated, AC power, measured in watts, depends only on the
> current and the voltage which are exactly in phase with each other.  Some
> electrical loads, e.g. motors, generate magnetic fields which store and
> release energy and result in the current being out of phase with the
> voltage.  It's just the way it is.  The current can then be considered as
> two parts: the part exactly in phase with the voltage, and the other part
> being the rest.  The total current is what the power cord has to carry,
> although it is larger than the watts delivered.  The ratio of the two is
> (approximately) the power factor.  The total current times voltage is the
> VA.  The part of current exactly in phase with voltage times voltage is
> watts.)
>
>
>> lower than the rating on the power supply would be correct if the power
>> supply sticker is VA and not watts....
>
>    ^^^^^^^^^^^^^^^^^^^
>
> which is the standard.
>
>>
>>  Being in a 230/240 country creates other issues for us - things that
>> come with 15A line cords as on 100v they draw more than 10A thus need
>> the higher rated cord. On 230v they are below 10A so don't need the
>> higher rated cord/socket, but we have to use a 15A outlet anyway or
>> change the plugs on the supplied cords :-)
>>
>
> Oh yes, we've seen this too.  Try getting customers in Germany to understand
> what the total power consumption of a rack is, and that they have to supply
> two circuits not just one.  (German power distribution seems to be fairly
> low in amps per circuit, relatively speaking).
>
> IEC320 cords (rated for 600V, and therefore good for 120 or 208/230) are
> good here.  These don't require "national" power cords, and you can run most
> equipment on 120 or 208/230, whatever is convenient, from one distribution
> panel supplied with a higher-power circuit.  The only exception seems to be
> laser printers, for which we have to supply localized versions.
>
>
> My main issue is for power-constrained situations where I need to be able
> account for every watt and every VA, and know the modes of operation.  It is
> something of an eye-opener to see R710 power jump from 250 to 430 watts just
> because the CPU is cranked up.  Another eye-opener is the VA rating, no load
> applied, of a power strip.   You might expect zero, and you would be wrong.
>
>
>
> --John
>
>
>
>
>
>
>
>
> ------------------------------
>
> Message: 5
> Date: Tue, 6 Apr 2010 11:41:16 -0400
> From: Nick Silkey <nick at silkey.org>
> Subject: semaphore leaks via RHEL3u5 WS + OMSA 5.1.0-354 +
> 	check_openmanage 	3.4.9 + 'high load'
> To: linux-poweredge at dell.com
> Message-ID:
> 	<p2m1cb9e23c1004060841q736a8e51pdc7f1a1d84d88700 at mail.gmail.com>
> Content-Type: text/plain; charset=ISO-8859-1
>
> We have quite a few production RHEL3u5 WS hosts running OMSA
> 5.1.0-354.  We find pointing Trond Amundsen's check_poweredge Nagios
> plugin at them eventually leads to semaphore resource exhaustion, but
> only when the machine is under high load (low load == semaphores come,
> do their job, and go as expected ; high load == orphaned semaphores
> build up over time and eventually hit kernel limits).
>
> Example syslog from an affected host:
>
> Apr 5 12:00:53 qweqaz Server Administrator (SMIL): Data Engine
> EventID: 0 A semaphore set has to be created but the system limit for
> the maximum number of semaphore sets has been exceeded
>
> Semaphore state on an affected machine:
>
> -bash-2.05b$ ipcs
>
> ------ Shared Memory Segments --------
> key        shmid      owner      perms      bytes      nattch     status
> 0x0001ffb8 0          root      666        76         3
> 0x00025990 32769      root      666        8308       3
> 0x00027cb9 65538      root      666        132256     1
> 0x00027cba 98307      root      666        132256     1
> 0x00027cdc 323092484  nagios    666        132256     0
> 0x00027cdd 393412613  nagios    666        132256     0
> 0x00027cde 393838598  nagios    666        132256     0
> 0x00027cdf 394231815  nagios    666        132256     0
> 0x00027ce0 413794312  nagios    666        132256     0
> 0x00027ce1 455770121  nagios    666        132256     0
> 0x00027ce2 483229706  nagios    666        132256     0
>
> ------ Semaphore Arrays --------
> key        semid      owner      perms      nsems
> 0x00000000 393216     root      666        1
> 0x00000000 425985     root      666        1
> 0x00000000 458754     root      666        1
> 0x00000000 491523     root      666        1
> 0x00000000 524292     root      666        1
> 0x00000000 557061     root      666        1
> 0x00000000 622599     root      666        1
> 0x00000000 655368     root      666        1
> 0x0001ffb8 688137     root      666        1
> 0x000251c0 720906     root      666        1
> 0x000255a8 753675     root      666        1
> 0x00025990 786444     root      666        1
> 0x00000000 1179661    root      666        1
> 0x000278d1 884750     root      666        1
> 0x00027cb9 917519     root      666        1
> 0x00000000 950288     root      666        1
> 0x00000000 983057     root      666        1
> 0x00000000 1015826    root      666        1
> 0x00000000 1048595    root      666        1
> 0x00000000 1081364    root      666        1
> 0x000278d2 1114133    root      666        1
> 0x00027cba 1146902    root      666        1
> 0x000278f4 197754904  nagios    666        1
> 0x00027cdc 197787673  nagios    666        1
> 0x000278f5 378044442  nagios    666        1
> 0x00027cdd 378077211  nagios    666        1
> 0x000278f6 379322396  nagios    666        1
> 0x00027cde 379355165  nagios    666        1
> 0x000278f7 380502046  nagios    666        1
> 0x00027cdf 380534815  nagios    666        1
> 0x000278f8 430571552  nagios    666        1
> 0x00027ce0 430604321  nagios    666        1
> 0x000278f9 538050594  nagios    666        1
> 0x00027ce1 538083363  nagios    666        1
> 0x000278fa 608436260  nagios    666        1
> 0x00027ce2 608469029  nagios    666        1
>
> ------ Message Queues --------
> key        msqid      owner      perms      used-bytes   messages
>
> Kernel proc bits on affected machines:
>
> -bash-2.05b$ cat /proc/sys/kernel/{sem,shm{all,max,mni}}
> 250	32000	32	128
> 2097152
> 33554432
> 4096
>
> This is the latest version of OMSA supported under RHEL3 per Dell Support.
>
> We are also several point releases behind the current check_openmanage
> Nagios plugin.  However the changelog doesnt appear to indicate that
> there is a helpful bugfix.  I mention this only as we have run a local
> heap of Big Brother bash mess against local OMSA on these high load
> hosts for years without any semaphore problems.
>
> We _could_ bump kernel limits _or_ splay Nagios checking to prolong
> intervals between semaphore exhaustion _or_ have something like cron
> or cfengine sweep in and ungracefully blast the orphaned semaphores at
> a fixed interval, but we would welcome a more elegant fix.  Curious to
> know if 1.) others have experienced this bug and 2.) how they have
> gotten around this issue.
>
> Input appreciated.  Thanks.
>
> --
> Nick Silkey
>
>
>
> ------------------------------
>
> _______________________________________________
> Linux-PowerEdge mailing list
> Linux-PowerEdge at dell.com
> https://lists.us.dell.com/mailman/listinfo/linux-poweredge
> Please read the FAQ at http://lists.us.dell.com/faq
>
> End of Linux-PowerEdge Digest, Vol 70, Issue 6
> **********************************************
>



More information about the Linux-PowerEdge mailing list