Bug 93491 - Kernel crashes every 10 minutes. Computer stalls
Summary: Kernel crashes every 10 minutes. Computer stalls
Status: CLOSED OBSOLETE
Alias: None
Product: File System
Classification: Unclassified
Component: ext4 (show other bugs)
Hardware: All Linux
: P1 blocking
Assignee: fs_ext4@kernel-bugs.osdl.org
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2015-02-19 10:03 UTC by Ionut Radu
Modified: 2018-09-12 10:25 UTC (History)
4 users (show)

See Also:
Kernel Version: 3.18.7-200.fc21.x86_64
Subsystem:
Regression: No
Bisected commit-id:

Attachments
abrt message (26.16 KB, image/png)
2015-02-19 10:03 UTC, Ionut Radu 		Details
dmesg after reboot (59.61 KB, text/x-log)
2015-02-19 16:36 UTC, Ionut Radu 		Details
Add an attachment (proposed patch, testcase, etc.)

Description Ionut Radu 2015-02-19 10:03:31 UTC 
Created attachment 167541 [details]
abrt message

With the latest kernel, there are crashes every 10 minutes and computer stalls.
After reboot ABRT displays : 
kernel BUG at fs/ext4/mballoc.c:3272!
Comment 1 Eric Sandeen 2015-02-19 16:13:47 UTC 
in static void ext4_mb_use_inode_pa(),

	BUG_ON(start < pa->pa_pstart);
	BUG_ON(end > pa->pa_pstart + EXT4_C2B(sbi, pa->pa_len));
	BUG_ON(pa->pa_free < len);  <<<<---- here

It'd be good to have full dmesg etc, this is a pretty sparse bug report.  Did a fedora bug get filed from abrt?

It might be worth booting a rescue environment and capturing an e2image -r or e2iamge -q of the filesystem, to see if this is caused by on-disk corruption somehow.
Comment 2 Ionut Radu 2015-02-19 16:36:38 UTC 
Created attachment 167571 [details]
dmesg after reboot




I've attached dmesg after reboot.
A fedora bug was not filled by the abrt. Computer stalled and after reboot abrt 
tells there is not enough data to report a bug.

After computer stall and forced turn off, filesystem got corrupted and was fixed via emergency disk with fsck.
Comment 3 Eric Sandeen 2015-02-19 16:45:56 UTC 
dmesg after reboot won't be helpful, I'm afraid.

If the fs was corrupt and fixed, but output not saved, and no further information is available from the crash, this will be very hard to resolve.
Comment 4 Ionut Radu 2015-02-20 09:10:22 UTC 
Hi Eric,

I see there are some oops dumps from abrt. 
Can you please take a look ?

https://www.dropbox.com/sh/dq0ocnrgocsuuzk/AABpo4_8PJjBFI_X0WBekI7Fa?dl=0
Comment 5 Eric Sandeen 2015-02-20 15:16:47 UTC 
That's a lot to look through; the first dmesg I grabbed had no oops in it, and dropbox is a little tedious to navigate.

If there's an interesting one, can you attach it here?
Comment 6 Ionut Radu 2015-02-20 15:25:41 UTC 

Hi Eric,

I don't know what you are looking for, so I can't tell if a dmesg is interesting or not.
Can't you temporary copy all of them to your disk if you find dropbox tedious to navigate ?
Comment 7 Eric Sandeen 2015-02-20 15:56:41 UTC 
sure, let me do that for you....

the only files which contain "kernel BUG" are "backtrace" and "reason" files, and they have no other information:

$ cat oops-2015-02-19-09:46:07-817-0/reason
kernel BUG at fs/ext4/mballoc.c:3272!

so there's still not much to go on.  I don't know why abrt didn't capture more.
Comment 8 Ionut Radu 2015-02-20 16:09:48 UTC 

Probably because the abrt is collecting data after reboot if computer stalls.
Comment 9 Carlos Maiolino 2015-03-03 18:38:40 UTC 
Can you collect data before the reboot then?

sysrq or serial console maybe?
Comment 10 Ionut Radu 2015-03-03 19:55:52 UTC 
No, I'm sorry. That's all I can provide.
Comment 11 Ionut Radu 2018-09-12 10:24:46 UTC 
Issue was fixed.
Note You need to log in before you can comment on or make changes to this bug.