Jump to content
Калькуляторы

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%.

 

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

Edited by replicant

Share this post


Link to post
Share on other sites

replicant

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

Share this post


Link to post
Share on other sites

replicant

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

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

 

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

Edited by replicant

Share this post


Link to post
Share on other sites

replicant

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

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

 

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

 

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

Share this post


Link to post
Share on other sites

Мы же о ванильных ядрах говорим? Ну так в них в старые ветки не портируют все багфиксы и важные изменения, сделанные в новых, это вам не 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.х.

 

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

Share this post


Link to post
Share on other sites

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

 

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

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

 

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

 

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

Share this post


Link to post
Share on other sites

В ядре 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

 

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

Edited by replicant

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this