#25855 – Kernel panic 1-2 раза в неделю

Bug 25855 - Kernel panic 1-2 раза в неделю

Summary: Kernel panic 1-2 раза в неделю

Status:	CLOSED WONTFIX

Alias:	None

Product:	Sisyphus
Classification:	Development
Component:	kernel-image-ovz-el (show other bugs)
Version:	unstable
Hardware:	all Linux

Importance:	P3 blocker
Assignee:	Gleb F-Malinovskiy
QA Contact:	qa-sisyphus

URL:	http://bugzilla.openvz.org/show_bug.c...
Keywords:

Depends on:
Blocks:

Reported:	2011-07-05 01:22 MSK by Slava Dubrovskiy
Modified:	2019-03-13 10:35 MSK (History)
CC List:	17 users (show)

See Also:

Attachments
vzswap script by Denis Kuznetsov (478 bytes, text/plain) 2011-10-28 11:03 MSK, Michael Shigorin	no flags	Details
View All Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.

Description

Slava Dubrovskiy 2011-07-05 01:22:35 MSK

Есть один сервер на котором периодически (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

Comment 1

aspsk 2011-07-05 12:16:06 MSK

А версия mdadm какая?

Comment 2

Slava Dubrovskiy 2011-07-05 19:05:29 MSK

(В ответ на комментарий №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

Comment 3

Slava Dubrovskiy 2011-07-05 19:16:23 MSK

(В ответ на комментарий №2)
> (В ответ на комментарий №1)
> > А версия mdadm какая?
Таск flush это первый просто в логе. Затем идут трейсы не только по jbd2/dm, но и по java, postgre и другие. В какой-то момент удалось во время повышенной загрузки перед ребутом зайти на сервер, кильнуть честь процессов и на секунд 30 загрузка снизилась, но потом опять начала расти и потом уже ребут. Такое я видел только когда происходит блокировка IO диска. Например при ресайзе на грячую. Именно поэтому грешу на контроллер. И еще в пользу mptsas то, что от других серверов с аналогичной конфигурацией он отличается именно наличием SAS контролеера.
Я попробую собрать новую версию драйвера и попробовать с ним. Если поможет, то тогда будет ясно точно.

Comment 4

Michael Shigorin 2011-07-06 16:50:07 MSK

Тебе, наверное, сюда: http://bugzilla.openvz.org/show_bug.cgi?id=1880

Comment 5

Michael Shigorin 2011-07-06 16:57:46 MSK

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

Comment 6

Michael Shigorin 2011-10-28 11:03:59 MSK

Created attachment 5177 [details]
vzswap script by Denis Kuznetsov

2 dubrsl: что сейчас? (до кучи: http://wiki.openvz.org/Vswap и скриптик dek@)

Comment 7

Slava Dubrovskiy 2011-10-28 11:24:12 MSK

(В ответ на комментарий №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 народ тоже жалуется сильно.

Comment 8

Slava Dubrovskiy 2012-01-01 22:01:19 MSK

В результате этих проблем пришлось отказаться от виртуализации и перенести на 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. Наблюдаю дальше.

Comment 9

Grigory Ustinov 2018-08-13 16:41:08 MSK

Бага всё ещё актуальна?

Comment 10

Sergey Y. Afonin 2019-03-13 10:35:59 MSK

(In reply to comment #9)

> Бага всё ещё актуальна?

Ввиду отсутствия kernel-image-ovz-el в Sisyphus уже, видимо, нет. Теоретически можно на p8 перевесить, но там уже вагон обновлений - alt166 текущее. У меня alt162 нормально работает, но VPS-ка на железном RAID, так что не та конфигурация. Наверное, надо как WONTFIX закрыть.