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) && P
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 comple
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 loa
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, whethe
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 N
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
> launc
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 Chr
Hi, Mikhail,
On Wed, May 29, 2019 at 12:05 PM Mikhail Gavrilov
wrote:
>
> Hi folks.
> I am observed kernel panic after update to git tag 5.2-rc2.
> This crash happens at memory pressing when swap being used.
>
> Unfortunately in journalctl saved only this:
>
> May 29 08:02:02 localhost.localdomai
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 jetlag
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
On Mon, 17 Jun 2019 at 17:17, Vlastimil Babka wrote:
>
> That's commit "tcp: fix retrans timestamp on passive Fast Open" which is
> almost certainly not the culprit.
Yes, I seen also content of this commit.
And it looks like madness.
But I can proving that my bisect are properly created.
Here I s
On 5/29/19 7:32 PM, Mikhail Gavrilov wrote:
> On Wed, 29 May 2019 at 09:05, Mikhail Gavrilov
> wrote:
>>
>> Hi folks.
>> I am observed kernel panic after update to git tag 5.2-rc2.
>> This crash happens at memory pressing when swap being used.
>>
>> Unfortunately in journalctl saved only this:
>>
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 this?
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
# go
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.
On Wed, 29 May 2019 at 23:09, Michal Hocko wrote:
>
> On Wed 29-05-19 22:32:08, Mikhail Gavrilov wrote:
> > On Wed, 29 May 2019 at 09:05, Mikhail Gavrilov
> > wrote:
> > >
> > > Hi folks.
> > > I am observed kernel panic after update to git tag 5.2-rc2.
> > > This crash happens at memory pressing
On Wed 29-05-19 22:32:08, Mikhail Gavrilov wrote:
> On Wed, 29 May 2019 at 09:05, Mikhail Gavrilov
> wrote:
> >
> > Hi folks.
> > I am observed kernel panic after update to git tag 5.2-rc2.
> > This crash happens at memory pressing when swap being used.
> >
> > Unfortunately in journalctl saved on
On Wed, 29 May 2019 at 09:05, Mikhail Gavrilov
wrote:
>
> Hi folks.
> I am observed kernel panic after update to git tag 5.2-rc2.
> This crash happens at memory pressing when swap being used.
>
> Unfortunately in journalctl saved only this:
>
Now I captured better trace.
: page:d6d34dff
20 matches
Mail list logo
