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

tcpdump намертво повесил debian 7

Добрый день. Есть сервер dell 1950 с debian7 на нем. Ядро стандартное 3.2.0-4-686-pae, на него возложено довольно много функций(bgp, терминация клиентских вланов, nat, shaiper), но он с легкойстью стравляется, 2 гигабитных встроенных интерфейса объеденены в bond, в такой конфигурации все работало больше года стабильно. Обновились 1.5 месяца назад на ядро 3.19.5 и переключились на 10 гигабитную карту intel x520, но не задалось со стабильностью, переодически сервер падал с разными паниками ядра. Откатились на старую конфигурацию, на ядро 3.2.0 и на bond интерфейс. И вот сегодня, безобидная команда "tcpdump -i bond0.6 host 10.9.4.5" просто намертво повесила сервер. Подключили монитор, изображение не выводится, на клавиатуру сервер не реагирует. После перезагрузки, еще раз введенная эта команда снова вешает намертво сервер. Включена netconsole, данных на ней не больше чем в файле /var/log/messages, собственно последние сообщения.

May 13 16:36:31 rd2 kernel: [181074.682018] device bond0.6 left promiscuous mode
May 13 16:36:31 rd2 kernel: [181074.684804] device bond0 left promiscuous mode
May 13 16:36:31 rd2 kernel: [181074.687742] device eth0 left promiscuous mode
May 13 16:36:31 rd2 kernel: [181074.690626] device eth1 left promiscuous mode

 

Как такая безобидная утилита как tcpdump может приводить к таким результатам?

Share this post


Link to post
Share on other sites

Похоже что-то с драйвером карты не то. Чуток поновее ядро бы, чем 3.2.0.

Share this post


Link to post
Share on other sites

Работало же довольно долго в такой конфигурации, и проблем не было, даже между двумя зависонами по tcpdump -i bond0.6, дергался снифер на другие вланы, ничего не произошло, включили на 6 влане и сервер повис. По ядру понятно, мы как раз хотели на втором, точно таком же и по железу и по ПО сервере, все оттестировать получше.

Share this post


Link to post
Share on other sites

Повесьте netconsole/ldump на машину, чтобы было понятно, что прозошло. Так не выгадать. Да и ядро 3/2 - хлам, скорее апнитесь на Джесси :)

Share this post


Link to post
Share on other sites

Ядро хлам, ещё и первых минорных релизов.

Я так вообще ловил kernel panic с вероятностью 50% при банальном iptables restart на 3.10.0, на 3.10.3(и всех последующих) проблема исчезла.

Share this post


Link to post
Share on other sites

pavel.odintsov

netconsole запущена, я ж написал об этом, в том то и дело, что следов никакиз нету

Хлам, ни хлам, это дефолтное ядро дебиана, и работало очень долго без нареканий. Мы то и включили его снова(после экспериментов с 3.19.5), как проверенное, чтобы потихоньку оттестировать что-то поновей.

Share this post


Link to post
Share on other sites

Кстати, стоит

~# cat /proc/sys/kernel/panic
5

Но если ядро даже перезагрузиться не смогло, сможет ли оно подгрузить другое ядро, чтобы записать дамп на фс.

Edited by swelf

Share this post


Link to post
Share on other sites

1) перейдите на amd64

2) обновите фирмваре бортовых сетевух

3) корректно настройте ACPI

Share this post


Link to post
Share on other sites

1) перейдите на amd64

 

поддерживаю. 32bit скорее мертво, чем живо.

Share this post


Link to post
Share on other sites

1) перейдите на amd64

2) обновите фирмваре бортовых сетевух

3) корректно настройте ACPI

1)Я думаю архитекрута сама по себе сейчас маловероятный источник проблем.

2)Это интересное предложение, попробуем.

3)Можно подробней, что там настраивать то, и на что это вообще может повлиять.

Share this post


Link to post
Share on other sites

tcpdump ни при чем, просто совпадение. Если случилось один раз, забудьте. Будет повторяться, выводите сервер и проверяйте железо. Dell не самый надежный производитель.

Share this post


Link to post
Share on other sites

Про дрова хороший довод, у меня бывало, что система ложтлиась от ухода в промиск, когда я игрался с дровами сетевых.

Share this post


Link to post
Share on other sites

nu11

случилось 2 раза, причем подряд, самое интересное, что когда ввели в промиск влан 754 (клиентский) ничего не произошло, а с 6м вланом, до и после 754 система наглухо повисла, на втором маршрутизаторе(резервном) обновили ядро и прошивку для встроенных сетевых, ночью планируем переключить.

Share this post


Link to post
Share on other sites

1) перейдите на amd64

2) обновите фирмваре бортовых сетевух

3) корректно настройте ACPI

1)Я думаю архитекрута сама по себе сейчас маловероятный источник проблем.

2)Это интересное предложение, попробуем.

3)Можно подробней, что там настраивать то, и на что это вообще может повлиять.

 

У меня стояла FreeBSD на подобном железе.

Пояснение к пунктам:

1) Вы собираетесь юзать 10Г сетевые, а это выше 32битной адресации

2) На дефолтных фирмваре зависают сетевые интерфейсы, а с учетом того, что через них работает IPMI - куча всяких подобных эффектов. TSO, RSO и оффлоадинг отключайте по необходимости.

3) При неправильно выставленном ACPI, при простое, некоторые приложения начнут на ровном месте кушать CPU, у меня так quagga при простое потреблять 40%CPU. Почитайте на досуге про ACPI и timecounter. Во Фряхе доступны несколько режимов:

kern.timecounter.choice: TSC-low(-100) ACPI-fast(900) HPET(950) i8254(0) dummy(-1000000)

Share this post


Link to post
Share on other sites

История имеет продолжение. У нас 2 одинаковых dell1950, должны дублировать друг друга. Итак назовем их A и B. Первый пост был о сервере A, после некоторых эксперементов с ПО сейчас у нас в работе сервер B, debian 6 64bit, ядро дистрибутивное

# uname -a
Linux rd1 3.16.0-4-amd64 #1 SMP Debian 3.16.7-ckt9-3~deb8u1 (2015-04-24) x86_64 GNU/Linux

команда tcpdump -i eth2.1999 -nn вызвала падение сервера, если в первый раз, сервер намертво вис, то теперь он перезагрузился, думаю помог один из параметров ядра

pcie_aspm=off acpi=off noapic intel_idle.max_cstate=0 processor.max_cstate=0 idle=poll nmi_watchdog=panic softlockup_panic=5

скорее всего softlockup_panic=5

 

eth2 это собственно сетевая intel x520, драйвер самосборный

# modinfo ixgbe
filename:       /lib/modules/3.16.0-4-amd64/kernel/drivers/net/ethernet/intel/ixgbe/ixgbe.ko
version:        4.0.3
license:        GPL
description:    Intel(R) 10 Gigabit PCI Express Network Driver
author:         Intel Corporation, <linux.nics@intel.com>
srcversion:     51251F41E617087482AB9D3

изначально все висло на встроенных BCM5708.

 

Дабы попытать воспроизвести проблему, вчера на сервере A(debian 7, 3.2.0,32bit) запустил команду

for i in `seq 1 10000`; do echo $i; tcpdump -i eth2.160 -nn -c5; done

чтобы подергать интерфейс. Это дело отработало пару раз, я даже в порт eth2 миррорил весь наш трафик, ничего интересного не происходило.

Сейчас, на сервере B(debian 8, 3.16, 64bit) эта команда привела к перезагрузке роутера на 30 и 15 итерации соответственно, т.е. можно сказать, что проблему я легко вопроизвожу, что уже не плохо.

 

На сервере A уже стоит debian 8, 64bit, 4.0.0-1 из unstable. проблема не воспроизводится, пока он работает в холостую, даже с замирроренным на него трафиком, причем изначально все и началось с этого сервера.

С учетом того, что проблему я легко вопроизвожу, пусть и на "боевом" сервере, какие у кого есть предложения по диагностике, решению проблемы?

Share this post


Link to post
Share on other sites

Не то чтоб я подозревал сам tcpdump, но чтоб развеять сомнения,

for i in `seq 1 10000`; do echo $i; ip l set dev eth2.160 promisc on; sleep 0.2; ip l set dev eth2.160 promisc off; sleep 0.2; done

тоже ложит роутер

 

еще немного экспериментов

for i in `seq 1 10000`; do echo $i; ip l set dev eth2 promisc on; sleep 0.2; ip l set dev eth2 promisc off; sleep 0.2; done

300 итераций, без проблем

если оставить eth2 в promisc и дергать только eth2.160, то тоже 300 итераций без проблем.

А вот когда дергаются оба интерфейса, и eth2.160 и eth2, то 40 и 80 итераций и роутер падает. логов никаких.

Edited by swelf

Share this post


Link to post
Share on other sites

Я оказался не прав по поводу логов, в 2х из 4х раз он остался.

 

tcpdump

Jun  5 03:37:49 rd1 kernel: [ 1126.696264] ------------[ cut here ]------------
Jun  5 03:37:49 rd1 kernel: [ 1126.696264] WARNING: CPU: 7 PID: 30057 at /build/linux-RGM_Ed/linux-3.16.7-ckt9/kernel/softirq.c:146 __local_bh_enable_ip+0x6a/0x90()
Jun  5 03:37:49 rd1 kernel: [ 1126.696264] Modules linked in: sch_ingress act_mirred cls_u32 sch_htb ifb nfsv3 rpcsec_gss_krb5 nfsv4 dns_resolver xt_CT ipt_NETFLOW(O) xt_TCPMSS xt_tcpmss xt_multiport ip_set_hash_ip xt_set ip_set_hash_net ip_set nfnetlink ipt_REJECT xt_conntrack xt_nat xt_tcpudp iptable_raw iptable_mangle iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 iptable_filter ip_tables x_tables nf_nat_pptp nf_nat_proto_gre nf_conntrack_pptp nf_conntrack_proto_gre nf_nat nf_conntrack 8021q garp stp mrp llc binfmt_misc nfsd auth_rpcgss oid_registry nfs_acl nfs lockd fscache sunrpc radeon iTCO_wdt iTCO_vendor_support lpc_ich evdev ttm drm_kms_helper drm mfd_core i2c_algo_bit i2c_core shpchp i5000_edac processor thermal_sys rng_core dcdbas edac_core coretemp i5k_amb pcspkr psmouse kvm ioatdma serio_raw netconsole configfs mii loop bonding fuse autofs4 ext4 crc16 mbcache jbd2 dm_mod sg sd_mod crc_t10dif crct10dif_generic crct10dif_common uhci_hcd ehci_pci ehci_hcd mptsas usbcore scsi_transport_sas ixgbe mptscsih usb_common dca mptbase ptp pps_core mdio bnx2 scsi_mod
Jun  5 03:37:49 rd1 kernel: [ 1126.696264] CPU: 7 PID: 30057 Comm: tcpdump Tainted: G           O  3.16.0-4-amd64 #1 Debian 3.16.7-ckt9-3~deb8u1
Jun  5 03:37:49 rd1 kernel: [ 1126.696264] Hardware name: Dell Inc. PowerEdge 1950/0M788G, BIOS 2.6.1 04/20/2009
Jun  5 03:37:49 rd1 kernel: [ 1126.696264]  0000000000000009 ffffffff8150ac96 0000000000000000 ffffffff81067747
Jun  5 03:37:49 rd1 kernel: [ 1126.696264]  0000000000000200 0000000000000000 ffff8800ca0e24d0 0000000000006a08
Jun  5 03:37:49 rd1 kernel: [ 1126.696264]  ffff8802241a0040 ffffffff8106c8aa ffff8802241a0128 ffffffffa00b6151
Jun  5 03:37:49 rd1 kernel: [ 1126.696264] Call Trace:
Jun  5 03:37:49 rd1 kernel: [ 1126.696264]  [<ffffffff8150ac96>] ? dump_stack+0x41/0x51
Jun  5 03:37:49 rd1 kernel: [ 1126.696264]  [<ffffffff81067747>] ? warn_slowpath_common+0x77/0x90
Jun  5 03:37:49 rd1 kernel: [ 1126.696264]  [<ffffffff8106c8aa>] ? __local_bh_enable_ip+0x6a/0x90
Jun  5 03:37:49 rd1 kernel: [ 1126.696264]  [<ffffffffa00b6151>] ? ixgbe_poll+0x441/0x860 [ixgbe]
Jun  5 03:37:49 rd1 kernel: [ 1126.696264]  [<ffffffff81437d38>] ? netpoll_poll_dev+0x108/0x1b0
Jun  5 03:37:49 rd1 kernel: [ 1126.696264]  [<ffffffff81437f03>] ? netpoll_send_skb_on_dev+0x123/0x260
Jun  5 03:37:49 rd1 kernel: [ 1126.696264]  [<ffffffff81438305>] ? netpoll_send_udp+0x2c5/0x410
Jun  5 03:37:49 rd1 kernel: [ 1126.696264]  [<ffffffffa014a83b>] ? write_msg+0xcb/0x130 [netconsole]
Jun  5 03:37:49 rd1 kernel: [ 1126.696264]  [<ffffffff810b79e2>] ? call_console_drivers.constprop.24+0x92/0xf0
Jun  5 03:37:49 rd1 kernel: [ 1126.696264]  [<ffffffff810b8972>] ? console_unlock+0x3f2/0x430
Jun  5 03:37:49 rd1 kernel: [ 1126.696264]  [<ffffffff810b8c30>] ? vprintk_emit+0x280/0x550
Jun  5 03:37:49 rd1 kernel: [ 1126.696264]  [<ffffffff8150848a>] ? printk+0x54/0x56
Jun  5 03:37:49 rd1 kernel: [ 1126.696264]  [<ffffffff8141f562>] ? __dev_set_promiscuity+0xf2/0x1d0
Jun  5 03:37:49 rd1 kernel: [ 1126.696264]  [<ffffffff8150848a>] ? printk+0x54/0x56
Jun  5 03:37:49 rd1 kernel: [ 1126.696264]  [<ffffffff8141f8be>] ? dev_set_promiscuity+0x1e/0x50
Jun  5 03:37:49 rd1 kernel: [ 1126.696264]  [<ffffffff8141f589>] ? __dev_set_promiscuity+0x119/0x1d0
Jun  5 03:37:49 rd1 kernel: [ 1126.696264]  [<ffffffff810c14e0>] ? ftrace_raw_output_rcu_utilization+0x40/0x40
Jun  5 03:37:49 rd1 kernel: [ 1126.696264]  [<ffffffff8141f8be>] ? dev_set_promiscuity+0x1e/0x50
Jun  5 03:37:49 rd1 kernel: [ 1126.696264]  [<ffffffff814f5b3f>] ? packet_setsockopt+0x7df/0x9b0
Jun  5 03:37:49 rd1 kernel: [ 1126.696264]  [<ffffffff81403d8f>] ? SYSC_bind+0xbf/0x100
Jun  5 03:37:49 rd1 kernel: [ 1126.696264]  [<ffffffff81404bec>] ? SyS_setsockopt+0x6c/0xd0
Jun  5 03:37:49 rd1 kernel: [ 1126.696264]  [<ffffffff81510e4d>] ? system_call_fast_compare_end+0x10/0x15
Jun  5 03:37:49 rd1 kernel: [ 1126.696264] ---[ end trace bae094ba4dce25bb ]---

 

Просто дергал интерсейс promisc on/off

Jun  5 05:07:40 rd1 kernel: [ 5247.880003] ------------[ cut here ]------------
Jun  5 05:07:40 rd1 kernel: [ 5247.880003] WARNING: CPU: 5 PID: 10091 at /build/linux-RGM_Ed/linux-3.16.7-ckt9/kernel/softirq.c:146 __local_bh_enable_ip+0x6a/0x90()
Jun  5 05:07:40 rd1 kernel: [ 5247.880003] Modules linked in: sch_ingress act_mirred cls_u32 sch_htb ifb nfsv3 rpcsec_gss_krb5 nfsv4 dns_resolver xt_CT ipt_NETFLOW(O) xt_TCPMSS xt_tcpmss xt_multiport ip_set_hash_ip xt_set ip_set_hash_net ip_set nfnetlink ipt_REJECT xt_conntrack xt_nat xt_tcpudp iptable_raw iptable_mangle iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 iptable_filter ip_tables x_tables nf_nat_pptp nf_nat_proto_gre nf_conntrack_pptp nf_conntrack_proto_gre nf_nat nf_conntrack 8021q garp stp mrp llc binfmt_misc nfsd auth_rpcgss oid_registry nfs_acl nfs lockd fscache sunrpc radeon processor thermal_sys ttm drm_kms_helper coretemp drm kvm iTCO_wdt i2c_algo_bit iTCO_vendor_support i2c_core i5000_edac evdev lpc_ich mfd_core dcdbas edac_core pcspkr shpchp i5k_amb rng_core ioatdma psmouse serio_raw netconsole configfs mii loop bonding fuse autofs4 ext4 crc16 mbcache jbd2 dm_mod sg sd_mod crc_t10dif crct10dif_generic crct10dif_common ehci_pci uhci_hcd ehci_hcd mptsas ixgbe usbcore scsi_transport_sas mptscsih usb_common dca ptp mptbase pps_core mdio bnx2 scsi_mod
Jun  5 05:07:40 rd1 kernel: [ 5247.880003] CPU: 5 PID: 10091 Comm: ip Tainted: G           O  3.16.0-4-amd64 #1 Debian 3.16.7-ckt9-3~deb8u1
Jun  5 05:07:40 rd1 kernel: [ 5247.880003] Hardware name: Dell Inc. PowerEdge 1950/0M788G, BIOS 2.6.1 04/20/2009
Jun  5 05:07:40 rd1 kernel: [ 5247.880003]  0000000000000009 ffffffff8150ac96 0000000000000000 ffffffff81067747
Jun  5 05:07:40 rd1 kernel: [ 5247.880003]  0000000000000200 0000000000000000 ffff880224af9890 0000000000000000
Jun  5 05:07:40 rd1 kernel: [ 5247.880003]  ffff8802247c6040 ffffffff8106c8aa ffff8802247c6128 ffffffffa00ed151
Jun  5 05:07:40 rd1 kernel: [ 5247.880003] Call Trace:
Jun  5 05:07:40 rd1 kernel: [ 5247.880003]  [<ffffffff8150ac96>] ? dump_stack+0x41/0x51
Jun  5 05:07:40 rd1 kernel: [ 5247.880003]  [<ffffffff81067747>] ? warn_slowpath_common+0x77/0x90
Jun  5 05:07:40 rd1 kernel: [ 5247.880003]  [<ffffffff8106c8aa>] ? __local_bh_enable_ip+0x6a/0x90
Jun  5 05:07:40 rd1 kernel: [ 5247.880003]  [<ffffffffa00ed151>] ? ixgbe_poll+0x441/0x860 [ixgbe]
Jun  5 05:07:40 rd1 kernel: [ 5247.880003]  [<ffffffff81437d38>] ? netpoll_poll_dev+0x108/0x1b0
Jun  5 05:07:40 rd1 kernel: [ 5247.880003]  [<ffffffff81437f03>] ? netpoll_send_skb_on_dev+0x123/0x260
Jun  5 05:07:40 rd1 kernel: [ 5247.880003]  [<ffffffff81438305>] ? netpoll_send_udp+0x2c5/0x410
Jun  5 05:07:40 rd1 kernel: [ 5247.880003]  [<ffffffffa023383b>] ? write_msg+0xcb/0x130 [netconsole]
Jun  5 05:07:40 rd1 kernel: [ 5247.880003]  [<ffffffff810b79e2>] ? call_console_drivers.constprop.24+0x92/0xf0
Jun  5 05:07:40 rd1 kernel: [ 5247.880003]  [<ffffffff810b8972>] ? console_unlock+0x3f2/0x430
Jun  5 05:07:40 rd1 kernel: [ 5247.880003]  [<ffffffff810b8c30>] ? vprintk_emit+0x280/0x550
Jun  5 05:07:40 rd1 kernel: [ 5247.880003]  [<ffffffff8150848a>] ? printk+0x54/0x56
Jun  5 05:07:40 rd1 kernel: [ 5247.880003]  [<ffffffff8141f562>] ? __dev_set_promiscuity+0xf2/0x1d0
Jun  5 05:07:40 rd1 kernel: [ 5247.880003]  [<ffffffff8150848a>] ? printk+0x54/0x56
Jun  5 05:07:40 rd1 kernel: [ 5247.880003]  [<ffffffff8141f8be>] ? dev_set_promiscuity+0x1e/0x50
Jun  5 05:07:40 rd1 kernel: [ 5247.880003]  [<ffffffff8141f589>] ? __dev_set_promiscuity+0x119/0x1d0
Jun  5 05:07:40 rd1 kernel: [ 5247.880003]  [<ffffffff8150848a>] ? printk+0x54/0x56
Jun  5 05:07:40 rd1 kernel: [ 5247.880003]  [<ffffffff8141f8be>] ? dev_set_promiscuity+0x1e/0x50
Jun  5 05:07:40 rd1 kernel: [ 5247.880003]  [<ffffffff8141f589>] ? __dev_set_promiscuity+0x119/0x1d0
Jun  5 05:07:40 rd1 kernel: [ 5247.880003]  [<ffffffff814246d4>] ? dev_uc_sync+0x84/0x90
Jun  5 05:07:40 rd1 kernel: [ 5247.880003]  [<ffffffff8141fadc>] ? __dev_change_flags+0xdc/0x160
Jun  5 05:07:40 rd1 kernel: [ 5247.880003]  [<ffffffff8141fb83>] ? dev_change_flags+0x23/0x60
Jun  5 05:07:40 rd1 kernel: [ 5247.880003]  [<ffffffff8142dfbb>] ? do_setlink+0x31b/0xa80
Jun  5 05:07:40 rd1 kernel: [ 5247.880003]  [<ffffffff8101ba0d>] ? native_sched_clock+0x2d/0x80
Jun  5 05:07:40 rd1 kernel: [ 5247.880003]  [<ffffffff8101ba65>] ? sched_clock+0x5/0x10
Jun  5 05:07:40 rd1 kernel: [ 5247.880003]  [<ffffffff81099705>] ? sched_clock_local+0x15/0x80
Jun  5 05:07:40 rd1 kernel: [ 5247.880003]  [<ffffffff8115aa05>] ? zone_statistics+0x85/0x90
Jun  5 05:07:40 rd1 kernel: [ 5247.880003]  [<ffffffff8142ed5c>] ? rtnl_newlink+0x50c/0x750
Jun  5 05:07:40 rd1 kernel: [ 5247.880003]  [<ffffffff8142e943>] ? rtnl_newlink+0xf3/0x750
Jun  5 05:07:40 rd1 kernel: [ 5247.880003]  [<ffffffff812b2fea>] ? number.isra.2+0x31a/0x350
Jun  5 05:07:40 rd1 kernel: [ 5247.880003]  [<ffffffff8115aa05>] ? zone_statistics+0x85/0x90
Jun  5 05:07:40 rd1 kernel: [ 5247.880003]  [<ffffffff81145b5f>] ? get_page_from_freelist+0x57f/0x910
Jun  5 05:07:40 rd1 kernel: [ 5247.880003]  [<ffffffff8142b45f>] ? rtnetlink_rcv_msg+0x8f/0x250
Jun  5 05:07:40 rd1 kernel: [ 5247.880003]  [<ffffffff8140cd08>] ? __alloc_skb+0x48/0x2a0
Jun  5 05:07:40 rd1 kernel: [ 5247.880003]  [<ffffffff8142b3d0>] ? rtnetlink_rcv+0x30/0x30
Jun  5 05:07:40 rd1 kernel: [ 5247.880003]  [<ffffffff8144aef9>] ? netlink_rcv_skb+0xa9/0xc0
Jun  5 05:07:40 rd1 kernel: [ 5247.880003]  [<ffffffff8142b3c4>] ? rtnetlink_rcv+0x24/0x30
Jun  5 05:07:40 rd1 kernel: [ 5247.880003]  [<ffffffff8144a5c0>] ? netlink_unicast+0xf0/0x1f0
Jun  5 05:07:40 rd1 kernel: [ 5247.880003]  [<ffffffff8144a9ee>] ? netlink_sendmsg+0x32e/0x680
Jun  5 05:07:40 rd1 kernel: [ 5247.880003]  [<ffffffff81403f5b>] ? sock_sendmsg+0x8b/0xc0
Jun  5 05:07:40 rd1 kernel: [ 5247.880003]  [<ffffffff8105d7b9>] ? flush_tlb_page+0x39/0xa0
Jun  5 05:07:40 rd1 kernel: [ 5247.880003]  [<ffffffff81403c89>] ? move_addr_to_kernel.part.17+0x19/0x60
Jun  5 05:07:40 rd1 kernel: [ 5247.880003]  [<ffffffff81404729>] ? ___sys_sendmsg+0x389/0x3a0
Jun  5 05:07:40 rd1 kernel: [ 5247.880003]  [<ffffffff811ce202>] ? __inode_wait_for_writeback+0x72/0xc0
Jun  5 05:07:40 rd1 kernel: [ 5247.880003]  [<ffffffff810a7960>] ? autoremove_wake_function+0x30/0x30
Jun  5 05:07:40 rd1 kernel: [ 5247.880003]  [<ffffffff810572c1>] ? __do_page_fault+0x1d1/0x4f0
Jun  5 05:07:40 rd1 kernel: [ 5247.880003]  [<ffffffff811bda8e>] ? dput+0x9e/0x170
Jun  5 05:07:40 rd1 kernel: [ 5247.880003]  [<ffffffff811a9a51>] ? __fput+0x161/0x1d0
Jun  5 05:07:40 rd1 kernel: [ 5247.880003]  [<ffffffff81404dce>] ? __sys_sendmsg+0x3e/0x80
Jun  5 05:07:40 rd1 kernel: [ 5247.880003]  [<ffffffff81510e4d>] ? system_call_fast_compare_end+0x10/0x15

 

Второй сервер, с тем же ядром, тем же драйвером сетевой, не падает, ночью поменяем их местами и еще поэксперементируем

Share this post


Link to post
Share on other sites

Доп вопрос, почему показания расходятся.

# ethtool -i eth2
driver: ixgbe
version: 3.19.1-k
firmware-version: 0x1bab0001
bus-info: 0000:0c:00.0
supports-statistics: yes
supports-test: yes
supports-eeprom-access: yes
supports-register-dump: yes
supports-priv-flags: no

# modinfo ixgbe | head
filename:       /lib/modules/3.16.0-4-amd64/kernel/drivers/net/ethernet/intel/ixgbe/ixgbe.ko
version:        4.0.3
license:        GPL
description:    Intel(R) 10 Gigabit PCI Express Network Driver
author:         Intel Corporation, <linux.nics@intel.com>
srcversion:     51251F41E617087482AB9D3

Share this post


Link to post
Share on other sites

uname -a я показал еще вчера

# uname -a
Linux rd1 3.16.0-4-amd64 #1 SMP Debian 3.16.7-ckt9-3~deb8u1 (2015-04-24) x86_64 GNU/Linux

 

а из dmesg что надо? момент падения я показал, до этого там только сообщения типа

Jun  5 05:07:23 rd1 kernel: [ 5231.431053] device eth2.160 entered promiscuous mode
Jun  5 05:07:23 rd1 kernel: [ 5231.431149] device eth2 entered promiscuous mode
Jun  5 05:07:23 rd1 kernel: [ 5231.636185] device eth2.160 left promiscuous mode
Jun  5 05:07:23 rd1 kernel: [ 5231.636274] device eth2 left promiscuous mode

в большом кол-ве, в большинстве случаев кроме этого и нету ничего.

Share this post


Link to post
Share on other sites

с драйвером помогло, ночью продолжу тесты.

получается modinfo показывает данные модуля, который лежит на фс, а не реально загружен.

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