On Thu, 9 May 2024 23:24:20 +0300
Mike Rapoport wrote:
> On Thu, May 09, 2024 at 01:31:22PM -0400, Steven Rostedt wrote:
> > On Thu, 9 May 2024 00:00:23 -0400
> > Steven Rostedt wrote:
> >
> > > I tried this approach and it unfortunately picks a different physical
> > > location every time
On Thu, May 09, 2024 at 01:31:22PM -0400, Steven Rostedt wrote:
> On Thu, 9 May 2024 00:00:23 -0400
> Steven Rostedt wrote:
>
> > I tried this approach and it unfortunately picks a different physical
> > location every time :-(
> >
> > So it is either adding to e820 tables or we create a new
On Thu, 9 May 2024 00:00:23 -0400
Steven Rostedt wrote:
> I tried this approach and it unfortunately picks a different physical
> location every time :-(
>
> So it is either adding to e820 tables or we create a new way to
> allocate memory at early boot up.
>
Hmm, now I'm testing it more and
On Wed, 1 May 2024 18:30:40 +0300
Mike Rapoport wrote:
> > So this will allocate the same physical location for every boot, if booting
> > the same kernel and having the same physical memory layout?
>
> Up to kaslr that might use that location for the kernel image.
> But it's the same as
On Wed, May 01, 2024 at 12:09:04PM -0400, Steven Rostedt wrote:
> On Wed, 1 May 2024 18:30:40 +0300
> Mike Rapoport wrote:
>
> > > > /*
> > > > * Parse early_reserve_mem=nn:align:name
> > > > */
> > > > static int __init early_reserve_mem(char *p)
> > > > {
> > > > phys_addr_t start,
On Wed, 1 May 2024 18:30:40 +0300
Mike Rapoport wrote:
> > > /*
> > > * Parse early_reserve_mem=nn:align:name
> > > */
> > > static int __init early_reserve_mem(char *p)
> > > {
> > > phys_addr_t start, size, align;
> > > char *oldp;
> > > int err;
> > >
> > > if (!p)
> > >
On Wed, May 01, 2024 at 10:54:55AM -0400, Steven Rostedt wrote:
> On Wed, 1 May 2024 17:45:49 +0300
> Mike Rapoport wrote:
>
> > > +static void __init memmap_copy(void)
> > > +{
> > > + if (!early_mmap_size)
> > > + return;
> > > +
> > > + mmap_list = kcalloc(early_mmap_size + 1,
On Wed, 1 May 2024 17:45:49 +0300
Mike Rapoport wrote:
> > +static void __init memmap_copy(void)
> > +{
> > + if (!early_mmap_size)
> > + return;
> > +
> > + mmap_list = kcalloc(early_mmap_size + 1, sizeof(mmap_list),
> > GFP_KERNEL);
>
> We can keep early_mmap_size after boot
On Fri, Apr 12, 2024 at 01:22:43PM -0400, Steven Rostedt wrote:
> On Fri, 12 Apr 2024 09:17:18 -0300
> "Guilherme G. Piccoli" wrote:
>
> > Thanks Steve, seems a good idea. With that, I could test on kdumpst (the
> > tool used on Steam Deck), since it relies on modular pstore/ram.
>
> Something
On Fri, 12 Apr 2024 09:17:18 -0300
"Guilherme G. Piccoli" wrote:
> Thanks Steve, seems a good idea. With that, I could test on kdumpst (the
> tool used on Steam Deck), since it relies on modular pstore/ram.
Something like this could work.
-- Steve
diff --git a/arch/x86/kernel/e820.c
On 11/04/2024 16:40, Steven Rostedt wrote:
> [...]
> What I think I could do is to have a check after memory is allocated to
> copy the table mapping (in the heap) if it is filled. The reason I did it
> this way was because it was the easiest way to save the label to address
> memory before memory
On Thu, 11 Apr 2024 16:11:55 -0300
"Guilherme G. Piccoli" wrote:
> Thanks Steve! Like Kees, I've been wanting a consistent way of mapping
> some RAM for pstore for a while, without resorting to platform drivers
> like Chromebooks do...
Great!
>
> The idea seems very interesting and helpful,
On 09/04/2024 19:25, Luck, Tony wrote:
>>> I forgot to mention that this makes it trivial for any machine that doesn't
>>> clear memory on soft-reboot, to enable console ramoops (to have access to
>>> the last boot dmesg without needing serial).
>>>
>>> I tested this on a couple of my test boxes
> Do ECC servers wipe their RAM by default? I know that if you build with
> CONFIG_RESET_ATTACK_MITIGATION=y on an EFI system that supports the
> MemoryOverwriteRequestControl EFI variable you'll get a RAM wipe...
I know that after I've been running RAS tests that inject ECC errors into
On Tue, Apr 09, 2024 at 10:25:33PM +, Luck, Tony wrote:
> >> I forgot to mention that this makes it trivial for any machine that doesn't
> >> clear memory on soft-reboot, to enable console ramoops (to have access to
> >> the last boot dmesg without needing serial).
> >>
> >> I tested this on
On Tue, 9 Apr 2024 22:25:33 +
"Luck, Tony" wrote:
> >> I forgot to mention that this makes it trivial for any machine that doesn't
> >> clear memory on soft-reboot, to enable console ramoops (to have access to
> >> the last boot dmesg without needing serial).
> >>
> >> I tested this on a
> On Apr 10, 2024, at 3:55 AM, Luck, Tony wrote:
>
>
>>
>>> I forgot to mention that this makes it trivial for any machine that doesn't
>>> clear memory on soft-reboot, to enable console ramoops (to have access to
>>> the last boot dmesg without needing serial).
>>>
>>> I tested this on a
>> I forgot to mention that this makes it trivial for any machine that doesn't
>> clear memory on soft-reboot, to enable console ramoops (to have access to
>> the last boot dmesg without needing serial).
>>
>> I tested this on a couple of my test boxes and on QEMU, and it works rather
>> well.
>
On Tue, Apr 09, 2024 at 05:23:58PM -0400, Steven Rostedt wrote:
> On Tue, 09 Apr 2024 17:02:54 -0400
> Steven Rostedt wrote:
>
> > memmap=12M*4096:oops ramoops.mem_name=oops
>
> I forgot to mention that this makes it trivial for any machine that doesn't
> clear memory on soft-reboot, to
On Tue, 09 Apr 2024 17:02:54 -0400
Steven Rostedt wrote:
> memmap=12M*4096:oops ramoops.mem_name=oops
I forgot to mention that this makes it trivial for any machine that doesn't
clear memory on soft-reboot, to enable console ramoops (to have access to
the last boot dmesg without needing
Add wildcard option of reserving physical memory on kernel command line
Background:
In ChromeOS, we have 1 MB of pstore ramoops reserved so that we can extract
dmesg output and some other information when a crash happens in the field.
(This is only done when the user selects "Allow Google to
21 matches
Mail list logo
