25855 2011-07-05 01:22:35 +0400 Kernel panic 1-2 раза в неделю 2019-03-13 10:35:59 +0300 1 1 4 Development Sisyphus kernel-image-ovz-el unstable all Linux CLOSED WONTFIX http://bugzilla.openvz.org/show_bug.cgi?id=1880 P3 blocker --- 1 dubrsl glebfm asy boyarsh enp glebfm grenka kernelbot ldv mike mithraen rider sbolshakov shrek sin vitty vsu vt zerg qa-sisyphus oldest_to_newest 122855 0 dubrsl 2011-07-05 01:22:35 +0400 Есть один сервер на котором периодически (1-2 раза в неделю) происходит ребут в результате kernel panic. Перед ребутом LA уходит в космос - выше 200. Ядро 2.6.32-ovz-el-alt24 Стоит 2 SATA диска в raid1 на mdadm на котором установлена система и все служебные VPS И 2 SAS диска из которых собран софтовый raid1 на базе: 04:00.0 SCSI storage controller: LSI Logic / Symbios Logic SAS1064ET PCI-Express Fusion-MPT SAS (rev 02) Subsystem: Intel Corporation Device 3479 Flags: bus master, fast devsel, latency 0, IRQ 17 I/O ports at 3000 [size=256] Memory at b8910000 (64-bit, non-prefetchable) [size=16K] Memory at b8900000 (64-bit, non-prefetchable) [size=64K] Expansion ROM at b8e00000 [disabled] [size=2M] Capabilities: [50] Power Management version 2 Capabilities: [68] Express Endpoint, MSI 00 Capabilities: [98] MSI: Enable- Count=1/1 Maskable- 64bit+ Capabilities: [b0] MSI-X: Enable- Count=1 Masked- Capabilities: [100] Advanced Error Reporting Kernel driver in use: mptsas Kernel modules: mptsas и с него работает одна рабочая VPS. Диски по smart живые, ошибок нет. Есть подозрение на модуль mptsas, т.к. вот подобный баг https://bugzilla.redhat.com/show_bug.cgi?id=493093 В логе вот такое перед ребутом вижу: Jul 4 21:05:51 ua83 kernel: [293760.725062] INFO: task flush-253:1:1294 blocked for more than 120 seconds. Jul 4 21:05:59 ua83 kernel: [293760.725069] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. Jul 4 21:06:26 ua83 kernel: [293760.725074] flush-253:1 D ffff8801dcb82c90 0 1294 2 0x00000000 Jul 4 21:07:33 ua83 kernel: [293760.725083] ffff8801d5a0ba10 0000000000000046 0000000000000000 ffffffffa02cc12c Jul 4 21:07:33 ua83 kernel: [293760.725091] ffff88013696e5a8 ffffffff811b3e70 ffffffffa00d3c40 00000001117b8ec4 Jul 4 21:07:33 ua83 kernel: [293760.725098] ffff8801dcb83270 ffff8801d5a0bfd8 000000000000f7c8 ffff8801dcb83270 Jul 4 21:07:33 ua83 kernel: [293760.725106] Call Trace: Jul 4 21:07:33 ua83 kernel: [293760.725132] [<ffffffffa02cc12c>] ? dm_table_unplug_all+0x5c/0xd0 [dm_mod] Jul 4 21:07:33 ua83 kernel: [293760.725155] [<ffffffff811b3e70>] ? end_buffer_async_write+0x0/0x190 Jul 4 21:07:33 ua83 kernel: [293760.725185] [<ffffffffa00d3c40>] ? ext4_bh_delay_or_unwritten+0x0/0x30 [ext4] Jul 4 21:07:33 ua83 kernel: [293760.725195] [<ffffffff813ff403>] io_schedule+0xa3/0x110 Jul 4 21:07:33 ua83 kernel: [293760.725202] [<ffffffff8111a6e0>] ? sync_page+0x0/0x50 Jul 4 21:07:45 ua83 kernel: [293760.725207] [<ffffffff8111a71d>] sync_page+0x3d/0x50 Jul 4 21:08:27 ua83 kernel: [293760.725212] [<ffffffff813ffc8f>] __wait_on_bit+0x5f/0x90 Jul 4 21:08:29 ua83 kernel: [293760.725218] [<ffffffff8111a8d3>] wait_on_page_bit+0x73/0x80 Jul 4 21:08:38 ua83 kernel: [293760.725225] [<ffffffff81091a30>] ? wake_bit_function+0x0/0x50 Jul 4 21:08:38 ua83 kernel: [293760.725234] [<ffffffff81131355>] ? pagevec_lookup_tag+0x25/0x40 Jul 4 21:08:38 ua83 kernel: [293760.725239] [<ffffffff8111ac9b>] wait_on_page_writeback_range+0xfb/0x190 Jul 4 21:08:38 ua83 kernel: [293760.725245] [<ffffffff8111ad5f>] filemap_fdatawait+0x2f/0x40 Jul 4 21:08:38 ua83 kernel: [293760.725252] [<ffffffff811ab418>] writeback_single_inode+0x238/0x2e0 Jul 4 21:08:38 ua83 kernel: [293760.725258] [<ffffffff811ab706>] writeback_sb_inodes+0xf6/0x1b0 Jul 4 21:08:38 ua83 kernel: [293760.725263] [<ffffffff811abae0>] wb_writeback+0x170/0x400 Jul 4 21:08:38 ua83 kernel: [293760.725268] [<ffffffff813feb4c>] ? thread_return+0x4e/0x862 Jul 4 21:08:38 ua83 kernel: [293760.725276] [<ffffffff8107c7ba>] ? del_timer_sync+0x2a/0x40 Jul 4 21:08:38 ua83 kernel: [293760.725281] [<ffffffff811abe35>] wb_do_writeback+0xc5/0x250 Jul 4 21:08:38 ua83 kernel: [293760.725286] [<ffffffff8107bd20>] ? process_timeout+0x0/0x10 Jul 4 21:08:38 ua83 kernel: [293760.725292] [<ffffffff811ac027>] bdi_writeback_task+0x67/0x1c0 Jul 4 21:08:38 ua83 kernel: [293760.725297] [<ffffffff810918c7>] ? bit_waitqueue+0x17/0xc0 Jul 4 21:08:38 ua83 kernel: [293760.725305] [<ffffffff81141556>] bdi_start_fn+0x86/0x100 Jul 4 21:08:38 ua83 kernel: [293760.725310] [<ffffffff811414d0>] ? bdi_start_fn+0x0/0x100 Jul 4 21:08:38 ua83 kernel: [293760.725315] [<ffffffff81091680>] kthread+0xc0/0xe0 Jul 4 21:08:38 ua83 kernel: [293760.725321] [<ffffffff8100c2ca>] child_rip+0xa/0x20 Jul 4 21:08:38 ua83 kernel: [293760.725326] [<ffffffff810915c0>] ? kthread+0x0/0xe0 Jul 4 21:08:38 ua83 kernel: [293760.725331] [<ffffffff8100c2c0>] ? child_rip+0x0/0x20 Jul 4 21:08:38 ua83 kernel: [293760.725336] INFO: task jbd2/dm-1-8:1306 blocked for more than 120 seconds. Jul 4 21:09:58 ua83 kernel: [293760.725340] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. Jul 4 21:10:37 ua83 kernel: [293760.725344] jbd2/dm-1-8 D ffff8801da9ea640 0 1306 2 0x00000000 Jul 4 21:10:38 ua83 kernel: [293760.725351] ffff8801d4951b00 0000000000000046 ffff8801d4951ac0 ffffffffa02cc12c Jul 4 21:10:38 ua83 kernel: [293760.725358] ffff880119e48808 ffff880119eddb40 ffff8801d4951ab0 ffffffff8109c569 Jul 4 21:10:38 ua83 kernel: [293760.725365] ffff8801da9eac20 ffff8801d4951fd8 000000000000f7c8 ffff8801da9eac20 Jul 4 21:10:38 ua83 kernel: [293760.725372] Call Trace: Jul 4 21:10:38 ua83 kernel: [293760.725381] [<ffffffffa02cc12c>] ? dm_table_unplug_all+0x5c/0xd0 [dm_mod] Jul 4 21:10:38 ua83 kernel: [293760.725388] [<ffffffff8109c569>] ? ktime_get_ts+0xa9/0xe0 Jul 4 21:10:38 ua83 kernel: [293760.725394] [<ffffffff8109c569>] ? ktime_get_ts+0xa9/0xe0 Jul 4 21:10:38 ua83 kernel: [293760.725399] [<ffffffff813ff403>] io_schedule+0xa3/0x110 Jul 4 21:10:38 ua83 kernel: [293760.725404] [<ffffffff8111a6e0>] ? sync_page+0x0/0x50 Jul 4 21:10:38 ua83 kernel: [293760.725409] [<ffffffff8111a71d>] sync_page+0x3d/0x50 Jul 4 21:10:38 ua83 kernel: [293760.725414] [<ffffffff813ffc8f>] __wait_on_bit+0x5f/0x90 Jul 4 21:10:38 ua83 kernel: [293760.725419] [<ffffffff8111a8d3>] wait_on_page_bit+0x73/0x80 Jul 4 21:10:38 ua83 kernel: [293760.725425] [<ffffffff81091a30>] ? wake_bit_function+0x0/0x50 Jul 4 21:10:38 ua83 kernel: [293760.725430] [<ffffffff81131355>] ? pagevec_lookup_tag+0x25/0x40 Jul 4 21:10:38 ua83 kernel: [293760.725436] [<ffffffff8111ac9b>] wait_on_page_writeback_range+0xfb/0x190 Jul 4 21:10:38 ua83 kernel: [293760.725443] [<ffffffff811b7c9b>] ? bio_alloc_bioset+0x5b/0xf0 Jul 4 21:10:38 ua83 kernel: [293760.725449] [<ffffffff8111ad5f>] filemap_fdatawait+0x2f/0x40 Jul 4 21:10:38 ua83 kernel: [293760.725462] [<ffffffffa00a7ec0>] jbd2_journal_commit_transaction+0x7f0/0x1490 [jbd2] Jul 4 21:10:38 ua83 kernel: [293760.725469] [<ffffffff810919f0>] ? autoremove_wake_function+0x0/0x40 Jul 4 21:10:38 ua83 kernel: [293760.725480] [<ffffffffa00ad978>] kjournald2+0xb8/0x220 [jbd2] Jul 4 21:10:38 ua83 kernel: [293760.725486] [<ffffffff810919f0>] ? autoremove_wake_function+0x0/0x40 Jul 4 21:10:38 ua83 kernel: [293760.725496] [<ffffffffa00ad8c0>] ? kjournald2+0x0/0x220 [jbd2] Jul 4 21:10:38 ua83 kernel: [293760.725501] [<ffffffff81091680>] kthread+0xc0/0xe0 Jul 4 21:10:38 ua83 kernel: [293760.725506] [<ffffffff8100c2ca>] child_rip+0xa/0x20 Jul 4 21:10:38 ua83 kernel: [293760.725511] [<ffffffff810915c0>] ? kthread+0x0/0xe0 Jul 4 21:10:38 ua83 kernel: [293760.725516] [<ffffffff8100c2c0>] ? child_rip+0x0/0x20 122864 1 aspsk 2011-07-05 12:16:06 +0400 А версия mdadm какая? 122884 2 dubrsl 2011-07-05 19:05:29 +0400 (В ответ на комментарий №1) > А версия mdadm какая? mdadm-3.1.4-alt3 # mdadm --detail --scan ARRAY /dev/md0 metadata=0.90 UUID=5358b5ea:5ad7b5e6:e1095869:f818a80e ARRAY /dev/md2 metadata=0.90 UUID=9196ae44:14b5a12b:cd83f0b5:6c2d613c ARRAY /dev/md1 metadata=0.90 UUID=a4fdfb3b:687860ee:672934b9:16b0b41b 122885 3 dubrsl 2011-07-05 19:16:23 +0400 (В ответ на комментарий №2) > (В ответ на комментарий №1) > > А версия mdadm какая? Таск flush это первый просто в логе. Затем идут трейсы не только по jbd2/dm, но и по java, postgre и другие. В какой-то момент удалось во время повышенной загрузки перед ребутом зайти на сервер, кильнуть честь процессов и на секунд 30 загрузка снизилась, но потом опять начала расти и потом уже ребут. Такое я видел только когда происходит блокировка IO диска. Например при ресайзе на грячую. Именно поэтому грешу на контроллер. И еще в пользу mptsas то, что от других серверов с аналогичной конфигурацией он отличается именно наличием SAS контролеера. Я попробую собрать новую версию драйвера и попробовать с ним. Если поможет, то тогда будет ясно точно. 122915 4 mike 2011-07-06 16:50:07 +0400 Тебе, наверное, сюда: http://bugzilla.openvz.org/show_bug.cgi?id=1880 122916 5 mike 2011-07-06 16:57:46 +0400 PS: mptsas у меня прекрасно себя чувствует на: * SAS1068 под 2.6.18-ovz-rhel-alt13.M51.15; * SAS1064ET под 2.6.32-ovz-el-alt{10,13}. Обе машинки без нареканий. А похожее было на набортном sata_nv под 2.6.32-ovz-el-alt{17,22,23}. 126596 6 5177 mike 2011-10-28 11:03:59 +0400 Created attachment 5177 vzswap script by Denis Kuznetsov 2 dubrsl: что сейчас? (до кучи: http://wiki.openvz.org/Vswap и скриптик dek@) 126598 7 dubrsl 2011-10-28 11:24:12 +0400 (В ответ на комментарий №6) > Created an attachment (id=5177) [details] > vzswap script by Denis Kuznetsov > > 2 dubrsl: что сейчас? (до кучи: http://wiki.openvz.org/Vswap и скриптик dek@) Ну это давно сделано (vswap) в ручном режиме. По сути - Все плохо. Есть около десятка серверов. В целом конечно работает, но периодически бывают зависы не ясной этиологии. Я связываю с повышенной нагрузкой. Т.е. если нагрузки нет - то работает. Конкретно этот сервер последний месяц не ребутался. Но есть другой (бэкапный) который при включенной бакуле в контейнере стабильно зависает. Причем так что даже в netconsole ничего записать не успевает. На экране тоже темно. Вообщем я не спешу переводить сервера с 2.6.18 на 2.6.32. До стабильности еще далековато. Новые сервера конечно приходится сетапить на новом, но от безвыходности. В рассылке proxmox народ тоже жалуется сильно. 128023 8 dubrsl 2012-01-01 22:01:19 +0400 В результате этих проблем пришлось отказаться от виртуализации и перенести на HN все задачи. На std-def сервер работал месяц нормально. Вчера нужно было запустить одну виртуалку, в которой только ssd. Сразу получил завис 2 раза. При этом в netconsole удалось выловить Jan 1 07:25:05 ua56 [119519.441047] EDAC MC0: UE row 0, channel-a= 0 channel-b= 1 labels "-": (Branch=0 DRAM-Bank=0 RDWR=Read RAS=0 CAS=0, UE Err=0x20 (Non-Aliased Uncorrectable Non-Mirrored Demand Data ECC)) Jan 1 07:27:13 ua56 [119647.543061] EDAC MC0: UE row 0, channel-a= 0 channel-b= 1 labels "-": (Branch=0 DRAM-Bank=0 RDWR=Read RAS=0 CAS=0, UE Err=0x20 (Non-Aliased Uncorrectable Non-Mirrored Demand Data ECC)) Jan 1 07:29:03 ua56 [119757.359456] EDAC MC0: UE row 0, channel-a= 0 channel-b= 1 labels "-": (Branch=0 DRAM-Bank=0 RDWR=Read RAS=0 CAS=0, UE Err=0x20 (Non-Aliased Uncorrectable Non-Mirrored Demand Data ECC)) Jan 1 07:29:04 ua56 [119758.606068] EDAC MC0: UE row 0, channel-a= 0 channel-b= 1 labels "-": (Branch=0 DRAM-Bank=0 RDWR=Read RAS=0 CAS=0, UE Err=0x20 (Non-Aliased Uncorrectable Non-Mirrored Demand Data ECC)) Jan 1 07:30:40 ua56 [119854.491555] EDAC MC0: UE row 0, channel-a= 0 channel-b= 1 labels "-": (Branch=0 DRAM-Bank=0 RDWR=Read RAS=0 CAS=0, UE Err=0x20 (Non-Aliased Uncorrectable Non-Mirrored Demand Data ECC)) Jan 1 07:30:41 ua56 [119855.761699] EDAC MC0: UE row 0, channel-a= 0 channel-b= 1 labels "-": (Branch=0 DRAM-Bank=0 RDWR=Read RAS=0 CAS=0, UE Err=0x20 (Non-Aliased Uncorrectable Non-Mirrored Demand Data ECC)) Что привило на мысль о проблемах с edac. Нагуглилась схожая проблема: http://lists.us.dell.com/pipermail/linux-poweredge/2010-October/043457.html Попробовал выгрузить модуль и поставить в blacklist. Наблюдаю дальше. 173363 9 grenka 2018-08-13 16:41:08 +0300 Бага всё ещё актуальна? 179402 10 asy 2019-03-13 10:35:59 +0300 (In reply to comment #9) > Бага всё ещё актуальна? Ввиду отсутствия kernel-image-ovz-el в Sisyphus уже, видимо, нет. Теоретически можно на p8 перевесить, но там уже вагон обновлений - alt166 текущее. У меня alt162 нормально работает, но VPS-ка на железном RAID, так что не та конфигурация. Наверное, надо как WONTFIX закрыть. 5177 2011-10-28 11:03:59 +0400 2011-10-28 11:03:59 +0400 vzswap script by Denis Kuznetsov vzswap text/plain 478 mike IyEvYmluL3NoCgpWRUlEPSIkMSIKUkFNPSIkMiIKU1dBUD0iJDMiCmlmIFsgLXogIiRWRUlEIiAt byAteiAiJFJBTSIgLW8gLXogIiRTV0FQIiBdCnRoZW4KCWVjaG8gUnVuOiAkMCBWRUlEIFJBTSBT V0FQCglleGl0IDEKZmkKCk1FTVRPVEFMPSQoYXdrICcvXk1lbVRvdGFsOi8geyBwcmludCAkMjsg fScgL3Byb2MvYmMvMC9tZW1pbmZvICkKUEhZU1BBR0VTPSRSQU0KCmVjaG8gdnpjdGwgc2V0ICRW RUlEIC0tc2F2ZSAtLXBoeXNwYWdlcyAke1JBTX1NICAtLXN3YXBwYWdlcyAke1NXQVB9TSBcXApl Y2hvICIgICAtLXByaXZ2bXBhZ2VzICQoKE1FTVRPVEFMKjUvMTApKUs6JCgoTUVNVE9UQUwqNi8x MCkpSyBcXCIKZWNobyAiICAgLS1rbWVtc2l6ZSAgJCgoKCR7UkFNfSo5KS8yMCkpTTokKCgke1JB TX0vMikpTSBcXCIKZWNobyAiICAgLS1kY2FjaGVzaXplICQoKCR7UkFNfS80KSlNIC0tbG9ja2Vk cGFnZXMgJCgoJHtSQU19LzIpKU0iCg==