[Bug 260907] if_iwm: i7260 dropping connections silently, module load results in ping > 5000 ms

From: <bugzilla-noreply_at_freebsd.org>
Date: Mon, 03 Jan 2022 13:42:08 UTC

            Bug ID: 260907
           Summary: if_iwm: i7260 dropping connections silently, module
                    load results in ping > 5000 ms
           Product: Base System
           Version: 13.0-STABLE
          Hardware: Any
                OS: Any
            Status: New
          Severity: Affects Many People
          Priority: ---
         Component: wireless
          Assignee: wireless@FreeBSD.org
          Reporter: ohartmann@walstatt.org

The base is a Lenovo E450 notebook running recent 13/STABLE:

FreeBSD 13.0-STABLE #54 stable/13-n248811-2572b6bd6bf: Sun Jan  2 22:46:43 CET
2022 amd64

CPU microcode: updated from 0x25 to 0x28
CPU: Intel(R) Core(TM) i5-4200M CPU @ 2.50GHz (2494.37-MHz K8-class CPU)
  Origin="GenuineIntel"  Id=0x306c3  Family=0x6  Model=0x3c  Stepping=3
  AMD Features=0x2c100800<SYSCALL,NX,Page1GB,RDTSCP,LM>
  AMD Features2=0x21<LAHF,ABM>
  Structured Extended
  Structured Extended
  XSAVE Features=0x1<XSAVEOPT>
  TSC: P-state invariant, performance statistics
real memory  = 17179869184 (16384 MB)
avail memory = 16502960128 (15738 MB)
Event timer "LAPIC" quality 600
FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs
FreeBSD/SMP: 1 package(s) x 2 core(s) x 2 hardware threads
random: registering fast source Intel Secure Key RNG
random: fast provider: "Intel Secure Key RNG"
random: unblocking device.
Security policy loaded: MAC/ntpd (mac_ntpd)
Security policy loaded: TrustedBSD MAC/BSD Extended (mac_bsdextended)
ioapic0 <Version 2.0> irqs 0-23
Launching APs: 1 3 2
random: entropy device external interface
kbd1 at kbdmux0
efirtc0: <EFI Realtime Clock>
efirtc0: registered as a time-of-day clock, resolution 1.000000s
acpi0: <LENOVO TP-J9>
acpi_ec0: <Embedded Controller: GPE 0x17, ECDT> port 0x62,0x66 on acpi0
acpi0: Power Button (fixed)

The WiFi NIC is a Intel i7260:

iwm0@pci0:5:0:0:        class=0x028000 rev=0x73 hdr=0x00 vendor=0x8086
device=0x08b2 subvendor=0x8086 subdevice=0x4262
    vendor     = 'Intel Corporation'
    device     = 'Wireless 7260'
    class      = network
    bar   [10] = type Memory, range 64, base 0xf1c00000, size 8192, enabled
    cap 01[c8] = powerspec 3  supports D0 D3  current D0
    cap 05[d0] = MSI supports 1 message, 64 bit enabled with 1 message
    cap 10[40] = PCI-Express 2 endpoint max data 128(128) FLR RO NS
                 max read 128
                 link x1(x1) speed 2.5(2.5) ASPM L1(L0s/L1) ClockPM enabled
    ecap 0001[100] = AER 1 0 fatal 0 non-fatal 0 corrected
    ecap 0003[140] = Serial 1 ....
    ecap 0018[14c] = LTR 1
    ecap 000b[154] = Vendor [1] ID cafe Rev 1 Length 20

First observation:
With different networks and access points, the WiFi NIC results very often in
loosing network connection, it is more a freezing, since ifconfig reports still
IP and wpa_cli shows still some association to the AP, but there is no packet
flow anymore. I reported in this issue recently on freebsd-wireless and got the
advice to wait for the if_iwlwifi driver. Since this driver seems to be quite
far from ready to be used and with the above mentioned OS version unusable (no
FW is loaded), I'll report this issue in.
I have no clue why and how the connection of the i7260 WiFi NIC gets broken,
but it seems to be somehow related to the number of networks on the 2,4 GHz
band, but this observation is not accurate.

Second observation:
Since a couple of years for now I compile the if_iwm driver statically as well
as the (supposedly correct) firmware via
device iwm
device iwmfw

into the kernel. This procedure results in the above observed dropouts. With
the upcoming if_iwlwifi at hand I started loading (exclusive) either iwm or
iwlwifi via /boot/loader.conf.local into the kernel. Loading the if_iwm driver
this way results in a unusable state: very often and reproducable a ping
reaches latencies larger than 5000 - 6000 ms, with the result of a corruption
of the connections made and rapidly with the finale state as observed and
reported above  - the frozen state.

You are receiving this mail because:
You are the assignee for the bug.