On Fri, Feb 23, 2018 at 12:16:54AM -0500, trondd wrote: > >Synopsis: Since if_iwm.c r1.224 iwm constantly reports fatal firmware > >error > >Category: kernel > >Environment: > System : OpenBSD 6.2 > Details : OpenBSD 6.2-current (GENERIC.MP) #1: Tue Jan 23 20:28:22 > EST 2018 > > [email protected]:/usr/src/sys/arch/amd64/compile/GENERIC.MP > > Architecture: OpenBSD.amd64 > Machine : amd64 > >Description: > Since trying to update on Feb 16, trying snapshots and building > current, I've been getting fatal firmware errors as soon as the iwm device > is brought up. Last good kernel I have is from Jan 23 as shown in the dmesg. > > Rolling back the only commit to if_iwm.c since Jan 23 to r1.223 seems to fix > the problem.
This doesn't make much sense because r1.224 only moved debug prints around. Commit r1.223 is a more likely candidate. > The debug shows the fatal firmware error occuring each time a background scan > is > initiated. Either something with the scan or one of the access points it hits > since the scan doesn't seem to complete based on the fewer number of APs > found. There are some oddities in the output you've shown: > debug output on broken kernel followed by debug output on working kernel: > iwm0: hw rev 0x210, fw ver 16.242414.0, address dc:53:60:4a:b1:ea > iwm0: begin active scan > iwm0: INIT -> SCAN > iwm0: end active scan > + 88:9f:fa:0b:83:46 3 +23 54M ess privacy rsn "decepticons" > iwm0: SCAN -> AUTH > iwm0: sending auth to 88:9f:fa:0b:83:46 on channel 3 mode 11g > iwm0: AUTH -> ASSOC > iwm0: sending assoc_req to 88:9f:fa:0b:83:46 on channel 3 mode 11g > iwm0: received msg 1/4 of the 4-way handshake from 88:9f:fa:0b:83:46 > iwm0: sending msg 2/4 of the 4-way handshake to 88:9f:fa:0b:83:46 I would expect messages 3/4 and 4/4 to be exchanged here. They must have been exchanged because otherwise you'd never reach RUN state. > iwm0: ASSOC -> RUN > iwm0: associated with 88:9f:fa:0b:83:46 ssid "decepticons" channel 3 start > MCS 0 short preamble long slot time HT enabled > iwm0: missed beacon threshold set to 7 beacons, beacon interval is 100 TU > iwm0: received msg 1/4 of the 4-way handshake from 88:9f:fa:0b:83:46 > iwm0: sending msg 2/4 of the 4-way handshake to 88:9f:fa:0b:83:46 > iwm0: received msg 1/4 of the 4-way handshake from 88:9f:fa:0b:83:46 > iwm0: sending msg 2/4 of the 4-way handshake to 88:9f:fa:0b:83:46 > iwm0: RUN -> AUTH This looks like the WPA handshake failed and the AP has de-authed you. I've seen a handful of reports which look similar. It seems that with on some APs we do not complete the handshake correctly anymore. I don't know when this was introduced exactly, but it's likely another race condition which has always been there and is more prominent since this commit: https://marc.info/?l=openbsd-cvs&m=151385818828652&w=2 I need more information about this problem before deciding what to do. > iwm0: ASSOC -> RUN > iwm0: associated with 88:9f:fa:0b:83:46 ssid "decepticons" channel 3 start > MCS 0 short preamble long slot time HT enabled > iwm0: missed beacon threshold set to 7 beacons, beacon interval is 100 TU > iwm0: received msg 3/4 of the 4-way handshake from 88:9f:fa:0b:83:46 > iwm0: sending msg 4/4 of the 4-way handshake to 88:9f:fa:0b:83:46 > iwm0: begin background scan > iwm0: fatal firmware error > iwm0: RUN -> INIT This looks like a problem in driver/firmware interaction. What is strange is that I've never seen this being reported before. We need to try to figure out the circumstances that trigger this. BTW, can you please include the timestamps from /var/log/messages in your reports? This helps me to understand the timeline of events.
