On Thu, Feb 25, 2016 at 03:49:33PM +, Steve Capper wrote:
> On 23 February 2016 at 18:47, Will Deacon wrote:
> > [adding Steve, since he worked on THP for 32-bit ARM]
>
> Apologies for my late reply...
>
> >
> > On Tue, Feb 23, 2016 at 07:19:07PM +0100, Gerald Schaefer wrote:
> >> On Tue,
On 23 February 2016 at 18:47, Will Deacon wrote:
> [adding Steve, since he worked on THP for 32-bit ARM]
Apologies for my late reply...
>
> On Tue, Feb 23, 2016 at 07:19:07PM +0100, Gerald Schaefer wrote:
>> On Tue, 23 Feb 2016 13:32:21 +0300
>> "Kirill A. Shutemov"
On 23 February 2016 at 18:47, Will Deacon wrote:
> [adding Steve, since he worked on THP for 32-bit ARM]
Apologies for my late reply...
>
> On Tue, Feb 23, 2016 at 07:19:07PM +0100, Gerald Schaefer wrote:
>> On Tue, 23 Feb 2016 13:32:21 +0300
>> "Kirill A. Shutemov" wrote:
>> > The theory is
Christian Borntraeger writes:
> On 02/24/2016 11:41 AM, Will Deacon wrote:
>> On Wed, Feb 24, 2016 at 11:16:34AM +0100, Christian Borntraeger wrote:
>>> On 02/23/2016 09:22 PM, Will Deacon wrote:
On Tue, Feb 23, 2016 at 10:33:45PM +0300, Kirill A. Shutemov wrote:
Christian Borntraeger writes:
> On 02/24/2016 11:41 AM, Will Deacon wrote:
>> On Wed, Feb 24, 2016 at 11:16:34AM +0100, Christian Borntraeger wrote:
>>> On 02/23/2016 09:22 PM, Will Deacon wrote:
On Tue, Feb 23, 2016 at 10:33:45PM +0300, Kirill A. Shutemov wrote:
> On Tue, Feb 23, 2016
On Tue, 23 Feb 2016 22:33:45 +0300
"Kirill A. Shutemov" wrote:
> On Tue, Feb 23, 2016 at 07:19:07PM +0100, Gerald Schaefer wrote:
> > I'll check with Martin, maybe it is actually trivial, then we can
> > do a quick test it to rule that one out.
>
> Oh. I found a bug in
On Tue, 23 Feb 2016 22:33:45 +0300
"Kirill A. Shutemov" wrote:
> On Tue, Feb 23, 2016 at 07:19:07PM +0100, Gerald Schaefer wrote:
> > I'll check with Martin, maybe it is actually trivial, then we can
> > do a quick test it to rule that one out.
>
> Oh. I found a bug in
On Wed, 24 Feb 2016, Martin Schwidefsky wrote:
> On Tue, 23 Feb 2016 22:33:45 +0300
> "Kirill A. Shutemov" wrote:
>
> > On Tue, Feb 23, 2016 at 07:19:07PM +0100, Gerald Schaefer wrote:
> > > I'll check with Martin, maybe it is actually trivial, then we can
> > > do a quick
On Wed, 24 Feb 2016, Martin Schwidefsky wrote:
> On Tue, 23 Feb 2016 22:33:45 +0300
> "Kirill A. Shutemov" wrote:
>
> > On Tue, Feb 23, 2016 at 07:19:07PM +0100, Gerald Schaefer wrote:
> > > I'll check with Martin, maybe it is actually trivial, then we can
> > > do a quick test it to rule that
On Wed, Feb 24, 2016 at 11:51:47AM +0100, Christian Borntraeger wrote:
> On 02/24/2016 11:41 AM, Will Deacon wrote:
> > On Wed, Feb 24, 2016 at 11:16:34AM +0100, Christian Borntraeger wrote:
> >> Without that fix we would clearly have stale tlb entries, no?
> >
> > Yes, but AFAIU the sequence on
On Wed, Feb 24, 2016 at 11:51:47AM +0100, Christian Borntraeger wrote:
> On 02/24/2016 11:41 AM, Will Deacon wrote:
> > On Wed, Feb 24, 2016 at 11:16:34AM +0100, Christian Borntraeger wrote:
> >> Without that fix we would clearly have stale tlb entries, no?
> >
> > Yes, but AFAIU the sequence on
On 02/24/2016 11:41 AM, Will Deacon wrote:
> On Wed, Feb 24, 2016 at 11:16:34AM +0100, Christian Borntraeger wrote:
>> On 02/23/2016 09:22 PM, Will Deacon wrote:
>>> On Tue, Feb 23, 2016 at 10:33:45PM +0300, Kirill A. Shutemov wrote:
On Tue, Feb 23, 2016 at 07:19:07PM +0100, Gerald Schaefer
On 02/24/2016 11:41 AM, Will Deacon wrote:
> On Wed, Feb 24, 2016 at 11:16:34AM +0100, Christian Borntraeger wrote:
>> On 02/23/2016 09:22 PM, Will Deacon wrote:
>>> On Tue, Feb 23, 2016 at 10:33:45PM +0300, Kirill A. Shutemov wrote:
On Tue, Feb 23, 2016 at 07:19:07PM +0100, Gerald Schaefer
On Wed, Feb 24, 2016 at 11:16:34AM +0100, Christian Borntraeger wrote:
> On 02/23/2016 09:22 PM, Will Deacon wrote:
> > On Tue, Feb 23, 2016 at 10:33:45PM +0300, Kirill A. Shutemov wrote:
> >> On Tue, Feb 23, 2016 at 07:19:07PM +0100, Gerald Schaefer wrote:
> >>> I'll check with Martin, maybe it
On Wed, Feb 24, 2016 at 11:16:34AM +0100, Christian Borntraeger wrote:
> On 02/23/2016 09:22 PM, Will Deacon wrote:
> > On Tue, Feb 23, 2016 at 10:33:45PM +0300, Kirill A. Shutemov wrote:
> >> On Tue, Feb 23, 2016 at 07:19:07PM +0100, Gerald Schaefer wrote:
> >>> I'll check with Martin, maybe it
On 02/23/2016 09:22 PM, Will Deacon wrote:
> On Tue, Feb 23, 2016 at 10:33:45PM +0300, Kirill A. Shutemov wrote:
>> On Tue, Feb 23, 2016 at 07:19:07PM +0100, Gerald Schaefer wrote:
>>> I'll check with Martin, maybe it is actually trivial, then we can
>>> do a quick test it to rule that one out.
>>
On 02/23/2016 09:22 PM, Will Deacon wrote:
> On Tue, Feb 23, 2016 at 10:33:45PM +0300, Kirill A. Shutemov wrote:
>> On Tue, Feb 23, 2016 at 07:19:07PM +0100, Gerald Schaefer wrote:
>>> I'll check with Martin, maybe it is actually trivial, then we can
>>> do a quick test it to rule that one out.
>>
On Tue, Feb 23, 2016 at 07:19:07PM +0100, Gerald Schaefer wrote:
> I'll check with Martin, maybe it is actually trivial, then we can
> do a quick test it to rule that one out.
Oh. I found a bug in __split_huge_pmd_locked(). Although, not sure if it's
_the_ bug.
pmdp_invalidate() is called for
On Tue, Feb 23, 2016 at 07:19:07PM +0100, Gerald Schaefer wrote:
> I'll check with Martin, maybe it is actually trivial, then we can
> do a quick test it to rule that one out.
Oh. I found a bug in __split_huge_pmd_locked(). Although, not sure if it's
_the_ bug.
pmdp_invalidate() is called for
On Tue, 23 Feb 2016 22:33:45 +0300
"Kirill A. Shutemov" wrote:
> On Tue, Feb 23, 2016 at 07:19:07PM +0100, Gerald Schaefer wrote:
> > I'll check with Martin, maybe it is actually trivial, then we can
> > do a quick test it to rule that one out.
>
> Oh. I found a bug in
On Tue, 23 Feb 2016 22:33:45 +0300
"Kirill A. Shutemov" wrote:
> On Tue, Feb 23, 2016 at 07:19:07PM +0100, Gerald Schaefer wrote:
> > I'll check with Martin, maybe it is actually trivial, then we can
> > do a quick test it to rule that one out.
>
> Oh. I found a bug in
On Tue, 23 Feb 2016 19:19:07 +0100
Gerald Schaefer wrote:
> On Tue, 23 Feb 2016 13:32:21 +0300
> "Kirill A. Shutemov" wrote:
>
> > On Fri, Feb 12, 2016 at 06:16:40PM +0100, Gerald Schaefer wrote:
> > > On Fri, 12 Feb 2016 16:57:27 +0100
> > >
On Tue, 23 Feb 2016 19:19:07 +0100
Gerald Schaefer wrote:
> On Tue, 23 Feb 2016 13:32:21 +0300
> "Kirill A. Shutemov" wrote:
>
> > On Fri, Feb 12, 2016 at 06:16:40PM +0100, Gerald Schaefer wrote:
> > > On Fri, 12 Feb 2016 16:57:27 +0100
> > > Christian Borntraeger wrote:
> > >
> > > > > I'm
On Tue, Feb 23, 2016 at 10:33:45PM +0300, Kirill A. Shutemov wrote:
> On Tue, Feb 23, 2016 at 07:19:07PM +0100, Gerald Schaefer wrote:
> > I'll check with Martin, maybe it is actually trivial, then we can
> > do a quick test it to rule that one out.
>
> Oh. I found a bug in
On Tue, Feb 23, 2016 at 10:33:45PM +0300, Kirill A. Shutemov wrote:
> On Tue, Feb 23, 2016 at 07:19:07PM +0100, Gerald Schaefer wrote:
> > I'll check with Martin, maybe it is actually trivial, then we can
> > do a quick test it to rule that one out.
>
> Oh. I found a bug in
[adding Steve, since he worked on THP for 32-bit ARM]
On Tue, Feb 23, 2016 at 07:19:07PM +0100, Gerald Schaefer wrote:
> On Tue, 23 Feb 2016 13:32:21 +0300
> "Kirill A. Shutemov" wrote:
> > The theory is that the splitting bit effetely masked bogus pmd_present():
> > we had
[adding Steve, since he worked on THP for 32-bit ARM]
On Tue, Feb 23, 2016 at 07:19:07PM +0100, Gerald Schaefer wrote:
> On Tue, 23 Feb 2016 13:32:21 +0300
> "Kirill A. Shutemov" wrote:
> > The theory is that the splitting bit effetely masked bogus pmd_present():
> > we had pmd_trans_splitting()
On Tue, 23 Feb 2016 13:32:21 +0300
"Kirill A. Shutemov" wrote:
> On Fri, Feb 12, 2016 at 06:16:40PM +0100, Gerald Schaefer wrote:
> > On Fri, 12 Feb 2016 16:57:27 +0100
> > Christian Borntraeger wrote:
> >
> > > > I'm also confused by pmd_none() is
On Tue, 23 Feb 2016 13:32:21 +0300
"Kirill A. Shutemov" wrote:
> On Fri, Feb 12, 2016 at 06:16:40PM +0100, Gerald Schaefer wrote:
> > On Fri, 12 Feb 2016 16:57:27 +0100
> > Christian Borntraeger wrote:
> >
> > > > I'm also confused by pmd_none() is equal to !pmd_present() on s390. Hm?
> > >
>
On Tue, Feb 23, 2016 at 2:32 AM, Kirill A. Shutemov
wrote:
>
> I still worry about pmd_present(). It looks wrong to me. I wounder if
> patch below makes a difference.
Let's hope that's it, but in the meantime I do want to start the
discussion about what to do if it isn't.
On Tue, Feb 23, 2016 at 2:32 AM, Kirill A. Shutemov
wrote:
>
> I still worry about pmd_present(). It looks wrong to me. I wounder if
> patch below makes a difference.
Let's hope that's it, but in the meantime I do want to start the
discussion about what to do if it isn't. We're at rc5, and 4.5
On Fri, Feb 12, 2016 at 06:16:40PM +0100, Gerald Schaefer wrote:
> On Fri, 12 Feb 2016 16:57:27 +0100
> Christian Borntraeger wrote:
>
> > > I'm also confused by pmd_none() is equal to !pmd_present() on s390. Hm?
> >
> > Don't know, Gerald or Martin?
>
> The
On Fri, Feb 12, 2016 at 06:16:40PM +0100, Gerald Schaefer wrote:
> On Fri, 12 Feb 2016 16:57:27 +0100
> Christian Borntraeger wrote:
>
> > > I'm also confused by pmd_none() is equal to !pmd_present() on s390. Hm?
> >
> > Don't know, Gerald or Martin?
>
> The implementation frequently changes
On Thu, 18 Feb 2016, Kirill A. Shutemov wrote:
> I worth minimizing kernel config on which you can see the bug. Things like
> CONFIG_DEBUG_PAGEALLOC used to interfere with THP before.
I disabled all debugging options (using
arch/s390/configs/performance_defconfig) - we still chrashed.
Sebastian
On Thu, 18 Feb 2016, Kirill A. Shutemov wrote:
> I worth minimizing kernel config on which you can see the bug. Things like
> CONFIG_DEBUG_PAGEALLOC used to interfere with THP before.
I disabled all debugging options (using
arch/s390/configs/performance_defconfig) - we still chrashed.
Sebastian
:31 +0100 (CET)
> > > Sebastian Ott <seb...@linux.vnet.ibm.com> wrote:
> > >
> > > > [ 59.875935] [ cut here ]
> > > > [ 59.875937] kernel BUG at mm/huge_memory.c:2884!
> > > > [ 59.875979] illegal o
0 (CET)
> > > Sebastian Ott wrote:
> > >
> > > > [ 59.875935] --------[ cut here ]
> > > > [ 59.875937] kernel BUG at mm/huge_memory.c:2884!
> > > > [ 59.875979] illegal operation: 0001 ilc:1 [#1] PREEMPT SMP
> > > > DEBUG
gt;
> > > [ 59.875935] ----[ cut here ]
> > > [ 59.875937] kernel BUG at mm/huge_memory.c:2884!
> > > [ 59.875979] illegal operation: 0001 ilc:1 [#1] PREEMPT SMP
> > > DEBUG_PAGEALLOC
> > > [ 59.875986] Modules linked in: brid
On Thu, 18 Feb 2016 01:58:08 +0200
"Kirill A. Shutemov" wrote:
> On Wed, Feb 17, 2016 at 08:13:40PM +0100, Gerald Schaefer wrote:
> > On Sat, 13 Feb 2016 12:58:31 +0100 (CET)
> > Sebastian Ott wrote:
> >
> > > [ 59.875935] [ cut here ]----
On Wed, Feb 17, 2016 at 08:13:40PM +0100, Gerald Schaefer wrote:
> On Sat, 13 Feb 2016 12:58:31 +0100 (CET)
> Sebastian Ott <seb...@linux.vnet.ibm.com> wrote:
>
> > [ 59.875935] [ cut here ]----
> > [ 59.875937] kernel BUG at mm/huge_memor
On Wed, Feb 17, 2016 at 08:13:40PM +0100, Gerald Schaefer wrote:
> On Sat, 13 Feb 2016 12:58:31 +0100 (CET)
> Sebastian Ott wrote:
>
> > [ 59.875935] [ cut here ]
> > [ 59.875937] kernel BUG at mm/huge_memory.c:2884!
> > [ 59.875979] il
On Sat, 13 Feb 2016 12:58:31 +0100 (CET)
Sebastian Ott <seb...@linux.vnet.ibm.com> wrote:
> [ 59.875935] [ cut here ]
> [ 59.875937] kernel BUG at mm/huge_memory.c:2884!
> [ 59.875979] illegal operation: 0001 ilc:1 [#1] PREEMPT SMP DEBUG_PAGEALLOC
On Sat, 13 Feb 2016 12:58:31 +0100 (CET)
Sebastian Ott wrote:
> [ 59.875935] [ cut here ]
> [ 59.875937] kernel BUG at mm/huge_memory.c:2884!
> [ 59.875979] illegal operation: 0001 ilc:1 [#1] PREEMPT SMP DEBUG_PAGEALLOC
> [ 59.875986] Modules linked in
904111! ¢<002d44a4>! vfs_fstatat+0x6c/0xc8
¢ 1707.904113! ¢<002d4894>! SyS_newlstat+0x2c/0x48
¢ 1707.904115! ¢<006f9cce>! system_call+0xd6/0x258
¢ 1707.904117! ¢<03ffb45f1124>! 0x3ffb45f1124
¢ 1707.904118! 1 lock held by git/25215:
¢ 1707.904119! #0: (
vfs_fstatat+0x6c/0xc8
¢ 1707.904113! ¢<002d4894>! SyS_newlstat+0x2c/0x48
¢ 1707.904115! ¢<006f9cce>! system_call+0xd6/0x258
¢ 1707.904117! ¢<03ffb45f1124>! 0x3ffb45f1124
¢ 1707.904118! 1 lock held by git/25215:
¢ 1707.904119! #0: (_hash¢i!.lock){-.-
On Tue, Feb 16, 2016 at 05:24:44PM +0100, Gerald Schaefer wrote:
> On Mon, 15 Feb 2016 23:35:26 +0200
> "Kirill A. Shutemov" wrote:
>
> > Is there any chance that I'll be able to trigger the bug using QEMU?
> > Does anybody have an QEMU image I can use?
> >
>
> I have no
On Tue, Feb 16, 2016 at 05:24:44PM +0100, Gerald Schaefer wrote:
> On Mon, 15 Feb 2016 23:35:26 +0200
> "Kirill A. Shutemov" wrote:
>
> > Is there any chance that I'll be able to trigger the bug using QEMU?
> > Does anybody have an QEMU image I can use?
> >
>
> I have no image, but trying to
On 02/15/2016 10:35 PM, Kirill A. Shutemov wrote:
>
> Is there any chance that I'll be able to trigger the bug using QEMU?
> Does anybody have an QEMU image I can use?
qemu/TCG on s390 does neither provide SMP nor large pages (only QEMU/KVM does)
so this will probably not help you here.
On 02/15/2016 10:35 PM, Kirill A. Shutemov wrote:
>
> Is there any chance that I'll be able to trigger the bug using QEMU?
> Does anybody have an QEMU image I can use?
qemu/TCG on s390 does neither provide SMP nor large pages (only QEMU/KVM does)
so this will probably not help you here.
inside the pre-allocated pagetables instead of
> > page->lru,
> > because we have 2K pagetables on s390 and cannot use struct page ==
> > pgtable_t.
>
> 0x400 from empty pte makes more sense than TAIL_MAPPING. But I guess it
> worth changing TAIL_MAPPING to some other va
> > page->lru,
> > because we have 2K pagetables on s390 and cannot use struct page ==
> > pgtable_t.
>
> 0x400 from empty pte makes more sense than TAIL_MAPPING. But I guess it
> worth changing TAIL_MAPPING to some other value to make sure.
Right, but we cannot trigger this li
On Mon, 15 Feb 2016, Kirill A. Shutemov wrote:
> Just to make sure: commit 122afea9626a is fine, commit 61f5d698cc97
> crashes. Correct?
Correct.
On Mon, 15 Feb 2016, Kirill A. Shutemov wrote:
> Just to make sure: commit 122afea9626a is fine, commit 61f5d698cc97
> crashes. Correct?
Correct.
On Mon, Feb 15, 2016 at 07:37:02PM +0100, Gerald Schaefer wrote:
> On Mon, 15 Feb 2016 13:31:59 +0200
> "Kirill A. Shutemov" wrote:
>
> > On Sat, Feb 13, 2016 at 12:58:31PM +0100, Sebastian Ott wrote:
> > >
> > > On Sat, 13 Feb 2016, Kirill A. Shutemov wrote:
> > > > Could
On Mon, Feb 15, 2016 at 07:37:02PM +0100, Gerald Schaefer wrote:
> On Mon, 15 Feb 2016 13:31:59 +0200
> "Kirill A. Shutemov" wrote:
>
> > On Sat, Feb 13, 2016 at 12:58:31PM +0100, Sebastian Ott wrote:
> > >
> > > On Sat, 13 Feb 2016, Kirill A. Shutemov wrote:
> > > > Could you check if revert
On Mon, 15 Feb 2016 13:31:59 +0200
"Kirill A. Shutemov" wrote:
> On Sat, Feb 13, 2016 at 12:58:31PM +0100, Sebastian Ott wrote:
> >
> > On Sat, 13 Feb 2016, Kirill A. Shutemov wrote:
> > > Could you check if revert of fecffad25458 helps?
> >
> > I reverted fecffad25458 on
On Mon, 15 Feb 2016 13:31:59 +0200
"Kirill A. Shutemov" wrote:
> On Sat, Feb 13, 2016 at 12:58:31PM +0100, Sebastian Ott wrote:
> >
> > On Sat, 13 Feb 2016, Kirill A. Shutemov wrote:
> > > Could you check if revert of fecffad25458 helps?
> >
> > I reverted fecffad25458 on top of 721675fcf277cf
On Sat, 13 Feb 2016 01:15:10 +0200
"Kirill A. Shutemov" wrote:
>
> I'm trying to wrap my head around the issue and I don't think missing
> serialization with gup_fast is the cause -- we just don't need it
> anymore.
>
> Previously, __split_huge_page_splitting() required
On Sat, 13 Feb 2016 01:15:10 +0200
"Kirill A. Shutemov" wrote:
>
> I'm trying to wrap my head around the issue and I don't think missing
> serialization with gup_fast is the cause -- we just don't need it
> anymore.
>
> Previously, __split_huge_page_splitting() required serialization against
>
On Mon, 15 Feb 2016, Kirill A. Shutemov wrote:
> > [ 59.851421] list_del corruption. next->prev should be 6e1eb000,
> > but was 0400
>
> This kinda interesting: 0x400 is TAIL_MAPPING.. Hm..
>
> Could you check if you see the problem on commit 1c290f642101 and its
>
On Mon, 15 Feb 2016, Kirill A. Shutemov wrote:
> > [ 59.851421] list_del corruption. next->prev should be 6e1eb000,
> > but was 0400
>
> This kinda interesting: 0x400 is TAIL_MAPPING.. Hm..
>
> Could you check if you see the problem on commit 1c290f642101 and its
>
On Sat, Feb 13, 2016 at 12:58:31PM +0100, Sebastian Ott wrote:
>
> On Sat, 13 Feb 2016, Kirill A. Shutemov wrote:
> > Could you check if revert of fecffad25458 helps?
>
> I reverted fecffad25458 on top of 721675fcf277cf - it oopsed with:
>
> ¢ 1851.721062! Unable to handle kernel pointer
On Sat, Feb 13, 2016 at 12:58:31PM +0100, Sebastian Ott wrote:
>
> On Sat, 13 Feb 2016, Kirill A. Shutemov wrote:
> > Could you check if revert of fecffad25458 helps?
>
> I reverted fecffad25458 on top of 721675fcf277cf - it oopsed with:
>
> ¢ 1851.721062! Unable to handle kernel pointer
] [<03ff9bbfd282>] 0x3ff9bbfd282
[ 59.875904] 2 locks held by git/5402:
[ 59.875906] #0: (>mmap_sem){++}, at: [<0029bb5a>]
SyS_madvise+0x562/0x5e8
[ 59.875914] #1: (&(ptlock_ptr(page))->rlock){+.+...}, at:
[<0000002c4268>] __split_huge_pmd+0x70/0x
] [<03ff9bbfd282>] 0x3ff9bbfd282
[ 59.875904] 2 locks held by git/5402:
[ 59.875906] #0: (>mmap_sem){++}, at: [<0029bb5a>]
SyS_madvise+0x562/0x5e8
[ 59.875914] #1: (&(ptlock_ptr(page))->rlock){+.+...}, at:
[<0000002c4268>] __split_huge_pmd+0x70/0x
On Fri, Feb 12, 2016 at 06:16:40PM +0100, Gerald Schaefer wrote:
> On Fri, 12 Feb 2016 16:57:27 +0100
> Christian Borntraeger wrote:
>
> > On 02/12/2016 04:41 PM, Kirill A. Shutemov wrote:
> > > On Thu, Feb 11, 2016 at 08:57:02PM +0100, Gerald Schaefer wrote:
> > >> On Thu, 11 Feb 2016 21:09:42
On Fri, 12 Feb 2016 16:57:27 +0100
Christian Borntraeger wrote:
> On 02/12/2016 04:41 PM, Kirill A. Shutemov wrote:
> > On Thu, Feb 11, 2016 at 08:57:02PM +0100, Gerald Schaefer wrote:
> >> On Thu, 11 Feb 2016 21:09:42 +0200
> >> "Kirill A. Shutemov" wrote:
> >>
> >>> On Thu, Feb 11, 2016 at
Gerald Schaefer writes:
> On Fri, 12 Feb 2016 09:34:33 +0530
> "Aneesh Kumar K.V" wrote:
>
>> Gerald Schaefer writes:
>>
>> > On Thu, 11 Feb 2016 21:09:42 +0200
>> > "Kirill A. Shutemov" wrote:
>> >
>> >> On Thu, Feb 11, 2016 at 07:22:23PM +0100, Gerald Schaefer wrote:
>> >> > Hi,
>> >> >
On 02/12/2016 04:41 PM, Kirill A. Shutemov wrote:
> On Thu, Feb 11, 2016 at 08:57:02PM +0100, Gerald Schaefer wrote:
>> On Thu, 11 Feb 2016 21:09:42 +0200
>> "Kirill A. Shutemov" wrote:
>>
>>> On Thu, Feb 11, 2016 at 07:22:23PM +0100, Gerald Schaefer wrote:
Hi,
Sebastian Ott
On Fri, Feb 12, 2016 at 11:12:34AM +0100, Sebastian Ott wrote:
> On Fri, 12 Feb 2016, Will Deacon wrote:
> > On Thu, Feb 11, 2016 at 08:57:02PM +0100, Gerald Schaefer wrote:
> > > On Thu, 11 Feb 2016 21:09:42 +0200
> > > "Kirill A. Shutemov" wrote:
> > > > On Thu, Feb 11, 2016 at 07:22:23PM
On Thu, Feb 11, 2016 at 08:57:02PM +0100, Gerald Schaefer wrote:
> On Thu, 11 Feb 2016 21:09:42 +0200
> "Kirill A. Shutemov" wrote:
>
> > On Thu, Feb 11, 2016 at 07:22:23PM +0100, Gerald Schaefer wrote:
> > > Hi,
> > >
> > > Sebastian Ott reported random kernel crashes beginning with v4.5-rc1
On Thu, 11 Feb 2016, Kirill A. Shutemov wrote:
> On Thu, Feb 11, 2016 at 09:09:42PM +0200, Kirill A. Shutemov wrote:
> > On Thu, Feb 11, 2016 at 07:22:23PM +0100, Gerald Schaefer wrote:
> > > Hi,
> > >
> > > Sebastian Ott reported random kernel crashes beginning with v4.5-rc1 and
> > > he also
On Fri, 12 Feb 2016 09:34:33 +0530
"Aneesh Kumar K.V" wrote:
> Gerald Schaefer writes:
>
> > On Thu, 11 Feb 2016 21:09:42 +0200
> > "Kirill A. Shutemov" wrote:
> >
> >> On Thu, Feb 11, 2016 at 07:22:23PM +0100, Gerald Schaefer wrote:
> >> > Hi,
> >> >
> >> > Sebastian Ott reported random
On Fri, 12 Feb 2016, Will Deacon wrote:
> On Thu, Feb 11, 2016 at 08:57:02PM +0100, Gerald Schaefer wrote:
> > On Thu, 11 Feb 2016 21:09:42 +0200
> > "Kirill A. Shutemov" wrote:
> > > On Thu, Feb 11, 2016 at 07:22:23PM +0100, Gerald Schaefer wrote:
> > > > Sebastian Ott reported random kernel
On Thu, Feb 11, 2016 at 08:57:02PM +0100, Gerald Schaefer wrote:
> On Thu, 11 Feb 2016 21:09:42 +0200
> "Kirill A. Shutemov" wrote:
> > On Thu, Feb 11, 2016 at 07:22:23PM +0100, Gerald Schaefer wrote:
> > > Sebastian Ott reported random kernel crashes beginning with v4.5-rc1 and
> > > he also
On Thu, Feb 11, 2016 at 08:57:02PM +0100, Gerald Schaefer wrote:
> On Thu, 11 Feb 2016 21:09:42 +0200
> "Kirill A. Shutemov" wrote:
> > On Thu, Feb 11, 2016 at 07:22:23PM +0100, Gerald Schaefer wrote:
> > > Sebastian Ott reported random kernel crashes beginning with v4.5-rc1
On Fri, 12 Feb 2016, Will Deacon wrote:
> On Thu, Feb 11, 2016 at 08:57:02PM +0100, Gerald Schaefer wrote:
> > On Thu, 11 Feb 2016 21:09:42 +0200
> > "Kirill A. Shutemov" wrote:
> > > On Thu, Feb 11, 2016 at 07:22:23PM +0100, Gerald Schaefer wrote:
> > > > Sebastian Ott
On Fri, 12 Feb 2016 09:34:33 +0530
"Aneesh Kumar K.V" wrote:
> Gerald Schaefer writes:
>
> > On Thu, 11 Feb 2016 21:09:42 +0200
> > "Kirill A. Shutemov" wrote:
> >
> >> On Thu, Feb 11, 2016 at 07:22:23PM +0100,
On Thu, 11 Feb 2016, Kirill A. Shutemov wrote:
> On Thu, Feb 11, 2016 at 09:09:42PM +0200, Kirill A. Shutemov wrote:
> > On Thu, Feb 11, 2016 at 07:22:23PM +0100, Gerald Schaefer wrote:
> > > Hi,
> > >
> > > Sebastian Ott reported random kernel crashes beginning with v4.5-rc1 and
> > > he also
On Fri, 12 Feb 2016 16:57:27 +0100
Christian Borntraeger wrote:
> On 02/12/2016 04:41 PM, Kirill A. Shutemov wrote:
> > On Thu, Feb 11, 2016 at 08:57:02PM +0100, Gerald Schaefer wrote:
> >> On Thu, 11 Feb 2016 21:09:42 +0200
> >> "Kirill A. Shutemov"
Gerald Schaefer writes:
> On Fri, 12 Feb 2016 09:34:33 +0530
> "Aneesh Kumar K.V" wrote:
>
>> Gerald Schaefer writes:
>>
>> > On Thu, 11 Feb 2016 21:09:42 +0200
>> > "Kirill A. Shutemov"
On Thu, Feb 11, 2016 at 08:57:02PM +0100, Gerald Schaefer wrote:
> On Thu, 11 Feb 2016 21:09:42 +0200
> "Kirill A. Shutemov" wrote:
>
> > On Thu, Feb 11, 2016 at 07:22:23PM +0100, Gerald Schaefer wrote:
> > > Hi,
> > >
> > > Sebastian Ott reported random kernel crashes
On Fri, Feb 12, 2016 at 11:12:34AM +0100, Sebastian Ott wrote:
> On Fri, 12 Feb 2016, Will Deacon wrote:
> > On Thu, Feb 11, 2016 at 08:57:02PM +0100, Gerald Schaefer wrote:
> > > On Thu, 11 Feb 2016 21:09:42 +0200
> > > "Kirill A. Shutemov" wrote:
> > > > On Thu, Feb 11,
On 02/12/2016 04:41 PM, Kirill A. Shutemov wrote:
> On Thu, Feb 11, 2016 at 08:57:02PM +0100, Gerald Schaefer wrote:
>> On Thu, 11 Feb 2016 21:09:42 +0200
>> "Kirill A. Shutemov" wrote:
>>
>>> On Thu, Feb 11, 2016 at 07:22:23PM +0100, Gerald Schaefer wrote:
Hi,
On Fri, Feb 12, 2016 at 06:16:40PM +0100, Gerald Schaefer wrote:
> On Fri, 12 Feb 2016 16:57:27 +0100
> Christian Borntraeger wrote:
>
> > On 02/12/2016 04:41 PM, Kirill A. Shutemov wrote:
> > > On Thu, Feb 11, 2016 at 08:57:02PM +0100, Gerald Schaefer wrote:
> > >> On
Gerald Schaefer writes:
> On Thu, 11 Feb 2016 21:09:42 +0200
> "Kirill A. Shutemov" wrote:
>
>> On Thu, Feb 11, 2016 at 07:22:23PM +0100, Gerald Schaefer wrote:
>> > Hi,
>> >
>> > Sebastian Ott reported random kernel crashes beginning with v4.5-rc1 and
>> > he also bisected this to commit
On Thu, 11 Feb 2016 21:09:42 +0200
"Kirill A. Shutemov" wrote:
> On Thu, Feb 11, 2016 at 07:22:23PM +0100, Gerald Schaefer wrote:
> > Hi,
> >
> > Sebastian Ott reported random kernel crashes beginning with v4.5-rc1 and
> > he also bisected this to commit 61f5d698 "mm: re-enable THP". Further
>
On Thu, Feb 11, 2016 at 09:09:42PM +0200, Kirill A. Shutemov wrote:
> On Thu, Feb 11, 2016 at 07:22:23PM +0100, Gerald Schaefer wrote:
> > Hi,
> >
> > Sebastian Ott reported random kernel crashes beginning with v4.5-rc1 and
> > he also bisected this to commit 61f5d698 "mm: re-enable THP". Further
On Thu, Feb 11, 2016 at 07:22:23PM +0100, Gerald Schaefer wrote:
> Hi,
>
> Sebastian Ott reported random kernel crashes beginning with v4.5-rc1 and
> he also bisected this to commit 61f5d698 "mm: re-enable THP". Further
> review of the THP rework patches, which cannot be bisected, revealed
>
Hi,
Sebastian Ott reported random kernel crashes beginning with v4.5-rc1 and
he also bisected this to commit 61f5d698 "mm: re-enable THP". Further
review of the THP rework patches, which cannot be bisected, revealed
commit fecffad "s390, thp: remove infrastructure for handling splitting PMDs"
On Thu, Feb 11, 2016 at 09:09:42PM +0200, Kirill A. Shutemov wrote:
> On Thu, Feb 11, 2016 at 07:22:23PM +0100, Gerald Schaefer wrote:
> > Hi,
> >
> > Sebastian Ott reported random kernel crashes beginning with v4.5-rc1 and
> > he also bisected this to commit 61f5d698 "mm: re-enable THP". Further
On Thu, Feb 11, 2016 at 07:22:23PM +0100, Gerald Schaefer wrote:
> Hi,
>
> Sebastian Ott reported random kernel crashes beginning with v4.5-rc1 and
> he also bisected this to commit 61f5d698 "mm: re-enable THP". Further
> review of the THP rework patches, which cannot be bisected, revealed
>
On Thu, 11 Feb 2016 21:09:42 +0200
"Kirill A. Shutemov" wrote:
> On Thu, Feb 11, 2016 at 07:22:23PM +0100, Gerald Schaefer wrote:
> > Hi,
> >
> > Sebastian Ott reported random kernel crashes beginning with v4.5-rc1 and
> > he also bisected this to commit 61f5d698 "mm:
Gerald Schaefer writes:
> On Thu, 11 Feb 2016 21:09:42 +0200
> "Kirill A. Shutemov" wrote:
>
>> On Thu, Feb 11, 2016 at 07:22:23PM +0100, Gerald Schaefer wrote:
>> > Hi,
>> >
>> > Sebastian Ott reported random kernel crashes beginning with
Hi,
Sebastian Ott reported random kernel crashes beginning with v4.5-rc1 and
he also bisected this to commit 61f5d698 "mm: re-enable THP". Further
review of the THP rework patches, which cannot be bisected, revealed
commit fecffad "s390, thp: remove infrastructure for handling splitting PMDs"
On Mon 2015-09-21 17:33:21, Sheng Yang wrote:
> Thank you Paul! That's exactly the issue I met. I've read the whole
> thread and got a general idea of the issue.
>
> I try to summarize it and please correct me if I'm wrong:
>
> 1. The issue is the result of kill_bdev() when connection has been
On Mon 2015-09-21 17:33:21, Sheng Yang wrote:
> Thank you Paul! That's exactly the issue I met. I've read the whole
> thread and got a general idea of the issue.
>
> I try to summarize it and please correct me if I'm wrong:
>
> 1. The issue is the result of kill_bdev() when connection has been
nbd-general/thread/20131114075827.GA13554%40quack.suse.cz/#msg31636917
> >
> > Maybe Markus has some thoughts on how to fix it. I think there are a couple
> > options.
> >
> > --
> > Paul
> >
> > On Wed, Sep 16, 2015 at 9:18 PM, Sheng Yang wrote
//sourceforge.net/p/nbd/mailman/nbd-general/thread/20131114075827.GA13554%40quack.suse.cz/#msg31636917
> >
> > Maybe Markus has some thoughts on how to fix it. I think there are a couple
> > options.
> >
> > --
> > Paul
> >
> > On Wed, Sep 16, 2015 at
/mailman/nbd-general/thread/20131114075827.GA13554%40quack.suse.cz/#msg31636917
>
> Maybe Markus has some thoughts on how to fix it. I think there are a couple
> options.
>
> --
> Paul
>
> On Wed, Sep 16, 2015 at 9:18 PM, Sheng Yang wrote:
>>
>> Hi, Markus,
&g
201 - 300 of 1743 matches
Mail list logo