WiFi loses connection on an irregular basis probably due to buffer overflow

Bug #1902895 reported by Aleksander Miera
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
linux (Ubuntu)
Expired
Undecided
Unassigned

Bug Description

Dell XPS13, Ubuntu 20.10, kernel 5.8.
I cannot pinpoint the exact scenario, but it happens most often when trying to build Xorg-master from source via their build.sh script.
Setup: WiFi connected, xorg is built in terminal window. Speculatively I would say it say realted to trasferring large number of small files, but I don't have any hard evidence to prove that.

To depict it better:
A Main terminal (and let it run):
$ ./util/modular/build.sh --clone $HOME/build
B Second terminal (and let it run):
$ ping www.onet.pl #any host should do, just using popular news site as an example
C Third terminal (optionally)
# dmesg -w

At some point of build.sh cloning, the other terminal (B) starts to display this:
64 bytes from sg1.any.onet.pl (213.180.141.140): icmp_seq=151 ttl=58 time=20.2 ms #that's ok
ping: sendmsg: No buffer space available
ping: sendmsg: No buffer space available
ping: sendmsg: No buffer space available
It usually happens when A is in the middle of git clone, which just hangs there.
Nothing displayed by dmesg.
All other network activity stalls (but not fails). Waiting ca. 5 minutes does not help.
WiFi icon indicates everything's fine.
Restarting WiFi (either using the icon or with rfkill, ifconfig should probably work too) restores connectivity, but breaks all the stalled activity, e.g. scripts, git etc.

Increasing /proc/sys/net/core/wmem_max delays the problem and allows one or two clones to complete in the given example.

I have observed that on 18.04, 20.04 and 20.10, with the default kernels i.e. 5.4 and 5.8. Scenario in each case is exactly the same.

ProblemType: Bug
DistroRelease: Ubuntu 20.10
Package: linux-image-5.8.0-25-generic 5.8.0-25.26
ProcVersionSignature: Ubuntu 5.8.0-25.26-generic 5.8.14
Uname: Linux 5.8.0-25-generic x86_64
ApportVersion: 2.20.11-0ubuntu50
Architecture: amd64
AudioDevicesInUse:
 USER PID ACCESS COMMAND
 /dev/snd/controlC0: dladmin 1368 F.... pulseaudio
CasperMD5CheckResult: skip
CurrentDesktop: ubuntu:GNOME
Date: Wed Nov 4 15:51:00 2020
InstallationDate: Installed on 2020-10-26 (9 days ago)
InstallationMedia: Ubuntu 20.10 "Groovy Gorilla" - Release amd64 (20201022)
Lsusb:
 Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
 Bus 001 Device 004: ID 0c45:670c Microdia Integrated Webcam HD
 Bus 001 Device 003: ID 04f3:2234 Elan Microelectronics Corp. Touchscreen
 Bus 001 Device 002: ID 0cf3:e300 Qualcomm Atheros Communications QCA61x4 Bluetooth 4.0
 Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
MachineType: Dell Inc. XPS 13 9360
ProcFB: 0 i915drmfb
ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-5.8.0-25-generic root=UUID=746d5f05-e21a-42c5-9191-a65c526a3305 ro quiet splash vt.handoff=7
RelatedPackageVersions:
 linux-restricted-modules-5.8.0-25-generic N/A
 linux-backports-modules-5.8.0-25-generic N/A
 linux-firmware 1.190
SourcePackage: linux
UpgradeStatus: No upgrade log present (probably fresh install)
dmi.bios.date: 11/14/2019
dmi.bios.release: 2.13
dmi.bios.vendor: Dell Inc.
dmi.bios.version: 2.13.0
dmi.board.name: 0839Y6
dmi.board.vendor: Dell Inc.
dmi.board.version: A00
dmi.chassis.type: 9
dmi.chassis.vendor: Dell Inc.
dmi.modalias: dmi:bvnDellInc.:bvr2.13.0:bd11/14/2019:br2.13:svnDellInc.:pnXPS139360:pvr:rvnDellInc.:rn0839Y6:rvrA00:cvnDellInc.:ct9:cvr:
dmi.product.family: XPS
dmi.product.name: XPS 13 9360
dmi.product.sku: 075B
dmi.sys.vendor: Dell Inc.

Revision history for this message
Aleksander Miera (amiera) wrote :
Revision history for this message
Ubuntu Kernel Bot (ubuntu-kernel-bot) wrote : Status changed to Confirmed

This change was made by a bot.

Changed in linux (Ubuntu):
status: New → Confirmed
Revision history for this message
Kai-Heng Feng (kaihengfeng) wrote :
Changed in linux (Ubuntu):
status: Confirmed → Incomplete
Revision history for this message
Aleksander Miera (amiera) wrote :

It *seems* better in the sense that the problem appears later, say after 20 minutes of operation instead of 5. Nevertheless, it's not fixed.

Revision history for this message
Kai-Heng Feng (kaihengfeng) wrote :
Revision history for this message
Aleksander Miera (amiera) wrote :

Looks like with ath10k_pci FW ver. WLAN.RM.4.4.1-00157-QCARMSWPZ-1 the issue is gone or at least delayed that much, that it makes it irreproducible for me.

The faulty one wasWLAN.RM.4.4.1-00140-QCARMSWPZ-1.

Revision history for this message
Launchpad Janitor (janitor) wrote :

[Expired for linux (Ubuntu) because there has been no activity for 60 days.]

Changed in linux (Ubuntu):
status: Incomplete → Expired
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.