> #include
> +#include
> #include
> #include
> #include
> @@ -574,13 +575,13 @@ int qede_add_tc_flower_fltr(struct qede_dev *edev,
> __be16 proto,
> #define RX_RING_SIZE ((u16)BIT(RX_RING_SIZE_POW))
> #define NUM_RX_BDS_MAX (RX_RING_SIZE - 1)
> #define NUM_RX_BD
On Mon, May 04, 2020 at 09:03:56AM -0500, Eric W. Biederman wrote:
>
> I have added in the kexec mailling list.
>
> Looking at the patch we are discussing it appears that the kexec code
> could be doing much better in highmem situations today but is not.
Sound great!
>
>
> Joonsoo Kim writes
Hi David,
On Wed, May 6, 2020 at 2:54 AM David Miller wrote:
>
> From: Bhupesh Sharma
> Date: Wed, 6 May 2020 00:34:40 +0530
>
> > -#define NUM_RX_BDS_DEF ((u16)BIT(10) - 1)
> > +#define NUM_RX_BDS_DEF ((is_kdump_kernel()) ? ((u16)BIT(6) -
> > 1) : ((u16)BIT(10) - 1
From: Bhupesh Sharma
Date: Wed, 6 May 2020 00:34:40 +0530
> -#define NUM_RX_BDS_DEF ((u16)BIT(10) - 1)
> +#define NUM_RX_BDS_DEF ((is_kdump_kernel()) ? ((u16)BIT(6) -
> 1) : ((u16)BIT(10) - 1))
These parenthesis are very excessive and unnecessary. At the
very least
From: Ashish Kalra
Reset the host's page encryption bitmap related to kernel
specific page encryption status settings before we load a
new kernel by kexec. We cannot reset the complete
page encryption bitmap here as we need to retain the
UEFI/OVMF firmware specific settings.
The host's page encr
Since we have kdump kernel(s) running under severe memory constraint
it makes sense to disable the qed SRIOV functionality when running the
kdump kernel as kdump configurations on several distributions don't
support SRIOV targets for saving the vmcore (see [1] for example).
Currently the qed SRIOV
Since kdump kernel(s) run under severe memory constraint with the
basic idea being to save the crashdump vmcore reliably when the primary
kernel panics/hangs, large memory allocations done by a network driver
can cause the crashkernel to panic with OOM.
The qed* drivers take up approximately 214MB
Normally kdump kernel(s) run under severe memory constraint with the
basic idea being to save the crashdump vmcore reliably when the primary
kernel panics/hangs.
Currently the qed* ethernet driver ends up consuming a lot of memory in
the kdump kernel, leading to kdump kernel panic when one tries t
Hari Bathini writes:
> On 05/05/20 3:29 am, Eric W. Biederman wrote:
>>
>> Recently a patch was proposed to kimage_alloc_page to slightly alter
>> the logic of how pages allocated with incompatible flags were
>> detected. The logic was being altered because the semantics of the
>> page alloctor
On 05/05/20 3:29 am, Eric W. Biederman wrote:
>
> Recently a patch was proposed to kimage_alloc_page to slightly alter
> the logic of how pages allocated with incompatible flags were
> detected. The logic was being altered because the semantics of the
> page alloctor were changing yet again.
>
[ fixed Will's address... ]
On 2020-05-05 4:59 pm, Prabhakar Kushwaha wrote:
An SMMU Stream table is created by the primary kernel. This table is
used by the SMMU to perform address translations for device-originated
transactions. Any crash (if happened) launches the kdump kernel which
re-create
An SMMU Stream table is created by the primary kernel. This table is
used by the SMMU to perform address translations for device-originated
transactions. Any crash (if happened) launches the kdump kernel which
re-creates the SMMU Stream table. New transactions will be translated
via this new table.
12 matches
Mail list logo
