;Hello,
>> >
>> >I see the following when try to boot 4.5.0-rc6 on ARM TI AM33xx based board.
>> >
>> > [ 13.907631] [ cut here ]
>> > [ 13.912323] kernel BUG at ../mm/memory.c:1879!
>>
>> That's:
>
;I see the following when try to boot 4.5.0-rc6 on ARM TI AM33xx based board.
>> >
>> > [ 13.907631] --------[ cut here ]
>> > [ 13.912323] kernel BUG at ../mm/memory.c:1879!
>>
>> That's:
>> BUG_ON(addr >= end);
>>
>
board.
> >
> > [ 13.907631] [ cut here ]--------
> > [ 13.912323] kernel BUG at ../mm/memory.c:1879!
>
> That's:
> BUG_ON(addr >= end);
>
> where:
> end = addr + size;
>
> All these variables are unsigned long, so they overflown
board.
> >
> > [ 13.907631] [ cut here ]--------
> > [ 13.912323] kernel BUG at ../mm/memory.c:1879!
>
> That's:
> BUG_ON(addr >= end);
>
> where:
> end = addr + size;
>
> All these variables are unsigned long, so they overflown
]
[ 13.912323] kernel BUG at ../mm/memory.c:1879!
That's:
BUG_ON(addr >= end);
where:
end = addr + size;
All these variables are unsigned long, so they overflown?
I don't know ARM much, and there's no code for decodecode, but if I get
the calling convention correctly, and the registers didn't cha
]
[ 13.912323] kernel BUG at ../mm/memory.c:1879!
That's:
BUG_ON(addr >= end);
where:
end = addr + size;
All these variables are unsigned long, so they overflown?
I don't know ARM much, and there's no code for decodecode, but if I get
the calling convention correctly, and the registers didn't cha
[+CC ARM, module maintainers/lists]
On 03/07/2016 12:14 PM, Matwey V. Kornilov wrote:
Hello,
I see the following when try to boot 4.5.0-rc6 on ARM TI AM33xx based board.
[ 13.907631] [ cut here ]
[ 13.912323] kernel BUG at ../mm/memory.c:1879!
That's
[+CC ARM, module maintainers/lists]
On 03/07/2016 12:14 PM, Matwey V. Kornilov wrote:
Hello,
I see the following when try to boot 4.5.0-rc6 on ARM TI AM33xx based board.
[ 13.907631] [ cut here ]
[ 13.912323] kernel BUG at ../mm/memory.c:1879!
That's
On 06/19/2014 06:52 PM, Kirill A. Shutemov wrote:
http://marc.info/?l=linux-kernel=140319579508104=2
Yes, those symptoms look very familiar. The patch should really go in stable
3.15.y.
Thanks.
Ortwin
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of
On 06/19/2014 06:52 PM, Kirill A. Shutemov wrote:
http://marc.info/?l=linux-kernelm=140319579508104w=2
Yes, those symptoms look very familiar. The patch should really go in stable
3.15.y.
Thanks.
Ortwin
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of
2 CEST 2014 x86_64
> Intel(R) Xeon(R) CPU E5-2620 v2 @ 2.10GHz GenuineIntel GNU/Linux
>
> Jun 17 16:59:47 toaster kernel: [ cut here ]
> Jun 17 16:59:47 toaster kernel: kernel BUG at mm/memory.c:3924!
http://marc.info/?l=linux-kernel=140319579508104=2
--
Kirill A. S
:47 toaster kernel: [ cut here ]
Jun 17 16:59:47 toaster kernel: kernel BUG at mm/memory.c:3924!
Jun 17 16:59:47 toaster kernel: invalid opcode: [#1] PREEMPT SMP
Jun 17 16:59:47 toaster kernel: Modules linked in: iTCO_wdt iTCO_vendor_support
Jun 17 16:59:47 toaster kernel
:47 toaster kernel: [ cut here ]
Jun 17 16:59:47 toaster kernel: kernel BUG at mm/memory.c:3924!
Jun 17 16:59:47 toaster kernel: invalid opcode: [#1] PREEMPT SMP
Jun 17 16:59:47 toaster kernel: Modules linked in: iTCO_wdt iTCO_vendor_support
Jun 17 16:59:47 toaster kernel
) Xeon(R) CPU E5-2620 v2 @ 2.10GHz GenuineIntel GNU/Linux
Jun 17 16:59:47 toaster kernel: [ cut here ]
Jun 17 16:59:47 toaster kernel: kernel BUG at mm/memory.c:3924!
http://marc.info/?l=linux-kernelm=140319579508104w=2
--
Kirill A. Shutemov
--
To unsubscribe from
Hi,
For testing our product we use many virtual machines (KVM, qemu),
created and destroyed automatically. Every couple of days, a host system
(different HP blades) reports a kernel bug:
kernel BUG at
/home/abuild/rpmbuild/BUILD/kernel-default-3.14.2/linux-3.14/mm/memory.c:3797!
After
Hi,
For testing our product we use many virtual machines (KVM, qemu),
created and destroyed automatically. Every couple of days, a host system
(different HP blades) reports a kernel bug:
kernel BUG at
/home/abuild/rpmbuild/BUILD/kernel-default-3.14.2/linux-3.14/mm/memory.c:3797!
After
On Fri, 30 May 2014, Michael Ellerman wrote:
>
> diff --git a/include/linux/mempolicy.h b/include/linux/mempolicy.h
> index 3c1b968..f230a97 100644
> --- a/include/linux/mempolicy.h
> +++ b/include/linux/mempolicy.h
> @@ -175,6 +175,12 @@ static inline int vma_migratable(struct vm_area_struct
>
On Thu, 2014-05-29 at 14:34 -0400, Naoya Horiguchi wrote:
> On Thu, May 29, 2014 at 06:59:43PM +1000, Michael Ellerman wrote:
> > Applying your patch and running trinity pretty immediately results in the
> > following, which looks related (sys_move_pages() again) ?
> >
> > Unable to handle kernel
On Thu, 29 May 2014, Naoya Horiguchi wrote:
>
> Curretly hugepage migration is available for all archs which support pmd-level
> hugepage, but testing is done only for x86_64 and there're bugs for other
> archs.
And even for x86_64 I think: the follow_huge_pmd() locking issue I
mentioned. But
On Thu, 29 May 2014, Michael Ellerman wrote:
>
> Unfortunately I don't know our mm/hugetlb code well enough to give you a good
> answer. Ben had a quick look at our follow_huge_addr() and thought it looked
> "fishy". He suggested something like what we do in gup_pte_range() with
>
On Thu, 29 May 2014, Naoya Horiguchi wrote:
> On Wed, May 28, 2014 at 05:33:11PM -0700, Hugh Dickins wrote:
> > On Wed, 28 May 2014, Michael Ellerman wrote:
> > > Hey folks,
> > >
> > > Anyone seen this before? Trinity hit it just now:
> > >
> > > Linux Blade312-5 3.15.0-rc7 #306 SMP Wed May 28
On Wed, 2014-05-28 at 17:33 -0700, Hugh Dickins wrote:
> On Wed, 28 May 2014, Michael Ellerman wrote:
> > Linux Blade312-5 3.15.0-rc7 #306 SMP Wed May 28 17:51:18 EST 2014 ppc64
> >
> > [watchdog] 27853 iterations. [F:22642 S:5174 HI:1276]
> > [ cut here ]
> > kernel BUG
On Wed, 2014-05-28 at 17:33 -0700, Hugh Dickins wrote:
On Wed, 28 May 2014, Michael Ellerman wrote:
Linux Blade312-5 3.15.0-rc7 #306 SMP Wed May 28 17:51:18 EST 2014 ppc64
[watchdog] 27853 iterations. [F:22642 S:5174 HI:1276]
[ cut here ]
kernel BUG at
On Thu, 29 May 2014, Naoya Horiguchi wrote:
On Wed, May 28, 2014 at 05:33:11PM -0700, Hugh Dickins wrote:
On Wed, 28 May 2014, Michael Ellerman wrote:
Hey folks,
Anyone seen this before? Trinity hit it just now:
Linux Blade312-5 3.15.0-rc7 #306 SMP Wed May 28 17:51:18 EST 2014
On Thu, 29 May 2014, Michael Ellerman wrote:
Unfortunately I don't know our mm/hugetlb code well enough to give you a good
answer. Ben had a quick look at our follow_huge_addr() and thought it looked
fishy. He suggested something like what we do in gup_pte_range() with
On Thu, 29 May 2014, Naoya Horiguchi wrote:
Curretly hugepage migration is available for all archs which support pmd-level
hugepage, but testing is done only for x86_64 and there're bugs for other
archs.
And even for x86_64 I think: the follow_huge_pmd() locking issue I
mentioned. But I
On Thu, 2014-05-29 at 14:34 -0400, Naoya Horiguchi wrote:
On Thu, May 29, 2014 at 06:59:43PM +1000, Michael Ellerman wrote:
Applying your patch and running trinity pretty immediately results in the
following, which looks related (sys_move_pages() again) ?
Unable to handle kernel paging
On Fri, 30 May 2014, Michael Ellerman wrote:
diff --git a/include/linux/mempolicy.h b/include/linux/mempolicy.h
index 3c1b968..f230a97 100644
--- a/include/linux/mempolicy.h
+++ b/include/linux/mempolicy.h
@@ -175,6 +175,12 @@ static inline int vma_migratable(struct vm_area_struct
*vma)
On Wed, 28 May 2014, Michael Ellerman wrote:
> Hey folks,
>
> Anyone seen this before? Trinity hit it just now:
>
> Linux Blade312-5 3.15.0-rc7 #306 SMP Wed May 28 17:51:18 EST 2014 ppc64
>
> [watchdog] 27853 iterations. [F:22642 S:5174 HI:1276]
> [ cut here ]
> kernel
Hey folks,
Anyone seen this before? Trinity hit it just now:
Linux Blade312-5 3.15.0-rc7 #306 SMP Wed May 28 17:51:18 EST 2014 ppc64
[watchdog] 27853 iterations. [F:22642 S:5174 HI:1276]
[ cut here ]
kernel BUG at /home/michael/mmk-build/flow/mm/memory.c:1489!
cpu 0xc:
On Wed, 28 May 2014, Michael Ellerman wrote:
Hey folks,
Anyone seen this before? Trinity hit it just now:
Linux Blade312-5 3.15.0-rc7 #306 SMP Wed May 28 17:51:18 EST 2014 ppc64
[watchdog] 27853 iterations. [F:22642 S:5174 HI:1276]
[ cut here ]
kernel BUG at
Hey folks,
Anyone seen this before? Trinity hit it just now:
Linux Blade312-5 3.15.0-rc7 #306 SMP Wed May 28 17:51:18 EST 2014 ppc64
[watchdog] 27853 iterations. [F:22642 S:5174 HI:1276]
[ cut here ]
kernel BUG at /home/michael/mmk-build/flow/mm/memory.c:1489!
cpu 0xc:
following:
> >
> > [ 2043.098949] [ cut here ]----
> > [ 2043.099014] kernel BUG at mm/memory.c:1230!
>
> That's
>
> VM_BUG_ON(!rwsem_is_locked(>mm->mmap_sem));
>
> in zap_pmd_range()?
Originally split_huge_page_address did
:
[ 2043.098949] [ cut here ]
[ 2043.099014] kernel BUG at mm/memory.c:1230!
That's
VM_BUG_ON(!rwsem_is_locked(tlb-mm-mmap_sem));
in zap_pmd_range()?
Originally split_huge_page_address didn't exist. If the vma was
splitted at a not 2m aligned address by a syscall
34 matches
Mail list logo
