2017-01-30 18 views
2

Мой дочерний процесс пытается получить доступ к адресному пространству PCI. Он отлично работает в большинстве случаев.Ребенок-процесс не генерирует ядро ​​ТОЛЬКО для ошибки SIGBUS и стал процессом Zombie

Но иногда детский процесс переходит в состояние зомби. Журналы dmesg показывают следующую ошибку шины.

[ 501.134156] Caused by (from MCSR=10008): Bus - Read Data Bus Error 
[ 501.134169] Oops: Machine check, sig: 7 [#1] 

В этом случае нет файла ядра.

[Linux:/]$ ps -axl | grep tes1 
4  0 6805 32495 20 0  0  0 exit Zl ? 0:05 [test1] <defunct> 
[Linux:/]$ 

Ядро генерируется для ошибки SIGSEGV дочерним процессом. Поэтому я предполагаю, что это не имеет никакого отношения к настройкам разрешения/ulimit.

Может кто-нибудь помочь мне понять, почему ядро ​​не генерируется в этом случае?

Child Process: 
-------------- 

[Linux:/]$ cat /proc/6805/status 
Name: test1 
State: Z (zombie) 
Tgid: 6805 
Pid: 6805 
PPid: 32495 
TracerPid: 0 
Uid: 0 0 0 0 
Gid: 0 0 0 0 
FDSize: 0 
Groups: 
Threads: 2 
SigQ: 18/13007 
SigPnd: 0000000002000000 
ShdPnd: 0000000000000000 
SigBlk: 0000000000000000 
SigIgn: 0000000000001006 
SigCgt: 0000000182000200 
CapInh: 0000000000000000 
CapPrm: 0000001fffffffff 
CapEff: 0000001fffffffff 
CapBnd: 0000001fffffffff 
Seccomp: 0 
Cpus_allowed: 3 
Cpus_allowed_list: 0-1 
voluntary_ctxt_switches: 8998 
nonvoluntary_ctxt_switches: 857 

    Stack: 
    ------- 

[Linux:/]$ cat /proc/6805/stack 
[<00000000>] (nil) 
[<c0008640>] __switch_to+0xc0/0x160 
[<c004b4f4>] do_exit+0x5d4/0xa70 
[<c000c694>] die+0x224/0x310 
[<c000ce44>] machine_check_exception+0x124/0x1e0 
[<c00123bc>] ret_from_mcheck_exc+0x0/0x14c 
[Linux:/]$ 


Parent Process: 
--------------- 
[Linux:/]$ cat /proc/32495/status 
Name: test 
State: S (sleeping) 
Tgid: 32495 
Pid: 32495 
PPid: 21911 
TracerPid: 0 
Uid: 0 0 0 0 
Gid: 0 0 0 0 
FDSize: 256 
Groups: 
VmPeak:  4820 kB 
VmSize:  4820 kB 
VmLck:   0 kB 
VmPin:   0 kB 
VmHWM:  2548 kB 
VmRSS:  2548 kB 
VmData:  1284 kB 
VmStk:  132 kB 
VmExe:  900 kB 
VmLib:  1976 kB 
VmPTE:  24 kB 
VmSwap:  0 kB 
Threads: 1 
SigQ: 19/13007 
SigPnd: 0000000000000000 
ShdPnd: 0000000000000000 
SigBlk: 0000000000010000 
SigIgn: 0000000000001006 
SigCgt: 0000000043816ef9 
CapInh: 0000000000000000 
CapPrm: 0000001fffffffff 
CapEff: 0000001fffffffff 
CapBnd: 0000001fffffffff 
Seccomp: 0 
Cpus_allowed: 3 
Cpus_allowed_list: 0-1 
voluntary_ctxt_switches: 274 
nonvoluntary_ctxt_switches: 145 
[Linux:/]$ 
+0

Я предполагаю, что вы проверили свой код, чтобы узнать, намеренно ли вы случайно вышли из-за ошибки чтения. Предполагая, что родитель все еще жив, можете ли вы ждать ребенка и прочитать статус выхода и код возврата? – Ram

+0

Родительский процесс - это файл сценария оболочки, который запускает дочерний процесс и ждет его PID. –

+0

Родительский процесс не знает о сбое SIGBUS ребенка и все еще ждет его PID. Детский процесс получает SIGBUS, когда он пытается прочитать из одного из регистров устройства PCI. Я не выхожу из этого дочернего процесса, и он переходит в состояние зомби, как только произойдет сбой чтения. –

ответ

0

Я понимаю, что аппаратное обеспечение PCI, которое имеет mmaped, не отвечает. Поэтому уместно, чтобы только ядро ​​справлялось с ошибкой.

Ошибка не будет распространяться на уровне пользователя, поскольку это не ошибка программного обеспечения. Итак, мы не получаем дамп ядра (ядро или пользовательское пространство), так как это не сбой программного обеспечения.

Обработчик ошибок проверки машины в ядре сообщает, что произошло с аппаратным сбоем, и какой адрес/данные релевантны (в зависимости от причины). Необходимость дальнейшего изучения с точки зрения аппаратного обеспечения.