From: Hugh Dickins <hughd@google.com>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Zlatko Calusic <zlatko.calusic@iskon.hr>,
Borislav Petkov <bp@alien8.de>,
Andrew Morton <akpm@linux-foundation.org>,
Mel Gorman <mgorman@suse.de>,
Johannes Weiner <hannes@cmpxchg.org>,
Rik van Riel <riel@redhat.com>, linux-mm <linux-mm@kvack.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: kswapd craziness in 3.7
Date: Mon, 10 Dec 2012 15:27:08 -0800 (PST) [thread overview]
Message-ID: <alpine.LNX.2.00.1212101512040.1482@eggly.anvils> (raw)
In-Reply-To: <CA+55aFx9XSjtMZNuveyKrxL0LUjmZpFvJ7vzkjaKgQZLCs9QCg@mail.gmail.com>
On Mon, 10 Dec 2012, Linus Torvalds wrote:
> [ Adding High Dickins because of the shmem oops. ]
I had already noticed, and was about to reply; but only then refreshed
my mbox window, to find that you've already done it all for me: thanks.
>
> On Mon, Dec 10, 2012 at 12:35 PM, Zlatko Calusic
> <zlatko.calusic@iskon.hr> wrote:
> >
> > And funny thing that you mention i915, because yesterday my daughter managed to lock up our laptop hard (that was a first), and this is what I found in kern.log after restart:
> >
> > Dec 9 21:29:42 titan vmunix: general protection fault: 0000 [#1] PREEMPT SMP
> > Dec 9 21:29:42 titan vmunix: Modules linked in: vboxpci(O) vboxnetadp(O) vboxnetflt(O) vboxdrv(O) [last unloaded: microcode]
> > Dec 9 21:29:42 titan vmunix: CPU 2
> > Dec 9 21:29:42 titan vmunix: Pid: 2523, comm: Xorg Tainted: G O 3.7.0-rc8 #1 Hewlett-Packard HP Pavilion dv7 Notebook PC/144B
> > Dec 9 21:29:42 titan vmunix: RIP: 0010:[<ffffffff81090b9c>] [<ffffffff81090b9c>] find_get_page+0x3c/0x90
>
> Ho humm..
>
> I'm not convinced this is related.
>
> > Dec 9 21:29:42 titan vmunix: Call Trace:
> > Dec 9 21:29:42 titan vmunix: [<ffffffff81090e21>] find_lock_page+0x21/0x80
> > Dec 9 21:29:42 titan vmunix: [<ffffffff810a1b60>] shmem_getpage_gfp+0xa0/0x620
> > Dec 9 21:29:42 titan vmunix: [<ffffffff810a224c>] shmem_read_mapping_page_gfp+0x2c/0x50
> > Dec 9 21:29:42 titan vmunix: [<ffffffff812b3611>] i915_gem_object_get_pages_gtt+0xe1/0x270
> > Dec 9 21:29:42 titan vmunix: [<ffffffff812b127f>] i915_gem_object_get_pages+0x4f/0x90
> > Dec 9 21:29:42 titan vmunix: [<ffffffff812b1383>] i915_gem_object_bind_to_gtt+0xc3/0x4c0
> > Dec 9 21:29:42 titan vmunix: [<ffffffff812b4413>] i915_gem_object_pin+0x123/0x190
> > Dec 9 21:29:42 titan vmunix: [<ffffffff812b7d97>] i915_gem_execbuffer_reserve_object.isra.13+0x77/0x190
> > Dec 9 21:29:42 titan vmunix: [<ffffffff812b8171>] i915_gem_execbuffer_reserve.isra.14+0x2c1/0x320
> > Dec 9 21:29:42 titan vmunix: [<ffffffff812b87b2>] i915_gem_do_execbuffer.isra.17+0x5e2/0x11b0
> > Dec 9 21:29:42 titan vmunix: [<ffffffff812b9894>] i915_gem_execbuffer2+0x94/0x280
> > Dec 9 21:29:42 titan vmunix: [<ffffffff81287de3>] drm_ioctl+0x493/0x530
> > Dec 9 21:29:42 titan vmunix: [<ffffffff810d9cbf>] do_vfs_ioctl+0x8f/0x530
> > Dec 9 21:29:42 titan vmunix: [<ffffffff810da1ab>] sys_ioctl+0x4b/0x90
> > Dec 9 21:29:42 titan vmunix: [<ffffffff8154a4d2>] system_call_fastpath+0x16/0x1b
> >
> > It seems that whenever (if ever?) GFP_NO_KSWAPD removal is attempted again, the i915 driver will need to be taken better care of.
>
> That decodes to
>
> 11: e8 89 b7 15 00 callq 0x15b79f # radix_tree_lookup_slot
> 16: 48 85 c0 test %rax,%rax
> 19: 48 89 c6 mov %rax,%rsi
> 1c: 74 41 je 0x5f
> 1e: 48 8b 18 mov (%rax),%rbx #
> 21: 48 85 db test %rbx,%rbx
> 24: 74 1f je 0x45
> 26: f6 c3 03 test $0x3,%bl
> 29: 75 3c jne 0x67
> 2b:* 8b 53 1c mov 0x1c(%rbx),%edx <-- trapping instruction
> 2e: 85 d2 test %edx,%edx
> 30: 74 d9 je 0xb
>
> where %rbx is 0x0200000000000000. That looks like it could be a
> single-bit error, and should have been zero.
>
> It's the "atomic_read(&page->counter)" which is part of
> "page_cache_get_speculative()" as far as I can tell, and it's the
> "page" pointer that is that odd (non-pointer) value. The fact that
> %ecx contains the value "-6" makes me wonder if there was a -ENXIO
> somewhere, though.
Yes, just what I was about to say; except I never considered the -6.
I was going to suggest it's a new notebook with not-so-good memory,
but see that Borislav has since made a better suggestion.
>
> None of it looks all that much related to whether the i915 driver uses
> GFP_NO_KSWAPD or not, though.
Yes, no evidence here of anything to delay 3.7 further.
I'm running on current git, and no problems observed; but then, I never
did see any of these kswapd problems anyway. And, in particular, I was
unable to reproduce Zlatko's 1GB of 4GB kept free (on yesterday's tree,
with no swap) - I saw about 100MB kept free.
Hugh
next prev parent reply other threads:[~2012-12-10 23:27 UTC|newest]
Thread overview: 65+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-11-27 20:48 kswapd craziness in 3.7 Johannes Weiner
2012-11-27 20:48 ` [patch] mm: vmscan: fix kswapd endless loop on higher order allocation Johannes Weiner
2012-11-27 20:58 ` kswapd craziness in 3.7 Linus Torvalds
2012-11-27 21:16 ` Rik van Riel
2012-11-27 21:49 ` Johannes Weiner
2012-11-27 22:02 ` Rik van Riel
2012-11-27 22:26 ` Johannes Weiner
2012-11-27 23:19 ` Linus Torvalds
2012-11-28 10:13 ` Mel Gorman
2012-11-28 10:51 ` Thorsten Leemhuis
2012-11-28 16:42 ` Mel Gorman
2012-11-28 22:52 ` Andrew Morton
2012-11-28 23:54 ` Mel Gorman
2012-11-29 0:14 ` Andrew Morton
2012-11-29 15:30 ` Thorsten Leemhuis
2012-11-29 17:05 ` Johannes Weiner
2012-11-30 12:39 ` Thorsten Leemhuis
2012-12-01 0:45 ` Johannes Weiner
2012-12-03 8:30 ` Thorsten Leemhuis
2012-12-03 13:08 ` Fedora repo (was: Re: kswapd craziness in 3.7) Borislav Petkov
2012-12-03 19:42 ` kswapd craziness in 3.7 Johannes Weiner
2012-12-04 21:42 ` Johannes Weiner
2012-12-05 3:01 ` Bruno Wolff III
2012-12-06 17:37 ` Bruno Wolff III
2012-12-06 19:31 ` Linus Torvalds
2012-12-06 19:43 ` Rik van Riel
2012-12-06 20:23 ` Johannes Weiner
2012-12-06 20:32 ` Rik van Riel
2012-12-08 12:06 ` Zlatko Calusic
2012-12-08 21:22 ` Zlatko Calusic
2012-12-09 1:01 ` Linus Torvalds
2012-12-09 21:59 ` Zdenek Kabelac
2012-12-10 11:03 ` Mel Gorman
2012-12-10 16:39 ` Johannes Weiner
2012-12-10 18:01 ` Mel Gorman
2012-12-10 18:33 ` Zlatko Calusic
2012-12-10 19:13 ` Linus Torvalds
2012-12-10 20:35 ` Zlatko Calusic
2012-12-10 21:28 ` Linus Torvalds
2012-12-10 21:42 ` Borislav Petkov
2012-12-10 21:47 ` Linus Torvalds
2012-12-10 21:54 ` Borislav Petkov
2012-12-10 22:15 ` Zlatko Calusic
2012-12-10 23:27 ` Hugh Dickins [this message]
2012-12-11 0:19 ` Zlatko Calusic
2012-12-11 21:56 ` Zlatko Calusic
2012-12-19 22:24 ` Zlatko Calusic
2012-12-10 18:29 ` Zlatko Calusic
2012-12-06 8:09 ` Thorsten Leemhuis
2012-11-27 21:29 ` Johannes Weiner
2012-11-28 13:35 ` Zdenek Kabelac
2012-11-28 14:04 ` Jiri Slaby
2012-11-28 9:45 ` Mel Gorman
2012-12-03 15:23 ` Zdenek Kabelac
2012-12-03 19:18 ` Johannes Weiner
2012-12-04 9:05 ` Zdenek Kabelac
2012-12-04 9:15 ` Jiri Slaby
2012-12-04 16:11 ` Johannes Weiner
2012-12-04 16:22 ` Jiri Slaby
2012-12-04 19:50 ` Johannes Weiner
2012-12-08 10:35 ` Jiri Slaby
2012-12-04 16:15 ` Johannes Weiner
2012-12-06 13:51 ` Zdenek Kabelac
2012-12-03 13:14 ` Jiri Slaby
2012-12-04 8:55 ` Jiri Slaby
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=alpine.LNX.2.00.1212101512040.1482@eggly.anvils \
--to=hughd@google.com \
--cc=akpm@linux-foundation.org \
--cc=bp@alien8.de \
--cc=hannes@cmpxchg.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mgorman@suse.de \
--cc=riel@redhat.com \
--cc=torvalds@linux-foundation.org \
--cc=zlatko.calusic@iskon.hr \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).