Discuss

discuss@lists.centos.org

34753 discussions

SSHMenu (Gnome Applet) for CentOS 6
by Nikolaos Milas 05 Nov '12

05 Nov '12

Hello, I know that there exists a package for Gnome SSHMenuApplet for CentOS 5 (e.g. see http://rpmfind.net/linux/RPM/epel/testing/5/ppc/gnome-applet-sshmenu-3.15-5…) The package sshmenu (which I found here: http://dl.marmotte.net/rpms/redhat/el6/x86_64/sshmenu-3.18-7.el6/sshmenu-3.…) states: ======================================== Summary : Application to organize SSH connection information in a menu URL : http://sshmenu.sourceforge.net/ License : BSD Description : SSHMenu is a small program (which is to be used outside of GNOME) that : keeps all your regular SSH connections within a single menu. If you wish to : have the full GNOME applet version of the menu, install gnome-applet-sshmenu. ======================================== However, I can't find a gnome-applet-sshmenu RPM package for el6. So, does anyone knowof a gnome-applet-sshmenu RPM package for el6 (or can anyone provide one)? It should include SSHMenu v3.18. There is a package for FC15: ftp://fr2.rpmfind.net/linux/fedora/linux/releases/15/Everything/x86_64/os/P…, but Idon't know if it can/should be used in CentOS 6. Notes: sshmenu (v3.15) exists in EPEL for CentOS 5, but gnome-applet-sshmenu does not. Both (v3.15) exist in Extras repo. Neither exists in EPEL for Centos 6. Please advise. Thanks, Nick

7 10

Re: [CentOS] Migrate to Linux Server
by Ashkan Rahmani 05 Nov '12

05 Nov '12

On Mon, Nov 5, 2012 at 11:46 AM, Sorin Srbu <sorin.srbu(a)orgfarm.uu.se>wrote: > -----Original Message----- > From: centos-bounces(a)centos.org [mailto:centos-bounces@centos.org] On > Behalf > Of Ashkan Rahmani > Sent: den 5 november 2012 06:52 > To: CentOS mailing list > Subject: Re: [CentOS] Migrate to Linux Server > > >I need to make a document with charts and statistics. running both OS and > >ask user what they think, can not answer my needs! > > If you're looking for a benchmark test suite, have a look at Phoronix. I > believe they have a free set available for download for both Windows and > Linux. > > HTH. > > -- > /Sorin > > _______________________________________________ > CentOS mailing list > CentOS(a)centos.org > http://lists.centos.org/mailman/listinfo/centos > > Thank you. I found some articles. very good. -- Best Regards, Ashkan R

1 0

Migrate to Linux Server
by Ashkan Rahmani 05 Nov '12

05 Nov '12

Hi, In our company we have a DL380 ( 16gb ram) server with Windows server 2003 x86, this run only tomcat 6. We have 2 options: a) upgrade to windows 2008 x64 and b) migrate to Linux ( I mean centos 6 x64). I want to make some benchmarks. Please help me to compare a and b. How I can make this benchmark? -- Best Regards, Ashkan R

7 13

Information error (EDAC MC0 : UE row 0, channel-a= 0)
by Muhammad A. Fatahna 05 Nov '12

05 Nov '12

Dear All, I have problem with CentOS 6 64bit, this screen monitor view below EDAC MC0 : UE row 0, channel-a= 0 channel-b= 1 labels "-" (Branch= 0 DRAM RAM Bank= 2 RDWR=Write RAS=14316 CAS=0 FATAL Err=0x4 (> Tmid Thermal event with intelligent throttling disabled )) but, now this server running very well. Maybe know the couse of error. Thank you very much before. -- http://mafatahna.web.id

1 0

NoMachine Player on Mac OSX 10.7 and strange characters
by James B. Byrne 05 Nov '12

05 Nov '12

I have a FreeNX server running on a development CentOS-6.3 kvm guest and I have the NoMachine player for OSX installed on my MacBook pro. I can connect to my desktop without problem. However, when I run a terminal session on the remote desktop when I type / I get é displayed and I cannot enter directory paths in consequence. I recall having a similar problem with the VNC remote console in virt-manager and that was caused by virt-manager leaving out the keyboard specification from the graphics entry in /etc/libvirt/qemu/config.xml. However, I cannot discover if a similar configuration setting exists for NoMachine. Does anyone else here use NoMachine player from a Mac and if so have you encountered and solved this problem? If you have then I would appreciate being told how to fix this. -- *** E-Mail is NOT a SECURE channel *** James B. Byrne mailto:ByrneJB@Harte-Lyne.ca Harte & Lyne Limited http://www.harte-lyne.ca 9 Brockley Drive vox: +1 905 561 1241 Hamilton, Ontario fax: +1 905 561 0757 Canada L8E 3C3

1 1

Problem with CLVM (really openais)
by Cris Rhea 04 Nov '12

04 Nov '12

I'm desparately looking for more ideas on how to debug what's going on with our CLVM cluster. Background: 4 node "cluster"-- machines are Dell blades with Dell M6220/M6348 switches. Sole purpose of Cluster Suite tools is to use CLVM against an iSCSI storage array. Machines are running CentOS 5.8 with the Xen kernels. These blades host various VMs for a project. The iSCSI back-end storage hosts the disk images for the VMs. The blades themselves run from local disk. Each blade has 3 active networks: -- Front-end, public net. -- Back-end net (backups, Database connections to external servers, cluster communication) -- iSCSI net Front and Back nets are on Xen Bridges and available/used by the VMs. iSCSI net only used by Dom0/blades. Originally got CLVM working by installing Luci/Ricci. Cluster config is dead-simple: <?xml version="1.0"?> <cluster alias="Alliance Blades" config_version="6" name="Alliance Blades"> <fence_daemon clean_start="0" post_fail_delay="0" post_join_delay="3"/> <clusternodes> <clusternode name="calgb-blade1-mn.mayo.edu" nodeid="1" votes="1"> <fence/> </clusternode> <clusternode name="calgb-blade2-mn.mayo.edu" nodeid="3" votes="1"> <fence/> </clusternode> <clusternode name="calgb-blade3-mn.mayo.edu" nodeid="4" votes="1"> <fence/> </clusternode> <clusternode name="calgb-blade4-mn.mayo.edu" nodeid="2" votes="1"> <fence/> </clusternode> </clusternodes> <cman/> <fencedevices/> <rm> <failoverdomains/> <resources/> </rm> </cluster> All the basics are covered... LVM locking set to "Cluster", etc. This all worked fine for a period (pre 5.8)... at some point, an update took a step backwards. I can bring up the entire cluster and it will work for about 10 minutes. During that time, I'll get the following on several of the nodes: Nov 3 17:28:18 calgb-blade2 openais[7154]: [TOTEM] Retransmit List: fe Nov 3 17:28:49 calgb-blade2 last message repeated 105 times Nov 3 17:29:50 calgb-blade2 last message repeated 154 times Nov 3 17:30:51 calgb-blade2 last message repeated 154 times Nov 3 17:31:52 calgb-blade2 last message repeated 154 times Nov 3 17:32:53 calgb-blade2 last message repeated 154 times Nov 3 17:33:54 calgb-blade2 last message repeated 154 times Nov 3 17:34:55 calgb-blade2 last message repeated 154 times Nov 3 17:35:56 calgb-blade2 last message repeated 154 times Nov 3 17:36:36 calgb-blade2 last message repeated 105 times Nov 3 17:36:36 calgb-blade2 openais[7154]: [TOTEM] Retransmit List: fe ff Nov 3 17:37:07 calgb-blade2 last message repeated 104 times Nov 3 17:38:08 calgb-blade2 last message repeated 154 times Nov 3 17:39:09 calgb-blade2 last message repeated 154 times Nov 3 17:40:10 calgb-blade2 last message repeated 154 times Nov 3 17:41:11 calgb-blade2 last message repeated 154 times Nov 3 17:42:12 calgb-blade2 last message repeated 154 times Nov 3 17:43:13 calgb-blade2 last message repeated 154 times Nov 3 17:44:14 calgb-blade2 last message repeated 154 times Nov 3 17:44:24 calgb-blade2 last message repeated 26 times Around the 10 minute mark, one of the nodes (it is not always the same node) will do: Nov 3 17:44:24 calgb-blade1 openais[7179]: [TOTEM] FAILED TO RECEIVE Nov 3 17:44:24 calgb-blade1 openais[7179]: [TOTEM] entering GATHER state from 6. Nov 3 17:44:34 calgb-blade1 openais[7179]: [TOTEM] Creating commit token because I am the rep. Nov 3 17:44:34 calgb-blade1 openais[7179]: [TOTEM] Storing new sequence id for ring 34 Nov 3 17:44:34 calgb-blade1 openais[7179]: [TOTEM] entering COMMIT state. Nov 3 17:44:34 calgb-blade1 openais[7179]: [TOTEM] entering RECOVERY state. Nov 3 17:44:34 calgb-blade1 openais[7179]: [TOTEM] position [0] member 192.168.226.161: Nov 3 17:44:34 calgb-blade1 openais[7179]: [TOTEM] previous ring seq 48 rep 192.168.226.161 Nov 3 17:44:34 calgb-blade1 openais[7179]: [TOTEM] aru fd high delivered fd received flag 1 Nov 3 17:44:34 calgb-blade1 openais[7179]: [TOTEM] Did not need to originate any messages in recovery. Nov 3 17:44:34 calgb-blade1 openais[7179]: [TOTEM] Sending initial ORF token Nov 3 17:44:34 calgb-blade1 openais[7179]: [CLM ] CLM CONFIGURATION CHANGE Nov 3 17:44:34 calgb-blade1 openais[7179]: [CLM ] New Configuration: Nov 3 17:44:34 calgb-blade1 openais[7179]: [CLM ] r(0) ip(192.168.226.161) Nov 3 17:44:34 calgb-blade1 openais[7179]: [CLM ] Members Left: Nov 3 17:44:34 calgb-blade1 clurgmgrd[9933]: <emerg> #1: Quorum Dissolved Nov 3 17:44:34 calgb-blade1 kernel: dlm: closing connection to node 2 Nov 3 17:44:34 calgb-blade1 openais[7179]: [CLM ] r(0) ip(192.168.226.162) Nov 3 17:44:34 calgb-blade1 kernel: dlm: closing connection to node 3 Nov 3 17:44:34 calgb-blade1 openais[7179]: [CLM ] r(0) ip(192.168.226.163) Nov 3 17:44:34 calgb-blade1 kernel: dlm: closing connection to node 4 Nov 3 17:44:34 calgb-blade1 openais[7179]: [CLM ] r(0) ip(192.168.226.164) Nov 3 17:44:34 calgb-blade1 openais[7179]: [CLM ] Members Joined: Nov 3 17:44:34 calgb-blade1 openais[7179]: [CMAN ] quorum lost, blocking activity Nov 3 17:44:34 calgb-blade1 openais[7179]: [CLM ] CLM CONFIGURATION CHANGE Nov 3 17:44:34 calgb-blade1 openais[7179]: [CLM ] New Configuration: Nov 3 17:44:34 calgb-blade1 openais[7179]: [CLM ] r(0) ip(192.168.226.161) Nov 3 17:44:34 calgb-blade1 openais[7179]: [CLM ] Members Left: Nov 3 17:44:34 calgb-blade1 openais[7179]: [CLM ] Members Joined: Nov 3 17:44:34 calgb-blade1 openais[7179]: [SYNC ] This node is within the primary component and will provide service. Nov 3 17:44:34 calgb-blade1 openais[7179]: [TOTEM] entering OPERATIONAL state. ... When this happens, the node that lost connections kills CMAN. The other 3 nodes get into this state: [root@calgb-blade2 ~]# group_tool type level name id state fence 0 default 00010001 FAIL_START_WAIT [1 2 3] dlm 1 clvmd 00010003 FAIL_ALL_STOPPED [1 2 3 4] dlm 1 rgmanager 00020003 FAIL_ALL_STOPPED [1 2 3 4] One of the nodes will be barking about trying to fence the "failed" node (expected, as I don't have real fencing). Nothing (physically) has actually failed. All 4 blades are running their VMs and accessing the shared back-end storage. No network burps, etc. CLVM is unusable and any LVM commands hang. Here's where it gets really strange..... 1. Go to the blade that has "failed" and shut down all the VMs (just to be safe-- they are all running fine). 2. Go to the node that tried to fence the failed node and run: fence_ack_manual -e -n <failed node> 3. The 3 "surviving" nodes are instantly fine. group_tool reports "none" for state and all CLVM commands work properly. 4. OK, now reboot the "failed" node. It reboots and rejoins the cluster. CLVM commands work, but are slow. Lots of these errors: openais[7154]: [TOTEM] Retransmit List: fe ff 5. This goes on for about 10 minutes and the whole cycle repeats (one of the other nodes will "fail"...) What I've tried: 1. Switches have IGMP snooping disabled. This is a simple config, so no switch-to-switch multicast is needed (all cluster/multicast traffic stays on the blade enclosure switch). I've had the cluster messages use the front-end net and the back-end net (different switch model)-- no change in behavior. 2. Running the latest RH patched openais from their Beta channel: openais-0.80.6-37.el5 (yes, I actually have RH licenses, just prefer CentOS for various reasons). 3. Tested multicast by enabling multicast/ICMP and running multicast pings. Ran with no data loss for > 10 minutes. (IBM Tech web site article-- where the end of the article say it's almost always a network problem.) 4. Tried various configuration changes such as defining two rings. No change (or got worse- the dual ring config triggers a kernel bug). I've read about every article I can find... they usually fall into two camps: 1. Multiple years old, so no idea if it's accurate with today's versions of the software. 2. People trying to do 2-node clusters and wondering why they lose quorum. My feeling is that this is an openais issue-- the ring gets out of sync and can't fix itself. This system needs to go "production" in a matter of weeks, so I'm not sure I want to dive into doing some sort of custom compiled CLVM/Corosync/Pacemaker config. Since this software has been around for years, I believe it's something simple I'm just missing. Thanks for any help/ideas... --- Cris -- Cristopher J. Rhea Mayo Clinic - Research Computing Facility 200 First St SW, Rochester, MN 55905 crhea(a)Mayo.EDU (507) 284-0587

3 2

advice on storage for media storage/streaming server
by Phil Savoie 04 Nov '12

04 Nov '12

Hello, I would like to use centos 6.3 to build a media server with 7 2TB drives and would like suggestions on the storage aspect. This is going to run mediaplex and function only as a media storage/streaming server. 1. If I didn't care about redundancy, would ext4 handle the size of a raid 0? 2. If I did go with the redundancy, what raid level should I use? 3. Should I use LVM? Why? Thank you in advance for your thoughts on this. Phil

2 1

Desktop Switcher
by Mark LaPierre 04 Nov '12

04 Nov '12

Hey Y'all, Does CentOS have a desk top switcher similar to what you find on Fedora? A friend of mine want's to be able to switch between desktops. I've only got Gnome installed on my machine so I don't switch. A search of Google turns up reference to CentOS 4 for desktop switcher but I don't see anything for CentOS 6.3.

8 14

mtrr_gran_size and mtrr_chunk_size
by Earl Ramirez 03 Nov '12

03 Nov '12

Good Day All, Today I looked at the dmesg log and I notice that the following messages regarding mtrr_gran_size/mtrr_chunk_size. I am currently running CentOS 6.3 and I installed CentOS 6.2 and 6.1 and I was seeing the same errors. When I installed CentOS 5.8 on the same laptop I do not see these errors. $ lsb_release -a LSB Version: :core-4.0-amd64:core-4.0-noarch:graphics-4.0-amd64:graphics-4.0-noarch:printing-4.0-amd64:printing-4.0-noarch Distributor ID: CentOS Description: CentOS release 6.3 (Final) Release: 6.3 Codename: Final Below is an excerpt from dmesg BIOS-provided physical RAM map: BIOS-e820: 0000000000000000 - 000000000009e800 (usable) BIOS-e820: 000000000009e800 - 00000000000a0000 (reserved) BIOS-e820: 00000000000e0000 - 0000000000100000 (reserved) BIOS-e820: 0000000000100000 - 0000000020000000 (usable) BIOS-e820: 0000000020000000 - 0000000020200000 (reserved) BIOS-e820: 0000000020200000 - 0000000040000000 (usable) BIOS-e820: 0000000040000000 - 0000000040200000 (reserved) BIOS-e820: 0000000040200000 - 00000000aac0c000 (usable) BIOS-e820: 00000000aac0c000 - 00000000aad8e000 (reserved) BIOS-e820: 00000000aad8e000 - 00000000aad94000 (usable) BIOS-e820: 00000000aad94000 - 00000000aad95000 (reserved) BIOS-e820: 00000000aad95000 - 00000000aad96000 (usable) BIOS-e820: 00000000aad96000 - 00000000aadb8000 (reserved) BIOS-e820: 00000000aadb8000 - 00000000aadc6000 (usable) BIOS-e820: 00000000aadc6000 - 00000000aade8000 (reserved) BIOS-e820: 00000000aade8000 - 00000000aae22000 (usable) BIOS-e820: 00000000aae22000 - 00000000aafe8000 (ACPI NVS) BIOS-e820: 00000000aafe8000 - 00000000aaffd000 (usable) BIOS-e820: 00000000aaffd000 - 00000000ab000000 (ACPI data) BIOS-e820: 00000000ab000000 - 00000000b0000000 (reserved) BIOS-e820: 00000000e0000000 - 00000000e4000000 (reserved) BIOS-e820: 00000000fec00000 - 00000000fec01000 (reserved) BIOS-e820: 00000000fed10000 - 00000000fed14000 (reserved) BIOS-e820: 00000000fed18000 - 00000000fed1a000 (reserved) BIOS-e820: 00000000fed1c000 - 00000000fed20000 (reserved) BIOS-e820: 00000000fee00000 - 00000000fee01000 (reserved) BIOS-e820: 00000000ff980000 - 00000000ffc00000 (reserved) BIOS-e820: 00000000ffd80000 - 0000000100000000 (reserved) BIOS-e820: 0000000100000000 - 000000044f800000 (usable) DMI 2.6 present. SMBIOS version 2.6 @ 0xF0460 DMI: ASUSTeK Computer Inc. N55SL/N55SL, BIOS N55SL.201 11/10/2011 AMI BIOS detected: BIOS may corrupt low RAM, working around it. e820 update range: 0000000000000000 - 0000000000010000 (usable) ==> (reserved) e820 update range: 0000000000000000 - 0000000000001000 (usable) ==> (reserved) e820 remove range: 00000000000a0000 - 0000000000100000 (usable) last_pfn = 0x44f800 max_arch_pfn = 0x400000000 MTRR default type: uncachable MTRR fixed ranges enabled: 00000-9FFFF write-back A0000-BFFFF uncachable C0000-CFFFF write-protect D0000-E7FFF uncachable E8000-FFFFF write-protect MTRR variable ranges enabled: 0 base 000000000 mask C00000000 write-back 1 base 400000000 mask FC0000000 write-back 2 base 440000000 mask FF0000000 write-back 3 base 0C0000000 mask FC0000000 uncachable 4 base 0B0000000 mask FF0000000 uncachable 5 base 0AC000000 mask FFC000000 uncachable 6 base 0AB000000 mask FFF000000 uncachable 7 base 44F800000 mask FFF800000 uncachable 8 disabled 9 disabled x86 PAT enabled: cpu 0, old 0x7040600070406, new 0x7010600070106 original variable MTRRs reg 0, base: 0GB, range: 16GB, type WB reg 1, base: 16GB, range: 1GB, type WB reg 2, base: 17GB, range: 256MB, type WB reg 3, base: 3GB, range: 1GB, type UC reg 4, base: 2816MB, range: 256MB, type UC reg 5, base: 2752MB, range: 64MB, type UC reg 6, base: 2736MB, range: 16MB, type UC reg 7, base: 17656MB, range: 8MB, type UC total RAM covered: 16296M gran_size: 64K chunk_size: 64K num_reg: 10 lose cover RAM: 56M gran_size: 64K chunk_size: 128K num_reg: 10 lose cover RAM: 56M gran_size: 64K chunk_size: 256K num_reg: 10 lose cover RAM: 56M gran_size: 64K chunk_size: 512K num_reg: 10 lose cover RAM: 56M gran_size: 64K chunk_size: 1M num_reg: 10 lose cover RAM: 56M gran_size: 64K chunk_size: 2M num_reg: 10 lose cover RAM: 56M gran_size: 64K chunk_size: 4M num_reg: 10 lose cover RAM: 56M gran_size: 64K chunk_size: 8M num_reg: 10 lose cover RAM: 56M gran_size: 64K chunk_size: 16M num_reg: 10 lose cover RAM: 0G gran_size: 64K chunk_size: 32M num_reg: 10 lose cover RAM: 0G gran_size: 64K chunk_size: 64M num_reg: 10 lose cover RAM: 0G gran_size: 64K chunk_size: 128M num_reg: 10 lose cover RAM: 0G gran_size: 64K chunk_size: 256M num_reg: 10 lose cover RAM: 0G *BAD*gran_size: 64K chunk_size: 512M num_reg: 10 lose cover RAM: -256M *BAD*gran_size: 64K chunk_size: 1G num_reg: 10 lose cover RAM: -512M *BAD*gran_size: 64K chunk_size: 2G num_reg: 10 lose cover RAM: -512M gran_size: 128K chunk_size: 128K num_reg: 10 lose cover RAM: 56M gran_size: 128K chunk_size: 256K num_reg: 10 lose cover RAM: 56M gran_size: 128K chunk_size: 512K num_reg: 10 lose cover RAM: 56M gran_size: 128K chunk_size: 1M num_reg: 10 lose cover RAM: 56M gran_size: 128K chunk_size: 2M num_reg: 10 lose cover RAM: 56M gran_size: 128K chunk_size: 4M num_reg: 10 lose cover RAM: 56M gran_size: 128K chunk_size: 8M num_reg: 10 lose cover RAM: 56M gran_size: 128K chunk_size: 16M num_reg: 10 lose cover RAM: 0G gran_size: 128K chunk_size: 32M num_reg: 10 lose cover RAM: 0G gran_size: 128K chunk_size: 64M num_reg: 10 lose cover RAM: 0G gran_size: 128K chunk_size: 128M num_reg: 10 lose cover RAM: 0G gran_size: 128K chunk_size: 256M num_reg: 10 lose cover RAM: 0G *BAD*gran_size: 128K chunk_size: 512M num_reg: 10 lose cover RAM: -256M *BAD*gran_size: 128K chunk_size: 1G num_reg: 10 lose cover RAM: -512M *BAD*gran_size: 128K chunk_size: 2G num_reg: 10 lose cover RAM: -512M gran_size: 256K chunk_size: 256K num_reg: 10 lose cover RAM: 56M gran_size: 256K chunk_size: 512K num_reg: 10 lose cover RAM: 56M gran_size: 256K chunk_size: 1M num_reg: 10 lose cover RAM: 56M gran_size: 256K chunk_size: 2M num_reg: 10 lose cover RAM: 56M gran_size: 256K chunk_size: 4M num_reg: 10 lose cover RAM: 56M gran_size: 256K chunk_size: 8M num_reg: 10 lose cover RAM: 56M gran_size: 256K chunk_size: 16M num_reg: 10 lose cover RAM: 0G gran_size: 256K chunk_size: 32M num_reg: 10 lose cover RAM: 0G gran_size: 256K chunk_size: 64M num_reg: 10 lose cover RAM: 0G gran_size: 256K chunk_size: 128M num_reg: 10 lose cover RAM: 0G gran_size: 256K chunk_size: 256M num_reg: 10 lose cover RAM: 0G *BAD*gran_size: 256K chunk_size: 512M num_reg: 10 lose cover RAM: -256M *BAD*gran_size: 256K chunk_size: 1G num_reg: 10 lose cover RAM: -512M *BAD*gran_size: 256K chunk_size: 2G num_reg: 10 lose cover RAM: -512M gran_size: 512K chunk_size: 512K num_reg: 10 lose cover RAM: 56M gran_size: 512K chunk_size: 1M num_reg: 10 lose cover RAM: 56M gran_size: 512K chunk_size: 2M num_reg: 10 lose cover RAM: 56M gran_size: 512K chunk_size: 4M num_reg: 10 lose cover RAM: 56M gran_size: 512K chunk_size: 8M num_reg: 10 lose cover RAM: 56M gran_size: 512K chunk_size: 16M num_reg: 10 lose cover RAM: 0G gran_size: 512K chunk_size: 32M num_reg: 10 lose cover RAM: 0G gran_size: 512K chunk_size: 64M num_reg: 10 lose cover RAM: 0G gran_size: 512K chunk_size: 128M num_reg: 10 lose cover RAM: 0G gran_size: 512K chunk_size: 256M num_reg: 10 lose cover RAM: 0G *BAD*gran_size: 512K chunk_size: 512M num_reg: 10 lose cover RAM: -256M *BAD*gran_size: 512K chunk_size: 1G num_reg: 10 lose cover RAM: -512M *BAD*gran_size: 512K chunk_size: 2G num_reg: 10 lose cover RAM: -512M gran_size: 1M chunk_size: 1M num_reg: 10 lose cover RAM: 56M gran_size: 1M chunk_size: 2M num_reg: 10 lose cover RAM: 56M gran_size: 1M chunk_size: 4M num_reg: 10 lose cover RAM: 56M gran_size: 1M chunk_size: 8M num_reg: 10 lose cover RAM: 56M gran_size: 1M chunk_size: 16M num_reg: 10 lose cover RAM: 0G gran_size: 1M chunk_size: 32M num_reg: 10 lose cover RAM: 0G gran_size: 1M chunk_size: 64M num_reg: 10 lose cover RAM: 0G gran_size: 1M chunk_size: 128M num_reg: 10 lose cover RAM: 0G gran_size: 1M chunk_size: 256M num_reg: 10 lose cover RAM: 0G *BAD*gran_size: 1M chunk_size: 512M num_reg: 10 lose cover RAM: -256M *BAD*gran_size: 1M chunk_size: 1G num_reg: 10 lose cover RAM: -512M *BAD*gran_size: 1M chunk_size: 2G num_reg: 10 lose cover RAM: -512M gran_size: 2M chunk_size: 2M num_reg: 10 lose cover RAM: 56M gran_size: 2M chunk_size: 4M num_reg: 10 lose cover RAM: 56M gran_size: 2M chunk_size: 8M num_reg: 10 lose cover RAM: 56M gran_size: 2M chunk_size: 16M num_reg: 10 lose cover RAM: 0G gran_size: 2M chunk_size: 32M num_reg: 10 lose cover RAM: 0G gran_size: 2M chunk_size: 64M num_reg: 10 lose cover RAM: 0G gran_size: 2M chunk_size: 128M num_reg: 10 lose cover RAM: 0G gran_size: 2M chunk_size: 256M num_reg: 10 lose cover RAM: 0G *BAD*gran_size: 2M chunk_size: 512M num_reg: 10 lose cover RAM: -256M *BAD*gran_size: 2M chunk_size: 1G num_reg: 10 lose cover RAM: -512M *BAD*gran_size: 2M chunk_size: 2G num_reg: 10 lose cover RAM: -512M gran_size: 4M chunk_size: 4M num_reg: 10 lose cover RAM: 56M gran_size: 4M chunk_size: 8M num_reg: 10 lose cover RAM: 56M gran_size: 4M chunk_size: 16M num_reg: 10 lose cover RAM: 0G gran_size: 4M chunk_size: 32M num_reg: 10 lose cover RAM: 0G gran_size: 4M chunk_size: 64M num_reg: 10 lose cover RAM: 0G gran_size: 4M chunk_size: 128M num_reg: 10 lose cover RAM: 0G gran_size: 4M chunk_size: 256M num_reg: 10 lose cover RAM: 0G *BAD*gran_size: 4M chunk_size: 512M num_reg: 10 lose cover RAM: -256M *BAD*gran_size: 4M chunk_size: 1G num_reg: 10 lose cover RAM: -512M *BAD*gran_size: 4M chunk_size: 2G num_reg: 10 lose cover RAM: -512M gran_size: 8M chunk_size: 8M num_reg: 10 lose cover RAM: 56M gran_size: 8M chunk_size: 16M num_reg: 10 lose cover RAM: 0G gran_size: 8M chunk_size: 32M num_reg: 10 lose cover RAM: 0G gran_size: 8M chunk_size: 64M num_reg: 10 lose cover RAM: 0G gran_size: 8M chunk_size: 128M num_reg: 10 lose cover RAM: 0G gran_size: 8M chunk_size: 256M num_reg: 10 lose cover RAM: 0G *BAD*gran_size: 8M chunk_size: 512M num_reg: 10 lose cover RAM: -256M *BAD*gran_size: 8M chunk_size: 1G num_reg: 10 lose cover RAM: -512M *BAD*gran_size: 8M chunk_size: 2G num_reg: 10 lose cover RAM: -512M gran_size: 16M chunk_size: 16M num_reg: 10 lose cover RAM: 56M gran_size: 16M chunk_size: 32M num_reg: 10 lose cover RAM: 8M gran_size: 16M chunk_size: 64M num_reg: 10 lose cover RAM: 8M gran_size: 16M chunk_size: 128M num_reg: 10 lose cover RAM: 8M gran_size: 16M chunk_size: 256M num_reg: 10 lose cover RAM: 8M *BAD*gran_size: 16M chunk_size: 512M num_reg: 10 lose cover RAM: -248M *BAD*gran_size: 16M chunk_size: 1G num_reg: 10 lose cover RAM: -504M *BAD*gran_size: 16M chunk_size: 2G num_reg: 10 lose cover RAM: -504M gran_size: 32M chunk_size: 32M num_reg: 10 lose cover RAM: 40M gran_size: 32M chunk_size: 64M num_reg: 10 lose cover RAM: 40M gran_size: 32M chunk_size: 128M num_reg: 10 lose cover RAM: 40M gran_size: 32M chunk_size: 256M num_reg: 10 lose cover RAM: 40M *BAD*gran_size: 32M chunk_size: 512M num_reg: 10 lose cover RAM: -216M *BAD*gran_size: 32M chunk_size: 1G num_reg: 10 lose cover RAM: -472M *BAD*gran_size: 32M chunk_size: 2G num_reg: 10 lose cover RAM: -472M gran_size: 64M chunk_size: 64M num_reg: 8 lose cover RAM: 104M gran_size: 64M chunk_size: 128M num_reg: 8 lose cover RAM: 104M gran_size: 64M chunk_size: 256M num_reg: 9 lose cover RAM: 104M gran_size: 64M chunk_size: 512M num_reg: 10 lose cover RAM: 104M gran_size: 64M chunk_size: 1G num_reg: 10 lose cover RAM: 104M gran_size: 64M chunk_size: 2G num_reg: 10 lose cover RAM: 104M gran_size: 128M chunk_size: 128M num_reg: 7 lose cover RAM: 168M gran_size: 128M chunk_size: 256M num_reg: 9 lose cover RAM: 168M gran_size: 128M chunk_size: 512M num_reg: 10 lose cover RAM: 168M gran_size: 128M chunk_size: 1G num_reg: 10 lose cover RAM: 168M gran_size: 128M chunk_size: 2G num_reg: 10 lose cover RAM: 168M gran_size: 256M chunk_size: 256M num_reg: 5 lose cover RAM: 424M gran_size: 256M chunk_size: 512M num_reg: 5 lose cover RAM: 424M gran_size: 256M chunk_size: 1G num_reg: 6 lose cover RAM: 424M gran_size: 256M chunk_size: 2G num_reg: 7 lose cover RAM: 424M gran_size: 512M chunk_size: 512M num_reg: 5 lose cover RAM: 424M gran_size: 512M chunk_size: 1G num_reg: 6 lose cover RAM: 424M gran_size: 512M chunk_size: 2G num_reg: 7 lose cover RAM: 424M gran_size: 1G chunk_size: 1G num_reg: 4 lose cover RAM: 936M gran_size: 1G chunk_size: 2G num_reg: 5 lose cover RAM: 936M gran_size: 2G chunk_size: 2G num_reg: 3 lose cover RAM: 1960M mtrr_cleanup: can not find optimal value please specify mtrr_gran_size/mtrr_chunk_size e820 update range: 00000000ab000000 - 0000000100000000 (usable) ==> (reserved) last_pfn = 0xaaffd max_arch_pfn = 0x400000000 initial memory mapped : 0 - 20000000 init_memory_mapping: 0000000000000000-00000000aaffd000 0000000000 - 00aae00000 page 2M 00aae00000 - 00aaffd000 page 4k kernel direct mapping tables up to aaffd000 @ 10000-15000 init_memory_mapping: 0000000100000000-000000044f800000 0100000000 - 044f800000 page 2M kernel direct mapping tables up to 44f800000 @ 13000-26000 My Laptop currently has 16GB of RAM and 8GB of swap as indicated below $ cat /proc/meminfo MemTotal: 16235284 kB MemFree: 15024984 kB Buffers: 28128 kB Cached: 412944 kB SwapCached: 134284 kB Active: 404240 kB Inactive: 440124 kB Active(anon): 224792 kB Inactive(anon): 230964 kB Active(file): 179448 kB Inactive(file): 209160 kB Unevictable: 0 kB Mlocked: 0 kB SwapTotal: 8388600 kB SwapFree: 7555824 kB Dirty: 8 kB Writeback: 0 kB AnonPages: 291668 kB Mapped: 45216 kB Shmem: 52452 kB Slab: 120600 kB SReclaimable: 32100 kB SUnreclaim: 88500 kB KernelStack: 4344 kB PageTables: 35824 kB NFS_Unstable: 0 kB Bounce: 0 kB WritebackTmp: 0 kB CommitLimit: 16506240 kB Committed_AS: 3714116 kB VmallocTotal: 34359738367 kB VmallocUsed: 393260 kB VmallocChunk: 34359332704 kB HardwareCorrupted: 0 kB AnonHugePages: 165888 kB HugePages_Total: 0 HugePages_Free: 0 HugePages_Rsvd: 0 HugePages_Surp: 0 Hugepagesize: 2048 kB DirectMap4k: 10228 kB DirectMap2M: 16676864 kB $ cat /proc/swaps Filename Type Size Used Priority /dev/dm-0 partition 8388600 832688 -1 The laptop is running the latest updates and kernel $ uname -r 2.6.32-279.11.1.el6.x86_64 I saw that this was a bug from Fedora 14 and CentOS as well, however it does not appear to be resolved. https://bugzilla.redhat.com/show_bug.cgi?id=584493 http://bugs.centos.org/view.php?id=5659 At random times my laptop will just lock up and I will have to power cycle it, I don't know if this is related. I had CentOS 5.8 installed for over a week and I did not experience this behaviour. Do I need file this as a new bug or is there a solution for this? -- Kind Regards Earl Ramirez

1 0

CentOS-announce Digest, Vol 93, Issue 2
by centos-announce-request＠centos.org 02 Nov '12

02 Nov '12

Send CentOS-announce mailing list submissions to centos-announce(a)centos.org To subscribe or unsubscribe via the World Wide Web, visit http://lists.centos.org/mailman/listinfo/centos-announce or, via email, send a message with subject or body 'help' to centos-announce-request(a)centos.org You can reach the person managing the list at centos-announce-owner(a)centos.org When replying, please edit your Subject line so it is more specific than "Re: Contents of CentOS-announce digest..." Today's Topics: 1. CEBA-2012:1423 CentOS 6 rdma Update (Johnny Hughes) 2. CEBA-2012:1419 CentOS 6 resource-agents Update (Johnny Hughes) 3. CEBA-2012:1422 CentOS 6 glibc Update (Johnny Hughes) ---------------------------------------------------------------------- Message: 1 Date: Thu, 1 Nov 2012 15:00:14 +0000 From: Johnny Hughes <johnny(a)centos.org> Subject: [CentOS-announce] CEBA-2012:1423 CentOS 6 rdma Update To: centos-announce(a)centos.org Message-ID: <20121101150014.GA1874(a)chakra.karan.org> Content-Type: text/plain; charset=us-ascii CentOS Errata and Bugfix Advisory 2012:1423 Upstream details at : https://rhn.redhat.com/errata/RHBA-2012-1423.html The following updated files have been uploaded and are currently syncing to the mirrors: ( sha256sum Filename ) i386: 5d1aba1ef7c1955b55817bee8c0f729ab7f678271acaad23bde36b131862e885 rdma-3.3-4.el6_3.noarch.rpm x86_64: 9202e6046a3cd10c209e9e5136fe0f6eed6488797e76e3a565c8c327b00954f0 rdma-3.3-4.el6_3.noarch.rpm Source: 4b2f2be4923c56d5a9931fc5174ca89f2d67305c26af1523d35a0393bf74174d rdma-3.3-4.el6_3.src.rpm -- Johnny Hughes CentOS Project { http://www.centos.org/ } irc: hughesjr, #centos(a)irc.freenode.net ------------------------------ Message: 2 Date: Thu, 1 Nov 2012 15:00:28 +0000 From: Johnny Hughes <johnny(a)centos.org> Subject: [CentOS-announce] CEBA-2012:1419 CentOS 6 resource-agents Update To: centos-announce(a)centos.org Message-ID: <20121101150028.GA1929(a)chakra.karan.org> Content-Type: text/plain; charset=us-ascii CentOS Errata and Bugfix Advisory 2012:1419 Upstream details at : https://rhn.redhat.com/errata/RHBA-2012-1419.html The following updated files have been uploaded and are currently syncing to the mirrors: ( sha256sum Filename ) i386: ce3b345406447e518e872d164628349d9787efff33c49188e4db26c48ecaa4c8 resource-agents-3.9.2-12.el6_3.1.i686.rpm x86_64: a722145da540668af3770993d462f51720c3c878349f5b7a9324e63ed174ba23 resource-agents-3.9.2-12.el6_3.1.x86_64.rpm Source: 8be6f4edc4ba0718f6b54393fc173ee59630d7b4bbe01ce64dd4835f5bf8c072 resource-agents-3.9.2-12.el6_3.1.src.rpm -- Johnny Hughes CentOS Project { http://www.centos.org/ } irc: hughesjr, #centos(a)irc.freenode.net ------------------------------ Message: 3 Date: Thu, 1 Nov 2012 15:00:55 +0000 From: Johnny Hughes <johnny(a)centos.org> Subject: [CentOS-announce] CEBA-2012:1422 CentOS 6 glibc Update To: centos-announce(a)centos.org Message-ID: <20121101150055.GA2054(a)chakra.karan.org> Content-Type: text/plain; charset=us-ascii CentOS Errata and Bugfix Advisory 2012:1422 Upstream details at : https://rhn.redhat.com/errata/RHBA-2012-1422.html The following updated files have been uploaded and are currently syncing to the mirrors: ( sha256sum Filename ) i386: 457313a59d63eb2906589ab9e14e67996c44c0e5fcf77020e6d2c3b5625da26d glibc-2.12-1.80.el6_3.6.i686.rpm d69a18a8a0b325a16817b08d3bc50ed2623a51c4ecd482ab1055a58692dca888 glibc-common-2.12-1.80.el6_3.6.i686.rpm 1356817ed8af3bcaaf21122c00aaa2618cbb4093bb8c3fa14e2a1bee7e9a1afe glibc-devel-2.12-1.80.el6_3.6.i686.rpm 34c7a6d6dcc3e41f9877316cc3b395a66540f97bd68e742272706cb5e9def994 glibc-headers-2.12-1.80.el6_3.6.i686.rpm 7e11593a2a7a15853f4a3d57ed65c8821fc03543b6d5762dbfe1af45cdc00a35 glibc-static-2.12-1.80.el6_3.6.i686.rpm d7dd6f230e8fa3a60d35824f01c9ae384801cd682f06375ee34c33290cfad375 glibc-utils-2.12-1.80.el6_3.6.i686.rpm dc13da609d397533da365f1cc12fba37504a081309cf60d1f9cd2347876e26fc nscd-2.12-1.80.el6_3.6.i686.rpm x86_64: 457313a59d63eb2906589ab9e14e67996c44c0e5fcf77020e6d2c3b5625da26d glibc-2.12-1.80.el6_3.6.i686.rpm 68d5bd49bb92baeceb3ed8fe19300465bdc24cea00229f3269b00d4007c20748 glibc-2.12-1.80.el6_3.6.x86_64.rpm 106d25052ae0b2d264ed014a6dde2254da379702654047d164179edbcc1a20ff glibc-common-2.12-1.80.el6_3.6.x86_64.rpm 1356817ed8af3bcaaf21122c00aaa2618cbb4093bb8c3fa14e2a1bee7e9a1afe glibc-devel-2.12-1.80.el6_3.6.i686.rpm 85616b4c31190208b288798019b3920c1fa2782d60aeb46c5ae37904f5cd912d glibc-devel-2.12-1.80.el6_3.6.x86_64.rpm 63aea1c0f19fba720d20db6ee983adccff8eab0738fab3c2429d29dbfbf27e92 glibc-headers-2.12-1.80.el6_3.6.x86_64.rpm 7e11593a2a7a15853f4a3d57ed65c8821fc03543b6d5762dbfe1af45cdc00a35 glibc-static-2.12-1.80.el6_3.6.i686.rpm 44f9dc44ccfdddd391c821f3fec25685cb926c47db710a0f8ba9e9e0e3a6602b glibc-static-2.12-1.80.el6_3.6.x86_64.rpm 7b61bab183ba95c8c100f82b73744b97805e4d9d4280703b5a14e647c9c088c0 glibc-utils-2.12-1.80.el6_3.6.x86_64.rpm 882f7c5e39743082e8856acbb7d112db0c74e07697922502f2f43fbac03331eb nscd-2.12-1.80.el6_3.6.x86_64.rpm Source: a842f956739aa225dabc1a26a86397f6e23dca47a42ad44bc44584ff6b464409 glibc-2.12-1.80.el6_3.6.src.rpm -- Johnny Hughes CentOS Project { http://www.centos.org/ } irc: hughesjr, #centos(a)irc.freenode.net ------------------------------ _______________________________________________ CentOS-announce mailing list CentOS-announce(a)centos.org http://lists.centos.org/mailman/listinfo/centos-announce End of CentOS-announce Digest, Vol 93, Issue 2 **********************************************

1 0

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

Discuss