From: Ross Zwisler <ross.zwisler-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
To: Jan Kara <jack-AlSwsSmVLrQ@public.gmane.org>
Cc: linux-fsdevel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-nvdimm-y27Ovi1pjclAfugRpC6u6w@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Subject: Re: LTP rwtest01 blocks on DAX mountpoint
Date: Mon, 2 Jan 2017 14:49:41 -0700 [thread overview]
Message-ID: <20170102214941.GA2813@linux.intel.com> (raw)
In-Reply-To: <20170102171617.GA23612-4I4JzKEfoa/jFM9bn6wA6Q@public.gmane.org>
On Mon, Jan 02, 2017 at 06:16:17PM +0100, Jan Kara wrote:
> On Fri 30-12-16 17:33:53, Xiong Zhou wrote:
> > On Sat, Dec 24, 2016 at 07:07:14PM +0800, Xiong Zhou wrote:
> > > Hi lists,
> > >
> > > Since around 20161129 tag, LTP rwtest01 on dax mountpoint blocks
> > > on linux-next tree, now on Linus tree.
> > >
> > > In "normal", rwtest01 subcase ends in a few minutes, now it keeps
> > > running for hours on dax mountpoint, both ext4 and xfs. Ctrl + c
> > > can interrupt it.
> >
> > Test programme is waiting for a memcpy call to return.
> >
> > From sysrq output, kernel code is not blocking on somewhere,
> > it just wont return.
>
> I was trying to reproduce this but for me rwtest01 completes just fine on
> dax mountpoint (I've used your reproducer). So can you sample several
> kernel stack traces to get a rough idea where the kernel is running?
> Thanks!
>
> Honza
I'm also unable to reproduce this issue. I've tried with both the blamed
commit:
4b4bb46 (HEAD) dax: clear dirty entry tags on cache flush
and with v4.9-rc2. Both pass the test in my setup.
Perhaps the variable is the size of your PMEM partitions?
# fdisk -l /dev/pmem0
Disk /dev/pmem0: 16 GiB, 17179869184 bytes, 33554432 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disklabel type: dos
Disk identifier: 0xfe50c900
Device Boot Start End Sectors Size Id Type
/dev/pmem0p1 4096 25165823 25161728 12G 83 Linux
/dev/pmem0p2 25165824 33550335 8384512 4G 83 Linux
What does your setup look like?
I'm using the current tip of the LTP tree:
8cc4165 waitid02: define _XOPEN_SOURCE 500
Thanks,
- Ross
WARNING: multiple messages have this Message-ID (diff)
From: Ross Zwisler <ross.zwisler@linux.intel.com>
To: Jan Kara <jack@suse.cz>
Cc: Xiong Zhou <xzhou@redhat.com>,
linux-fsdevel@vger.kernel.org, linux-nvdimm@ml01.01.org,
linux-kernel@vger.kernel.org
Subject: Re: LTP rwtest01 blocks on DAX mountpoint
Date: Mon, 2 Jan 2017 14:49:41 -0700 [thread overview]
Message-ID: <20170102214941.GA2813@linux.intel.com> (raw)
In-Reply-To: <20170102171617.GA23612@quack2.suse.cz>
On Mon, Jan 02, 2017 at 06:16:17PM +0100, Jan Kara wrote:
> On Fri 30-12-16 17:33:53, Xiong Zhou wrote:
> > On Sat, Dec 24, 2016 at 07:07:14PM +0800, Xiong Zhou wrote:
> > > Hi lists,
> > >
> > > Since around 20161129 tag, LTP rwtest01 on dax mountpoint blocks
> > > on linux-next tree, now on Linus tree.
> > >
> > > In "normal", rwtest01 subcase ends in a few minutes, now it keeps
> > > running for hours on dax mountpoint, both ext4 and xfs. Ctrl + c
> > > can interrupt it.
> >
> > Test programme is waiting for a memcpy call to return.
> >
> > From sysrq output, kernel code is not blocking on somewhere,
> > it just wont return.
>
> I was trying to reproduce this but for me rwtest01 completes just fine on
> dax mountpoint (I've used your reproducer). So can you sample several
> kernel stack traces to get a rough idea where the kernel is running?
> Thanks!
>
> Honza
I'm also unable to reproduce this issue. I've tried with both the blamed
commit:
4b4bb46 (HEAD) dax: clear dirty entry tags on cache flush
and with v4.9-rc2. Both pass the test in my setup.
Perhaps the variable is the size of your PMEM partitions?
# fdisk -l /dev/pmem0
Disk /dev/pmem0: 16 GiB, 17179869184 bytes, 33554432 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disklabel type: dos
Disk identifier: 0xfe50c900
Device Boot Start End Sectors Size Id Type
/dev/pmem0p1 4096 25165823 25161728 12G 83 Linux
/dev/pmem0p2 25165824 33550335 8384512 4G 83 Linux
What does your setup look like?
I'm using the current tip of the LTP tree:
8cc4165 waitid02: define _XOPEN_SOURCE 500
Thanks,
- Ross
next prev parent reply other threads:[~2017-01-02 21:49 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-12-24 11:07 LTP rwtest01 blocks on DAX mountpoint Xiong Zhou
2016-12-24 11:07 ` Xiong Zhou
[not found] ` <20161224110714.mp2mevzwkhlxm7zw-obHvtwIU90hQcClZ3XN9yxcY2uh10dtjAL8bYrjMMd8@public.gmane.org>
2016-12-30 9:33 ` Xiong Zhou
2016-12-30 9:33 ` Xiong Zhou
[not found] ` <20161230093352.efidonh4btdbtaze-E9dkjZ7ERC1QcClZ3XN9yxcY2uh10dtjAL8bYrjMMd8@public.gmane.org>
2017-01-02 10:05 ` Jan Kara
2017-01-02 10:05 ` Jan Kara
2017-01-02 17:16 ` Jan Kara
2017-01-02 17:16 ` Jan Kara
[not found] ` <20170102171617.GA23612-4I4JzKEfoa/jFM9bn6wA6Q@public.gmane.org>
2017-01-02 21:49 ` Ross Zwisler [this message]
2017-01-02 21:49 ` Ross Zwisler
2017-01-03 6:49 ` Xiong Zhou
[not found] ` <20170103064922.o6v5dlq7pylhir36-E9dkjZ7ERC1QcClZ3XN9yxcY2uh10dtjAL8bYrjMMd8@public.gmane.org>
2017-01-03 16:57 ` Ross Zwisler
2017-01-03 16:57 ` Ross Zwisler
[not found] ` <20170103165710.GC13904-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
2017-01-04 1:21 ` Xiong Zhou
2017-01-04 1:21 ` Xiong Zhou
2017-01-04 1:49 ` Xiong Zhou
2017-01-04 1:49 ` Xiong Zhou
2017-01-04 9:48 ` Xiong Zhou
2017-01-04 9:48 ` Xiong Zhou
[not found] ` <20170104094834.siixhljtbuniopi2-E9dkjZ7ERC1QcClZ3XN9yxcY2uh10dtjAL8bYrjMMd8@public.gmane.org>
2017-01-04 16:40 ` Ross Zwisler
2017-01-04 16:40 ` Ross Zwisler
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=20170102214941.GA2813@linux.intel.com \
--to=ross.zwisler-vuqaysv1563yd54fqh9/ca@public.gmane.org \
--cc=jack-AlSwsSmVLrQ@public.gmane.org \
--cc=linux-fsdevel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=linux-nvdimm-y27Ovi1pjclAfugRpC6u6w@public.gmane.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.