NetBSD-Bugs archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: port-amd64/58410: x86_patch() panic with core ultra processor
The following reply was made to PR port-amd64/58410; it has been noted by GNATS.
From: Martin Husemann <martin%duskware.de@localhost>
To: matthew green <mrg%eterna23.net@localhost>
Cc: gnats-bugs%netbsd.org@localhost
Subject: Re: port-amd64/58410: x86_patch() panic with core ultra processor
Date: Tue, 6 Aug 2024 08:20:03 +0200
On Tue, Aug 06, 2024 at 11:49:17AM +1000, matthew green wrote:
> nicely found.
>
> so, the problem is that the boot cpu is not the first cpu, and
> we don't handle that right. good job, us :)
>
> hopefully this isn't too hard to figure out. i remember we had
> to do something for it on sparc long long ago, when you could
> ask the prom to switch cpu, and booting from that cpu would mean
> the boot cpu was not the first cpu.
We don't really expect the first cpu to be the bootstrap processor,
and the difference between that and other cpu's is mostly
- start with running main() instead of the trampoline code to wait for
MP startup
- allocate the cpu info early (and probably differently) than other CPUs
- (maybe, MD) make sure the boot CPUs is the last one running when halting
the machine
It happens on sparc64 a lot, I have several machines that boot on != cpu0
by default.
But even on x86 we seem to have code to deal (but maybe it has not been
tested that much). See for example
sys/arch/x86/x86/cpu.c:cpu_attach
/*
* Boot processor may not be attached first, but the below
* must be done to allow booting other processors.
*/
if (!again) {
/* Make sure DELAY() (likely i8254_delay()) is initialized. */
DELAY(1);
/*
* Basic init. Compute an approximate frequency for the TSC
* using the i8254. If there's a HPET we'll redo it later.
*/
atomic_or_32(&ci->ci_flags, CPUF_PRESENT | CPUF_PRIMARY);
Martin
Home |
Main Index |
Thread Index |
Old Index