On 10/27/22 at 02:28pm, Eric DeVolder wrote:
>
>
> On 10/27/22 08:52, Baoquan He wrote:
> > On 10/26/22 at 04:54pm, David Hildenbrand wrote:
> > > On 26.10.22 16:48, Baoquan He wrote:
> > > > On 10/25/22 at 12:31pm, Borislav Petkov wrote:
> > > > > On Thu, Oct 13, 2022 at 10:57:28AM +0800,
On Fri, Oct 28, 2022 at 04:22:54PM -0500, Eric DeVolder wrote:
> /*
> * For the kexec_file_load() syscall path, specify the maximum number of
> * memory regions that the elfcorehdr buffer/segment can accommodate.
> * These regions are obtained via walk_system_ram_res(); eg. the
> * 'System
On 10/28/22 15:30, Borislav Petkov wrote:
On Fri, Oct 28, 2022 at 02:26:58PM -0500, Eric DeVolder wrote:
config CRASH_MAX_MEMORY_RANGES
depends on CRASH_DUMP && KEXEC_FILE && MEMORY_HOTPLUG
int
default 8192
help
For the kexec_file_load path, specify the maximum
On 10/28/22 15:30, Borislav Petkov wrote:
On Fri, Oct 28, 2022 at 02:26:58PM -0500, Eric DeVolder wrote:
config CRASH_MAX_MEMORY_RANGES
depends on CRASH_DUMP && KEXEC_FILE && MEMORY_HOTPLUG
int
default 8192
help
For the kexec_file_load path, specify the maximum
On Fri, Oct 28, 2022 at 02:26:58PM -0500, Eric DeVolder wrote:
> config CRASH_MAX_MEMORY_RANGES
> depends on CRASH_DUMP && KEXEC_FILE && MEMORY_HOTPLUG
> int
> default 8192
> help
> For the kexec_file_load path, specify the maximum number of
> memory regions, eg. as
On 10/28/22 12:06, Borislav Petkov wrote:
On Fri, Oct 28, 2022 at 10:29:45AM -0500, Eric DeVolder wrote:
So it is with this in mind that I suggest we stay with the statically sized
elfcorehdr buffer.
If that can be agreed upon, then it is "just a matter" of picking a useful
elfcorehdr
On Fri, Oct 28, 2022 at 10:29:45AM -0500, Eric DeVolder wrote:
> So it is with this in mind that I suggest we stay with the statically sized
> elfcorehdr buffer.
>
> If that can be agreed upon, then it is "just a matter" of picking a useful
> elfcorehdr size. Currently that size is derived from
On 10/28/22 05:19, Borislav Petkov wrote:
On Thu, Oct 27, 2022 at 02:24:11PM -0500, Eric DeVolder wrote:
Be aware, in reality, that if the system was fully populated, it would not
actually consume all 8192 phdrs. Rather /proc/iomem would essentially show a
large contiguous address space
Greetings,
I've been hitting a bug on my Lenovo ThinkPad T480 where kexecing will
cause EFI mode (if that's the right term for it) to be unconditionally
disabled, even when not using the --noefi option to kexec.
What I mean by "EFI mode" being disabled, more than just EFI runtime
services, is
On Wed, Oct 26, 2022 at 10:13:48AM +0800, Xianting Tian wrote:
> Hi Simon
>
> thanks for the comments
>
> 在 2022/10/21 下午11:27, Simon Horman 写道:
> > On Thu, Oct 20, 2022 at 11:15:48AM +0800, Xianting Tian wrote:
> > > From: Nick Kossifidis
> > >
> > > This patch adds support for loading the
On Thu, Oct 27, 2022 at 02:24:11PM -0500, Eric DeVolder wrote:
> Be aware, in reality, that if the system was fully populated, it would not
> actually consume all 8192 phdrs. Rather /proc/iomem would essentially show a
> large contiguous address space which would require just a single phdr.
Then
On Fri, Oct 21, 2022 at 05:27:57PM +0200, Simon Horman wrote:
> Use to checkout@v3 instead of checkout@v2
> as the latter uses Node.js 12 actions which are deprecated.
>
> https://github.blog/changelog/2022-09-22-github-actions-all-actions-will-begin-running-on-node16-instead-of-node12/
>
>
12 matches
Mail list logo
