The OpenNET Project / Index page

[ новости /+++ | форум | wiki | теги | ]

форумы  помощь  поиск  регистрация  майллист  вход/выход  слежка  RSS
"FreeBSD kernel Panic "
Вариант для распечатки  
Пред. тема | След. тема 
Форум Открытые системы на сервере (Ядро / FreeBSD)
Изначальное сообщение [ Отслеживать ]

"FreeBSD kernel Panic "  +/
Сообщение от pevl email on 14-Ноя-13, 14:51 
Доброго времени суток !

Проблема заключается в в произвольной перезагрузке OC

FreeBSD 9.1-Release arch amd64

+panic: bad pte
+cpuid = 0
+KDB: stack backtrace:
+#0 0xffffffff808c80f6 at kdb_backtrace+0x66
+#1 0xffffffff8089201e at panic+0x1ce
+#2 0xffffffff80bbdcf8 at pmap_remove_pages+0x3a8
+#3 0xffffffff80b37257 at vmspace_exit+0x157
+#4 0xffffffff8085d599 at exit1+0x379
+#5 0xffffffff8085e46e at sys_sys_exit+0xe
+#6 0xffffffff80bc57f6 at amd64_syscall+0x546
+#7 0xffffffff80bb1157 at Xfast_syscall+0xf7
+Uptime: 8d6h24m54s

P.S. Тест RAM производился , ошибок не обнаружено

Ответить | Правка | Cообщить модератору

Оглавление

Сообщения по теме [Сортировка по времени | RSS]


1. "FreeBSD kernel Panic "  +/
Сообщение от Hammer (ok) on 21-Ноя-13, 06:01 
> +Uptime: 8d6h24m54s

То есть 8 суток работал, а потом в панику! 0|0
> P.S. Тест RAM производился , ошибок не обнаружено

Есть настойчивые подозрения, что он у Вас тупо перегрелся.

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

2. "FreeBSD kernel Panic "  +/
Сообщение от Pahanivo (ok) on 21-Ноя-13, 07:51 
>> +Uptime: 8d6h24m54s
> То есть 8 суток работал, а потом в панику! 0|0
>> P.S. Тест RAM производился , ошибок не обнаружено
> Есть настойчивые подозрения, что он у Вас тупо перегрелся.

смотреть железо: память/перегрев/винты

Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

3. "FreeBSD kernel Panic "  +/
Сообщение от lavr email on 21-Ноя-13, 11:18 
>[оверквотинг удален]
> +#0 0xffffffff808c80f6 at kdb_backtrace+0x66
> +#1 0xffffffff8089201e at panic+0x1ce
> +#2 0xffffffff80bbdcf8 at pmap_remove_pages+0x3a8
> +#3 0xffffffff80b37257 at vmspace_exit+0x157
> +#4 0xffffffff8085d599 at exit1+0x379
> +#5 0xffffffff8085e46e at sys_sys_exit+0xe
> +#6 0xffffffff80bc57f6 at amd64_syscall+0x546
> +#7 0xffffffff80bb1157 at Xfast_syscall+0xf7
> +Uptime: 8d6h24m54s
> P.S. Тест RAM производился , ошибок не обнаружено

попробуйте почитать:

http://lists.freebsd.org/pipermail/freebsd-bugs/2013-March/0...

глобально там два предположения:
- ошибки памяти (pmap.c) которые, кроме soft'овых могут быть связаны с ошибками железа
- разрушены данные на zfs (кстати после перевода на UFS в верхнем обсуждении -
проблема решилась и для ZFS там тоже были патчи)

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

4. "FreeBSD kernel Panic "  +/
Сообщение от an0 on 01-Дек-13, 11:39 
> - разрушены данные на zfs (кстати после перевода на UFS в верхнем
> обсуждении -
> проблема решилась и для ZFS там тоже были патчи)

Вопрос не совсем по теме, помнится в каком-то топике вы настоятельно не советовали использовать UFS с SU и J одновременно.
Если я не собираются использовать dump/restore (проблемы вроде с этим остались), то можно? Как можно добиться проявления проблем?
Дело в том что собираюсь использовать UFS SU+J на сравнительно старых машинках, куда будет установлена x86 версия FreeBSD. На данный момент никаких проблем так и не увидел под VirtualBox. Виртуальная машина была несколько дней нагружена - тут и закачка/обновление портов с исходниками (ZFS тут падала, какие бы я параметры не прикручивал, на amd64 - все ок), сборка из исходников всех необходимых портов, включая тяжелые вроде KDE4, openoffice и libreoffice.
И никаких проблем.


Ответить | Правка | ^ к родителю #3 | Наверх | Cообщить модератору

5. "FreeBSD kernel Panic "  +/
Сообщение от an0 on 01-Дек-13, 11:43 
Собственно вопрос возник т.к. инсталятор 9.2 использует журналирование для созданных ФС. Получается что уже достаточно надежно?


Ответить | Правка | ^ к родителю #4 | Наверх | Cообщить модератору

6. "FreeBSD kernel Panic "  +/
Сообщение от lavr email on 01-Дек-13, 14:58 
> Собственно вопрос возник т.к. инсталятор 9.2 использует журналирование для созданных ФС.
> Получается что уже достаточно надежно?

инсталлер - не показатель, SUJ by default был и в 9.0 и в 9.1 и самое печальное
что для "корня".

- dump/restore, snapshot
- бросок питания - требует fsck -fy
- gmirror - fsck -fy

мне этого хватило, какое ж это журналирование, если init вызывает fsck -y
тот сообщает что все Ok и потом паника в multiuser и исправляется только
принудительной полной проверкой.

Я случайно обнаружил когда попросили сделать продакшн с gmirror на 9.0 с jail'ами.
Стал демонстрировать креш, вытаскивая диски из зеркала и пропадание питания -
и выпал в осадок вместе с зазазчиком (нужно было до сдачи проверить с UFS и UFS+SU
то такого не было, понадеялся...).
Все было замечательно (после пропадания питания), fsck -y отрабатывал
моментально как и должно быть с журналом, а чуть позже - паника.
В списках рассылки ничего не было, разбор паники показал проблемы с SUJ,
добавил -f - все заработало, но смысл журналирования в этом случае потерян.
Send-pr отправлять было некогда, висела сдача, потом в списках рассылки появились
проблемы, хотя вру - проблема со снапшотом была еще до выхода 9.0R, именно она
навела на мысль.
Итог: корень либо UFS, либо UFS+SU, хоть и очень много было исправлений в SUJ и
в 9.1-Stable и в 9.2 у меня на ряде машин SUJ живет без проблем, в продакшене ни
на одной машине у меня нет корня с SUJ.

Ответить | Правка | ^ к родителю #5 | Наверх | Cообщить модератору

7. "FreeBSD kernel Panic "  +/
Сообщение от an0 on 01-Дек-13, 15:22 
ясно, спасибо, значит буду выключать, точнее изначально создавать без него.

Ответить | Правка | ^ к родителю #6 | Наверх | Cообщить модератору

8. "FreeBSD kernel Panic "  +/
Сообщение от an0 on 01-Дек-13, 15:24 
Еще небольшой вопрос :)
Чем плох SU на root? особенно если предполагается один раздел, как в PCBSD.


Ответить | Правка | ^ к родителю #6 | Наверх | Cообщить модератору

9. "FreeBSD kernel Panic "  +/
Сообщение от lavr email on 01-Дек-13, 17:04 
> Еще небольшой вопрос :)
> Чем плох SU на root? особенно если предполагается один раздел, как в
> PCBSD.

SU хорош и может быть использован и для корня и под один корневой раздел,
по скромным прикидкам, лет за 10 его вылизали, теперь будут вылизывать SUJ :)
если вовсе не забросят при наличии ZFS ;-)

Тут в другом дело, последнее время очень популлярно использовать один большой
корневой раздел под все, разумеется грамотно настроив логи, использование /tmp
и /var/tmp, переменные TMP/TMPDIR и тд и тп.
Вопрос в другом, если раздел большой, больше 200GB, ФС без журнала будет проверяться
и подниматься долго.
Как говорят "время - деньги"


Ответить | Правка | ^ к родителю #8 | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




Спонсоры:
Слёрм
Inferno Solutions
Hosting by Ihor
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2019 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру