All of lore.kernel.org
 help / color / mirror / Atom feed
From: Johannes Bauer <dfnsonfsduifb@gmx.de>
To: Jan Kara <jack@suse.cz>
Cc: linux-ext4@vger.kernel.org, linux-mm@kvack.org
Subject: Re: Frequent ext4 oopses with 4.4.0 on Intel NUC6i3SYB
Date: Tue, 4 Oct 2016 18:50:55 +0200	[thread overview]
Message-ID: <90dfe18f-9fe7-819d-c410-cdd160644ab7@gmx.de> (raw)
In-Reply-To: <20161004084136.GD17515@quack2.suse.cz>

On 04.10.2016 10:41, Jan Kara wrote:

> The problem looks like memory corruption:
[...]

Huh, very interesting -- thanks for the walkthrough!

> Anyway, adding linux-mm to CC since this does not look ext4 related but
> rather mm related issue.
> 
> Bugs like these are always hard to catch, usually it's some flaky device
> driver, sometimes also flaky HW. You can try running kernel with various
> debug options enabled in a hope to catch the code corrupting memory
> earlier - e.g. CONFIG_DEBUG_PAGE_ALLOC sometimes catches something,
> CONFIG_SLAB_DEBUG can be useful as well. Another option is to get a
> crashdump when the oops happens (although that's going to be a pain to
> setup on such a small machine) and then look at which places point to
> the corrupted memory - sometimes you can find old structures pointing to
> the place and find the use-after-free issue or stuff like that...

Uhh, that sounds painful. So I'm following Ted's advice and building
myself a 4.8 as we speak.

If the problem is fixed, would it be of any help to trace the source by
going back to the 4.4.0 and reproduce with the debug symbols you
mentioned? I don't think a memdump would be difficult on the machine
(while it certainly has a small form factor, it's got a 1 TB hdd and 16
GB of RAM, so it's not really that small).

Cheers,
Johannes

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

  reply	other threads:[~2016-10-04 16:50 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-10-03 10:52 Frequent ext4 oopses with 4.4.0 on Intel NUC6i3SYB Johannes Bauer
2016-10-04  3:18 ` Theodore Ts'o
2016-10-04  8:41 ` Jan Kara
2016-10-04 16:50   ` Johannes Bauer [this message]
2016-10-04 17:32     ` Johannes Bauer
2016-10-04 17:32       ` Johannes Bauer
2016-10-04 18:45       ` Andrey Korolyov
2016-10-04 18:45         ` Andrey Korolyov
2016-10-04 19:02         ` Johannes Bauer
2016-10-04 19:02           ` Johannes Bauer
2016-10-04 19:55         ` Johannes Bauer
2016-10-04 19:55           ` Johannes Bauer
2016-10-04 20:17           ` Andrey Korolyov
2016-10-04 20:17             ` Andrey Korolyov
2016-10-04 21:54             ` Johannes Bauer
2016-10-04 21:54               ` Johannes Bauer
2016-10-05  6:20               ` Jan Kara
2016-10-04 20:18         ` Johannes Bauer
2016-10-04 20:18           ` Johannes Bauer

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=90dfe18f-9fe7-819d-c410-cdd160644ab7@gmx.de \
    --to=dfnsonfsduifb@gmx.de \
    --cc=jack@suse.cz \
    --cc=linux-ext4@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.