On Mon, Feb 03, 2020 at 12:30:18AM +0100, Adam Wolk wrote: > On Sun, Feb 02, 2020 at 04:06:38PM -0500, Kenneth Westerback wrote: > > A kernel with XHCI_DEBUG may supply useful info. > > > > I'm currently running with the XHCI_DEBUG enabled in the kernel. > Attaching a dmesg and will report back if I manage to reproduce > the issue on it. > > Look for: > > OpenBSD 6.6-current (XHCI_DEBUG) #0: Sun Feb 2 23:55:04 CET 2020 > [email protected]:/sys/arch/amd64/compile/XHCI_DEBUG > > in the trace below. > > Between the first two panics I had roughly 1h of usage. You can > see that on the clock from ddb photos. I don't have a reliable > way to reproduce however I wasn't able to trigger it with the xhci.c > commit 1.111 reverted - had several hours of uptime with solid load. > > With the XHCI_DEBUG enabled I tried forcing the issue by generating load > (large downloads, speedtests, running pkg_add and trying to load chrome > with HD videos). No luck so far. > > > Testing the device on the EHCI port I see in your dmesg would also be > > useful to confirm the problem is likely in xhci vs run. > > > > I will attempt that if I manage to reproduce the issue one more time on > the xhci port. > > > A quick test with an older run device plugged into my Lenovo e595 has not > > panic'ed yet. > > > > Are you connecting to an ' N' access point or 'G', or ... > > > > I am using the same setup on all reboots. > > Currently: IEEE802.11 autoselect (OFDM9 mode 11g) >
Just a note ... > xhci0: NULL xfer pointer > xhci0: NULL xfer pointer are 'normal' debug messages and not necessarily indicative of an error condition. .... Ken
