This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "GNU Mach".
The branch, master has been updated
via 2a77238c976605ab5aeec2457658c63430aba581 (commit)
via f336f04cae1829073aab081a930671844882df42 (commit)
via a07c8731d2c480748451bcae103b3ab9c87149a7 (commit)
via f49095748d4d8ab0dcb84763adc3b868a097e82e (commit)
via aa3e3958d11d87c80bc1f21c5c4bf9c48e0bf98e (commit)
via 77759d58b7784879c210db6820f5e50744caf796 (commit)
via 71a71e47c7d32e48ca3790fa93a5cc2b285b741d (commit)
via 8e7ddb9c4769f0a0677be64adf8d67a8d9398350 (commit)
via 837f77a53f04e79a7f67bb8acbe84a04c094ea15 (commit)
via 9c68124736edbfeb835e70f7b443ec7f324b9b6b (commit)
from 93f7dc461087d129af0111b0d0ce8dc5f4f1c400 (commit)
Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.
- Log -----------------------------------------------------------------
commit 2a77238c976605ab5aeec2457658c63430aba581
Author: David Bidner <[email protected]>
Date: Wed Oct 7 05:39:47 2026 +0200
ddb: keep ddb output variables db_expr_t-sized on 64-bit
The ddb variable table accesses db_max_line, db_max_width and
db_tab_stop_width through db_expr_t pointers, but their definitions
use int. On 64-bit kernels, assigning these variables overwrites
adjacent storage. In particular, setting $lines cleared the tab width
and caused division by zero during tab expansion.
Define all three variables as db_expr_t. For non-positive tab widths,
avoid division in NEXT_TAB() and emit pending whitespace as spaces so
db_force_whitespace() keeps advancing. This also changes invalid-width
handling on 32-bit kernels.
Tested in the serial-console debugger on i386 and amd64 with tab widths
0, -1, 4 and 8; output completed and variable values were preserved.
Message-ID: <[email protected]>
commit f336f04cae1829073aab081a930671844882df42
Author: David Bidner <[email protected]>
Date: Mon Oct 5 07:25:42 2026 +0200
kern/lock_mon: record real caller at lock entry points
MACH_LOCK_MON's locate_lock_info() guessed the caller of a lock with
li->caller = *((vm_offset_t *)lock - 1);
which reads an unrelated stack slot and is compiler/codegen dependent.
Under MACH_LOCK_MON the lock entry points are real functions when
NCPUS > 1, so the stored value is frequently not a code address and
`show all slocks` / `lip` print bare or bogus hex such as 0x315(...)
instead of a caller function name.
Capture the actual return address at the three lock entry points with
__builtin_return_address(0) and pass it to locate_lock_info(). Resolve
the stored address with db_printsym(..., DB_STGY_PROC) so the
LOCK/CALLER column prints name+offset, and always show the lock address
in parentheses. This only bites the MACH_LOCK_MON diagnostic path:
locking semantics, statistics and the millisecond timing are unchanged,
and MACH_LOCK_MON remains off by default.
Based on upstream commit 5e25bd3c ("Add timing info to MACH_LOCK_MON
lock monitoring").
Message-ID: <[email protected]>
commit a07c8731d2c480748451bcae103b3ab9c87149a7
Author: David Bidner <[email protected]>
Date: Wed Sep 23 19:55:49 2026 +0200
configfrag-first: Clarify --enable-ncpus help
Say that NCPUS is an upper bound and that more detected CPUs boot with
min(eligible, NCPUS).
Message-ID: <[email protected]>
commit f49095748d4d8ab0dcb84763adc3b868a097e82e
Author: David Bidner <[email protected]>
Date: Wed Sep 23 19:55:48 2026 +0200
model_dep: Panic on APIC initialization failure
Panic with the acpi_error_string() text instead of printing the error and
spinning forever.
Message-ID: <[email protected]>
commit aa3e3958d11d87c80bc1f21c5c4bf9c48e0bf98e
Author: David Bidner <[email protected]>
Date: Wed Sep 23 19:55:47 2026 +0200
cpuboot: Park processors not accepted into the CPU list
The BSP starts APs with a broadcast INIT/STARTUP IPI, so every exposed AP
runs this code, including the ones the kernel rejected. Rejected APIC
IDs are -1 in cpu_id_lut; test the lookup and park before using it to
index percpu_array or the per-CPU GDT.
Message-ID: <[email protected]>
commit 77759d58b7784879c210db6820f5e50744caf796
Author: David Bidner <[email protected]>
Date: Wed Sep 23 19:55:46 2026 +0200
acpi_parse_apic: Reserve the BSP and bound CPU admission
Reserve the running BSP as kernel ID 0 before the MADT walk, so it
survives firmware that lists it later. Ignore duplicate LAPIC entries
and CPUs beyond NCPUS.
This uses the apic_add_cpu() return value and the cpu_lapic_list bound.
Message-ID: <[email protected]>
commit 71a71e47c7d32e48ca3790fa93a5cc2b285b741d
Author: David Bidner <[email protected]>
Date: Wed Sep 23 19:55:45 2026 +0200
acpi_parse_apic: Stop on malformed MADT entries
Do not advance past the end of the MADT with a truncated entry, and stop
instead of looping forever when an entry has zero length.
Message-ID: <[email protected]>
commit 8e7ddb9c4769f0a0677be64adf8d67a8d9398350
Author: David Bidner <[email protected]>
Date: Wed Sep 23 19:55:44 2026 +0200
acpi_parse_apic: Ignore x2APIC and NMI MADT entries
Recognize MADT type 9 (x2APIC) and type 4 (Local APIC NMI) explicitly
instead of reporting them as unhandled. The x2APIC entry is ignored
because this xAPIC port cannot map its 32-bit IDs, and the NMI entry does
not describe a processor.
Message-ID: <[email protected]>
commit 837f77a53f04e79a7f67bb8acbe84a04c094ea15
Author: David Bidner <[email protected]>
Date: Wed Sep 23 19:55:43 2026 +0200
acpi_parse_apic: Name ACPI error codes
Add acpi_error_string() and use it in the APIC setup diagnostics, so the
startup path can report why ACPI/APIC setup failed instead of a bare
number.
Message-ID: <[email protected]>
commit 9c68124736edbfeb835e70f7b443ec7f324b9b6b
Author: David Bidner <[email protected]>
Date: Wed Sep 23 19:55:42 2026 +0200
apic: Bound cpu_lapic_list by NCPUS
apic_add_cpu() wrote cpu_lapic_list[ncpus] without checking the
allocation size. Keep the allocated size in capacity, return -1 when the
list is full, and bound apic_get_cpu_apic_id() and the refit copy/free by
it.
cpu_id_lut now starts at -1, so an APIC ID that was not accepted is no
longer mapped to the bootstrap processor.
Message-ID: <[email protected]>
-----------------------------------------------------------------------
Summary of changes:
configfrag-first.ac | 3 +-
ddb/db_output.c | 17 +++++++---
i386/i386/apic.c | 25 ++++++++++++---
i386/i386/apic.h | 3 +-
i386/i386/cpuboot.S | 12 +++++++
i386/i386at/acpi_parse_apic.c | 75 +++++++++++++++++++++++++++++++------------
i386/i386at/acpi_parse_apic.h | 4 ++-
i386/i386at/model_dep.c | 4 +--
kern/lock_mon.c | 23 ++++++-------
x86_64/cpuboot.S | 17 ++++++++++
10 files changed, 137 insertions(+), 46 deletions(-)
hooks/post-receive
--
GNU Mach
