On 12/01/23 at 11:53am, Randy Dunlap wrote:
>
>
> On 11/30/23 18:37, Stephen Rothwell wrote:
> > Hi all,
> >
> > Changes since 20231130:
> >
>
> on riscv 32-bit or 64-bit, with
> # CONFIG_MMU is not set
Can you provide your .config so that I reproduce it? Disabling
CONFIG_MMU need find all
On 11/30/23 18:37, Stephen Rothwell wrote:
> Hi all,
>
> Changes since 20231130:
>
on riscv 32-bit or 64-bit, with
# CONFIG_MMU is not set
In file included from ../arch/riscv/kernel/crash_core.c:3:
../arch/riscv/kernel/crash_core.c: In function 'arch_crash_save_vmcoreinfo':
On Fri 01-12-23 16:51:13, Philipp Rudo wrote:
> On Fri, 1 Dec 2023 12:55:52 +0100
> Michal Hocko wrote:
>
> > On Fri 01-12-23 12:33:53, Philipp Rudo wrote:
> > [...]
> > > And yes, those are all what-if concerns but unfortunately that is all
> > > we have right now.
> >
> > Should theoretical
On Fri, Dec 01, 2023 at 10:54:49PM +0800, Huacai Chen wrote:
> Hi, Simon,
>
> On Fri, Dec 1, 2023 at 10:06 PM Simon Horman wrote:
> >
> > On Wed, Nov 29, 2023 at 12:15:17PM +0800, Huacai Chen wrote:
> > > Hi, all,
> > >
> > > On Tue, Nov 28, 2023 at 2:27 PM WANG Rui wrote:
> > > >
> > > > Hi,
>
On Thu, Nov 23, 2023 at 09:38:13AM +, Huang, Kai wrote:
>
> > diff --git a/arch/x86/kernel/acpi/boot.c b/arch/x86/kernel/acpi/boot.c
> > index 171d86fe71ef..602b5d3982ff 100644
> > --- a/arch/x86/kernel/acpi/boot.c
> > +++ b/arch/x86/kernel/acpi/boot.c
> > @@ -22,6 +22,7 @@
> > #include
> >
On Fri, 1 Dec 2023 12:55:52 +0100
Michal Hocko wrote:
> On Fri 01-12-23 12:33:53, Philipp Rudo wrote:
> [...]
> > And yes, those are all what-if concerns but unfortunately that is all
> > we have right now.
>
> Should theoretical concerns without an actual evidence (e.g. multiple
> drivers
Hi, Simon,
On Fri, Dec 1, 2023 at 10:06 PM Simon Horman wrote:
>
> On Wed, Nov 29, 2023 at 12:15:17PM +0800, Huacai Chen wrote:
> > Hi, all,
> >
> > On Tue, Nov 28, 2023 at 2:27 PM WANG Rui wrote:
> > >
> > > Hi,
> > >
> > > On Mon, Nov 27, 2023 at 10:36 AM RuiRui Yang wrote:
> > > >
> > > >
On Wed, Nov 29, 2023 at 12:15:17PM +0800, Huacai Chen wrote:
> Hi, all,
>
> On Tue, Nov 28, 2023 at 2:27 PM WANG Rui wrote:
> >
> > Hi,
> >
> > On Mon, Nov 27, 2023 at 10:36 AM RuiRui Yang wrote:
> > >
> > > On Mon, 27 Nov 2023 at 09:53, RuiRui Yang wrote:
> > > >
> > > > On Sat, 25 Nov 2023
On Thu, Nov 30, 2023 at 12:01:36PM +0800, Baoquan He wrote:
> On 11/29/23 at 11:51am, Jiri Bohac wrote:
> > We get a lot of problems reported by partners testing kdump on
> > their setups prior to release. But even if we tune the reserved
> > size up, OOM is still the most common reason for kdump
On Fri 01-12-23 12:33:53, Philipp Rudo wrote:
[...]
> And yes, those are all what-if concerns but unfortunately that is all
> we have right now.
Should theoretical concerns without an actual evidence (e.g. multiple
drivers known to be broken) become a roadblock for this otherwise useful
feature?
Hi Jiri,
I'd really love to see something like this to work. Although I also
share the concerns about shitty device drivers corrupting the CMA.
Please see my other mail for that.
Anyway, one more comment below.
On Fri, 24 Nov 2023 20:54:36 +0100
Jiri Bohac wrote:
[...]
> Now, specifying
>
Hi Michal,
On Thu, 30 Nov 2023 14:41:12 +0100
Michal Hocko wrote:
> On Thu 30-11-23 20:31:44, Baoquan He wrote:
> [...]
> > > > which doesn't use the proper pinning API (which would migrate away from
> > > > the CMA) then what is the worst case? We will get crash kernel corrupted
> > > >
On Fri 01-12-23 08:54:20, Pingfan Liu wrote:
[...]
> > I am not aware of any method to detect a driver is going to configure a
> > RDMA.
> >
>
> If there is a pattern, scripts/coccinelle may give some help. But I am
> not sure about that.
I am not aware of any pattern.
> > > If this can be
On Thu, Nov 30, 2023 at 10:39:53AM +0800, Baoquan He wrote:
$subject has a typo in the arch bit :)
> Replace pr_debug() with the newly added kexec_dprintk() in kexec_file
> loading related codes.
Commit messages should be understandable in isolation, but this only
explains (part of) what is
14 matches
Mail list logo