Until Red Hat Enterprise Linux 2.1 there was a limitation on the partition size of 2GB for each swap space. This was due to the mkswap command not supporting creation of a swap partition larger than 2GB. If the system requires more than 2GB of swap space, work around this limitation by creating multiple swap partitions.

In Red Hat Enterprise Linux 3 and above, the mkswap command allows the creation of a swap partition of a larger size than 2GB.

To summarize:

Red Hat Enterprise Linux 2.1 supports upto 32 swap partitions, each can be a maximum size of 2GB. Maximum total swap size is 64GB.

Red Hat Enterprise Linux 3 and higher supports larger swap partitions, each can be of maximum size set by the file size limit and the block device limit for swap partitions on that platform. Red Hat Enterprise Linux 3 has a 1TB limitation as maximum size of block devices, so it’s 1TB.

While larger swap partitions are permitted, one large swap partition could affect system performance. For better performance it is recommended to split swap space to multiple discs. Separating swap partitions to different disk could reduce the load on a single disk.

Red Hat is working to update this information in the installation guide.

Losing some ticks… checking if CPU frequency changed.
Losing some ticks… checking if CPU frequency changed.
Losing some ticks… checking if CPU frequency changed.

You can simply ignore this while you are using normal applications.If you are running some mission critical application or testing some development activities …then,

 Actually this is a bug in Linux, RedHat stating that the SMP-Kernel speeds up system clock under network load. check https://bugzilla.redhat.com/show_bug.cgi?id=55223

i got a suggestion like,

its due to poor ACPI implementation for CPU throttling. Change the clock source by changing your kernel boot options to clock=pmtmr or clock=pit

Disable Dynamic overclocking @BIOS

I hope this bug has been reseolved in kernel 2.6.21,

http://git.kernel.org/?p=linux%2Fkernel%2Fgit%2Ftorvalds%2Flinux-2.6.git&a=search&h=v2.6.21-rc1&st=commit&s=ticks

But for me,

Before upgrade my kernel from 2.6.9 or try other options,We corrected our application.

Backup the data is one of the administrative task, and its a nice one also. (we don’t know the value of things until we miss that), Backup will be very useful and sometimes it will help us greatly.

Here lets see about the Backup of mail, addresses and appointments from Evolution (a GNOME mail client tool)

I found that there is no built in provisions for taking backup or export the settings. and Evolution uses a mbox file format. So we can save messages to files.

Evolution’s default directory is .evolution (a hidden directory in your home folder) , if you logged and using as a user called ravi, then the evolution’s directory is /home/ravi/.evolution, within this directory,it’ll maintain the separate folder for mail, calender, task and all of the different functions.

If you want to take a backup of your local inbox, that’ll be in the /mail/local/Inbox under the .evolution directory. or you can backup the whole .evolution directory.(copy in to somewhere) before that, Stop Evolution (if it is running).

Later you can import the files ( mail, address book, etc.) in to some other mail client like Outlook express (Windows), KMail (KDE), Thunderbird (Mozilla).

If you have a habit of taking a backup in regular basis, you wont be get afraid of a system crash or some other problems. You can safely get back everything as it is. Enjoy

To avoid user shutdown and reboot from the Action menu, the gdm screen, or from consoles, follow these tips:

* To prevent these actions from occurring through the Action menu, run the gconf-editor program on the GNOME desktop, and check off the entry for /apps/gnome-session/options/logout_prompt.

* To prevent these actions from occurring at the gdm screen, edit the /etc/X11/gdm/gdm.conf file, and set the SystemMenu directive to false.

* To prevent these actions from occurring at the console, rename the reboot, poweroff, and halt files under the /etc/security/console.apps/ directory.
In the directory /etc/security/console.apps/, delete the files reboot, poweroff, and halt.
Remove the file /usr/bin/poweroff.

* In the file /etc/inittab, change the line that reads:

ca::ctrlaltdel:/sbin/shutdown -t3 -r now
to
ca::ctrlaltdel:echo (A message indicating rebooting is not possible)

a Test post…