Rebooting in 40 seconds..
--
You may reply to this email to add a comment.
You are receiving this mail because:
You are watching someone on the CC list of the bug.
--- Comment #1 from Erhard F. (erhard_f@mailbox.org) ---
Created attachment 298019
--> https://bugzilla.kernel.org/attachment.cgi?id=298019&action=edit
kernel .config (5.13.4, PowerMac G5 11,2)
--
You may reply to this email to add a comment.
You are receiving this mail because:
You are watching someone on the CC list of the bug.
Rebooting in 40 seconds..
--
You may reply to this email to add a comment.
You are receiving this mail because:
You are watching someone on the CC list of the bug.
--- Comment #3 from Erhard F. (erhard_f@mailbox.org) ---
Created attachment 298395
--> https://bugzilla.kernel.org/attachment.cgi?id=298395&action=edit
kernel .config (5.14-rc6, PowerMac G5 11,2)
--
You may reply to this email to add a comment.
You are receiving this mail because:
You are watching someone on the CC list of the bug.
--- Comment #4 from Erhard F. (erhard_f@mailbox.org) ---
Checked out whether this has really something to do with bug #213079 or not by
copying this root partition to a regular HDD and use that one instead. As the
issue still happens it seems these are two seperate bugs.
[...]
Kernel panic - not syncing: corrupted stack end detected inside scheduler
CPU: 1 PID: 1509 Comm: powerpc64-unkno Tainted: G W
5.14.1-PowerMacG5+ #2
Call Trace:
[c0000000386434c0] [c00000000054cd64] .dump_stack_lvl+0x98/0xe0 (unreliable)
[c000000038643550] [c000000000068ab8] .panic+0x160/0x40c
[c000000038643600] [c00000000081202c] .__schedule+0x7c/0x840
[c0000000386436d0] [c00000000081293c] .preempt_schedule_common+0x28/0x48
[c000000038643750] [c00000000081298c] .__cond_resched+0x30/0x4c
[c0000000386437d0] [c0000000004edf18] .copy_page_to_iter+0xbc/0x32c
[c0000000386438a0] [c0000000001c99d8] .filemap_read+0x574/0x618
[c000000038643a60] [c00000000033182c] .ext4_file_read_iter+0xb8/0x11c
[c000000038643b00] [c000000000272f1c] .new_sync_read+0x94/0xe0
[c000000038643c00] [c0000000002746c0] .vfs_read+0x128/0x12c
[c000000038643ca0] [c000000000274a58] .ksys_read+0x78/0xc4
[c000000038643d60] [c000000000022808] .system_call_exception+0x1a4/0x1dc
[c000000038643e10] [c00000000000b4cc] system_call_common+0xec/0x250
Rebooting in 40 seconds..
--
You may reply to this email to add a comment.
You are receiving this mail because:
You are watching someone on the CC list of the bug.
https://bugzilla.kernel.org/show_bug.cgi?id=213837
Erhard F. (erhard_f@mailbox.org) changed:
What |Removed |Added
----------------------------------------------------------------------------
Attachment #298395|0 |1
is obsolete| |
--- Comment #5 from Erhard F. (erhard_f@mailbox.org) ---
Created attachment 298671
--> https://bugzilla.kernel.org/attachment.cgi?id=298671&action=edit
kernel .config (5.14.1, PowerMac G5 11,2)
--
You may reply to this email to add a comment.
You are receiving this mail because:
You are watching someone on the CC list of the bug.
--- Comment #4 from Erhard F. (erhard_f@mailbox.org) ---
Checked out whether this has really something to do with bug #213079 or not by
copying this root partition to a regular HDD and use that one instead. As the
issue still happens it seems these are two seperate bugs.
[...]
Kernel panic - not syncing: corrupted stack end detected inside scheduler
Can you try this patch, it might help us work out what is corrupting the
stack.
cheers
--- Comment #4 from Erhard F. (erhard_f@mailbox.org) ---
Checked out whether this has really something to do with bug #213079 or not
by
copying this root partition to a regular HDD and use that one instead. As the
issue still happens it seems these are two seperate bugs.
[...]
Kernel panic - not syncing: corrupted stack end detected inside scheduler
Can you try this patch, it might help us work out what is corrupting the
stack.
cheers
*prev)
static inline void schedule_debug(struct task_struct *prev, bool preempt)
{
#ifdef CONFIG_SCHED_STACK_END_CHECK
- if (task_stack_end_corrupted(prev))
+ if (task_stack_end_corrupted(prev)) {
+ char *start = (char *)end_of_stack(prev);
+ pr_err("stack corrupted? stack end = 0x%px\n",
end_of_stack(prev));
+ print_hex_dump(KERN_ERR, "stack: ", DUMP_PREFIX_ADDRESS, 16, 4,
+ start - SZ_1K, THREAD_SIZE + SZ_1K, true);
+
panic("corrupted stack end detected inside scheduler\n");
+ }
if (task_scs_end_corrupted(prev))
panic("corrupted shadow stack detected inside scheduler\n");
--
You may reply to this email to add a comment.
You are receiving this mail because:
You are watching someone on the CC list of the bug.
https://bugzilla.kernel.org/show_bug.cgi?id=213837
Michael Ellerman (michael@ellerman.id.au) changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |michael@ellerman.id.au
Component|Other |PPC-64
Hardware|All |PPC-64
Assignee|akpm@linux-foundation.org |platform_ppc-64@kernel-bugs
| |.osdl.org
Product|Memory Management |Platform Specific/Hardware
--
You may reply to this email to add a comment.
You are receiving this mail because:
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.
https://bugzilla.kernel.org/show_bug.cgi?id=213837
Michael Ellerman (michael@ellerman.id.au) changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |NEEDINFO
--
You may reply to this email to add a comment.
You are receiving this mail because:
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.
Can you try this patch, it might help us work out what is corrupting the
stack.
With your patch applied to recent v5.15-rc2 the output looks like this:
[...]
stack corrupted? stack end = 0xc000000029fdc000
stack: c000000029fdbc00: 5a5a5a5a 5a5a5a5a cccccccc cccccccc ZZZZZZZZ........
...
Can't make much sense out of it but hopefully you can. ;)
Thanks. Obvious isn't it? ;)
stack corrupted? stack end = 0xc000000029fdc000
stack: c000000029fdbc00: 5a5a5a5a 5a5a5a5a cccccccc cccccccc ZZZZZZZZ........
stack: c000000029fdbc10: 00000ddc 7c000010 cccccccc cccccccc ....|...........
stack: c000000029fdbc20: 29fc4e41 673d4bb3 5a5a5a5a 5a5a5a5a ).NAg=K.ZZZZZZZZ
stack: c000000029fdbc30: cccccccc cccccccc 00000ddc 8e000010 ................
stack: c000000029fdbc40: cccccccc cccccccc 41fc4e41 673d41a3 ........A.NAg=A.
stack: c000000029fdbc50: 5a5a5a5a 5a5a5a5a cccccccc cccccccc ZZZZZZZZ........
stack: c000000029fdbc60: 00000ddc 8e00000c cccccccc cccccccc ................
stack: c000000029fdbc70: 79fc4e41 673d4dab 5a5a5a5a 5a5a5a5a y.NAg=M.ZZZZZZZZ
stack: c000000029fdbc80: cccccccc cccccccc 00000ddc 90000008 ................
stack: c000000029fdbc90: cccccccc cccccccc 91fc4e41 673d4573 ..........NAg=Es
stack: c000000029fdbca0: 5a5a5a5a 5a5a5a5a cccccccc cccccccc ZZZZZZZZ........
stack: c000000029fdbcb0: 00000dd7 ac000016 cccccccc cccccccc ................
stack: c000000029fdbcc0: c9fc4e41 673d4203 5a5a5a5a 5a5a5a5a ..NAg=B.ZZZZZZZZ
stack: c000000029fdbcd0: cccccccc cccccccc 00000ddc 6c000004 ............l...
stack: c000000029fdbce0: cccccccc cccccccc e1fc4e41 673d474b ..........NAg=GK
stack: c000000029fdbcf0: 5a5a5a5a 5a5a5a5a cccccccc cccccccc ZZZZZZZZ........
stack: c000000029fdbd00: 00000ddc 88000000 cccccccc cccccccc ................
stack: c000000029fdbd10: 19fd4e41 673d4143 5a5a5a5a 5a5a5a5a ..NAg=ACZZZZZZZZ
stack: c000000029fdbd20: cccccccc cccccccc 00000ddb 6c00000e ............l...
stack: c000000029fdbd30: cccccccc cccccccc 31fd4e41 673d4f43 ........1.NAg=OC
stack: c000000029fdbd40: 5a5a5a5a 5a5a5a5a cccccccc cccccccc ZZZZZZZZ........
stack: c000000029fdbd50: 00000ddc 8e000008 cccccccc cccccccc ................
stack: c000000029fdbd60: 69fd4e41 673d407b 5a5a5a5a 5a5a5a5a i.NAg=@{ZZZZZZZZ
stack: c000000029fdbd70: cccccccc cccccccc 00000ddc 92000008 ................
stack: c000000029fdbd80: cccccccc cccccccc 81fd4e41 673d4633 ..........NAg=F3
stack: c000000029fdbd90: 5a5a5a5a 5a5a5a5a cccccccc cccccccc ZZZZZZZZ........
stack: c000000029fdbda0: 00000ddb 42000018 cccccccc cccccccc ....B...........
stack: c000000029fdbdb0: b9fd4e41 673d42fb 5a5a5a5a 5a5a5a5a ..NAg=B.ZZZZZZZZ
stack: c000000029fdbdc0: cccccccc cccccccc 00000ddc 7e000018 ............~...
stack: c000000029fdbdd0: cccccccc cccccccc d1fd4e41 673d4a1b ..........NAg=J.
stack: c000000029fdbde0: 5a5a5a5a 5a5a5a5a cccccccc cccccccc ZZZZZZZZ........
stack: c000000029fdbdf0: 00000ddc 8e000004 cccccccc cccccccc ................
stack: c000000029fdbe00: 09fe4e41 673d4ee3 5a5a5a5a 5a5a5a5a ..NAg=N.ZZZZZZZZ
stack: c000000029fdbe10: cccccccc cccccccc 00000dd9 7200001c ............r...
stack: c000000029fdbe20: cccccccc cccccccc 21fe4e41 673d4fa3 ........!.NAg=O.
That's slab data.
It's not clear what the actual data is, but because you booted with
slub_debug=FZP we can see the red zones and poison.
The cccccccc is SLUB_RED_ACTIVE, and 5a5a5a5a is POISON_INUSE (see poison.h)
stack: c000000029fdbe30: c0000000 29fdbeb0 cccccccc cccccccc ....)...........
But then here we have an obvious pointer (big endian FTW).
And it points nearby, just slightly higher in memory, so that looks
suspiciously like a stack back chain pointer. There's more similar
values if you look further.
But we shouldn't be seeing the stack yet, it's meant to start (end) at
c000000029fdc000 ...
stack: c000000029fdbe40: 00000ddc 94000000 cccccccc cccccccc ................
stack: c000000029fdbe50: 59fe4e41 673d4933 5a5a5a5a 5a5a5a5a Y.NAg=I3ZZZZZZZZ
stack: c000000029fdbe60: cccccccc cccccccc 00000dd9 60000024 ............`..$
stack: c000000029fdbe70: cccccccc cccccccc 71fe4e41 673d416b ........q.NAg=Ak
stack: c000000029fdbe80: 5a5a5a5a 5a5a5a5a cccccccc cccccccc ZZZZZZZZ........
stack: c000000029fdbe90: 00000ddc 6000000c cccccccc cccccccc ....`...........
stack: c000000029fdbea0: c0000000 29fdbf20 00000000 00000002 ....).. ........
stack: c000000029fdbeb0: c0000000 29fdbf30 00000ddc 7e00001c ....)..0....~... <---
stack: c000000029fdbec0: c0000000 29fdbf40 c1fe4e41 673d4723 ....)..@..NAg=G#
stack: c000000029fdbed0: 5a5a5a5a 5a5a5a5a cccccccc cccccccc ZZZZZZZZ........
stack: c000000029fdbee0: c0000000 29fdbf60 cccccccc cccccccc ....)..`........
stack: c000000029fdbef0: c0000000 29fdbf70 5a5a5a5a 5a5a5a5a ....)..pZZZZZZZZ
stack: c000000029fdbf00: cccccccc cccccccc 00000ddc 60000010 ............`...
stack: c000000029fdbf10: c0000000 29fdbf90 00000000 00000002 ....)...........
stack: c000000029fdbf20: c0000000 29fdbf01 001d3029 96167689 ....).....0)..v.
stack: c000000029fdbf30: c0000000 29fdbfc0 c0000004 7f6f1800 ....)........o.. <---
stack: c000000029fdbf40: c0000000 29fdbfc0 5a5a5a5a 5a5a5a5a ....)...ZZZZZZZZ
stack: c000000029fdbf50: c0000000 000ea33c 00000000 00000000 .......<........
stack: c000000029fdbf60: c0000000 29fdbfe0 c0000000 05cdb700 ....)...........
stack: c000000029fdbf70: c0000000 29fdbff0 cccccccc cccccccc ....)...........
stack: c000000029fdbf80: c0000000 000ea33c 00000000 00328780 .......<.....2..
stack: c000000029fdbf90: c0000000 29fdc010 001d3029 96167689 ....).....0)..v.
stack: c000000029fdbfa0: c0000000 29fdc020 00000000 000008e4 ....).. ........
stack: c000000029fdbfb0: 00000000 00000201 001d3029 96167689 ..........0)..v.
stack: c000000029fdbfc0: c0000000 29fdc040 cccccccc cccccccc ....)..@........ <---
stack: c000000029fdbfd0: c0000000 000c2344 001d3029 96167689 ......#D..0)..v.
stack: c000000029fdbfe0: c0000000 29fdc001 001d3029 96167689 ....).....0)..v.
stack: c000000029fdbff0: c0000000 29fdc080 00000088 554c539a ....).......ULS.
... which is here:
stack: c000000029fdc000: c0000000 000c1d9c 001d3029 96167689 ..........0)..v.
stack: c000000029fdc010: c0000000 29fdc0d0 c0000004 7f6f1700 ....)........o..
stack: c000000029fdc020: c0000000 29fdc0a0 c0000000 05cdb580 ....)...........
stack: c000000029fdc030: c0000000 29fdc0b0 c0000004 7f6f1700 ....)........o..
stack: c000000029fdc040: c0000000 29fdc0c0 00000000 00000001 ....)...........
So it looks like you have actually overran your stack, rather than
something else clobbering your stack.
Can you attach your System.map for that exact kernel? We might be able
to work out what functions we were in when we overran.
You could also try changing CONFIG_THREAD_SHIFT to 15, that might keep
the system running a bit longer and give us some other clues.
cheers
Can you try this patch, it might help us work out what is corrupting the
stack.
With your patch applied to recent v5.15-rc2 the output looks like this:
[...]
stack corrupted? stack end = 0xc000000029fdc000
stack: c000000029fdbc00: 5a5a5a5a 5a5a5a5a cccccccc cccccccc
ZZZZZZZZ........
...
Can't make much sense out of it but hopefully you can. ;)
Thanks. Obvious isn't it? ;)
stack corrupted? stack end = 0xc000000029fdc000
stack: c000000029fdbc00: 5a5a5a5a 5a5a5a5a cccccccc cccccccc
ZZZZZZZZ........
stack: c000000029fdbc10: 00000ddc 7c000010 cccccccc cccccccc
....|...........
stack: c000000029fdbc20: 29fc4e41 673d4bb3 5a5a5a5a 5a5a5a5a
).NAg=K.ZZZZZZZZ
stack: c000000029fdbc30: cccccccc cccccccc 00000ddc 8e000010
................
stack: c000000029fdbc40: cccccccc cccccccc 41fc4e41 673d41a3
........A.NAg=A.
stack: c000000029fdbc50: 5a5a5a5a 5a5a5a5a cccccccc cccccccc
ZZZZZZZZ........
stack: c000000029fdbc60: 00000ddc 8e00000c cccccccc cccccccc
................
stack: c000000029fdbc70: 79fc4e41 673d4dab 5a5a5a5a 5a5a5a5a
y.NAg=M.ZZZZZZZZ
stack: c000000029fdbc80: cccccccc cccccccc 00000ddc 90000008
................
stack: c000000029fdbc90: cccccccc cccccccc 91fc4e41 673d4573
..........NAg=Es
stack: c000000029fdbca0: 5a5a5a5a 5a5a5a5a cccccccc cccccccc
ZZZZZZZZ........
stack: c000000029fdbcb0: 00000dd7 ac000016 cccccccc cccccccc
................
stack: c000000029fdbcc0: c9fc4e41 673d4203 5a5a5a5a 5a5a5a5a
..NAg=B.ZZZZZZZZ
stack: c000000029fdbcd0: cccccccc cccccccc 00000ddc 6c000004
............l...
stack: c000000029fdbce0: cccccccc cccccccc e1fc4e41 673d474b
..........NAg=GK
stack: c000000029fdbcf0: 5a5a5a5a 5a5a5a5a cccccccc cccccccc
ZZZZZZZZ........
stack: c000000029fdbd00: 00000ddc 88000000 cccccccc cccccccc
................
stack: c000000029fdbd10: 19fd4e41 673d4143 5a5a5a5a 5a5a5a5a
..NAg=ACZZZZZZZZ
stack: c000000029fdbd20: cccccccc cccccccc 00000ddb 6c00000e
............l...
stack: c000000029fdbd30: cccccccc cccccccc 31fd4e41 673d4f43
........1.NAg=OC
stack: c000000029fdbd40: 5a5a5a5a 5a5a5a5a cccccccc cccccccc
ZZZZZZZZ........
stack: c000000029fdbd50: 00000ddc 8e000008 cccccccc cccccccc
................
stack: c000000029fdbd60: 69fd4e41 673d407b 5a5a5a5a 5a5a5a5a
i.NAg=@{ZZZZZZZZ
stack: c000000029fdbd70: cccccccc cccccccc 00000ddc 92000008
................
stack: c000000029fdbd80: cccccccc cccccccc 81fd4e41 673d4633
..........NAg=F3
stack: c000000029fdbd90: 5a5a5a5a 5a5a5a5a cccccccc cccccccc
ZZZZZZZZ........
stack: c000000029fdbda0: 00000ddb 42000018 cccccccc cccccccc
....B...........
stack: c000000029fdbdb0: b9fd4e41 673d42fb 5a5a5a5a 5a5a5a5a
..NAg=B.ZZZZZZZZ
stack: c000000029fdbdc0: cccccccc cccccccc 00000ddc 7e000018
............~...
stack: c000000029fdbdd0: cccccccc cccccccc d1fd4e41 673d4a1b
..........NAg=J.
stack: c000000029fdbde0: 5a5a5a5a 5a5a5a5a cccccccc cccccccc
ZZZZZZZZ........
stack: c000000029fdbdf0: 00000ddc 8e000004 cccccccc cccccccc
................
stack: c000000029fdbe00: 09fe4e41 673d4ee3 5a5a5a5a 5a5a5a5a
..NAg=N.ZZZZZZZZ
stack: c000000029fdbe10: cccccccc cccccccc 00000dd9 7200001c
............r...
stack: c000000029fdbe20: cccccccc cccccccc 21fe4e41 673d4fa3
........!.NAg=O.
That's slab data.
It's not clear what the actual data is, but because you booted with
slub_debug=FZP we can see the red zones and poison.
The cccccccc is SLUB_RED_ACTIVE, and 5a5a5a5a is POISON_INUSE (see poison.h)
stack: c000000029fdbe30: c0000000 29fdbeb0 cccccccc cccccccc
....)...........
But then here we have an obvious pointer (big endian FTW).
And it points nearby, just slightly higher in memory, so that looks
suspiciously like a stack back chain pointer. There's more similar
values if you look further.
But we shouldn't be seeing the stack yet, it's meant to start (end) at
c000000029fdc000 ...
stack: c000000029fdbe40: 00000ddc 94000000 cccccccc cccccccc
................
stack: c000000029fdbe50: 59fe4e41 673d4933 5a5a5a5a 5a5a5a5a
Y.NAg=I3ZZZZZZZZ
stack: c000000029fdbe60: cccccccc cccccccc 00000dd9 60000024
............`..$
stack: c000000029fdbe70: cccccccc cccccccc 71fe4e41 673d416b
........q.NAg=Ak
stack: c000000029fdbe80: 5a5a5a5a 5a5a5a5a cccccccc cccccccc
ZZZZZZZZ........
stack: c000000029fdbe90: 00000ddc 6000000c cccccccc cccccccc
....`...........
stack: c000000029fdbea0: c0000000 29fdbf20 00000000 00000002 ....)..
........
stack: c000000029fdbeb0: c0000000 29fdbf30 00000ddc 7e00001c ....)..0....~...
<---
stack: c000000029fdbec0: c0000000 29fdbf40 c1fe4e41 673d4723
....)..@..NAg=G#
stack: c000000029fdbed0: 5a5a5a5a 5a5a5a5a cccccccc cccccccc
ZZZZZZZZ........
stack: c000000029fdbee0: c0000000 29fdbf60 cccccccc cccccccc
....)..`........
stack: c000000029fdbef0: c0000000 29fdbf70 5a5a5a5a 5a5a5a5a
....)..pZZZZZZZZ
stack: c000000029fdbf00: cccccccc cccccccc 00000ddc 60000010
............`...
stack: c000000029fdbf10: c0000000 29fdbf90 00000000 00000002
....)...........
stack: c000000029fdbf20: c0000000 29fdbf01 001d3029 96167689
....).....0)..v.
stack: c000000029fdbf30: c0000000 29fdbfc0 c0000004 7f6f1800 ....)........o..
<---
stack: c000000029fdbf40: c0000000 29fdbfc0 5a5a5a5a 5a5a5a5a
....)...ZZZZZZZZ
stack: c000000029fdbf50: c0000000 000ea33c 00000000 00000000
.......<........
stack: c000000029fdbf60: c0000000 29fdbfe0 c0000000 05cdb700
....)...........
stack: c000000029fdbf70: c0000000 29fdbff0 cccccccc cccccccc
....)...........
stack: c000000029fdbf80: c0000000 000ea33c 00000000 00328780
.......<.....2..
stack: c000000029fdbf90: c0000000 29fdc010 001d3029 96167689
....).....0)..v.
stack: c000000029fdbfa0: c0000000 29fdc020 00000000 000008e4 ....)..
........
stack: c000000029fdbfb0: 00000000 00000201 001d3029 96167689
..........0)..v.
stack: c000000029fdbfc0: c0000000 29fdc040 cccccccc cccccccc ....)..@........
<---
stack: c000000029fdbfd0: c0000000 000c2344 001d3029 96167689
......#D..0)..v.
stack: c000000029fdbfe0: c0000000 29fdc001 001d3029 96167689
....).....0)..v.
stack: c000000029fdbff0: c0000000 29fdc080 00000088 554c539a
....).......ULS.
... which is here:
stack: c000000029fdc000: c0000000 000c1d9c 001d3029 96167689
..........0)..v.
stack: c000000029fdc010: c0000000 29fdc0d0 c0000004 7f6f1700
....)........o..
stack: c000000029fdc020: c0000000 29fdc0a0 c0000000 05cdb580
....)...........
stack: c000000029fdc030: c0000000 29fdc0b0 c0000004 7f6f1700
....)........o..
stack: c000000029fdc040: c0000000 29fdc0c0 00000000 00000001
....)...........
So it looks like you have actually overran your stack, rather than
something else clobbering your stack.
Can you attach your System.map for that exact kernel? We might be able
to work out what functions we were in when we overran.
You could also try changing CONFIG_THREAD_SHIFT to 15, that might keep
the system running a bit longer and give us some other clues.
cheers
--
You may reply to this email to add a comment.
You are receiving this mail because:
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.
So it looks like you have actually overran your stack, rather than
something else clobbering your stack.
Can you attach your System.map for that exact kernel? We might be able
to work out what functions we were in when we overran.
You could also try changing CONFIG_THREAD_SHIFT to 15, that might keep
the system running a bit longer and give us some other clues.
cheers
Hm, interesting...
What I do to trigger this bug is building llvm-12 on the G5 via distcc (on the
other side is a 16-core Opteron) and MAKEOPTS="-j10 -l3". As the G5 got 16 GiB
RAM building runs in a zstd-compressed ext2 filesystem (/sbin/zram-init -d1 -s2
-azstd -text2 -orelatime -m1777 -Lvar_tmp_dir 49152 /var/tmp). Most of the time
the bug is triggered very shortly after the actual building starts via meson.
At this time the build directory /var/tmp/portage occupies about 800 MiB.
Also sometimes I don't get a proper stack trace via netconsole but this:
BUG: unable to handle kernel data access on write at 0xc000000037c82040
BUG: unable to handle kernel data access on write at 0xc000000037c80000
Please find the relevant System.map attached. I'll do another kernel build with
CONFIG_THREAD_SHIFT=15 and see if anything changes.
Thanks for investigating this!
--
You may reply to this email to add a comment.
You are receiving this mail because:
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.
You could also try changing CONFIG_THREAD_SHIFT to 15, that might keep
the system running a bit longer and give us some other clues.
The stack seems just large enough with CONFIG_THREAD_SHIFT=15 to not run into
this bug. I let the G5 build stuff via distcc in zram disk for a day without an
issue. With CONFIG_THREAD_SHIFT=14 I hit the bug within minutes.
Just for completeness I'll upload the System.map and kernel .config with
CONFIG_THREAD_SHIFT=15.
--
You may reply to this email to add a comment.
You are receiving this mail because:
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.
--- Comment #11 from Erhard F. (erhard_f@mailbox.org) ---
Created attachment 298961
--> https://bugzilla.kernel.org/attachment.cgi?id=298961&action=edit
System.map (5.15-rc2 + patch + CONFIG_THREAD_SHIFT=15, PowerMac G5 11,2)
--
You may reply to this email to add a comment.
You are receiving this mail because:
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.
Rebooting in 40 seconds..
--
You may reply to this email to add a comment.
You are receiving this mail because:
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.
--- Comment #13 from Erhard F. (erhard_f@mailbox.org) ---
Created attachment 299755
--> https://bugzilla.kernel.org/attachment.cgi?id=299755&action=edit
dmesg (5.16-rc2 + patch, PowerMac G5 11,2)
Still happens with with 5.16-rc2, but getting a slightly different error
message this time. Also this crash happened earlier, not at building distcc but
at unpacking the to be built tar.gz archive with tar + pigz:
[...]
stack: c000000005b0e600: 00000000 00000003 c0000000 00105b2c ..............[,
stack: c000000005b0e610: c0000000 05b0e6a0 0031faa1 bd74990f .........1...t..
stack: c000000005b0e620: c0000000 00104f50 00000000 00000006 ......OP........
stack: c000000005b0e630: c0000000 05b0e6a0 0031faa1 bd74990f .........1...t..
kernel tried to execute exec-protected page (c000000005b0bbe0) - exploit
attemp? (uid: 0)
stack: c000000005b0e640: c0000000 00000001 c0000000 022f2a08 ............./*.
The last 2 lines were not in the netconsole.log but only were to be seen on the
screen of the frozen G5 so I added them manually.
--
You may reply to this email to add a comment.
You are receiving this mail because:
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.
--- Comment #14 from Erhard F. (erhard_f@mailbox.org) ---
Created attachment 300297
--> https://bugzilla.kernel.org/attachment.cgi?id=300297&action=edit
bisect.log
Finally did a bisect which revealed the following commit:
# git bisect good
c2c11289021dfacec1658b2019faab10e12f383a is the first bad commit
commit c2c11289021dfacec1658b2019faab10e12f383a
Merge: 63bef48fd6c9 ef516e8625dd
Author: David S. Miller [off-list ref]
Date: Tue Apr 7 18:08:06 2020 -0700
Merge git://git.kernel.org/pub/scm/linux/kernel/git/pablo/nf
Pablo Neira Ayuso says:
====================
Netfilter fixes for net
The following patchset contains Netfilter fixes for net, they are:
1) Fix spurious overlap condition in the rbtree tree, from Stefano Brivio.
2) Fix possible uninitialized pointer dereference in nft_lookup.
3) IDLETIMER v1 target matches the Android layout, from
Maciej Zenczykowski.
4) Dangling pointer in nf_tables_set_alloc_name, from Eric Dumazet.
5) Fix RCU warning splat in ipset find_set_type(), from Amol Grover.
6) Report EOPNOTSUPP on unsupported set flags and object types in sets.
7) Add NFT_SET_CONCAT flag to provide consistent error reporting
when users defines set with ranges in concatenations in old kernels.
====================
Signed-off-by: David S. Miller [off-list ref]
include/net/netfilter/nf_tables.h | 2 +-
include/uapi/linux/netfilter/nf_tables.h | 2 ++
include/uapi/linux/netfilter/xt_IDLETIMER.h | 1 +
net/netfilter/ipset/ip_set_core.c | 3 ++-
net/netfilter/nf_tables_api.c | 7 ++++---
net/netfilter/nft_lookup.c | 12 +++++++-----
net/netfilter/nft_set_bitmap.c | 1 -
net/netfilter/nft_set_rbtree.c | 23 +++++++++++------------
net/netfilter/xt_IDLETIMER.c | 3 +++
9 files changed, 31 insertions(+), 23 deletions(-)
--
You may reply to this email to add a comment.
You are receiving this mail because:
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.
https://bugzilla.kernel.org/show_bug.cgi?id=213837
Erhard F. (erhard_f@mailbox.org) changed:
What |Removed |Added
----------------------------------------------------------------------------
Summary|"Kernel panic - not |[bisected] "Kernel panic -
|syncing: corrupted stack |not syncing: corrupted
|end detected inside |stack end detected inside
|scheduler" at building via |scheduler" at building via
|distcc on a G5 |distcc on a G5
--- Comment #15 from Erhard F. (erhard_f@mailbox.org) ---
This may look a bit odd at first to cause memory corruption while building
stuff, but as I do the builds via distcc on another host (sources are fetched
via nfs from this host too) it seems possible.
Problem is the 'bad' commit is a merge and reverting it on v5.16.2 for a test
via git revert -m1 c2c11289021dfacec1658b2019faab10e12f383a gets me some merge
conflicts which I don't know to resolve properly..
--
You may reply to this email to add a comment.
You are receiving this mail because:
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.
https://bugzilla.kernel.org/show_bug.cgi?id=213837
Erhard F. (erhard_f@mailbox.org) changed:
What |Removed |Added
----------------------------------------------------------------------------
Attachment #298019|0 |1
is obsolete| |
Attachment #298671|0 |1
is obsolete| |
Attachment #298959|0 |1
is obsolete| |
--- Comment #16 from Erhard F. (erhard_f@mailbox.org) ---
Created attachment 300486
--> https://bugzilla.kernel.org/attachment.cgi?id=300486&action=edit
kernel .config (5.17-rc4, PowerMac G5 11,2)
--
You may reply to this email to add a comment.
You are receiving this mail because:
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.
https://bugzilla.kernel.org/show_bug.cgi?id=213837
Erhard F. (erhard_f@mailbox.org) changed:
What |Removed |Added
----------------------------------------------------------------------------
Attachment #298393|0 |1
is obsolete| |
Attachment #299755|0 |1
is obsolete| |
--- Comment #17 from Erhard F. (erhard_f@mailbox.org) ---
Created attachment 300487
--> https://bugzilla.kernel.org/attachment.cgi?id=300487&action=edit
dmesg (5.17-rc4 + patch, PowerMac G5 11,2)
Still an issue on 5.17-rc4.
Stacktrace looks a bit more interesting this time.
--
You may reply to this email to add a comment.
You are receiving this mail because:
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.
https://bugzilla.kernel.org/show_bug.cgi?id=213837
Erhard F. (erhard_f@mailbox.org) changed:
What |Removed |Added
----------------------------------------------------------------------------
Attachment #298933|0 |1
is obsolete| |
Attachment #298961|0 |1
is obsolete| |
--- Comment #18 from Erhard F. (erhard_f@mailbox.org) ---
Created attachment 300561
--> https://bugzilla.kernel.org/attachment.cgi?id=300561&action=edit
System.map (5.17-rc7 + patch, PowerMac G5 11,2)
--
You may reply to this email to add a comment.
You are receiving this mail because:
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.
--- Comment #19 from Erhard F. (erhard_f@mailbox.org) ---
Created attachment 300562
--> https://bugzilla.kernel.org/attachment.cgi?id=300562&action=edit
kernel .config (5.17-rc7, PowerMac G5 11,2)
--
You may reply to this email to add a comment.
You are receiving this mail because:
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.
https://bugzilla.kernel.org/show_bug.cgi?id=213837
Erhard F. (erhard_f@mailbox.org) changed:
What |Removed |Added
----------------------------------------------------------------------------
Attachment #298919|0 |1
is obsolete| |
Attachment #298963|0 |1
is obsolete| |
--- Comment #20 from Erhard F. (erhard_f@mailbox.org) ---
Created attachment 300563
--> https://bugzilla.kernel.org/attachment.cgi?id=300563&action=edit
dmesg (5.17-rc7 + patch, PowerMac G5 11,2)
--
You may reply to this email to add a comment.
You are receiving this mail because:
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.
--- Comment #21 from Erhard F. (erhard_f@mailbox.org) ---
(Luckily) I am no longer able to reproduce this. Re-tested on 5.19-rc5.
I'll keep an eye on it and will close here if it stays like that for the next
few stable kernels.
--
You may reply to this email to add a comment.
You are receiving this mail because:
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.