> -Original Message-
> On 04/29/2020 10:27 PM, HAGIO KAZUHITO wrote:
> > Hi Pingfan,
> >
> >> -Original Message-
> >> Hi Kazu and Cascardo,
> >>
> >> I encounter a weird problem when running makedumpfile on a s390 machine.
> >>
> >> Our production kernel uses extreme sparse memory
On 04/29/2020 10:27 PM, HAGIO KAZUHITO(萩尾 一仁) wrote:
> Hi Pingfan,
>
>> -Original Message-
>> Hi Kazu and Cascardo,
>>
>> I encounter a weird problem when running makedumpfile on a s390 machine.
>>
>> Our production kernel uses extreme sparse memory model, and has the
>> following:
>>
Hi Pingfan,
> -Original Message-
> Hi Kazu and Cascardo,
>
> I encounter a weird problem when running makedumpfile on a s390 machine.
>
> Our production kernel uses extreme sparse memory model, and has the
> following:
>
> in mm/sparse.c
>
> #ifdef CONFIG_SPARSEMEM_EXTREME
> struct
Hi Kazu and Cascardo,
I encounter a weird problem when running makedumpfile on a s390 machine.
Our production kernel uses extreme sparse memory model, and has the
following:
in mm/sparse.c
#ifdef CONFIG_SPARSEMEM_EXTREME
struct mem_section **mem_section;
#else
struct mem_section
-Original Message-
> Hi, Kazu.
>
> For now, I would keep Pingfan's patch as is. I decided to test some other
> kernels, like 3.16 and 4.9 without commit
> 83e3c48729d9ebb7af5a31a504f3fd6aff0348c4.
>
> So, they would be valid for the first iteration and invalid for the second,
> just like
On Thu, Feb 20, 2020 at 03:40:12PM +, HAGIO KAZUHITO(萩尾 一仁) wrote:
> -Original Message-
> > On 02/20/2020 04:12 AM, HAGIO KAZUHITO wrote:
> > > Hi Cascardo,
> > >
> > > Do you have any solution or detailed information on the failure on your
> > > kernel?
> > > or could you try this
-Original Message-
> On 02/20/2020 04:12 AM, HAGIO KAZUHITO wrote:
> > Hi Cascardo,
> >
> > Do you have any solution or detailed information on the failure on your
> > kernel?
> > or could you try this branch? It has an additional patch on top of
> > Pingfan's
> > one to avoid the false
On 02/20/2020 04:12 AM, HAGIO KAZUHITO(萩尾 一仁) wrote:
> Hi Cascardo,
>
> Do you have any solution or detailed information on the failure on your
> kernel?
> or could you try this branch? It has an additional patch on top of Pingfan's
> one to avoid the false positive failure that I'm
On Wed, Feb 19, 2020 at 08:12:41PM +, HAGIO KAZUHITO(萩尾 一仁) wrote:
> Hi Cascardo,
>
> Do you have any solution or detailed information on the failure on your
> kernel?
> or could you try this branch? It has an additional patch on top of Pingfan's
> one to avoid the false positive failure
Hi Cascardo,
Do you have any solution or detailed information on the failure on your kernel?
or could you try this branch? It has an additional patch on top of Pingfan's
one to avoid the false positive failure that I'm suspecting:
On 02/12/2020 12:11 PM, piliu wrote:
>
>
> On 02/06/2020 11:46 AM, piliu wrote:
>>
>>
>> On 02/05/2020 05:18 AM, HAGIO KAZUHITO(萩尾 一仁) wrote:
-Original Message-
On Tue, Feb 04, 2020 at 02:24:17PM +0800, piliu wrote:
> Hi,
>
> Sorry to reply late due to a long
On 02/06/2020 11:46 AM, piliu wrote:
>
>
> On 02/05/2020 05:18 AM, HAGIO KAZUHITO(萩尾 一仁) wrote:
>>> -Original Message-
>>> On Tue, Feb 04, 2020 at 02:24:17PM +0800, piliu wrote:
Hi,
Sorry to reply late due to a long festival.
I have tested this patch against
On 02/05/2020 05:18 AM, HAGIO KAZUHITO(萩尾 一仁) wrote:
>> -Original Message-
>> On Tue, Feb 04, 2020 at 02:24:17PM +0800, piliu wrote:
>>> Hi,
>>>
>>> Sorry to reply late due to a long festival.
>>>
>>> I have tested this patch against v4.15 and latest kernel with small
>>> modification to
> -Original Message-
> On Tue, Feb 04, 2020 at 02:24:17PM +0800, piliu wrote:
> > Hi,
> >
> > Sorry to reply late due to a long festival.
> >
> > I have tested this patch against v4.15 and latest kernel with small
> > modification to meet the situation we discussed here. Both work fine.
>
On Tue, Feb 04, 2020 at 02:24:17PM +0800, piliu wrote:
> Hi,
>
> Sorry to reply late due to a long festival.
>
> I have tested this patch against v4.15 and latest kernel with small
> modification to meet the situation we discussed here. Both work fine.
>
> The below is the modification of two
Hi,
Sorry to reply late due to a long festival.
I have tested this patch against v4.15 and latest kernel with small
modification to meet the situation we discussed here. Both work fine.
The below is the modification of two kernel
test1. latest kernel with two extra modification to expose the
On Tue, Jan 28, 2020 at 05:03:12PM +, HAGIO KAZUHITO(萩尾 一仁) wrote:
> Hi Cascardo,
>
> > -Original Message-
> > On Mon, Jan 27, 2020 at 02:04:54PM -0300, Thadeu Lima de Souza Cascardo
> > wrote:
> > > Sorry for taking too long to respond, as I was on vacation.
> > >
> > > The kernels
Hi Cascardo,
> -Original Message-
> On Mon, Jan 27, 2020 at 02:04:54PM -0300, Thadeu Lima de Souza Cascardo wrote:
> > Sorry for taking too long to respond, as I was on vacation.
> >
> > The kernels that had commit 83e3c48729d9, but not commit a0b1280368d1, are
> > not supported anymore.
On Mon, Jan 27, 2020 at 02:04:54PM -0300, Thadeu Lima de Souza Cascardo wrote:
> Sorry for taking too long to respond, as I was on vacation.
>
> The kernels that had commit 83e3c48729d9, but not commit a0b1280368d1, are
> not supported anymore. In a way that it's even hard for me to test them.
>
On Thu, Jan 23, 2020 at 05:07:50PM +, HAGIO KAZUHITO(萩尾 一仁) wrote:
> Hi Pingfan,
>
> Sorry, I had been busy, then was looking into its history a bit.
>
> > -Original Message-
> > On 01/20/2020 04:59 PM, Baoquan He wrote:
> > > On 01/20/20 at 09:33am, David Hildenbrand wrote:
> > >>
>
Hi Pingfan,
Sorry, I had been busy, then was looking into its history a bit.
> -Original Message-
> On 01/20/2020 04:59 PM, Baoquan He wrote:
> > On 01/20/20 at 09:33am, David Hildenbrand wrote:
> >>
> >>
> >>> Am 20.01.2020 um 03:25 schrieb Pingfan Liu :
> >>>
> >>> After kernel commit
On 01/20/2020 04:59 PM, Baoquan He wrote:
> On 01/20/20 at 09:33am, David Hildenbrand wrote:
>>
>>
>>> Am 20.01.2020 um 03:25 schrieb Pingfan Liu :
>>>
>>> After kernel commit ba72b4c8cf60 ("mm/sparsemem: support sub-section
>>> hotplug"), when hot-removed, section_mem_map is still encoded with
On 01/20/20 at 09:33am, David Hildenbrand wrote:
>
>
> > Am 20.01.2020 um 03:25 schrieb Pingfan Liu :
> >
> > After kernel commit ba72b4c8cf60 ("mm/sparsemem: support sub-section
> > hotplug"), when hot-removed, section_mem_map is still encoded with section
> > start pfn, not NULL. This break
> Am 20.01.2020 um 03:25 schrieb Pingfan Liu :
>
> After kernel commit ba72b4c8cf60 ("mm/sparsemem: support sub-section
> hotplug"), when hot-removed, section_mem_map is still encoded with section
> start pfn, not NULL. This break the current makedumpfile.
>
> Whatever section_mem_map coding
After kernel commit ba72b4c8cf60 ("mm/sparsemem: support sub-section
hotplug"), when hot-removed, section_mem_map is still encoded with section
start pfn, not NULL. This break the current makedumpfile.
Whatever section_mem_map coding info after hot-removed, it is reliable
just to work on
25 matches
Mail list logo
