Wi-Fi stops working after a while

[thiccyoshi]

So I recently install Linux Mint Cinnamon and it's working great except for one thing. Every now and then the Wi-Fi is unavailable and I need to restart to fix this. Sometimes it's unavailable when I turn it on and sometimes it's not. Could someone help me?

Output of inxi -Fxz

Code: Select all

System:
  Kernel: 5.4.0-70-generic x86_64 bits: 64 compiler: gcc v: 9.3.0 
  Desktop: Cinnamon 4.8.6 Distro: Linux Mint 20.1 Ulyssa 
  base: Ubuntu 20.04 focal 
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.2650 date: 04/30/2019 
Battery:
  ID-1: BAT0 charge: 36.0 Wh condition: 36.0/42.2 Wh (85%) 
  model: SIMPLO X898289 status: Full 
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: 19953 
  Speed: 1153 MHz min/max: 800/2900 MHz Core speeds (MHz): 1: 1620 2: 1914 
  3: 1862 4: 1713 
Graphics:
  Device-1: Intel Haswell-ULT Integrated Graphics vendor: Microsoft 
  driver: i915 v: kernel bus ID: 00:02.0 
  Display: x11 server: X.Org 1.20.9 driver: modesetting unloaded: fbdev,vesa 
  resolution: 2160x1440~60Hz 
  OpenGL: renderer: Mesa DRI Intel HD Graphics 4400 (HSW GT2) 
  v: 4.5 Mesa 20.2.6 direct render: Yes 
Audio:
  Device-1: Intel Haswell-ULT HD Audio driver: snd_hda_intel v: kernel 
  bus ID: 00:03.0 
  Device-2: Intel 8 Series HD Audio vendor: Microsoft driver: snd_hda_intel 
  v: kernel bus ID: 00:1b.0 
  Sound Server: ALSA v: k5.4.0-70-generic 
Network:
  Device-1: Marvell 88W8897 [AVASTAR] 802.11ac Wireless vendor: SafeNet 
  driver: mwifiex_pcie v: 1.0 port: 3040 bus ID: 01:00.0 
  IF: wlp1s0 state: up mac: <filter> 
  Device-2: Marvell Bluetooth and Wireless LAN Composite Device type: USB 
  driver: btusb bus ID: 1-6:4 
  IF-ID-1: virbr0 state: down mac: <filter> 
  IF-ID-2: virbr0-nic state: down mac: <filter> 
Drives:
  Local Storage: total: 238.47 GiB used: 54.24 GiB (22.7%) 
  ID-1: /dev/sda vendor: Samsung model: MZMTE256HMHP-000MV size: 238.47 GiB 
Partition:
  ID-1: / size: 233.24 GiB used: 54.23 GiB (23.3%) fs: ext4 dev: /dev/sda2 
Sensors:
  System Temperatures: cpu: 51.0 C mobo: N/A 
  Fan Speeds (RPM): N/A 
Info:
  Processes: 222 Uptime: 4m Memory: 7.68 GiB used: 1.22 GiB (15.9%) 
  Init: systemd runlevel: 5 Compilers: gcc: 9.3.0 Shell: bash v: 5.0.17 
  inxi: 3.0.38

[hglee]

So I recently install Linux Mint Cinnamon and it's working great except for one thing. Every now and then the Wi-Fi is unavailable and I need to restart to fix this. Sometimes it's unavailable when I turn it on and sometimes it's not. Could someone help me?

Others with that wifi chipset got some improvement by disabling autosuspend:

On your Surface Pro, open a Terminal (Ctrl-Alt-T), then copy-and-paste the following two commands, one by one...

Code: Select all

sudo sed -i 's/3/2/' /etc/NetworkManager/conf.d/default-wifi-powersave-on.conf
systemctl restart network-manager.service

Others also found that a firmware upgrade could help:

Open a Terminal (Ctrl-Alt-T), then copy-and-paste the following three commands, one by one...

Code: Select all

cd ~/Downloads
wget http://archive.ubuntu.com/ubuntu/pool/main/l/linux-firmware/linux-firmware_1.195_all.deb
sudo dpkg -i linux-firmware_1.195_all.deb 2>/dev/null

Reboot and confirm that Secure Boot is disabled in your BIOS, as it's known to interfere with device drivers.


Let's take a closer look at your laptop's hardware:

Open a Terminal (Ctrl-Alt-T), then copy-and-paste the following long command-line...

Code: Select all

(lsusb -tv;iwconfig;lspci -nnk;(lsmod;dmesg)|egrep -i "wl|firm|wif";rfkill list;mokutil --sb-state) 2>&1|nc termbin.com 9999

After a brief pause, a termbin.com URL will appear in the Terminal. Post that URL in a reply here.

[thiccyoshi]

Alright I've done all the commands. Here's the link: https://termbin.com/ojoj

[thiccyoshi]

Bump

[hglee]

Bump

I haven't forgotten.

I'm attempting to compose a reply that may let you down gently, because it isn't happy news.

[thiccyoshi]

So, there's nothing I can do? I mean it hasn't really played up recently but yeah.

[hglee]

So, there's nothing I can do? I mean it hasn't really played up recently but yeah.

Among other things specific to this particular issue: I've read every Linux developer's message in a Bugzilla discussion thread at the fine olde institute of Kernel.org, where their insightful dialogue spanned almost five years. They know where the culprit lives. They have it surrounded. But they can't access it.

Your Marvell 88W8897 wifi chipset has its own internal brain (microcontroller), with its own embedded firmware (software coded into a microchip) -- and only the manufacturer can service it.

Worse, it doesn't appear to be a firmware programming error that can be systematically debugged with a black-box approach -- it has all of the maddening characteristics a manufacturing flaw. The 88W8897 interfaces to your computer via PCI Express, and that internal interface is exhibiting the behaviours of intermittent power-failures. That's why you'll have days when your wifi seems entirely absent. Its performance can be dismal.

This is one reason that disabling Autosuspend could appear to help, because the good-intention suspension of power may only compound the consequences of unmanageable outages.

Now, I will tell you that I've come across some magic beans, in the form of unvetted scripts that manhandle the 88W8897's configuration files. Some clever Jack noticed that the devs were successfully focused on power management tactics -- so the script twirls the knobs of the PCIe's internal Active-State Power Management (ASPM) system. Electrical modifications by amateurs. Unqualified for the praise. Who knows what that'll eventually do to digital devices.

One foreboding comment line in the code: "We can surely read the spec to get a better value". **chills**

It appears that the script has so far reached a limited audience, possibly because there are some technical hurdles to overcome for its use:

1: Your have to know how to use command-line utilities to ID the domain, bus, slot, etc, of your specific PCIe device.

2: You have to modify the script to add that device ID to the code (which is undocumented).

3: The script's configuration modifications are lost when your PC powers down -- so either you manually sudo the script at every login, or you know how to make the script automatically run as root at every power-on.

I've already seen boasts from smarty-pants about how they've tweaked the script code, before they pass it on to clueless others.

[thiccyoshi]

So the reason it's been playing up is because of power issues? And someone has built or modified a script file that works with the firmware of my chipset?

[hglee]

So the reason it's been playing up is because of power issues? And someone has built or modified a script file that works with the firmware of my chipset?

IMO, "works with" is a little too flattering for something that's unvetted and applied irresponsibly.

Some of the fixes that you see dispensed in these forums might appear haphazard -- but the firmware that drives the metal is from legitimate devs or original equipment manufacturer (OEM) sources.


Electronic devices -- particularly "smart" devices with an embedded microcontroller -- that are subject to power fluctuations can exhibit odd come-and-go symptoms. Components can become irreversibley fatigued.

Blindly disrupting the ASPM could impact the local ecosystem, not just the one device/chipset. Over time, other subsystems may malfunction as a result of forcibly operating out-of-spec.


You probably rolled some relatively serious coin for your Microsoft Surface Pro 3, even if you purchased a refurb. A dongle could be a wiser (safer) solution than a rogue script.