On Fri, Jun 16, 2023 at 04:06:58PM +0300, Vitaliy Makkoveev wrote:
> On Fri, Jun 16, 2023 at 02:16:29PM +0200, Peter J. Philipp wrote:
> > On Fri, Jun 16, 2023 at 02:30:27PM +0300, Vitaliy Makkoveev wrote:
> > > On Fri, Jun 16, 2023 at 10:53:33AM +0200, Peter J. Philipp wrote:
> > > > On Fri, Jun 16, 2023 at 10:40:30AM +0200, Peter J. Philipp wrote:
> > > > > Sorry for no formatting and the bad quality photo, the kernel paniced
> > > > > on me
> > > > > on process Xorg, when I turned on the sound card. I use fluxbox
> > > > > windows
> > > > > manager if it's worth any. Odd is that it paniced on poll(). I had
> > > > > turned
> > > > >
> > > > > pjp@polarstern$ sysctl -a|grep aperture
> > > > > machdep.allowaperture=1
> > > > >
> > > > > aperture to 1 a while back, dunno if this could be the cause?
> > > >
> > > > It was paniced in the wscons keyboard driver attached to control
> > > > buttons > of the sound card. Could you detach all you usb keyboards,
> > > > connect sound > card and turn it on?
> >
> > Let me explain my console setup. I have a usb keyboard attached to a "4x1 \
> > USB HDMI KVM Switch" purchased at conrad.de. When I press shift-lock three
> > times and the number of the kvm port (1 to 4) I switch into another physical
> > computer. This could be windows or another OpenBSD computer. I don't know
> > if it's relevant because I did not switch KVM consoles at the moment of
> > panic. However, and many can probably attest to this too, when in console
> > without X (so installer, or just not booting into xenodm) the keyboard and
> > mouse detach frequently from the computer and one has to wait a while for it
> > to come back. This is often seen on KVM's (I noticed this at hetzner
> > online,
> > possibly at iweb.com too). I may have tried to investigate this once but
> > that
> > was a long time ago and I gave up after not finding anything further.
> >
> > It seems to me when the X11 drivers are attached that there is no such mis-
> > event happening, but then there was this panic so who knows what is really
> > happening.
> >
>
> According your photo, panic occurred in filt_wseventdetach().
The following tweak might help.
This code gets called indirectly through vdevgone() when a ws device
is detached. In principle, another thread could register a new event
with the device after the klist_invalidate() before the vnode clearing
takes effect in full. However, it looks that the callers
of wsevent_kqfilter() bail out if me_evp is NULL. The ws device close
routines clear this pointer before calling wsevent_fini().
Index: dev/wscons/wsevent.c
===================================================================
RCS file: src/sys/dev/wscons/wsevent.c,v
retrieving revision 1.26
diff -u -p -r1.26 wsevent.c
--- dev/wscons/wsevent.c 2 Jul 2022 08:50:42 -0000 1.26
+++ dev/wscons/wsevent.c 16 Jun 2023 13:53:52 -0000
@@ -134,6 +134,8 @@ wsevent_fini(struct wseventvar *ev)
free(ev->q, M_DEVBUF, WSEVENT_QSIZE * sizeof(struct wscons_event));
ev->q = NULL;
+ klist_invalidate(&ev->sel.si_note);
+
sigio_free(&ev->sigio);
}
