On Thu, Jan 21, 2021 at 12:47:25AM +0000, James Cook wrote: > >Synopsis: iwx0 repeatedly goes offline with "unhandled firmware response > >0x3fd" > >Category: kernel > >Environment: > System : OpenBSD 6.8 > Details : OpenBSD 6.8-current (GENERIC.MP) #284: Wed Jan 20 > 02:40:03 MST 2021 > > dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP > > Architecture: OpenBSD.amd64 > Machine : amd64 > >Description: > My wireless connection keeps dropping and then coming back up several > seconds or a few minutes later. Here is a typical example from > /var/log/messages: > > Jan 21 00:34:27 moth /bsd: iwx0: dumping device error log > Jan 21 00:34:27 moth /bsd: iwx0: Start Error Log Dump: > Jan 21 00:34:27 moth /bsd: iwx0: Status: 0x39, count: 6 > Jan 21 00:34:27 moth /bsd: iwx0: 0x00004424 | ADVANCED_SYSASSERT >
> Jan 21 00:34:27 moth /bsd: iwx0: fatal firmware error This first firmware error is most likely a symptom of a driver bug. To figure out what's causing this it would help to see exactly which frames were exchanged with the AP at the time (00:34:27). The best way to observe this is to capture raw frames from another machine listening in monitor mode on the same channel (iwn/iwm/iwx would do). Alternatively, you could capture frames on the iwx(4) client itself, but in this case some information could be missing because the firmware will not expose all received frames to the driver. In either case, the command to capture raw wifi frames is: tcpdump -n -i iwx0 -s 4096 -y IEEE802_11_RADIO -w /tmp/iwx.pcap Replace iwx0 with the correct interface if you're using monitor mode. wireshark from ports is the most useful tool for viewing the resulting pcap file. > Jan 21 00:36:13 moth /bsd: iwx0: unhandled firmware response > 0x3fd/0x2000000c rx ring 64[71] This is an interesting one. I've never seen it happen. 0x3fd doesn't map to any known firmware response code so perhaps this value is garbage memory. Is this value always the same?
