Difference between revisions of "Process got signal 8"

From BOINC Wiki
(removing box)
(removing broken link to original faq)
 
(One intermediate revision by the same user not shown)
Line 47: Line 47:
  
 
;Fix<br>
 
;Fix<br>
Recently this bug was fixed in the Kernel. You will need a kernel of 2.6.25.6 or higher for this fix.
+
Recently this bug was fixed in the Kernel. You will need a kernel of 2.6.25.6 or higher for this fix.  
 +
 
 +
 
 +
{| class="wikitable" style="text-align: center;"
 +
! Original writer
 +
! Original FAQ
 +
! Date
 +
|-
 +
| Jorden
 +
| 377
 +
| 06-06-2008
 +
|-
 +
|}

Latest revision as of 20:54, 16 August 2017

When you're running into constant signal 8 / error 38 problems with a project and your operating system is Linux with a Kernel version of between 2.6.20 and 2.6.27, then read on.

The problem is that the Kernel is compiled with CONFIG_PREEMPT=Y while it should be =N
The CONFIG_PREEMPT option preempts any running task in memory, by permitting a low priority process to be preempted involuntarily even if it is in kernel mode executing a system call and would otherwise not be about to reach a natural preemption point. This wrecks the FPU stack, which in return gives you a signal 8 error outcome.

To check what the status of CONFIG_PREEMPT is in your Kernel, check the .config file in the /usr/src/linux directory, or similar directory, so do: grep PREEMPT /usr/src/linux/.config

Or using /proc/config.gz do:

cat /proc/config.gz | gunzip - | grep PREEMPT

You'll get a list of PREEMPT options, the ones that your Kernel can do and which ones are set.
You'll have to make sure that CONFIG_PREEMPT isn't set to Yes, but preferably that PREEMPT_VOLUNTARY is set.
You can do this by recompiling your kernel. The how and what on that depends on your distro and your skill to roam around in Linux.

There are also runtime /proc/sys knobs and boot-time flags to turn voluntary preemption (CONFIG_VOLUNTARY_PREEMPT) and kernel preemption (CONFIG_PREEMPT) on/off:

# turn on/off voluntary preemption (if CONFIG_VOLUNTARY_PREEMPT)
echo 1 > /proc/sys/kernel/voluntary_preemption
echo 0 > /proc/sys/kernel/voluntary_preemption
# turn on/off the preemptible kernel feature (if CONFIG_PREEMPT)
/proc/sys/kernel/kernel_preemption
/proc/sys/kernel/kernel_preemption

The 'voluntary-preemption=0/1' and 'kernel-preemption=0/1' boot options can be used to control these flags at boot-time.

Not all distros allow for the latter use of startup flags, though.

PREEMPT options and what they do:

PREEMPT_NONE No forced preemption (server)
This is the traditional Linux preemption model, geared toward maximizing throughput. It still provides good latency most of the time, occasional longer delays are possible.
Select this option if you are building a kernel for a server or scientific/computation system, or if you want to maximize the raw processing power of the kernel, irrespective of scheduling latencies.
PREEMPT_VOLUNTARY Voluntary kernel preemption (desktop)
This option reduces the latency of the kernel by adding more "explicit preemption points" to the kernel code. These new preemption points have been selected to reduce the maximum latency of rescheduling, which provides faster response to applications at the cost of slighly lower throughput.
This option speeds up reaction to interactive events by allowing a low-priority process to voluntarily preempt itself even if it is in kernel mode executing a system call. This allows applications to appear to run more smoothly even when the system is under load.
Select this if you are building a kernel for a desktop system.
PREEMPT Preemptible kernel (low-latency desktop)
This option reduces the latency of the kernel by making all kernel code (except code executing in a critical section) preemptible. This allows reaction to interactive events by permitting a low priority process to be preempted involuntarily even if it is in kernel mode executing a system call and would otherwise not be about to reach a natural preemption point. This allows applications to appear to run more smoothly even when the system is under load, at the cost of slightly lower throughput and a slight runtime overhead to kernel code.
Select this if you are building a kernel for a desktop or embedded system with latency requirements in the milliseconds range.
Fix

Recently this bug was fixed in the Kernel. You will need a kernel of 2.6.25.6 or higher for this fix.


Original writer Original FAQ Date
Jorden 377 06-06-2008