Перейти к содержимому
Калькуляторы

RCU Stallwarn или ошибки на ядре 3.2.35/37

Есть несколько серверов, выполняющих задачи авторизации абонентов по pptp (accel-ppp), но судя по всему это к делу не относится.

 

Конфиг примерно таков:

 

# lspci (частичная выборка)

00:1a.0 USB controller: Intel Corporation 5 Series/3400 Series Chipset USB2 Enhanced Host Controller (rev 05)
00:1c.0 PCI bridge: Intel Corporation 5 Series/3400 Series Chipset PCI Express Root Port 1 (rev 05)
00:1e.0 PCI bridge: Intel Corporation 82801 PCI Bridge (rev a5)
00:1f.0 ISA bridge: Intel Corporation 3400 Series Chipset LPC Interface Controller (rev 05)
00:1f.2 SATA controller: Intel Corporation 5 Series/3400 Series Chipset 6 port SATA AHCI Controller (rev 05)
00:1f.3 SMBus: Intel Corporation 5 Series/3400 Series Chipset SMBus Controller (rev 05)
01:00.0 Ethernet controller: Intel Corporation 82576 Gigabit Network Connection (rev 01)
01:00.1 Ethernet controller: Intel Corporation 82576 Gigabit Network Connection (rev 01)
05:00.0 Ethernet controller: Intel Corporation 82574L Gigabit Network Connection
06:00.0 Ethernet controller: Intel Corporation 82574L Gigabit Network Connection
07:05.0 VGA compatible controller: ASPEED Technology, Inc. ASPEED Graphics Family (rev 10)

# uname -a
Linux 3.2.37 #1 SMP Sat Jan 26 15:26:53 MSK 2013 x86_64 Intel(R) Xeon(R) CPU           X3470  @ 2.93GHz GenuineIntel GNU/Linux

 

Машин таких несколько. Периодически на одной из таких машин возникает такое:

 

[76560.772957] INFO: rcu_sched detected stalls on CPUs/tasks: { 4} (detected by 5, t=60002 jiffies)
[76560.772964] Pid: 0, comm: swapper/5 Tainted: G           O 3.2.37 #1
[76560.772965] Call Trace:
[76560.772966]  <IRQ>  [<ffffffff810ad9b5>] __rcu_pending+0x415/0x420
[76560.772974]  [<ffffffff810addbf>] rcu_check_callbacks+0x7f/0x1c0
[76560.772977]  [<ffffffff81060778>] update_process_times+0x48/0x90
[76560.772980]  [<ffffffff810824f6>] tick_sched_timer+0x66/0xc0
[76560.772983]  [<ffffffff8107562f>] __run_hrtimer+0x7f/0x1c0
[76560.772985]  [<ffffffff81082490>] ? tick_nohz_handler+0xf0/0xf0
[76560.772987]  [<ffffffff81075fb7>] hrtimer_interrupt+0xf7/0x220
[76560.772991]  [<ffffffff81552b79>] smp_apic_timer_interrupt+0x69/0x99
[76560.772993]  [<ffffffff8155194b>] apic_timer_interrupt+0x6b/0x70
[76560.772994]  <EOI>  [<ffffffff812f965a>] ? intel_idle+0xea/0x150
[76560.772998]  [<ffffffff812f9638>] ? intel_idle+0xc8/0x150
[76560.773001]  [<ffffffff81433759>] cpuidle_idle_call+0xc9/0x230
[76560.773003]  [<ffffffff8100096a>] cpu_idle+0xaa/0x110
[76560.773006]  [<ffffffff815405ba>] start_secondary+0x1cf/0x1d6
[76560.781953] INFO: rcu_bh detected stalls on CPUs/tasks: { 4} (detected by 7, t=60002 jiffies)
[76560.781958] Pid: 0, comm: swapper/7 Tainted: G           O 3.2.37 #1
[76560.781961] Call Trace:
[76560.781962]  <IRQ>  [<ffffffff810ad9b5>] __rcu_pending+0x415/0x420
[76560.781968]  [<ffffffff810ade0b>] rcu_check_callbacks+0xcb/0x1c0
[76560.781971]  [<ffffffff81060778>] update_process_times+0x48/0x90
[76560.781974]  [<ffffffff810824f6>] tick_sched_timer+0x66/0xc0
[76560.781977]  [<ffffffff8107562f>] __run_hrtimer+0x7f/0x1c0
[76560.781980]  [<ffffffff81082490>] ? tick_nohz_handler+0xf0/0xf0
[76560.781982]  [<ffffffff81075fb7>] hrtimer_interrupt+0xf7/0x220
[76560.781986]  [<ffffffff81552b79>] smp_apic_timer_interrupt+0x69/0x99
[76560.781988]  [<ffffffff8155194b>] apic_timer_interrupt+0x6b/0x70
[76560.781990]  <EOI>  [<ffffffff812f965a>] ? intel_idle+0xea/0x150
[76560.781994]  [<ffffffff812f9638>] ? intel_idle+0xc8/0x150
[76560.781997]  [<ffffffff81433759>] cpuidle_idle_call+0xc9/0x230
[76560.782000]  [<ffffffff8100096a>] cpu_idle+0xaa/0x110
[76560.782002]  [<ffffffff815405ba>] start_secondary+0x1cf/0x1d6

 

При этом машина не падает, не виснет, никак не подает признаков глюка, а просто работает как всегда периодически гадя в dmesg. Абоненты авторизуются, трафик считается, все корректно шейпится и т.п. Ни малейшего признака влияния на что либо. Нагрузка на машину тоже не запредельная. В пиках около 10% CPU. В трафике от 25 до 40 Мбайт/с вход и около 15-25 Мбайт/с выход. Авторизованных абонентов около 500-600. Т.е. ничего подозрительного нет.

 

Курил долго и нудно Гуглы и т.п. Упоминается какой-то патч для ядер 2.6.3х, но это что-то не то.

 

Долго читал документ http://www.kernel.org/doc/Documentation/RCU/stallwarn.txt Что-то понял, но так и не уловил в каком месте в ядре надо что-то включить/выключить, чтобы такого не было вообще или просто не показывалось.

 

Поскольку машин таких несколько, а глюки бывают только на двух из четырех, то диагностировать проблему еще сложнее в силу того факта, что ОС+ПО клонированы с единого первоначального образа, т.е. отличия в конфигурациях ядра и т.п. я даже искать не буду, потому что их нет (кроме нескольких паролей в конфигах и ip адресов интерфейсов).

 

Единственно что отметил - это вялость абонентских коннекций к проблемному серверу. Поясню на примере.

Есть зона в DNS в ней несколько A записей на одно имя для нескольких разных IP. Т.е. если абоненты обращаются к серверу по имени, то раскидывание абонентов примерно равномерное. Однако на серверах с подобным мусором в dmesg об ошибках абонентов соединено меньше процентов на 35-40%, что никак нельзя отнести к погрешностям статистического распределения. Однако присоединенные к проблемному серверу абоненты не фиксируют никаких проблем. У них все работает. Почему на проблемный сервер приходит меньше коннекций тоже не понятно.

 

Соответственно на безпроблемных серверах коннекций примерно поровну с некоторой погрешностью 1-2%, но не более и никак не 40%.

 

Вопрос: Что делать и куда бежать (а может просто забить)?

Изменено пользователем replicant

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

replicant

Соберите ядро из последних и попробуйте на нём, 99% что поможет

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

replicant

Соберите ядро из последних и попробуйте на нём, 99% что поможет

Ну как бы 3.2.37 тоже не старое ядро. Вышло только 2013-01-16. Или 3.7.х предлагаете?

 

Как бы новых глюков на новом ядре не словить.

Изменено пользователем replicant

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

replicant

Соберите ядро из последних и попробуйте на нём, 99% что поможет

Ну как бы 3.2.37 тоже не старое ядро. Вышло только 2013-01-16. Или 3.7.х предлагаете?

 

Как бы новых глюков на новом ядре не словить.

 

Мы же о ванильных ядрах говорим? Ну так в них в старые ветки не портируют все багфиксы и важные изменения, сделанные в новых, это вам не redhat, у которого ядро может называться 2.6.32, а включать в себя самые последние коммиты

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Мы же о ванильных ядрах говорим? Ну так в них в старые ветки не портируют все багфиксы и важные изменения, сделанные в новых, это вам не redhat, у которого ядро может называться 2.6.32, а включать в себя самые последние коммиты

Это известно, но речь о клонированных системах с единого образа. Две машины не сбоят, а две сбоят. Вот я и думаю что проблема не в версии ядра, а чуть ли даже не в аппаратных различиях, хотя о каких аппаратных различиях можно говорить, если платформа типа SuperMicro 1U 2in1 (т.е. два одинаковых сервака в одном коробке).

 

Я конечно подготовил ядро 3.7.5 и ночью проведу замену, но думается надо копать в другую сторону.

 

Changelog прочитал от ветки 3.2.13 до 3.2.37 и еще по моим наблюдениям 3.2.10-14 с таким багом не сталкивались (стоит в одной из стоек три таких тазика с аптаймом почти год и тишина), а вылез он на 3.2.35 и выше (его могли породить рожая в муках 3.7.х на основе ранних веток). И еще прочитал то же самое от ветки 3.7.1 до 3.7.5, что-то на тему rcu там проскакивало, но это же было и в 3.2.3х. Это я к тому, что 3.7.5 может оказаться не лекарством, а наоборот и откатываться надо вниз по 3.2.х.

 

Короче говоря буду проверять. Скорее всего придется опытным путем искать источник ошибки.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

+ еще одно наблюдение

 

Все машины, где наблюдается баг имеют Xeon более старых серий на чипсетах i3400 и i5520 и прошли обновление до ядра 3.2.35 или 37, после чего был зафиксирован баг.

Такие же машины, где обновление с ядер 3.2.10-14 произведено не было с этим багом замечены не были ни разу.

 

На Xeon E3-E5 и чипсетах C202-602 установка из того же самого образа прошла успешно и такая проблема за более чем 2 месяца работы этих машин не встречалась.

 

Это опять наводит на мысль что баг при использовании ранних моделей CPU-Chipset возник в последних версиях ядра в связи с выходом 3.7.х, если верить changelog.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

В ядре 3.7.х появилось такое предупреждение:

 

[ 6.340945] nf_conntrack: automatic helper assignment is deprecated and it will be removed soon. Use the iptables CT target to attach helpers instead.

 

Т.е. насколько я понимаю, то скоро придется делать так:

 

iptables -t raw -A OUTPUT -p tcp --dport 21 -j CT --helper ftp

или

iptables -A PREROUTING -p tcp --dport 6667 -j CT --helper irc
iptables -A PREROUTING -p tcp --dport 6566 -j CT --helper sane

 

Или я что-то не так понял?

Изменено пользователем replicant

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Гость
Ответить в тему...

×   Вставлено в виде отформатированного текста.   Вставить в виде обычного текста

  Разрешено не более 75 смайлов.

×   Ваша ссылка была автоматически встроена.   Отобразить как ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставить изображения напрямую. Загрузите или вставьте изображения по ссылке.