> From: Mike Belopuhov <[email protected]> > Date: Thu, 30 Jul 2020 09:21:32 +0200 > > On 29/07/2020 15:23, Mark Kettenis wrote: > >> Date: Wed, 29 Jul 2020 23:01:15 +1000 > >> From: Jonathan Gray <[email protected]> > >> > >> On Wed, Jul 29, 2020 at 02:05:18PM +0200, Andre Stoebe wrote: > >>>> Synopsis: Panic on boot with Hyper-V since Jun 17 snapshot > >>>> Category: kernel > >>>> Environment: > >>> System : OpenBSD 6.7 > >>> Details : OpenBSD 6.7-current (GENERIC.MP) #375: Sun Jul 26 > >>> 11:26:37 MDT 2020 > >>> > >>> [email protected]:/usr/src/sys/arch/amd64/compile/GENERIC.MP > >>> > >>> Architecture: OpenBSD.amd64 > >>> Machine : amd64 > >>>> Description: > >>> Booting -current on Hyper-V with hvn(4) results in a panic after > >>> "starting network". > >>> > >>> This seems to only affect the multi-user boot; hvn(4) still > >>> works flawlessly on the ramdisk. > >>> > >>> Last working snapshot: > >>> OpenBSD 6.7-current (GENERIC.MP) #273: Mon Jun 15 19:13:12 MDT 2020 > >>> > >>> First non-working snapshot: > >>> OpenBSD 6.7-current (GENERIC.MP) #278: Wed Jun 17 12:18:35 MDT 2020 > >>> > >>> Below is the serial output including ddb trace and ps. > >>>> How-To-Repeat: > >>> Boot OpenBSD-current on Hyper-V with a hvn(4) network adapter. > >>>> Fix: > >>> Unknown. As a workaround, disabling hvn(4) via "boot -c" does > >>> not result in a panic. > >> > >> more fallout of intr_barrier() now using the argument > > > > The change doesn't make an awful lot of sense though. Just like the > > current code doesn't make any sense since the driver doesn't do > > interrupts. It is unclear to me what the call is trying to achive. > > My guess would be that if anything needs to be done here it is > > flushing any pending work associated with the channel. Which would > > imply a taskq_barrier() on the task associated with the channel. > > > > > > Hi Mark, > > hvn is interrupt driven; hvn_nvs_intr is the interrupt handler. > It lacks a conventional PCI interrupt establish dance because of > Hyper-V specifics: interrupts and device communication happens > over channels, not conventional buses.
Ah, now I remember. The interrupts bypass the normal interrupt establish logic. These interrupts always run on cpu0? > I cannot attest to Jonathan's diff, but if that worked for xnf, > I don't see a reason why it wouldn't work here. Slightly better there though since the operation is abstracted into xen_intr_barrier(). Something similar should be done for hyperv. Maybe for now it is good enough to add a hv_channel_intr_barier() function that takes the channel as an argument and simply calls sched_barrier(NULL)?
