Re: Intermitent loss of WiFi

[bsdprg%tuta.io@localhost]

Aug 3, 2023, 03:12 by gdt%lexort.com@localhost:

> bsdprg%tuta.io@localhost writes:
>
>> I am on NetBSD 10.0 Beta.
>> I get intermitent loss of WiFi with my iwm driver.
>>
>
> This sort of problem happens with some adaptors sometimes, but is not
> super common.  I have a few urtwn(4) devices.  One, on a 2006 macbook
> (i386) has been reliable.  Another, on a RPI3 (earmv7hf-el) has
> occasional failures and I have a cron script to detect that and down/up.
> Both of those experiences were on 8 and 9; I'm getting ready to move to
> 10.
>
> Please describe your hardware and which architecture you are running.
> We have no idea what kind of cpu/system etc.  even if it seems likely an
> i386 or amd64 laptop.
>

$ uname -a
NetBSD latitude 10.99.7 NetBSD 10.99.7 (MYKERNEL) #0: Thu Aug  3 09:08:25 PDT 2023  swadnerkar@latitude:/usr/obj/sys/arch/amd64/compile/MYKERNEL amd64

I was on 10.0 Beta, but I plan to provide the iwm logs by setting IWM_DEBUG=1 as you asked. So, I compiled the current kernel. (And also because if this problem was already fixed in the current, I didn't want to waste anyone's time).


> Please post the dmesg lines for iwm attachment.  You can blur our the
> mac address.
>

$ doas dmesg | grep -w iwm0
[     1.031913] iwm0 at pci2 dev 0 function 0: Intel Dual Band Wireless AC 8265 (rev. 0x78)
[     1.031913] iwm0: interrupting at msi3 vec 0
[     4.380047] iwm0: hw rev 0x230, fw ver 22.361476.0, address <mac address>
[ 10910.342873] iwm0: autoconfiguration error: fatal firmware error
[     1.033640] iwm0 at pci2 dev 0 function 0: Intel Dual Band Wireless AC 8265 (rev. 0x78)
[     1.033640] iwm0: interrupting at msi3 vec 0
[     5.657031] iwm0: hw rev 0x230, fw ver 22.361476.0, address <mac address>
[ 28069.286994] iwm0: autoconfiguration error: device timeout

I don't remember seeing this last line in 10.0 Beta. So, I think current correctly logs the error. I get tons of pci devices timeout:


[ 30993.196990] autoconfiguration error: pms_disable: command error
[ 30994.196994] pckbport: command timeout
[ 31004.356990] autoconfiguration error: pms_enable: command error 35
[ 31005.356994] pckbport: command timeout
[ 31015.516990] autoconfiguration error: pms_disable: command error
[ 31016.516994] pckbport: command timeout
[ 31026.678834] autoconfiguration error: pms_enable: command error 35

These may not have anything to do with iwm, because as I understand these are config errors for mouse and keyboard (though they both work fine).



> You say "loss of WiFi", but I wonder if you can narrow that down.
>
> How often does this happen?
>
> Does "ifconfig" show it still associated?
>

In 10.0 Beta, it showed the interface stil associated. But, in current, it does show it as unassociated, which is an improvement.

$ ifconfig iwm0
iwm0: flags=0x8802<BROADCAST,SIMPLEX,MULTICAST> mtu 1500
ssid "" nwkey *****
powersave off
address: <mac address>
media: IEEE802.11 autoselect (autoselect mode 11g)
status: no network



> On the router/AP/whatever, can you tell if it is gone from the network?
> If you run tcpdump -n on the adaptor, do you see any incoming frames?
> If you "ping -n [router's IP addr]", do you see outgoing frames?
> What does netstat -i show for in/out/error counts when it is "lost"?
>
> (I'm not really asking you to post all of this, but to try it all and
> see what you can figure out.)
>
>> I think this is the error message in dmesg (I am not sure whether this DRM is i915 or iwm)
>> [   968.284136] {drm:netbsd:intel_pipe_update_start+0x33b} *ERROR* Potential atomic update failure on pipe A: -35
>>
>
> That's about graphics.  Does that happen just once, or does it happen
> again when the wifi fails again?  Is there anything else in dmesg or
> syslog?
>
>> The workaround is to execute the following twice:
>> doas ifconfig iwm0 down
>> doas ifconfig iwm0 up
>>
>> It needs to be executed twice, because after the first down and up, I get:
>> ifconfig: exec_matches: Resource temporarily unavailable
>>
>
> Try waiting 10s after down before up.  Run ifconfig in between.
> Basically try every inspection method you can think of.
>
> If you are up for it, you can read the driver src/sys/dev/pci/if_iwm.c
> and turn on IWM_DEBUG and set iwm_debug to nonzero and get lots of
> messages.
>
Thank you, I am planning to do that soon.