This bug was fixed in the package linux-raspi - 5.11.0-1003.3
---------------
linux-raspi (5.11.0-1003.3) hirsute; urgency=medium
* hirsute/linux-raspi: 5.11.0-1003.3 -proposed tracker (LP: #1917734)
* Packaging resync (LP: #1786013)
- [Packaging] update variants
- [Packaging] update update.conf
* Miscellaneous Ubuntu changes
- [Packaging] raspi: Initial version of linux-raspi for Hirsute
- [Config] raspi: updateconfigs after rebase to Ubuntu-5.11.0-11.12
- [Packaging] raspi: Set disable_d_i=true in hooks.mk
- [Packaging] raspi: Add dctrl-tools to Build-Depends
- [Packaging] raspi: Correctly implement noudeb build profiles
- [Packaging] raspi: remove Provides: aufs-dkms
[ Ubuntu: 5.11.0-11.12 ]
* hirsute/linux: 5.11.0-11.12 -proposed tracker (LP: #1917335)
* Packaging resync (LP: #1786013)
- update dkms package versions
- [Packaging] update variants
* Support no udeb profile (LP: #1916095)
- [Packaging] replace custom filter script with dctrl-tools
- [Packaging] correctly implement noudeb build profiles.
* Miscellaneous Ubuntu changes
- [Packaging] dkms-versions -- remove nvidia-graphics-drivers-440-server
- [Debian] run ubuntu-regression-suite for linux-unstable
- [Packaging] remove Provides: aufs-dkms
- [Packaging] Change source package name to linux
- [Config] update gcc version in config due to toolchain update
* Miscellaneous upstream changes
- Revert "UBUNTU: [Config] disable nvidia and nvidia_server builds"
- Xen/x86: don't bail early from clear_foreign_p2m_mapping()
- Xen/x86: also check kernel mapping in set_foreign_p2m_mapping()
- Xen/gntdev: correct dev_bus_addr handling in gntdev_map_grant_pages()
- Xen/gntdev: correct error checking in gntdev_map_grant_pages()
- xen/arm: don't ignore return errors from set_phys_to_machine
- xen-blkback: don't "handle" error by BUG()
- xen-netback: don't "handle" error by BUG()
- xen-scsiback: don't "handle" error by BUG()
- xen-blkback: fix error handling in xen_blkbk_map()
- tty: protect tty_write from odd low-level tty disciplines
- Bluetooth: btusb: Always fallback to alt 1 for WBS
- media: pwc: Use correct device for DMA
- bpf: Fix truncation handling for mod32 dst reg wrt zero
- HID: make arrays usage and value to be the same
- USB: quirks: sort quirk entries
- usb: quirks: add quirk to start video capture on ELMO L-12F document
camera
reliable
- ntfs: check for valid standard information attribute
- Bluetooth: btusb: Some Qualcomm Bluetooth adapters stop working
- arm64: tegra: Add power-domain for Tegra210 HDA
- hwmon: (dell-smm) Add XPS 15 L502X to fan control blacklist
- KVM: x86: Zap the oldest MMU pages, not the newest
- KVM: do not assume PTE is writable after follow_pfn
- mm: provide a saner PTE walking API for modules
- KVM: Use kvm_pfn_t for local PFN variable in hva_to_pfn_remapped()
-- Juerg Haefliger <jue...@canonical.com> Thu, 04 Mar 2021 14:42:19
+0100
** Changed in: linux-raspi (Ubuntu)
Status: Confirmed => Fix Released
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux-raspi in Ubuntu.
https://bugs.launchpad.net/bugs/1890487
Title:
rpi3b+ wifi doesn't get used if ethernet disconnected
Status in linux-raspi package in Ubuntu:
Fix Released
Status in linux-raspi source package in Focal:
Fix Released
Status in linux-raspi source package in Groovy:
Fix Released
Bug description:
[Impact]
When testing 20.04.1, I noticed some different behavior on rpi3b+ that
I didn't see on rpi3b or rpi4. I have configured the device with
ethernet, added netplan yaml for my wifi network, and rebooted. So
both eth0 and wlan0 have an ip address.
On all other devices (rpi3b, rpi4, etc), if I unplug eth0 wile pinging
something, I'll miss maybe 1 ping and then it will continue to work
and just switch over to wlan0. However, on rpi3b+ it just stops being
able to access the network completely. If I re-run netplan apply, it
will start using wifi again, but if I plug eth0 back in, then unplug
it, it stops just like before.
I am seeing this with the current 20.04.1 release:
Linux ubuntu 5.4.0-1015-raspi #15-Ubuntu SMP Fri Jul 10 05:34:24 UTC 2020
aarch64 aarch64 aarch64 GNU/Linux
I also went back and tested the original 20.04 release and it happens there
too, so this is not a regression:
Linux ubuntu 5.4.0-1008-raspi #8-Ubuntu SMP Wed Apr 8 11:13:06 UTC 2020
aarch64 aarch64 aarch64 GNU/Linux
I see this happen on both armhf and arm64. One difference I did note, is that
I get a link down message in dmesg on rpi3b, but not rpi3b+. When I disconnect
eth0 on rpi3b I see this:
[ 82.203702] smsc95xx 1-1.1:1.0 eth0: link down
...but nothing on the 3b+.
[Test Case]
Disconnect and reconnect the eth0 cable. The link will not come back
up. Or down eth0 and bring it back up. The link will not come back up.
$ ip a
...
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP
group default qlen 1000
link/ether b8:27:eb:3e:ab:fb brd ff:ff:ff:ff:ff:ff
inet 192.168.99.191/24 brd 192.168.99.255 scope global dynamic eth0
valid_lft 795197sec preferred_lft 795197sec
inet6 fe80::ba27:ebff:fe3e:abfb/64 scope link
valid_lft forever preferred_lft forever
...
$ ip link set eth0 down
$ ip link set eth0 up
$ ip a
...
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP
group default qlen 1000
link/ether b8:27:eb:3e:ab:fb brd ff:ff:ff:ff:ff:ff
...
[Where problems could occur]
The fix is to read the PHY status register to clear pending
interrupts. That read could fail for various reasons which would
probably result in kernel error messages. But nothing more should
happen. IMO worst case is that we get the old behavior.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux-raspi/+bug/1890487/+subscriptions
--
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help : https://help.launchpad.net/ListHelp
