[AlKov]

Железка с CentOS 6.7 ядро 2.6.32-573.8.1.el6.x86_64.

Задачи: NAT, nfdump+nat events, routing (RIP и static), DNS(named), dhcpd.

Приблизительно раз в два месяца уходит в kernel panic всегда с одной и той же проблемой

  KERNEL: /usr/lib/debug/lib/modules/2.6.32-573.8.1.el6.x86_64/vmlinux
   DUMPFILE: vmcore  [PARTIAL DUMP]
       CPUS: 8
       DATE: Tue Nov 29 21:37:23 2016
     UPTIME: 56 days, 10:02:52
LOAD AVERAGE: 0.01, 0.00, 0.00
      TASKS: 272
   NODENAME: border0
    RELEASE: 2.6.32-573.8.1.el6.x86_64
    VERSION: #1 SMP Tue Nov 10 18:01:38 UTC 2015
    MACHINE: x86_64  (2133 Mhz)
     MEMORY: 12 GB
      PANIC: "BUG: unable to handle kernel NULL pointer dereference at 0000000000000014"
        PID: 0
    COMMAND: "swapper"
       TASK: ffff8801bd66f520  (1 of 8)  [THREAD_INFO: ffff8801bd674000]
        CPU: 7
      STATE: TASK_RUNNING (PANIC)

crash> log | grep swapper
Pid: 0, comm: swapper Not tainted 2.6.32-573.8.1.el6.x86_64 #1 DEPO Computers X8DTN+-F/X8DTN+-F
Process swapper (pid: 0, threadinfo ffff8801bd674000, task ffff8801bd66f520)

 

Нагуглить что-либо про то, куда и на что смотреть, не удалось..

Прошу помощь зала..

[zhenya`]

Уберите сервисы с машины

[AlKov]

Уберите сервисы с машины

Не понял.. Это "шутка такой"?

[nshut]

Прошу помощь зала..

а разве трэйса нет краша? а то маловато инфы. Такая же система трудится без нареканий, конечно сервисы другие, но модулей ядра точно больше.

я краши долго не разгребал, делал только так, в папке с крашем makedumpfile --dump-dmesg vmcore txt

в трейсе практиески видно кто был инициатором до падения.

[AlKov]

... в папке с крашем makedumpfile --dump-dmesg vmcore txt

в трейсе практиески видно кто был инициатором до падения.

А по какому критерию определить инициатора?

Это оно - ??

<3>xt_TCPMSS: bad length (236 bytes)
<3>xt_TCPMSS: bad length (290 bytes)
<3>xt_TCPMSS: bad length (290 bytes)
<3>xt_TCPMSS: bad length (315 bytes)
<3>xt_TCPMSS: bad length (311 bytes)
<1>BUG: unable to handle kernel NULL pointer dereference at 0000000000000014
<1>IP: [<ffffffff81485008>] fib_rules_lookup+0x38/0xf0

[nshut]

вот пример моего дампа смерти.

[11078.080927] RIP: 0010:[<ffffffff81067bf6>] [<ffffffff81067bf6>] internal_ add_timer+0x46/0x150

[11078.080998] RSP: 0018:ffff88013fc43a08 EFLAGS: 00010002

[11078.081039] RAX: ffff8801399f1570 RBX: ffff8800a673d308 RCX: 0000000100a48 a5f

[11078.081092] RDX: ffffffffa042e2a0 RSI: ffff8800a673d308 RDI: ffff8801399f0 000

[11078.081145] RBP: ffff88013fc43a08 R08: ffff880139ad8128 R09: 0000000000000 000

[11078.081199] R10: 0000000000000002 R11: 0000000000000000 R12: 0000000100a50 000

[11078.081253] R13: ffff8801399f0000 R14: 0000000000000000 R15: ffff8801399f0 000

[11078.081307] FS: 0000000000000000(0000) GS:ffff88013fc40000(0000) knlGS:00 00000000000000

[11078.081368] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b

[11078.081411] CR2: ffffffffa042e2a0 CR3: 000000013818a000 CR4: 0000000000000 7e0

[11078.081465] Stack:

[11078.081482] ffff88013fc43a58 ffffffff8106a716 ffff8800a673d300 0000000000 000286

[11078.081546] ffffffff81d1c040 ffffffff81d1c040 ffff8800a673d300 ffffffff82 0f1b00

[11078.081611] 0000000000000000 0000000000000307 ffff88013fc43aa8 ffffffff81 5b6d64

[11078.081675] Call Trace:

[11078.081696] <IRQ>

[11078.081714]

[11078.081734] [<ffffffff8106a716>] mod_timer+0x106/0x200

[11078.081768] [<ffffffff815b6d64>] inet_frag_intern+0x94/0x1a0

[11078.081815] [<ffffffff815b6f7f>] inet_frag_find+0x10f/0x120

[11078.081861] [<ffffffff81573299>] ip_defrag+0xc9/0x180

[11078.081903] [<ffffffff81571520>] ? inet_add_protocol+0x50/0x50

[11078.081952] [<ffffffffa040809f>] ipv4_conntrack_defrag+0x8f/0xfc [nf_defr

RIP показывает где умерло, дальше видим, был вызов mod_timer, его вызвал inet_frag_in. выводы, функция фрагментации попыталась обратиться к таймеру, который либо умер, либо нет указателя на него. в общем здесь явно в модуле ядра смерть пришла.

как то у меня падал роутер связанный с фибом по включенному иому, но это у меня ядро 3.10 было, вылечилось грабе intel_iommu=off

Изменено 1 декабря, 2016 пользователем nshut

[AlKov]

RIP показывает где умерло, дальше видим, был вызов mod_timer, его вызвал inet_frag_in. выводы, функция фрагментации попыталась обратиться к таймеру, который либо умер, либо нет указателя на него. в общем здесь явно в модуле ядра смерть пришла.

как то у меня падал роутер связанный с фибом по включенному иому, но это у меня ядро 3.10 было, вылечилось грабе intel_iommu=off

Судя по всему, у меня именно это(fib)

<1>BUG: unable to handle kernel NULL pointer dereference at 0000000000000014

<1>IP: [<ffffffff81485008>] fib_rules_lookup+0x38/0xf0

<4>PGD 0

<4>Oops: 0000 [#1] SMP

<4>last sysfs file: /sys/devices/system/cpu/online

<4>CPU 7

<4>Modules linked in: ipt_REDIRECT ipt_REJECT xt_TCPMSS xt_state ts_kmp xt_multiport xt_string ip_set_hash_ip iptable_filter nf_nat_pptp nf_conntrack_pptp nf

_conntrack_proto_gre nf_nat_proto_gre ip_gre ip_tunnel autofs4 cpufreq_ondemand acpi_cpufreq freq_table mperf 8021q garp stp llc bonding ipv6 xt_set ip_set n

fnetlink iptable_nat nf_nat nf_conntrack_ipv4 nf_conntrack nf_defrag_ipv4 iptable_mangle ip_tables sg joydev microcode serio_raw iTCO_wdt iTCO_vendor_support

igb i2c_algo_bit ptp pps_core i2c_i801 i2c_core lpc_ich mfd_core ioatdma dca i7core_edac edac_core shpchp ext4 jbd2 mbcache sr_mod cdrom sd_mod crc_t10dif a

hci dm_mirror dm_region_hash dm_log dm_mod [last unloaded: scsi_wait_scan]

<4>

<4>Pid: 0, comm: swapper Not tainted 2.6.32-573.8.1.el6.x86_64 #1 DEPO Computers X8DTN+-F/X8DTN+-F

<4>RIP: 0010:[<ffffffff81485008>] [<ffffffff81485008>] fib_rules_lookup+0x38/0xf0

<4>RSP: 0018:ffff8801c5863a40 EFLAGS: 00010213

<4>RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000018

<4>RDX: 0000000000000009 RSI: ffff8801c5863b50 RDI: ffffffff81b301f8

<4>RBP: ffff8801c5863a80 R08: 00000000611b587c R09: 000000000000007c

<4>R10: 0000000000000000 R11: ffffffff81b280e0 R12: ffff8801c5863b50

<4>R13: ffff88033cc68bc0 R14: 0000000000000000 R15: ffff88033cc68c38

<4>FS: 0000000000000000(0000) GS:ffff8801c5860000(0000) knlGS:0000000000000000

<4>CS: 0010 DS: 0018 ES: 0018 CR0: 000000008005003b

<4>CR2: 0000000000000014 CR3: 0000000001a8d000 CR4: 00000000000007e0

<4>DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000

<4>DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400

<4>Process swapper (pid: 0, threadinfo ffff8801bd674000, task ffff8801bd66f520)

<4>Stack:

<4> ffff8803398d5020 ffff8801c5863a90 ffff88032abac034 ffff8801c5863b10

<4><d> ffff8803398d5020 ffff88032a955680 ffff8801c5863b50 0000000000000000

<4><d> ffff8801c5863ac0 ffffffff814e7d17 0000000000000000 ffff8801c5863b10

<4>Call Trace:

<4> <IRQ>

<4> [<ffffffff814e7d17>] fib_lookup+0x37/0x60

<4> [<ffffffff814a2e00>] ip_route_input_slow+0x240/0xb80

<4> [<ffffffff814a3896>] ip_route_input+0x66/0x5e0

<4> [<ffffffff814a5160>] ? ip_rcv_finish+0x0/0x440

<4> [<ffffffff8149acd6>] ? nf_hook_slow+0x76/0x120

<4> [<ffffffff814a5160>] ? ip_rcv_finish+0x0/0x440

<4> [<ffffffff814a53f9>] ip_rcv_finish+0x299/0x440

<4> [<ffffffff814a5815>] ip_rcv+0x275/0x350

<4> [<ffffffff8146abc8>] __netif_receive_skb+0x208/0x570

<4> [<ffffffff8146e468>] netif_receive_skb+0x58/0x60

<4> [<ffffffff8146e570>] napi_skb_finish+0x50/0x70

<4> [<ffffffff814703b9>] napi_gro_receive+0x39/0x50

<4> [<ffffffffa0155cc0>] igb_poll+0x6c0/0xfe0 [igb]

<4> [<ffffffffa01560d0>] ? igb_poll+0xad0/0xfe0 [igb]

<4> [<ffffffff810f0248>] ? handle_edge_irq+0x98/0x180

<4> [<ffffffff810f2bfe>] ? rcu_start_gp+0x1be/0x230

<4> [<ffffffff814704d3>] net_rx_action+0x103/0x2f0

<4> [<ffffffff8107ffa1>] __do_softirq+0xc1/0x1e0

<4> [<ffffffff810ed920>] ? handle_IRQ_event+0x60/0x170

<4> [<ffffffff8100c38c>] call_softirq+0x1c/0x30

<4> [<ffffffff8100fbd5>] do_softirq+0x65/0xa0

<4> [<ffffffff8107fe55>] irq_exit+0x85/0x90

<4> [<ffffffff815426e5>] do_IRQ+0x75/0xf0

<4> [<ffffffff8100ba53>] ret_from_intr+0x0/0x11

<4> <EOI>

<4> [<ffffffff812f112e>] ? intel_idle+0xfe/0x1b0

<4> [<ffffffff812f1111>] ? intel_idle+0xe1/0x1b0

<4> [<ffffffff810149c9>] ? sched_clock+0x9/0x10

<4> [<ffffffff810a895d>] ? sched_clock_cpu+0xcd/0x110

<4> [<ffffffff814337fa>] cpuidle_idle_call+0x7a/0xe0

<4> [<ffffffff81009fe6>] cpu_idle+0xb6/0x110

<4> [<ffffffff81531b22>] start_secondary+0x2c0/0x316

<4>Code: 48 83 ec 18 0f 1f 44 00 00 48 89 4d c8 48 8b 5f 78 4c 8d 7f 78 49 89 fd 49 89 f4 41 89 d6 4c 39 fb 0f 84 8a 00 00 00 0f 1f 40 00 <8b> 43 14 85 c0 74

37 90 41 3b 44 24 04 74 2f 31 c0 f6 43 34 02

<1>RIP [<ffffffff81485008>] fib_rules_lookup+0x38/0xf0

<4> RSP <ffff8801c5863a40>

<4>CR2: 0000000000000014

И как я понимаю, мне необходимо в grub.conf добавить intel_iommu=off?

Вот в эту строку?-

kernel /vmlinuz-2.6.32-573.8.1.el6.x86_64 ro root=/dev/mapper/vg_border-lv_root LANG=ru_RU.UTF-8 rd_NO_LUKS rd_LVM_LV=vg_border/lv_root rd_LVM_LV=vg_border/lv_swap rd_NO_MD crashkernel=auto  KEYBOARDTYPE=pc KEYTABLE=ru rd_NO_DM rhgb quiet

[nshut]

И как я понимаю, мне необходимо в grub.conf добавить intel_iommu=off?

да правильно, но у меня было ядро другое и в трэйсе были упоминания что иому включен. я говорю я не спец в крашах. вообще у вас видно вот что napi_gro_receive.

не знаю должна ли быть она в выключенном gro, но интел в своих драйверах пишет: "Disable GRO when routing/bridging" ethtool -K ethX gro off".

как и lro, но опять же, может у вас все это настроено. я верю интел и всегда это выключаю

Изменено 1 декабря, 2016 пользователем nshut

[SABRE]

AlKov

добавьте параметры

processor.max_cstate=1 intel_idle.max_cstate=0

intel idle всегда рекомендуют выключать. Похоже это ваш случай.

А в БИОС поотключайте все EIST/C-State и т.п.

Изменено 1 декабря, 2016 пользователем SABRE

[AlKov]

не знаю должна ли быть она в выключенном gro, но интел в своих драйверах пишет: "Disable GRO when routing/bridging" ethtool -K ethX gro off".

как и lro, но опять же, может у вас все это настроено. я верю интел и всегда это выключаю

Этого нет. Для сетевых только вот это -

#
/sbin/ethtool -K eth0 tso off tx off sg off
/sbin/ethtool -G eth0 rx 2048
/sbin/ethtool -G eth0 tx 2048
#
/sbin/ethtool -K eth1 tso off tx off sg off
/sbin/ethtool -G eth1 rx 2048
/sbin/ethtool -G eth1 tx 2048
#
/sbin/ethtool -K eth2 tso off tx off sg off
/sbin/ethtool -G eth2 rx 2048
/sbin/ethtool -G eth2 tx 2048
#
/sbin/ethtool -K eth3 tso off tx off sg off
/sbin/ethtool -G eth3 rx 2048
/sbin/ethtool -G eth3 tx 2048
#

Спасибо за замечание! Добавлю..

 

добавьте параметры

processor.max_cstate=1 intel_idle.max_cstate=0

intel idle всегда рекомендуют выключать. Похоже это ваш случай.

Это куда добавить? Также в grub.conf?

 

P.S. Ещё один вопрос - я немного поспешил сегодня и сделал апдейт ядра (yum-ом), а потом вспомнил, что у меня модуль ipt_NETFLOW собран на "старом" ядре. Теперь опасаюсь, взлетит ли вообще система на обновлённом ядре, не завалится сразу в kernel panic?

Машина - "удалёнка", поправить будет проблематично..

Можно, конечно, поправить в grub загрузку на "старое" ядро, но ручки чешутся на новое. :)

[nshut]

взлетит ли вообще система на обновлённом ядре, не завалится сразу в kernel panic?

взлетит, но если чек сум ядра и модуля не сойдутся, то модуль просто не загрузится. сойдется ли он или нет никто не знает :)

[SABRE]

Тоже в grub.conf

[pavel.odintsov]

А память memster'ом проверяли?