On Wed, Feb 17, 2021 at 01:26:05PM +0100, Stephen Bosch wrote:
> 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.
I have exactly the same issue. So far I didn't figure out how to track
down the problem of a device loosing connection and not able to
re-authenticate again to OpenBSD accesspoint based on athn(4).
I also had couple of times the `key unset for sw crypto` panic, but
in last few months actually it didn't happen. However I'm on:
OpenBSD 6.9-beta (GENERIC.MP) #338: Tue Feb 16 10:01:46 MST 2021
[email protected]:/usr/src/sys/arch/amd64/compile/GENERIC.MP
and upgrading that accesspoint at least once a month, more often once a
week.
> 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
>
--
Regards,
Mikolaj
