On 06/12/19 at 07:10pm, Lendacky, Thomas wrote:
> On 6/12/19 1:07 PM, Borislav Petkov wrote:
> > On Wed, Jun 12, 2019 at 04:52:22PM +, Lendacky, Thomas wrote:
> >> I think the discussion ended up being that debuginfo wasn't being stripped
> >> from the kernel and initrd (mainly the initrd). Wh
On 06/12/19 at 08:07pm, Borislav Petkov wrote:
> On Wed, Jun 12, 2019 at 04:52:22PM +, Lendacky, Thomas wrote:
> > I think the discussion ended up being that debuginfo wasn't being stripped
> > from the kernel and initrd (mainly the initrd). What are the sizes of
> > the kernel and initrd that
On 6/12/19 1:07 PM, Borislav Petkov wrote:
> On Wed, Jun 12, 2019 at 04:52:22PM +, Lendacky, Thomas wrote:
>> I think the discussion ended up being that debuginfo wasn't being stripped
>> from the kernel and initrd (mainly the initrd). What are the sizes of
>> the kernel and initrd that you ar
On Wed, Jun 12, 2019 at 04:52:22PM +, Lendacky, Thomas wrote:
> I think the discussion ended up being that debuginfo wasn't being stripped
> from the kernel and initrd (mainly the initrd). What are the sizes of
> the kernel and initrd that you are loading for kdump via kexec?
>
> From previou
On 6/12/19 10:10 AM, Borislav Petkov wrote:
> On Wed, Jun 12, 2019 at 09:55:49AM +0800, Baoquan He wrote:
>> With further investigation, the failure after applying Tom's patch is
>> caused by OOM. When increase crashkernel reservation to 512M, kdump
>> kernel can boot successfully. I noticed your c
On Wed, Jun 12, 2019 at 09:55:49AM +0800, Baoquan He wrote:
> With further investigation, the failure after applying Tom's patch is
> caused by OOM. When increase crashkernel reservation to 512M, kdump
> kernel can boot successfully. I noticed your crashkernel reservation is
> 256M, that will fail
On 06/12/19 at 09:55am, Baoquan He wrote:
> On 06/10/19 at 01:37pm, Borislav Petkov wrote:
> > On Sat, Jun 08, 2019 at 06:26:59PM +0800, Baoquan He wrote:
> > > OK, I see. Then it should be the issue we have met and talked about with
> > > Tom.
> > > https://lkml.kernel.org/r/20190604134952.GC26891
On 06/10/19 at 01:37pm, Borislav Petkov wrote:
> On Sat, Jun 08, 2019 at 06:26:59PM +0800, Baoquan He wrote:
> > OK, I see. Then it should be the issue we have met and talked about with
> > Tom.
> > https://lkml.kernel.org/r/20190604134952.GC26891@MiWiFi-R3L-srv
> >
> > You can apply Tom's patch a
在 2019年06月10日 19:37, Borislav Petkov 写道:
> On Sat, Jun 08, 2019 at 06:26:59PM +0800, Baoquan He wrote:
>> OK, I see. Then it should be the issue we have met and talked about with
>> Tom.
>> https://lkml.kernel.org/r/20190604134952.GC26891@MiWiFi-R3L-srv
>>
>> You can apply Tom's patch as below. I t
On Sat, Jun 08, 2019 at 06:26:59PM +0800, Baoquan He wrote:
> OK, I see. Then it should be the issue we have met and talked about with
> Tom.
> https://lkml.kernel.org/r/20190604134952.GC26891@MiWiFi-R3L-srv
>
> You can apply Tom's patch as below. I tested it, it can make kexec
> kernel succeed to
在 2019年06月08日 01:42, Borislav Petkov 写道:
> On Tue, May 28, 2019 at 03:30:21PM +0800, lijiang wrote:
>> Hi, Boris and Thomas
>>
>> Could you give me any suggestions about this patch series? Other reviewers?
>
> So I'm testing this on a box with SME enabled but after loading the
> crash kernel, it f
On 06/08/19 at 12:06pm, Borislav Petkov wrote:
> On Sat, Jun 08, 2019 at 06:01:39PM +0800, Baoquan He wrote:
> > OK, it may be different with the case we met, if panic happened when
> > load a kdump kernel.
> >
> > We can load with 'kexec -l' or 'kexec -p', but can't boot after triggering
> > cras
On Sat, Jun 08, 2019 at 06:01:39PM +0800, Baoquan He wrote:
> OK, it may be different with the case we met, if panic happened when
> load a kdump kernel.
>
> We can load with 'kexec -l' or 'kexec -p', but can't boot after triggering
> crash or execute 'kexec -e' to do kexec jumping.
No, I load a
On 06/08/19 at 11:10am, Borislav Petkov wrote:
> On Sat, Jun 08, 2019 at 11:54:51AM +0800, Baoquan He wrote:
> > Is it a UEFI box?
>
> Yes.
OK, it doesn't matter with uefi since CONFIG_RANDOMIZE_BASE is not set.
>
> > If it's uefi machine, it should relate to below issue. Because kexec
> > al
On Sat, Jun 08, 2019 at 11:54:51AM +0800, Baoquan He wrote:
> Is it a UEFI box?
Yes.
> If it's uefi machine, it should relate to below issue. Because kexec
> always fails to randomly choose a new position for kernel.
The kernel succeeds in selecting a position for the kernel - the kexec
kernel d
On 06/07/19 at 07:42pm, Borislav Petkov wrote:
> On Tue, May 28, 2019 at 03:30:21PM +0800, lijiang wrote:
> > Hi, Boris and Thomas
> >
> > Could you give me any suggestions about this patch series? Other reviewers?
>
> So I'm testing this on a box with SME enabled but after loading the
> crash ke
On Tue, May 28, 2019 at 03:30:21PM +0800, lijiang wrote:
> Hi, Boris and Thomas
>
> Could you give me any suggestions about this patch series? Other reviewers?
So I'm testing this on a box with SME enabled but after loading the
crash kernel, it freezes instead of rebooting. My cmdline is:
kexec
Hi, Boris and Thomas
Could you give me any suggestions about this patch series? Other reviewers?
Thanks.
Lianbo
在 2019年04月23日 09:30, Lianbo Jiang 写道:
> This patchset did three things:
>
> a). x86/e820, resource: add a new I/O resource descriptor 'IORES_DESC_
> RESERVED'
>
> b). x86/mm: cha
18 matches
Mail list logo
