On Thu, Mar 09, 2017 at 02:38:06PM +0800, Dave Young wrote:
> Add efi/kexec list.
>
> On 03/08/17 at 12:16pm, Omar Sandoval wrote:
[snip]
> I have no more clue yet from your provided log, but the runtime value is
> odd to me. It is set in below code:
>
> arch/x
ze)
> return;
> }
>
> + /* No need to reserve regions that will never be freed. */
> + if (md.attribute & EFI_MEMORY_RUNTIME)
> + return;
> +
> size += addr % EFI_PAGE_SIZE;
> size = round_up(size, EFI_PAGE_SIZE
On Thu, Mar 16, 2017 at 10:50:48AM -0700, Omar Sandoval wrote:
> On Thu, Mar 16, 2017 at 12:41:32PM +, Matt Fleming wrote:
> > On Mon, 13 Mar, at 03:37:48PM, Dave Young wrote:
> > >
> > > Omar, could you try below patch? Looking at the efi_mem_desc_lookup, it
>
VMCOREINFO_SYMBOL(contig_page_data);
> > #endif
> > #ifdef CONFIG_SPARSEMEM
> > - VMCOREINFO_SYMBOL(mem_section);
> > + VMCOREINFO_SYMBOL_ARRAY(mem_section);
> > VMCOREINFO_LENGTH(mem_section, NR_SECTION_ROOTS);
> > VMCOREINFO_STRUCT_SIZE(mem_section);
> > VMCOREINFO
From: Omar Sandoval
We hit a bug where vmcore-dmesg would get stuck in a loop, and since we
were redirecting the output to a file, it wouldn't stop until it filled
up the disk. This only happened when the dmesg buffer had filled up and
wrapped around. It turns out that when we hit the end o
On Wed, Jul 11, 2018 at 09:06:27PM +0530, Bhupesh Sharma wrote:
> Hi James,
>
> On Wed, Jul 11, 2018 at 6:54 PM, James Morse wrote:
> > Hi Bhupesh,
> >
> > (CC: +Omar)
> >
> > On 20/06/18 08:26, Bhupesh Sharma wrote:
> >> On Wed, Jun 20, 2018 at 7:46 AM, Jin, Yanjiang
> >> wrote:
> From: Bh
On Fri, Apr 08, 2022 at 11:02:47AM +0800, Baoquan He wrote:
> On 04/07/22 at 03:36pm, Chris Down wrote:
> > Omar Sandoval writes:
> > > From: Omar Sandoval
> > >
> > > Commit 3ee48b6af49c ("mm, x86: Saving vmcore with non-lazy freeing of
> > > v
From: Omar Sandoval
Commit 3ee48b6af49c ("mm, x86: Saving vmcore with non-lazy freeing of
vmas") introduced set_iounmap_nonlazy(), which sets vmap_lazy_nr to
lazy_max_pages() + 1, ensuring that any future vunmaps() immediately
purge the vmap areas instead of doing it lazily.
Commit 69
From: Omar Sandoval
Commit 3ee48b6af49c ("mm, x86: Saving vmcore with non-lazy freeing of
vmas") introduced set_iounmap_nonlazy(), which sets vmap_lazy_nr to
lazy_max_pages() + 1, ensuring that any future vunmaps() immediately
purges the vmap areas instead of doing it lazil
On Wed, Apr 06, 2022 at 05:59:53PM +0800, Baoquan He wrote:
> On 04/06/22 at 11:13am, Uladzislau Rezki wrote:
> > > On Tue, Apr 05, 2022 at 12:40:31PM -0700, Omar Sandoval wrote:
> > > > A simple way to "fix" this would be to make set_iounmap_nonlazy() set
>
From: Omar Sandoval
Commit 3ee48b6af49c ("mm, x86: Saving vmcore with non-lazy freeing of
vmas") introduced set_iounmap_nonlazy(), which sets vmap_lazy_nr to
lazy_max_pages() + 1, ensuring that any future vunmaps() immediately
purge the vmap areas instead of doing it lazily.
Commit 69
11 matches
Mail list logo
