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(). So it was one of your keyboards or mouses. At least one is the keyboard associated with your usb sound card, it represents control buttons like volume control. You said panic was occurred after your interactions with sound card, so I suspect uhidev1 or ucc0 does something wrong around kevent subsystem. > I tried unplugging the keyboard from this KVM switch and turned on the sound- > card as you had requested. It did not panic again. Was it just memory > corruption in the computer you think? One thing to note is that I have the > basic pf rules set on with a bit of other anchors. > > uhub4 at uhub3 port 2 configuration 1 interface 0 "Genesys Logic USB2.0 Hub" rev 2.00/77.63 addr 4 uaudio0 at uhub4 port 4 configuration 1 interface 1 "C-Media Electronics Inc. USB PnP Sound Device" rev 1.10/1.00 addr 5 uhidev1 at uhub4 port 4 configuration 1 interface 3 "C-Media Electronics Inc. USB PnP Sound Device" rev 1.10/1.00 addr 5 uhidev1: iclass 3/0 ucc0 at uhidev1: 10 usages, 3 keys, enum wskbd1 at ucc0 mux 1 uhub6 at uhub4 port 2 configuration 1 interface 0 "ROCLA KVM PORT SWITCH" rev 1.10/1.00 addr 6 According this one, your sound card is not attached to the kvm switch, but keyboards are. Since you said they are attached/detached multiple times during boot process, the memory corruption could be in one of ukbd instances. To me it seems the reason is the missing klist_invalidate() call in the ukbd detach sequence. Is it easy to reproduce this panic?
