> From: S V <ner...@gmail.com>
> Date: Thu, 5 Oct 2023 12:58:51 +0300
>
> чт, 5 окт. 2023 г., 09:59 Mark Kettenis <mark.kette...@xs4all.nl>:
> >
> > > Date: Thu, 5 Oct 2023 04:10:10 +0000
> > > From: Klemens Nanni <k...@openbsd.org>
> > >
> > > On Mon, Sep 25, 2023 at 01:33:31PM +0000, Klemens Nanni wrote:
> > > > On Tue, Jul 25, 2023 at 01:30:43PM +0300, Slava Voronzoff wrote:
> > > > > Hi, pinging and refreshing this patch
> > > > >
> > > > > What it does:
> > > > > allow arm64 cpus to break from the loop of waiting to start core and
> > > > > drop to DDB or OS.
> > > > >
> > > > > Patch based on same concept in amd64 cpu.c
> > > > >
> > > > > Any suggestions? Good to go?
> > > >
> > > > So instead of waiting possibly forever for secondary CPUs to come up,
> > > > you can continue debug the system and/or continue boot with less CPUs.
> > > >
> > > > Apart from the trailing empty line you introduce, the approach does
> > > > match amd64 (down to the for loop lacking a space after semicolon).
> > > >
> > > > That allows making progress on these machines and I don't see a
> > > > downside,
> > > > so OK kn modulo the empty line.
> > > >
> > > > Any input from our arm64 hackers?
> > > >
> > > > Same diff ten days ago:
> > > > https://marc.info/?l=openbsd-bugs&m=169465443200821&w=2
> > >
> > > Anyone?
> >
> > Really, if those secondary CPUs don't come up, your system is beyond
> > repair. You need to do some low-level debugging at that point and DDB
> > isn't going to help you. So no, let's keep this code as simple as we
> > can.
> >
>
> This cores are starting and working properly,
> but something messes with order
> (maybe related to shared caches per 2 cores cluster, I'm not so
> hardware-good ).
> So 7th core will answer that it booted after 6th core.
> But with 'while' loop we never got to 6th core.
That suggests that the interrupt that we think we're sending to the
6th core is actually going to the 7th core and vice-versa. Feels like
a firmware bug to me. What hardware is this on?
> > > Index: sys/arch/arm64//arm64/cpu.c
> > > ===================================================================
> > > RCS file: /cvs/src/sys/arch/arm64/arm64/cpu.c,v
> > > retrieving revision 1.98
> > > diff -u -p -r1.98 cpu.c
> > > --- sys/arch/arm64//arm64/cpu.c 10 Aug 2023 19:29:32 -0000 1.98
> > > +++ sys/arch/arm64//arm64/cpu.c 25 Sep 2023 13:24:39 -0000
> > > @@ -1096,6 +1096,8 @@ cpu_start_secondary(struct cpu_info *ci,
> > > void
> > > cpu_boot_secondary(struct cpu_info *ci)
> > > {
> > > + int i;
> > > +
> > > atomic_setbits_int(&ci->ci_flags, CPUF_GO);
> > > __asm volatile("dsb sy; sev" ::: "memory");
> > >
> > > @@ -1105,8 +1107,16 @@ cpu_boot_secondary(struct cpu_info *ci)
> > > */
> > > arm_send_ipi(ci, ARM_IPI_NOP);
> > >
> > > - while ((ci->ci_flags & CPUF_RUNNING) == 0)
> > > + for (i = 1000; (!(ci->ci_flags & CPUF_RUNNING)) && i>0;i--) {
> > > __asm volatile("wfe");
> > > + }
> > > + if (! (ci->ci_flags & CPUF_RUNNING)) {
> > > + printf("cpu %d failed to start\n", ci->ci_cpuid);
> > > +#if defined(MPDEBUG) && defined(DDB)
> > > + printf("dropping into debugger; continue from here to
> > > resume boot\n");
> > > + db_enter();
> > > +#endif
> > > + }
> > > }
> > >
> > > void
> > >
> > >
>
