Matthew Wilcox writes:
> On Tue, Jul 23, 2019 at 01:08:42PM +0800, Huang, Ying wrote:
>> @@ -2489,6 +2491,14 @@ static void __split_huge_page(struct page *page,
>> struct list_head *list,
>> /* complete memcg works before add pages to LRU */
>> mem_cgroup_split_huge_fixup(head);
>>
On Tue, Jul 23, 2019 at 01:08:42PM +0800, Huang, Ying wrote:
> @@ -2489,6 +2491,14 @@ static void __split_huge_page(struct page *page,
> struct list_head *list,
> /* complete memcg works before add pages to LRU */
> mem_cgroup_split_huge_fixup(head);
>
> + if (PageAnon(head) &&
Mikhail Gavrilov writes:
> On Tue, 23 Jul 2019 at 10:08, Huang, Ying wrote:
>>
>> Thanks! I have found another (easier way) to reproduce the panic.
>> Could you try the below patch on top of v5.2-rc2? It can fix the panic
>> for me.
>>
>
> Thanks! Amazing work! The patch fixes the issue
On Tue, 23 Jul 2019 at 10:08, Huang, Ying wrote:
>
> Thanks! I have found another (easier way) to reproduce the panic.
> Could you try the below patch on top of v5.2-rc2? It can fix the panic
> for me.
>
Thanks! Amazing work! The patch fixes the issue completely. The system
worked at a high
Mikhail Gavrilov writes:
> On Mon, 22 Jul 2019 at 12:53, Huang, Ying wrote:
>>
>> Yes. This is quite complex. Is the transparent huge page enabled in
>> your system? You can check the output of
>>
>> $ cat /sys/kernel/mm/transparent_hugepage/enabled
>
> always [madvise] never
>
>> And,
On Mon, 22 Jul 2019 at 12:53, Huang, Ying wrote:
>
> Yes. This is quite complex. Is the transparent huge page enabled in
> your system? You can check the output of
>
> $ cat /sys/kernel/mm/transparent_hugepage/enabled
always [madvise] never
> And, whether is the swap device you use a SSD or
Mikhail Gavrilov writes:
> On Mon, 22 Jul 2019 at 06:37, huang ying wrote:
>>
>> I am trying to reproduce this bug. Can you give me some information
>> about your test case?
>
> It not easy, but I try to explain:
>
> 1. I have the system with 32Gb RAM, 64GB swap and after boot, I always
>
On Mon, 22 Jul 2019 at 06:37, huang ying wrote:
>
> I am trying to reproduce this bug. Can you give me some information
> about your test case?
It not easy, but I try to explain:
1. I have the system with 32Gb RAM, 64GB swap and after boot, I always
launch follow applications:
a. Google
kernel: page dumped because:
> VM_BUG_ON_PAGE(entry != page)
> May 29 08:02:02 localhost.localdomain kernel:
> page->mem_cgroup:8f41aeeff000
> May 29 08:02:02 localhost.localdomain kernel: [ cut here
> ]--------
> May 29 08:02:02 localhost.localdomain kernel:
On Fri, Jul 5, 2019 at 4:03 PM Jan Kara wrote:
>
> Yeah, I guess revert of 5fd4ca2d84b2 at this point is probably the best we
> can do. Let's CC Linus, Andrew, and Greg (Linus is travelling AFAIK so I'm
> not sure whether Greg won't do release for him).
I'm back home now, although possibly
On Fri 05-07-19 20:19:48, Mikhail Gavrilov wrote:
> Hey folks.
> Excuse me, is anybody read my previous message?
> 5.2-rc7 is still affected by this issue [the logs in file
> dmesg-5.2rc7-0.1.tar.xz] and I worry that stable 5.2 would be released
> with this bug because there is almost no time left
On Mon, 17 Jun 2019 at 17:17, Vlastimil Babka wrote:
>
>
> You told bisect that 5.2-rc1 is good, but it probably isn't.
> What you probably need to do is:
> git bisect good v5.1
> git bisect bad v5.2-rc2
>
$ git bisect log
git bisect start
# good: [e93c9c99a629c61837d5a7fc2120cd2b6c70dbdd] Linux
rly created.
Here I saved all dmesg output from all bisecting steps:
https://mega.nz/#F!00wFHACA!nmaLgkkbrlt46DteERjl7Q
And only one of them ended without crash message "kernel BUG at
mm/swap_state.c:170!"
This is step5 with commit 3d21b6525cae.
I tried to cause kernel panic several t
0 978433ace000
> : page dumped because: VM_BUG_ON_PAGE(entry != page)
> : page->mem_cgroup:ffff978433ace000
> : [ cut here ]
> : kernel BUG at mm/swap_state.c:170!
> : invalid opcode: [#1] SMP NOPTI
> : CPU: 1 PID: 221 Comm: kswapd0 Not tainted
On 6/16/19 12:12 PM, Mikhail Gavrilov wrote:
> Hi,
> I finished today bisecting kernel.
> And first bad commit for me was cd736d8b67fb22a85a68c1ee8020eb0d660615ec
That's commit "tcp: fix retrans timestamp on passive Fast Open" which is
almost certainly not the culprit.
> Can you look into
Hi,
I finished today bisecting kernel.
And first bad commit for me was cd736d8b67fb22a85a68c1ee8020eb0d660615ec
Can you look into this?
$ git bisect log
git bisect start
# good: [a188339ca5a396acc588e5851ed7e19f66b0ebd9] Linux 5.2-rc1
git bisect good a188339ca5a396acc588e5851ed7e19f66b0ebd9
#
On Wed, 29 May 2019 at 23:09, Michal Hocko wrote:
>
> Do you see the same with 5.2-rc1 resp. 5.1?
The problem still occurs at 5.2-rc3.
Unfortunately hard reproducible does not allow to make bisect.
Any ideas what is wrong?
--
Best Regards,
Mike Gavrilov.
433ace000
> > : page dumped because: VM_BUG_ON_PAGE(entry != page)
> > : page->mem_cgroup:978433ace000
> > : [ cut here ]
> > : kernel BUG at mm/swap_state.c:170!
>
> Do you see the same with 5.2-rc1 resp. 5.1?
On 5.2-rc1 I has another another issue
https://www.spinics.net/lists/linux-ext4/msg65661.html
--
Best Regards,
Mike Gavrilov.
7fffe00080034 d6d34c67c508 d6d3504b8d48 97812323a689
> : raw: fecec363 0001 978433ace000
> : page dumped because: VM_BUG_ON_PAGE(entry != page)
> : page->mem_cgroup:978433ace000
> : [ cut here ]
> : kernel
3ace000
: page dumped because: VM_BUG_ON_PAGE(entry != page)
: page->mem_cgroup:978433ace000
: [ cut here ]----
: kernel BUG at mm/swap_state.c:170!
: invalid opcode: [#1] SMP NOPTI
: CPU: 1 PID: 221 Comm: kswapd0 Not tainted 5.2.0-0.rc2.git0.1.fc31.x86_64 #1
: Hardware n
:02 localhost.localdomain kernel: [ cut here
]
May 29 08:02:02 localhost.localdomain kernel: kernel BUG at mm/swap_state.c:170!
--
Best Regards,
Mike Gavrilov.
21 matches
Mail list logo
