LINUX.ORG.RU

[kernel bug?][финн гадит] RTNETLINK answers: Cannot allocate memory


0

0

Дано: есть некая довольно старая железяка, работающая домашним роутером у одного человека. В этой железяке торчат три сетевухи, все они работают через драйвер r8169:

00:0a.0 Ethernet controller: D-Link System Inc DGE-528T Gigabit Ethernet Adapter (rev 10)
00:0b.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8169 Gigabit Ethernet (rev 10)
00:0c.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8169 Gigabit Ethernet (rev 10)

Есть дебиан, с ядрами 2.6.26-486, 2.6.26-2-openvz-486 и 2.6.32-5-486 (из unstable). На всех этих ядрах воспроизводится один и тот же баг, проявляющийся в следующем:

  • После некоторого аптайма, при попытке поднять опущенный интерфейс, вылезает пасквиль
    RTNETLINK answers: Cannot allocate memory
    и нифига не поднимается. Если вместо ip li se dev ethX up использовать сыплющий песком ifconfig, песня меняется незначительно:
    SIOCSIFFLAGS: Cannot allocate memory
  • Аналогичный эффект проявляется сразу после загрузки, если при загрузке была автоматически запущена fsck для ext3 на /. Сеть в этом случае не поднимается вообще, ни один интерфейс.

При этом свободной памяти более чем достаточно:

             total       used       free     shared    buffers     cached
Mem:           249        237         12          0         69        136
-/+ buffers/cache:         30        218
Swap:          972          0        972

Особо дотошные люди могут изучить ругательства dmesg по этому поводу.

По результатам гугления сложилось впечатление, что это застарелый и никого не беспокоящий баг ядра. Уж кто-кто, а r8169 всегда изобиловал багами. Впрочем, в RHEL, ради разнообразия, их иногда фиксят, чего не скажешь о мейнстриме. Хотя наиболее эффективным решением в сложившейся ситуации мне представляется закатывание туда опенка, в котором к ядреным багам относятся без особого почтения. Однако меня еще не покинула надежда, что проблему можно решить шаманством с sysctl et cetera. Идеи?

★★★★

Последнее исправление: nnz (всего исправлений: 1)

Ответ на: комментарий от Black_Shadow

Попробовал. Он вообще моих сетевух не видит.
И неудивительно — он новые 69-е не поддерживает.

RTL8111B/RTL8168B/RTL8111/RTL8168

RTL8111C/RTL8111CP/RTL8111D(L)


RTL8168C/RTL8111DP/RTL8111E



А у меня RTL8169.

nnz ★★★★
() автор топика
Ответ на: комментарий от Black_Shadow

>Я ошибся. Вот правильная ссылка

Уже лучше. Увидел две из трех. Есть еще более правильные ссылки?

nnz ★★★★
() автор топика
Ответ на: комментарий от nnz

На сколько я понял, для D-Link должен этот же драйвер подойти. У меня нет этих сетевых карт, но есть похожие, интегрированные в мать.

Black_Shadow ★★★★★
()
Ответ на: комментарий от nnz

При том, что со штатным r8169 длинк работает нормально.

nnz ★★★★
() автор топика

> Впрочем, в RHEL, ради разнообразия, их иногда фиксят, чего не скажешь о мейнстриме

Ну так возьми драйвер из RHEL.

tailgunner ★★★★★
()
Ответ на: комментарий от tailgunner

>Ну так возьми драйвер из RHEL.

Очень остроумно.

anonymous
()

> Аналогичный эффект проявляется сразу после загрузки, если при загрузке была автоматически запущена fsck для ext3 на /. Сеть в этом случае не поднимается вообще, ни один интерфейс.
Тоже встречался с этим. Как лечить, не знаю. Как это вообще может быть связано?

AITap ★★★★★
()
Ответ на: комментарий от AITap

>Тоже встречался с этим.

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

Как это вообще может быть связано?

Чисто интуитивно и по-дилетантски - у ядра заканчивается место в его областях памяти, а аллоцировать новые ему религия не позволяет.

anonymous
()

Не знаю, поможет или нет, но в качестве временного решения попробуй указать vm.min_free_kbytes=65536 в /etc/sysctl.conf

Black_Shadow ★★★★★
()
Ответ на: комментарий от Black_Shadow

>попробуй указать vm.min_free_kbytes=65536

АААААААААА! It works!!!!1
Во всяком случае, после fsck сеть поднимается.
Спасибо тебе огромное!

nnz ★★★★
() автор топика
Ответ на: комментарий от anonymous

> А на каком железе и с каким ядром (конфиг, патчи) вы с этим сталкивались?

Toshiba Satellite L350 17Z
Ядро дебиановское Linux deb-notebook 2.6.32-5-686 #1 SMP Tue Jun 1 04:59:47 UTC 2010 i686 GNU/Linux из тестинга.

Система прекрасно запускалась, не считая backtrace-ов в syslog и нерабочей сети. (дальше DM проверять работу испугался и просто перезагрузил машину)

AITap ★★★★★
()
Ответ на: комментарий от AITap

Нда. Я предполагал, что это присуще только 486-м сборкам без PAE.
Интересно, на amd64 оно бывает?

А метод фикса тут уже предложили, works for me :)

nnz ★★★★
() автор топика
Ответ на: комментарий от Black_Shadow

Кстати, а как у тебя эта идея появилась? Если сам допер — поясни, пожалуйста, ход рассуждений. Если нагуглил, кинь ссылку.

nnz ★★★★
() автор топика
Ответ на: комментарий от Black_Shadow

>У меня была похожая проблема с другим драйвером.

Тоже интерфейс не поднимался?

Вот, что я нагуглил: http://www.acc.umu.se/~maswan/linux-netperf.txt


Хм. Лично я не вижу прямой логической связи между тюнингом по скорости TCP и не поднимающимся интерфейсом.

nnz ★★★★
() автор топика
Ответ на: комментарий от nnz

Тоже интерфейс не поднимался?

Нет, но при большой сетевой активности было что-то типа «swapper: page allocation failure» и куча других сообщений, после чего сеть больше не работала до перезагрузки модуля.

Хм. Лично я не вижу прямой логической связи между тюнингом по скорости TCP и не поднимающимся интерфейсом.

If you see stuff like «swapper: page allocation failure. order:0, mode:0x20» you definately need to increase min_free_kbytes for the vm.

Black_Shadow ★★★★★
()
Ответ на: комментарий от Black_Shadow

Ага, так уже понятнее. Спасибо.

nnz ★★★★
() автор топика
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.