Как вызвать тестовый катастрофический отказ с kdump?

После установки linux-crashdump и kdump-tools согласно https://wiki.ubuntu.com/Kernel/CrashdumpRecipe и конфигурирование последнего так, чтобы cat /sys/kernel/kexec_crash_loaded печать 1, Я испытываю затруднения при порождении тестового катастрофического отказа с

echo 1 | sudo tee /proc/sys/kernel/sysrq
echo c | sudo tee /proc/sysrq-trigger

Системные замораживания и графические ошибки происходят в единице, но затем ничего не происходит в течение 10 минут (статья Wiki, на которую ссылаются выше состояний, которые там "должны быть некоторой задержкой" в зависимости от памяти (16 ГБ в моем случае), но это не может быть таким длинным, правильно?!). Я ожидаю перезагрузку и создание дампа в /var/crash.

Есть ли другие утверждения, которые должны быть проверены, кроме того, cat /sys/kernel/kexec_crash_loaded? Я протестировал с 3.17-rc6 и 3.16.0-18-универсальным на Ubuntu, 14.10-beta1 и 3.13.0-36-универсальной на Ubuntu 14.04.1.

Infos:

$ uname -a
Linux richter-lenovo-IdeaPad-Z500 3.17.0-031700rc6-generic #201409211935 SMP Sun Sep 21 23:37:11 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux
$ cat /etc/default/kdump-tools | grep -Ev '(#.*$)|(^$)'
USE_KDUMP=1
KDUMP_COREDIR="/var/crash"

Следующее присутствует в /var/crash/, но это, кажется, не результат crashdump, по-моему (помимо того, что перезапуск не работает):

$ ls /var/crash/
kexec_cmd                              _usr_bin_gnome-tweak-tool.1000.uploaded
nvidia-331.0.crash                     _usr_bin_meld.0.crash
nvidia-343.0.crash                     _usr_bin_nautilus.1000.crash
_usr_bin_gnome-tweak-tool.1000.crash   _usr_bin_update-manager.1000.crash
_usr_bin_gnome-tweak-tool.1000.upload  _usr_share_apport_apport-gtk.0.crash
$ cat /var/crash/kexec_cmd
/sbin/kexec -p --command-line="BOOT_IMAGE=/boot/vmlinuz-3.17.0-031700rc6-generic root=UUID=c5aaeaf4-f555-45ff-a4f8-185a3aeac543 ro quiet splash irqpoll maxcpus=1 nousb" --initrd=/boot/initrd.img-3.17.0-031700rc6-generic /boot/vmlinuz-3.17.0-031700rc6-generic
1
задан 28 September 2014 в 03:06

2 ответа

У меня также была эта проблема, я просто понимаю это.

Вот то, что я сделал:

Используйте Kdump и ядро, которое Вы создаете, при создании ядра, передаете аргумент

"deb-pkg" (человечность), чтобы 'сделать', который означает, "делают-jN deb-pkg",

затем установите пакеты и kdump (linux-crashdump),

0
ответ дан 6 October 2019 в 15:11

замораживание обычно указывает, что неподходящая зарезервированная память пытается увеличить его 128M за один раз

, Ваш crashkernel параметр в конфигурации личинки был бы похож на это:

увеличение 384M-:256M

256M постепенно

0
ответ дан 7 October 2019 в 01:11

Другие вопросы по тегам:

Похожие вопросы: