[SOLVED] KVM (KeyboardVideoMouse) switch switching knocks wifi offline

Weird SP3 (surface pro 3) issue, Wifi dropping after switching screens with KVM switch.

Have a SP3 running kernel 4.19.79. I've disabled MAC address changing, Wifi power management as they normally cause issues and wifi seems stable with that.

However, I've started using a KVM switch to treat the system as a separate workstation with the lid closed. When I use the KVM to switch my monitor/mouse/keyboard to another workstation (connected through a usb3 hub), the builtin wifi drops on the SP3 within seconds of switching. I can bring it back online by removing the wifi module with modprobe, but it's a hassle that it drops when I switch away. I've removed TLP and I'm not sure what else to do.

I thought I'd reach out to see if anyone had ideas on how to fix or troubleshoot it. Thanks!

System:
  Host: lmm2019c Kernel: 4.19.79-1-MANJARO x86_64 bits: 64 
  compiler: gcc v: 9.2.0 Desktop: Gnome 3.34.1 
  wm: gnome-shell dm: GDM 3.34.1 Distro: Manjaro Linux 
Machine:
  Type: Laptop System: Microsoft product: Surface Pro 3 
  v: 1 serial: <filter> 
  Mobo: Microsoft model: Surface Pro 3 v: 1 
  serial: <filter> UEFI: American Megatrends v: 3.11.2450 
  date: 05/02/2018 
Battery:
  ID-1: BAT0 charge: 35.4 Wh condition: 35.4/42.2 Wh (84%) 
  volts: 8.0/7.6 model: LGC-LGC X883815 type: Li-ion 
  serial: <filter> status: Full cycles: 1580 
CPU:
  Topology: Dual Core model: Intel Core i5-4300U bits: 64 
  type: MT MCP arch: Haswell rev: 1 L2 cache: 3072 KiB 
  flags: avx avx2 lm nx pae sse sse2 sse3 sse4_1 sse4_2 
  ssse3 vmx 
  bogomips: 19960 
  Speed: 847 MHz min/max: 800/2900 MHz Core speeds (MHz): 
  1: 1277 2: 1416 3: 1275 4: 1249 
Graphics:
  Device-1: Intel Haswell-ULT Integrated Graphics 
  vendor: Microsoft driver: i915 v: kernel bus ID: 00:02.0 
  chip ID: 8086:0a16 
  Display: x11 server: X.org 1.20.5 driver: i915 
  compositor: gnome-shell resolution: <xdpyinfo missing> 
  OpenGL: renderer: Mesa DRI Intel Haswell Mobile 
  v: 4.5 Mesa 19.2.1 compat-v: 3.0 direct render: Yes 
Audio:
  Device-1: Intel Haswell-ULT HD Audio 
  driver: snd_hda_intel v: kernel bus ID: 00:03.0 
  chip ID: 8086:0a0c 
  Device-2: Intel 8 Series HD Audio vendor: Microsoft 
  driver: snd_hda_intel v: kernel bus ID: 00:1b.0 
  chip ID: 8086:9c20 
  Sound Server: ALSA v: k4.19.79-1-MANJARO 
Network:
  Device-1: Marvell 88W8897 [AVASTAR] 802.11ac Wireless 
  vendor: SafeNet driver: mwifiex_pcie v: 1.0 port: 3040 
  bus ID: 01:00.0 chip ID: 11ab:2b38 
  IF: wlp1s0 state: up mac: <filter> 
  Device-2: Marvell Bluetooth and Wireless LAN Composite 
  Device 
  type: USB driver: hid-generic,usbhid bus ID: 1-1.1.1.6:8 
  chip ID: 09ea:0131 serial: <filter> 
  Device-3: Marvell Bluetooth and Wireless LAN Composite 
  Device 
  type: USB driver: btusb bus ID: 1-6:9 chip ID: 1286:204b 
  serial: <filter> 
  IF-ID-1: docker0 state: down mac: <filter> 
  IF-ID-2: tun0 state: unknown speed: 10 Mbps duplex: full 
  mac: N/A 
Drives:
  Local Storage: total: 238.47 GiB 
  used: 211.13 GiB (88.5%) 
  ID-1: /dev/sda vendor: Samsung model: MZMTE256HMHP-000MV 
  size: 238.47 GiB speed: 6.0 Gb/s serial: <filter> 
  rev: 1M0Q scheme: GPT 
Partition:
  ID-1: / size: 224.77 GiB used: 211.13 GiB (93.9%) 
  fs: ext4 dev: /dev/dm-0 
  ID-2: swap-1 size: 8.80 GiB used: 0 KiB (0.0%) fs: swap 
  dev: /dev/dm-1 
Sensors:
  System Temperatures: cpu: 54.0 C mobo: N/A 
  Fan Speeds (RPM): N/A 
Info:
  Processes: 269 Uptime: 5d 2h 59m Memory: 7.70 GiB 
  used: 4.21 GiB (54.7%) Init: systemd v: 242 Compilers: 
  gcc: 9.2.0 clang: 9.0.0 Shell: bash v: 5.0.11 
  running in: gnome-terminal inxi: 3.0.36

which modules do you need to reload to get the wifi working after switching?

post:

hwinfo --netcard
lsmod | grep -i mwif

the only module i see with available parameters is mwifiex

parm:           reg_alpha2:charp
parm:           drcs:multi-channel operation:1, single-channel operation:0 (bool)
parm:           disable_auto_ds:deepsleep enabled=0(default), deepsleep disabled=1 (bool)
parm:           disconnect_on_suspend:int
parm:           disable_tx_amsdu:bool
parm:           debug_mask:bitmap for debug flags (uint)
parm:           cal_data_cfg:charp
parm:           driver_mode:station=0x1(default), ap-sta=0x3, station-p2p=0x5, ap-sta-p2p=0x7 (ushort)
parm:           mfg_mode:manufacturing mode enable:1, disable:0 (bool)
parm:           aggr_ctrl:usb tx aggregation enable:1, disable:0 (bool)

you could try

#/etc/modprobe.d/mwifiex.conf

options mwifiex disable_auto_ds=1

save/exit/reboot

if thats not it, add this line to that file also
options mwifiex disconnect_on_suspend=1

You're right on the module, it is mwifiex.

hwinfo --netcard
10: PCI 100.0: 0282 WLAN controller                             
  [Created at pci.386]
  Unique ID: yWPJ.gZjiGgu5zi4
  Parent ID: z8Q3.WTISIRr_mg6
  SysFS ID: /devices/pci0000:00/0000:00:1c.0/0000:01:00.0
  SysFS BusID: 0000:01:00.0
  Hardware Class: network
  Model: "Marvell 88W8897 [AVASTAR] 802.11ac Wireless"
  Vendor: pci 0x11ab "Marvell Technology Group Ltd."
  Device: pci 0x2b38 "88W8897 [AVASTAR] 802.11ac Wireless"
  SubVendor: pci 0x0001 "SafeNet (wrong ID)"
  SubDevice: pci 0x045e 
  Driver: "mwifiex_pcie"
  Driver Modules: "mwifiex_pcie"
  Device File: wlp1s0
  Features: WLAN
  Memory Range: 0xc0500000-0xc05fffff (ro,non-prefetchable)
  Memory Range: 0xc0400000-0xc04fffff (ro,non-prefetchable)
  IRQ: 47 (4109 events)
  Link detected: yes
  WLAN channels: 1 2 3 4 5 6 7 8 9 10 11 38 42 46 36 40 44 48 52 56 60 64 100 104 108 112 116 120 124 128 132 136
  WLAN frequencies: 2.412 2.417 2.422 2.427 2.432 2.437 2.442 2.447 2.452 2.457 2.462 5.19 5.21 5.23 5.18 5.2 5.22 5.24 5.26 5.28 5.3 5.32 5.5 5.52 5.54 5.56 5.58 5.6 5.62 5.64 5.66 5.68
  WLAN encryption modes: WEP40 WEP104 TKIP CCMP
  WLAN authentication modes: open sharedkey wpa-psk wpa-eap
  Module Alias: "pci:v000011ABd00002B38sv00000001sd0000045Ebc02sc00i00"
  Driver Info #0:
    Driver Status: mwifiex_pcie is active
    Driver Activation Cmd: "modprobe mwifiex_pcie"
  Config Status: cfg=new, avail=yes, need=no, active=unknown
  Attached to: #7 (PCI bridge)
lsmod | grep -i mwif
mwifiex_pcie           45056  0
mwifiex               319488  1 mwifiex_pcie
cfg80211              790528  1 mwifiex

Trying your suggest config change and will report back.

1 Like

Tried adding both lines to the suggested file,
the wifi still fails after I switch away. I do think it might be related to suspend though, cause with the lid closed, and the monitor disconnecting, I assume it tries to suspend cause If I start a ping before I switch away, the wifi will continue to send 13 packets or so after I switchaway before the wifi goes down.

When I login again the wifi is down and here's the ip addr result (XX for ID scrubbing):

5: wlp1s0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc mq state DOWN group default qlen 1000
link/ether XX:XX:XX:XX:XX:XX brd ff:ff:ff:ff:ff:ff

check dmesg right after doing a switch, post relevant output.

if it is a suspend issue you can try disconnecting and unloading modules before switching and loading them back after the switch is made. if that works you can use a systemd service to do this for you whenever going into suspend/wake .

another thing you could try is going into power management settings and change the suspend behavior. "closing lid does: ?" try changing it to "nothing" so a perceived suspend action due to lid close will be ignored.

I don't know how you would go about finding an actual fix if the driver options @dglt recommended do not help. I do think a satisfactory workaround would be a service to automatically rmmod and modprobe your module for you when your connection goes down.

I have used this service that I wrote for a while and it works very well.

The script I have written does a full network restart. If you only need to rmmod and modprobe both modules then simply pare down the script to what you need.

Here is another example of a suspend service written for your driver a few days ago.

With both those examples you should easily be able to write a service that will restart your connection within seconds of it going down. Not a proper fix, but not a bad workaround. The constant ping executed by the service may even be enough to keep the connection alive on it's own.

Good luck.

1 Like

Disabling "suspend on lid close" in the tweaks app seems to resolve the issue now. Thanks for the help!

2 Likes

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.

Forum kindly sponsored by