I'm also affected by this bug on Trusty with the latest kernel
(3.13.0-53-generic):
[500345.624596] BUG: soft lockup - CPU#0 stuck for 23s! [khugepaged:54]
[500345.630989] Modules linked in: ipt_REJECT btrfs ufs qnx4
hfsplus[500345.636604] BUG: soft lockup - CPU#1 stuck for 23s! [kthreadd:2]
I've hit this bug the second time within one week on a 24/7 Server
system. Is there any workaround for this, currently I'm thinking about
switching from ext4 to ext3.
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
Bianco,
based on my comment #1:
...
Finally we arrive at ext4_es_lru_del(struct inode *inode):
1023 spin_lock(sbi-s_es_lru_lock);
The task is hang and someone is holding this lock. I would have to have this
core to know who and why.
...
Could you provide me a kdump ?
If you are not aware
Bianco Veigel, it will help immensely if you filed a new report via a terminal:
ubuntu-bug linux
Please feel free to subscribe me to it.
** Changed in: linux (Ubuntu)
Status: Confirmed = Incomplete
--
You received this bug notification because you are a member of Kernel
Packages, which
[Expired for linux (Ubuntu) because there has been no activity for 60
days.]
** Changed in: linux (Ubuntu)
Status: Incomplete = Expired
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
For the other back trace (the one I have the core and can use crash tool):
* I'm still analysing this...
PID: 4453 TASK: 8800362dddc0 CPU: 16 COMMAND: git
#0 [880092791a60] machine_kexec at 8104b141
#1 [880092791ad0] crash_kexec at 810d5a58
#2 [880092791ba0]
continuing on the back trace:
#8 [880092791dd0] page_fault at 81747e98
[exception RIP: kmem_cache_alloc+102]
RIP: 8119c316 RSP: 880092791e88 RFLAGS: 00010286
RAX: RBX: ffea RCX: 26be
RDX: 26bd RSI: 00d0
For This specific back trace...
Oct 15 14:19:08 LGEARND8B5 kernel: [796493.152776] [8128eb02]
ext4_es_lru_del+0x32/0x80
Oct 15 14:19:08 LGEARND8B5 kernel: [796493.152781] [81270595]
ext4_clear_inode+0x45/0x90
Oct 15 14:19:08 LGEARND8B5 kernel: [796493.152786]
Small comment:
We might be dealing with 2 different situations/bugs for the two
different stack traces we got (possible race condition / deadlock for
the ext4 page flush for high memory pressure AND kmem_cache_alloc trying
to access wrong addresses)...
As I said, investigating both and checking
For the kmem_cache_alloc problem I found a really promising fix saying
that the commit:
commit ba5bb147330a8737b6b5a812cc774c79c070704b
Author: Al Viro v...@zeniv.linux.org.uk
Date: Thu Mar 21 02:21:19 2013 -0400
pipe: take allocation and freeing of pipe_inode_info out of -i_mutex
present
I'm going to mark this bug as invalid for now, since it is reported
against an EOL Saucy kernel. Please mark the bug as confirmed if the
issue still persists with Trusty/3.13.
** Changed in: linux (Ubuntu)
Importance: Undecided = Medium
--
You received this bug notification because you are
Rafael David Tinoco, thank you for reporting this and helping make
Ubuntu better. The Saucy enablement kernel has been EoL since August
2014 as per https://wiki.ubuntu.com/Kernel/LTSEnablementStack .
While it appears you have a thorough analysis of the root cause, your
best bet would be to
12 matches
Mail list logo
