On 2025-04-05 01:31 +0200, Roberto Ricci wrote:
> I've bisected this other bug with kexec_load. I found commit
> 62a03defeabd PM / hibernate: Verify the consistent of e820 memory map by md5
> digest
> Reverting it on v6.14 fixes kexec_load, but not kexec_file_load.
> Als
On 2025-03-29 21:30 +0100, Roberto Ricci wrote:
> On 2025-03-29 09:44 +0800, Baoquan He wrote:
> > [snip]
> > 3) If answer to 1) and 2) is yes, does kexec_load works for you? Asking
> > this because kexec_load interface defaults to put kexec kernel on top of
> > system
On 2025-04-04 12:50 +0700, msizanoen wrote:
> Here's an updated version of the patch that better handles pathological e820
> tables.
>
> On 4/4/25 11:56, msizanoen wrote:
> > Also, can you reproduce this issue with a target kernel (the kernel
> > being kexec-ed) that has one of the patches attache
On 2025-04-04 09:54 +0700, msizanoen wrote:
> Can you send the dmesg logs for this case (6.13 + mentioned patch series
> backported as target kernel, using kexec_load)?
>
> On 4/4/25 05:00, Roberto Ricci wrote:
> > On 2025-04-01 19:59 +0700, msizanoen wrote:
> > >
On 2025-04-01 19:59 +0700, msizanoen wrote:
> [snip]
> It seems like `e820__register_nosave_regions` is erroneously marking some
> kernel memory as nosave in the presence of sub-page e820 regions. In theory
> backporting
> https://lore.kernel.org/all/20250214090651.3331663-1-r...@kernel.org/ should
On 2025-03-31 11:22 +0800, Dave Young wrote:
> > With v4.9.337, kexec (via kexec_load) + hibernation works.
> > With v5.4.291 it doesn't.
> > I'm not sure how bisection could be done in this case.
I just found out that 5.0 is not what comes after 4.9 [facepalm].
With v4.14.336 kexec_load + hiberna
Try gzip decompression.
Try LZMA decompression.
kernel: 0x7f5df32b5010 kernel_size: 0x8a9540
MEMORY RANGES
0400-0009fbff (0)
0009fc00-0009 (1)
000f-000f (1)
0010-bffd (0)
bffe-bfff (1)
00
On 2025-03-29 09:44 +0800, Baoquan He wrote:
> On 03/29/25 at 01:14am, Roberto Ricci wrote:
> [snip]
> > Anyway, I performed yet another bisection, this time with just plain
> > defconfig plus CONFIG_KEXEC_FILE=y, and I got different results.
> >
> > Updated steps to
[0.00] Linux version 6.14.0 (ricci@desktop0a) (gcc (GCC) 13.2.0, GNU ld
(GNU Binutils) 2.41) #1 SMP PREEMPT_DYNAMIC @0
[0.00] Command line: root=UUID=71b5e20d-efaa-4c09-b189-73cd6255e8ce ro
loglevel=4 oops=panic panic=30 crashkernel=512M
[0.00] BIOS-provided physical RAM m
On 2025-01-27 10:42 +0800, Dave Young wrote:
> On Mon, 27 Jan 2025 at 10:39, Dave Young wrote:
> > On 01/13/25 at 10:28pm, Roberto Ricci wrote:
> > > After rebooting the system via kexec, hibernating and rebooting the
> > > machine, this oops occurs:
> > >
&g
On 2025-01-22 Wed 17:45:41 +0800, RuiRui Yang wrote:
> > I can reproduce this with kernel 6.13-rc7 in a qemu x86_64 virtual machine
> > running Void Linux, with the following commands:
> >
> > ```
> > # kexec -l /boot/vmlinuz-6.13.0-rc7 --initrd=/boot/initramfs-6.13.0-rc7
> > --reuse-cmdline
> > #
On 17 January 2025 04:41:14 CET, Baoquan He wrote:
>On 01/17/25 at 09:55am, Baoquan He wrote:
>> On 01/16/25 at 12:52pm, Roberto Ricci wrote:
>> > On 2025-01-15 Wed 13:00:52 +0100, Roberto Ricci wrote:
>> > > On 2025-01-15 Wed 12:04:10 +0800, Baoquan He wrote:
&
On 2025-01-15 Wed 13:00:52 +0100, Roberto Ricci wrote:
> On 2025-01-15 Wed 12:04:10 +0800, Baoquan He wrote:
> > On 01/14/25 at 02:16pm, Roberto Ricci wrote:
> > > On 2025-01-13 Mon 22:28:48 +0100, Roberto Ricci wrote:
> > > > I can reproduce this with kernel 6.1
On 2025-01-15 Wed 12:04:10 +0800, Baoquan He wrote:
> On 01/14/25 at 02:16pm, Roberto Ricci wrote:
> > On 2025-01-13 Mon 22:28:48 +0100, Roberto Ricci wrote:
> > > I can reproduce this with kernel 6.13-rc7 in a qemu x86_64 virtual machine
> > > running Void Linux,
On 2025-01-13 Mon 15:17:49 -0800, Andrew Morton wrote:
> Thanks. Are you able to confirm that reverting 18d565ea95fe fixes things?
Actually no, reverting 18d565ea95fe553f442c5bbc5050415bab3c3fa4
("kexec_file: fix incorrect temp_start value in locate_mem_hole_top_down()")
on top of v6.13-rc7 does
On 2025-01-13 Mon 22:28:48 +0100, Roberto Ricci wrote:
> I can reproduce this with kernel 6.13-rc7 in a qemu x86_64 virtual machine
> running Void Linux, with the following commands:
>
> ```
> # kexec -l /boot/vmlinuz-6.13.0-rc7 --initrd=/boot/initramfs-6.13.0-rc7
> --reuse-
[0.00] Linux version 6.13.0-rc7_ricci (ricci@desktop0a) (gcc (GCC)
13.2.0, GNU ld (GNU Binutils) 2.41) #1 SMP PREEMPT_DYNAMIC @0
[0.00] Command line: root=UUID=71b5e20d-efaa-4c09-b189-73cd6255e8ce ro
loglevel=4 oops=panic panic=-1 crashkernel=512M
[0.00] BIOS-provided phys
After rebooting the system via kexec, hibernating and rebooting the machine,
this oops occurs:
```
[ 88.485216] Oops: general protection fault, probably for non-canonical
address 0xdc000940: [#1] PREEMPT SMP KASAN PTI
[ 88.485233] KASAN: probably user-memory-access in range
[0x
Hi,
I'm trying to cross-compile s-nail version 14.9.19 on a Void Linux host.
I run the command:
make CC=name_of_cross_compiler OPT_CROSS_BUILD=yes config
but I get the following error:
[...]
. OS error mapping table generated ... no
make: *** [makefile:23: config] Error 1
This p
Signed-off-by: Roberto Ricci
atof(3), whose return value is undefined on error, is used to parse
command line arguments, leading to undefined beavior if something else
than a number is specified.
this patch uses strtod(3) and exits on error.
---
xbacklight.c | 23 +--
1 file
20 matches
Mail list logo
