CONFIG_PROFILING on production system

Is there a reason why I would not want to run a production system with CONFIG_PROFILING enabled? I am wondering if there are any reasons associated with performance, stability or security that I should worry about when CONFIG_PROFILING is enabled. Thanks, Cam - To unsubscribe from this

CONFIG_PROFILING on production system

Is there a reason why I would not want to run a production system with CONFIG_PROFILING enabled? I am wondering if there are any reasons associated with performance, stability or security that I should worry about when CONFIG_PROFILING is enabled. Thanks, Cam - To unsubscribe from this

Re: Kernel assertion (BUG) on 2.6.20-1-2316 FC5

Cameron Schaus wrote: I am seeing the following kernel assertion (BUG) trip whenever I run a set of RPM commands. It is 100% reproducible, and occurs on a machine running vmware. The kernel is a FC5 2.6.20-1-2316 kernel recompiled to disable CONFIG_DEBUG_SPINLOCK

Re: Kernel assertion (BUG) on 2.6.20-1-2316 FC5

Cameron Schaus wrote: I am seeing the following kernel assertion (BUG) trip whenever I run a set of RPM commands. It is 100% reproducible, and occurs on a machine running vmware. The kernel is a FC5 2.6.20-1-2316 kernel recompiled to disable CONFIG_DEBUG_SPINLOCK

Kernel assertion (BUG) on 2.6.20-1-2316 FC5

Hello All, I am seeing the following kernel assertion (BUG) trip whenever I run a set of RPM commands. It is 100% reproducible, and occurs on a machine running vmware. The kernel is a FC5 2.6.20-1-2316 kernel recompiled to disable CONFIG_DEBUG_SPINLOCK and CONFIG_DEBUG_SPINLOCK_SLEEP. Is this

Re: Kernel Oops on 2.6.18-1.2869.fc6 is this a bug?

Michal Piotrowski wrote: You need to upgrade the kernel "yum upgrade kernel.i686" If the problem still appears, fill bug report in RedHat bugzilla https://bugzilla.redhat.com/bugzilla/index.cgi I am seeing this problem in the FC5 2.6.20-1-2316 kernel, and I have not seen a new kernel show up

Re: Kernel Oops on 2.6.18-1.2869.fc6 is this a bug?

Michal Piotrowski wrote: You need to upgrade the kernel yum upgrade kernel.i686 If the problem still appears, fill bug report in RedHat bugzilla https://bugzilla.redhat.com/bugzilla/index.cgi I am seeing this problem in the FC5 2.6.20-1-2316 kernel, and I have not seen a new kernel show up in

Kernel assertion (BUG) on 2.6.20-1-2316 FC5

Hello All, I am seeing the following kernel assertion (BUG) trip whenever I run a set of RPM commands. It is 100% reproducible, and occurs on a machine running vmware. The kernel is a FC5 2.6.20-1-2316 kernel recompiled to disable CONFIG_DEBUG_SPINLOCK and CONFIG_DEBUG_SPINLOCK_SLEEP. Is this

Re: 2.6.20 OOM with 8Gb RAM

Andrew Morton wrote: All of ZONE_NORMAL got used by ramdisk, and networking wants to allocate a page from ZONE_NORMAL. An oom-killing is the correct response, although probably not effective. ramdisk is a nasty thing - cannot you use ramfs or tmpfs? Sure enough, changing the ramdisk to a

2.6.20 OOM with 8Gb RAM

I am running the latest FC5-i686-smp kernel, 2.6.20, on a machine with 8Gb of RAM, and 2 Xeon processors. The system has a 750Mb ramdisk, and one process allocating and deallocating memory that is also writing lots of files to the ramdisk. The process also reads and writes from the network.

2.6.20 OOM with 8Gb RAM

I am running the latest FC5-i686-smp kernel, 2.6.20, on a machine with 8Gb of RAM, and 2 Xeon processors. The system has a 750Mb ramdisk, and one process allocating and deallocating memory that is also writing lots of files to the ramdisk. The process also reads and writes from the network.

Re: 2.6.20 OOM with 8Gb RAM

Andrew Morton wrote: All of ZONE_NORMAL got used by ramdisk, and networking wants to allocate a page from ZONE_NORMAL. An oom-killing is the correct response, although probably not effective. ramdisk is a nasty thing - cannot you use ramfs or tmpfs? Sure enough, changing the ramdisk to a