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, [email protected] <[email protected]> wrote: > Send Linux-PowerEdge mailing list submissions to > [email protected] > > 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 > [email protected] > > You can reach the person managing the list at > [email protected] > > 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" <[email protected]> > Subject: RE: Help with multipath failover > To: "[email protected]" > <[email protected]> > Message-ID: > <86e8da9e18bc2344bd0218bf23c88df30142bd90f...@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: [email protected] [mailto:[email protected]] > Sent: Wednesday, March 31, 2010 7:51 PM > To: Brian O'Mahony; [email protected]; [email protected] > 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: [email protected] on behalf of Brian O'Mahony > Sent: Wed 3/31/2010 2:02 PM > To: '[email protected]'; 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 <[email protected]> > 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" <[email protected]> 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 >> >> [r...@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: >> >> [r...@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 >> [email protected] >> 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 > [email protected] > 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 <[email protected]> > Subject: Problem updating megaraid_sas > To: [email protected] > Message-ID: <[email protected]> > 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 <[email protected]> > Subject: Re: Power consumption -- real vs actual > To: John LLOYD <[email protected]> > Cc: "[email protected]" <[email protected]> > Message-ID: <[email protected]> > 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 >> [email protected] >> 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 <[email protected]> > Subject: RE: Power consumption -- real vs actual > To: Matthew Geier <[email protected]> > Cc: "[email protected]" <[email protected]> > Message-ID: > <[email protected]> > Content-Type: text/plain; charset="us-ascii" > > > >> -----Original Message----- >> From: Matthew Geier [mailto:[email protected]] >> Sent: Monday, April 05, 2010 5:02 PM >> To: John LLOYD >> Cc: [email protected] >> 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 <[email protected]> > Subject: semaphore leaks via RHEL3u5 WS + OMSA 5.1.0-354 + > check_openmanage 3.4.9 + 'high load' > To: [email protected] > Message-ID: > <[email protected]> > 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 > [email protected] > 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 > ********************************************** > _______________________________________________ Linux-PowerEdge mailing list [email protected] https://lists.us.dell.com/mailman/listinfo/linux-poweredge Please read the FAQ at http://lists.us.dell.com/faq
