Re: [EXTERNAL] Re: enabling same PPI interrupt to all CPU in ARM64 SMP

On Mon, May 15, 2023 at 12:27 PM Souradeep Chakrabarti
<schakrabarti@microsoft.com> wrote:
>
>
>
>
> >-----Original Message-----
> >From: owner-freebsd-hackers@freebsd.org <owner-freebsd-hackers@freebsd.org>
> >On Behalf Of Souradeep Chakrabarti
> >Sent: Monday, May 15, 2023 10:37 PM
> >To: Kyle Evans <kevans@freebsd.org>
> >Cc: Wei Hu <weh@microsoft.com>; freebsd-hackers@FreeBSD.org
> >Subject: RE: [EXTERNAL] Re: enabling same PPI interrupt to all CPU in ARM64 SMP
> >
> >
> >
> >
> >>-----Original Message-----
> >>From: Kyle Evans <kevans@freebsd.org>
> >>Sent: Monday, May 15, 2023 7:24 PM
> >>To: Souradeep Chakrabarti <schakrabarti@microsoft.com>
> >>Cc: Wei Hu <weh@microsoft.com>; freebsd-hackers@FreeBSD.org
> >>Subject: Re: [EXTERNAL] Re: enabling same PPI interrupt to all CPU in
> >>ARM64 SMP
> >>
> >[Souradeep] It has worked! Thanks a lot. We should get it committed in src.
> >Before I commit the SMP related changes for Hyper-V driver.
> >>Thanks,
>

Awesome- I posted the PPI patch for review here:
https://reviews.freebsd.org/D40112 -- I'm travelling to Ottawa for
most of today and tomorrow, but we'll see if we can get this taken
care of this week.

> [Souradeep] But after install it is keep getting rebooted after hitting a panic
>
>
> mbus0: vmbus_handle_intr1 for cpu 0
> vmbus0: the irq 18
> vmbus0: smp_started = 0
> KDvmbus0: vmbus_handle_intr1 for cpu 0
> B: stack backtrace:
> db_trace_self() at db_trace_self
> db_trace_self_wrapper() at db_trace_self_wrapper+0x30
> mi_switch() at mi_switch+0x27c
> sleepq_switch() at sleepq_switch+0xfc
> _sleep() at _sleep+0x294
> vmbus_xact_wait1() at vmbus_xact_wait1+0x120
> vmbus_sysinit() at vmbus_sysinit+0x6a4
> mi_startup() at mi_startup+0x1fc
> virtdone() at virtdone+0x70
> KDB: reentering
> KDB: stack backtrace:
> db_trace_self() at db_trace_self
> db_trace_self_wrapper() at db_trace_self_wrapper+0x30
> kdb_reenter() at kdb_reenter+0x44
> mi_switch() at mi_switch+0x280
> sleepq_switch() at sleepq_switch+0xfc
> _sleep() at _sleep+0x294
> vmbus_xact_wait1() at vmbus_xact_wait1+0x120
> vmbus_sysinit() at vmbus_sysinit+0x6a4
> mi_startup() at mi_startup+0x1fc
> virtdone() at virtdone+0x70
>
> Looks like vmbus_sysinit() is getting called even before SMP has started after installation.
> Wondering what could be the reason.
> Also any idea how to disable this reboot cycle post post panic, so that I can get the backtrace properly.

Odd- I thought we had pushed that back to SI_SUB_SMP late or
SI_SUB_SMP + 1. The backtrace here looks reasonably complete-
mi_startup() does invoke sysinits directly. Can you post your full
diff against sys/dev/hyperv somewhere, please?

Thanks,

Kyle Evans