dummynet и паника "bad switch -256!"

[dadv]

В продолжение темы.

После того, как Глеб исправил несколько проблем в ядре FreeBSD, нагруженные роутеры с mpd5/PPPoE у меня работают стабильно. Однако, где-то раз в год всё-таки на каком-нибудь из них нет-нет, да и произойдет паника и все следы ведут в dummynet. Но раньше по разным причинам не удавалось сохранить одновременно крешдамп и отладочное ядро, а сегодня-таки удалось.

По итогам предварительного разбирательства найдено подозрительное место в коде dummynet и оформлен PR: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=195102

Судя по коду, проблема общая и для 9.x, 10.x и CURRENT - это место практически неизменно во всех ветках. Теперь главное, чтобы PR не завис незамеченным на годы.

Comments

[dadv.livejournal.com]

Не будешь репортить проблему - и в 11.1 будет не пора.

[guest-o.livejournal.com]

Багрепорт там уже есть, просто по нему движения пока нет. Завтра на работе буду, уточню номер.

[guest-o.livejournal.com]

Нашёл. Вот с этой граблей столкнулись: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=186114

[guest-o.livejournal.com]

Кстати, товарищ. Вы на ruBSD 14-го декабря в Москву не собираетесь?

[dadv.livejournal.com]

Нет.

[guest-o.livejournal.com]

А имеет смысл в уже существующий репорт дописать чего-нибудь? Типа "у нас тоже всплыла эта проблема"? Я бы подебажил её, только не знаю, как. Да и там вроде репортер достаточно информации предоставил, даже не знаю, что там можно добавить.

[dadv.livejournal.com]

Чем больше отзывов от разных людей, тем лучше. Если можешь позволить себе подебажить и собрать хорошую статистику - можно оформить отдельный PR, а в старый добавить комментарий со ссылкой на свой.

Для дебага лучше всего почитать главу Kernel Debug в Developers Handbook (раньше эта глава была в основном Handbook, зачем убрали в девелоперский, непонятно). Первым делом нужно собрать отладочное ядро (kernel.debug) плюс добавить в его конфиг INVARIANTS/WITNESS/DIAGNOSTICS (для начала можно только INVARIANTS) с тем, чтобы вместо тупого зависания спровоцировать раннюю панику и получить крешдамп, с которым дальше по Handbook поступать.

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

[guest-o.livejournal.com]

Окэ, спасибо. Соберу тестовый стенд, попробую с помощью твоих скриптов создать соответствующую нагрузку и подебажить.