Предлагаю включить в конфиг ядра две-три опции:
Первая - CONFIG_PRINTK_TIME, расположение:
Kernel hacking --->
[*] Show timing information on printks
заставляет добавлять тайминги в лог событий ядра, пример:
# dmesg |tail
[ 22.374958] lo: Disabled Privacy Extensions
[ 23.114078] fbcondecor: console 0 using theme 'tty1'
[ 23.139182] fbcondecor: switched decor state to 'on' on console 0
[ 33.278013] eth0: no IPv6 routers present
[27882.493528] aufs test_add:213:mount[17102]: unsupported filesystem, / (aufs)
[28414.139135] aufs test_add:207:mount[17224]: / must be outside
[28593.933713] aufs test_add:213:mount[17446]: unsupported filesystem, / (aufs)
[29888.840657] aufs may_rename_srcdir:487:mv[18089]: renaming dir who has child(ren) on multiple branches, is not supported
[30529.538281] aufs test_add:207:mount[18205]: / must be outside
[39268.136409] aufs test_add:213:mount[21611]: unsupported filesystem, / (aufs)
Кстати, об этом я уже писал тут
Второе: однажды столкнулся с такой ситуацией - кривой драйвер WiFi своими событиями сразу же забивал все тот же лог ядра.
С тех пор я всегда поднимаю размер буфера лога ядра до максимума:
вместо CONFIG_LOG_BUF_SHIFT=15 (что равняется 32KB)
CONFIG_LOG_BUF_SHIFT=21 (что соответственно 2MB)
General setup --->
(21) Kernel log buffer size (16 => 64KB, 17 => 128KB)
2 MB - это максимум что разрешает конфиг ядра, возможно можно и больше, но надо лазить в сорц, у меня пока такой необходимости не возникало. Но думаю 2 МБ памяти для dmesg не жалко, если это может помочь локализовать проблему.
И третья опция которую я бы добавил в ядро, это CONFIG_CC_STACKPROTECTOR=y расположение:
Processor type and features --->
[*] Enable -fstack-protector buffer overflow detection (EXPERIMENTAL)
Не смотря на статус (EXPERIMENTAL) - у меня с этим пунктом проблем никогда не возникало. А жить с этим ключиком немного спокойнее.
Если верить документации - этот ключ указывает GCC собирать ядро с ключем -fstack-protector
Предлагаю желающим самостоятельно почитать про этот ключ в конфигураторе ядра, а также в документации к gcc
man gcc
Из того что я понял (а по английски я понимаю не так хорошо) - получается, что защита от buffer overflow реализуется добавлением ключа в стек. И при атаке переполнением этот ключ затирается другим значением, чем вызывает kernel panic
Конечно кернел паник - ситуация неприятная.
НО вопервых - можно среди опций ядра передать параметр:
panic=<время_в_секундах_через_которое_послеkernel_panic_система_ребутнется>.
А во вторых - это лучше чем скомпрометировать систему
Кстати, это же время можно задать/изменить и в уже запущенной системе записав значение в /proc/sys/kernel/panic