Am 17.02.21 um 11:24 schrieb Stefan Sperling: > On Tue, Feb 16, 2021 at 09:50:23PM +0100, Stephen wrote: >>> Synopsis: panic in athn driver >>> Category: amd64 >>> Environment: >> System : OpenBSD 6.8 >> Details : OpenBSD 6.8 (GENERIC.MP) #98: Sun Oct 4 18:13:26 MDT 2020 >> >> [email protected]:/usr/src/sys/arch/amd64/compile/GENERIC.MP >> >> Architecture: OpenBSD.amd64 >> Machine : amd64 >>> Description: I have been getting these panics, which seem to occur >> randomly, for many months now. This is on a PC Engines APU2. >>> How-To-Repeat: I cannot discern a specific condition which causes this >> panic. My impression is that they occur when network load is high, but I >> haven't measured this. Sometimes the system will go many weeks without a >> panic, sometimes I will get two in a week. >> >> I have left out acpidump. The pcidump is from a running kernel, dmesg is >> from the debugger. I also have no 'show registers' output, and no kernel >> image, either, sorry about that. (This is the first time I've filed a >> problem report for OpenBSD. The next time it panics, and it will, I'll >> be better prepared.) >> > > This is a known issue but we don't know yet what is triggering it. > > Some problems with the same panic message and the same driver have already > been solved. It seems there are remaining bugs which lead to the same symptom > but it is unclear why. > > If there was a known way to trigger the crash on demand it would be much > easier to fix the issue. Can you find one?
I can certainly _try_ to find one :) I will assume the trigger is directly related to wireless ethernet, given that the panic occurs in ieee80211_encrypt, and would start experimenting there. For example, I might start with throughput tests via wireless or repeatedly disconnecting and reconnecting with a client device. Another perhaps related problem I have noticed is that sometimes, specific devices are no longer able to connect to the host network provided by this interface, even while other devices remain connected or can disconnect and reconnect. The only way to resolve this is to restart the interface, but even in that case, it will often stop working again after a short time and I will be forced to restart the OpenBSD device in order to be able to connect again. Do you know of any operations (perhaps for those problems already solved) that have triggered this panic in the past? That might give me more ideas. Best Stephen
OpenPGP_signature
Description: OpenPGP digital signature
