[Kernel-packages] [Bug 1900438] Re: Bcache bypasse writeback on caching device with fragmentation
** Tags added: verification-done-bionic
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1900438
Title:
Bcache bypasse writeback on caching device with fragmentation
Status in linux package in Ubuntu:
Fix Released
Status in linux source package in Bionic:
Fix Committed
Status in linux source package in Focal:
Fix Committed
Status in linux source package in Groovy:
Fix Committed
Status in linux source package in Hirsute:
Fix Released
Bug description:
SRU Justification:
[Impact]
This bug in bcache affects I/O performance on all versions of the kernel
[correct versions affected]. It is particularly negative on ceph if used with
bcache.
Write I/O latency would suddenly go to around 1 second from around 10
ms when hitting this issue and would easily be stuck there for hours
or even days, especially bad for ceph on bcache architecture. This
would make ceph extremely slow and make the entire cloud almost
unusable.
The root cause is that the dirty bucket had reached the 70 percent
threshold, thus causing all writes to go direct to the backing HDD
device. It might be fine if it actually had a lot of dirty data, but
this happens when dirty data has not even reached over 10 percent, due
to having high memory fragmentation. What makes it worse is that the
writeback rate might be still at minimum value (8) due to the
writeback percent not reached, so it takes ages for bcache to really
reclaim enough dirty buckets to get itself out of this situation.
[Fix]
* 71dda2a5625f31bc3410cb69c3d31376a2b66f28 “bcache: consider the
fragmentation when update the writeback rate”
The current way to calculate the writeback rate only considered the dirty
sectors.
This usually works fine when memory fragmentation is not high, but it will
give us an unreasonably low writeback rate when we are in the situation that a
few dirty sectors have consumed a lot of dirty buckets. In some cases, the
dirty buckets reached CUTOFF_WRITEBACK_SYNC (i.e., stopped writeback) while
the dirty data (sectors) had not even reached the writeback_percent threshold
(i.e., started writeback). In that situation, the writeback rate will still be
the minimum value (8*512 = 4KB/s), thus it will cause all the writes to bestuck
in a non-writeback mode because of the slow writeback.
We accelerate the rate in 3 stages with different aggressiveness:
the first stage starts when dirty buckets percent reach above
BCH_WRITEBACK_FRAGMENT_THRESHOLD_LOW (50),
the second is BCH_WRITEBACK_FRAGMENT_THRESHOLD_MID (57),
the third is BCH_WRITEBACK_FRAGMENT_THRESHOLD_HIGH (64).
By default the first stage tries to writeback the amount of dirty data
in one bucket (on average) in (1 / (dirty_buckets_percent - 50)) seconds,
the second stage tries to writeback the amount of dirty data in one bucket
in (1 / (dirty_buckets_percent - 57)) * 100 milliseconds, the third
stage tries to writeback the amount of dirty data in one bucket in
(1 / (dirty_buckets_percent - 64)) milliseconds.
The initial rate at each stage can be controlled by 3 configurable
parameters:
writeback_rate_fp_term_{low|mid|high}
They are by default 1, 10, 1000, chosen based on testing and
production data, detailed below.
A. When it comes to the low stage, it is still far from the 70%
threshold, so we only want to give it a little bit push by setting the
term to 1, it means the initial rate will be 170 if the fragment is 6,
it is calculated by bucket_size/fragment, this rate is very small,
but still much more reasonable than the minimum 8.
For a production bcache with non-heavy workload, if the cache device
is bigger than 1 TB, it may take hours to consume 1% buckets,
so it is very possible to reclaim enough dirty buckets in this stage,
thus to avoid entering the next stage.
B. If the dirty buckets ratio didn’t turn around during the first stage,
it comes to the mid stage, then it is necessary for mid stage
to be more aggressive than low stage, so the initial rate is chosen
to be 10 times more than the low stage, which means 1700 as the initial
rate if the fragment is 6. This is a normal rate
we usually see for a normal workload when writeback happens
because of writeback_percent.
C. If the dirty buckets ratio didn't turn around during the low and mid
stages, it comes to the third stage, and it is the last chance that
we can turn around to avoid the horrible cutoff writeback sync issue,
then we choose 100 times more aggressive than the mid stage, that
means 17 as the initial rate if the fragment is 6. This is also
inferred from a production bcache, I've got one week's writeback rate
data from a production bcache which has quite heavy workloads,
again, the writeback is triggered by the writeback pe
[Kernel-packages] [Bug 1925452] Comment bridged from LTC Bugzilla
--- Comment From alexs...@de.ibm.com 2021-04-27 04:52 EDT--- Verified successfully on focal, ping works fine in switchdev mode. root@pok1-qz1-sr1-rk011-s21:~# uname -a Linux pok1-qz1-sr1-rk011-s21 5.4.0-73-generic #82~lp1925452-Ubuntu SMP Mon Apr 26 15:44:18 UTC 2021 s390x s390x s390x GNU/Linux root@pok1-qz1-sr1-rk011-s21:~# devlink dev eswitch show pci/0100:00:00.1 pci/0100:00:00.1: mode switchdev inline-mode none encap enable root@pok1-qz1-sr1-rk011-s21:~# ping -c 5 172.31.22.42 PING 172.31.22.42 (172.31.22.42) 56(84) bytes of data. 64 bytes from 172.31.22.42: icmp_seq=1 ttl=0 time=0.085 ms 64 bytes from 172.31.22.42: icmp_seq=2 ttl=0 time=0.071 ms 64 bytes from 172.31.22.42: icmp_seq=3 ttl=0 time=0.066 ms 64 bytes from 172.31.22.42: icmp_seq=4 ttl=0 time=0.078 ms 64 bytes from 172.31.22.42: icmp_seq=5 ttl=0 time=0.078 ms --- 172.31.22.42 ping statistics --- 5 packets transmitted, 5 received, 0% packet loss, time 4134ms rtt min/avg/max/mdev = 0.066/0.075/0.085/0.006 ms -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1925452 Title: [Ubuntu 21.04] net/mlx5: Fix HW spec violation configuring uplink Status in Ubuntu on IBM z Systems: In Progress Status in linux package in Ubuntu: In Progress Status in linux source package in Focal: In Progress Status in linux source package in Groovy: In Progress Status in linux source package in Hirsute: In Progress Bug description: SRU Justification: == [Impact] * In addition to 9c9be85f6b59 "net/mlx5e: Add missing capability check for uplink follow" (handled in LP#1921104) another fix 1a73704c82ed "Fix HW spec violation configuring uplink" (handled in this bug, LP#1925452) is needed to fix issues that were introduced with commit 7d0314b11cdd "net/mlx5e: Modify uplink state on interface up/down". * Commit 1a73704c82ed "Fix HW spec violation configuring uplink" fixes a regression for mlx5 adapters required to operate in switchdev mode. * This fix makes sure that the uplink port is modified to follow only if the uplink_follow capability if it's set as required by the hw specification. * Failure cause traffic to the uplink representer net device to cease after switching to switchdev mode. [Fix] * upstream fix (upstream with v5.12-rc7) 1a73704c82ed4ee95532ac04645d02075bd1ce3d 1a73704c82ed "Fix HW spec violation configuring uplink" * can be cleanly cherry picked from hirsute master-next. * a backport for groovy: https://launchpadlibrarian.net/534888680/groovy-0001-net-mlx5-Fix-HW-spec-violation-configuring-uplink.patch * a backport for focal: https://launchpadlibrarian.net/534847308/focal-0001-net-mlx5-Fix-HW-spec-violation-configuring-uplink.patch [Test Case] * Two servers, installed with Ubuntu Server 20.04 or 20.10 are needed. * Each server needs to have a Mellanox ConnectX4/5 adapter, attached to the same switch * Adapters must be running adapter firmware level 16.29.1006 or earlier. * enable SRIOV and switchdev mode on one adapter: echo 0 > /sys/bus/pci/devices/0100\:00\:00.0/sriov_drivers_autoprobe echo 0 > /sys/bus/pci/devices/0100\:00\:00.1/sriov_drivers_autoprobe echo 64 > /sys/bus/pci/devices/0100\:00\:00.0/sriov_numvfs echo 64 > /sys/bus/pci/devices/0100\:00\:00.1/sriov_numvfs devlink dev eswitch set pci/0100:00:00.0 mode switchdev devlink dev eswitch set pci/0100:00:00.1 mode switchdev * Assign an IP address to the physical function device of the adapters on both systems * IP communication will fail * With the fix, IP communication can be established. [Regression Potential] * There is always at least some potential for regression. In this case the new code can go wrong (or might become worse than before) in case the new if statement is wrong. * It checks for the condition of "MLX5_CAP_GEN(mdev, uplink_follow)" and in case MLX5_CAP_GEN is calculated erroneous or mdev is other than expected, the mlx5_modify_vport_admin_state call might go wrong, too. * But since only the If clause was added, the changes are pretty minimal and therefore well traceable. [Other] * Since the patch/commit is upstream with 5.12-rc7, it will be in Impish. __ With the 5.4.0-48 update for Ubuntu 20.04, the commit "net/mlx5e: Modify uplink state on interface up/down" was integrated which contains a regression for mlx5 adapters with older adapter firmware. This is the second bugfix to repair the regression, required to operate the adapter in switchdev mode. The first part was integrated via Bug 192185 - LP1921104. This is the upstream fix required to be backported to Ubuntu 20.04: https://github.com/torvalds/linux/commit/1a73704c82ed4ee95532ac04645d02075bd1ce3d ---Additional Hardware Info--- Mellanox ConnectX network adapter ---uname output--- 5.4.0-73-generic -
[Kernel-packages] [Bug 1921452] Re: [SRU] alsa-lib: conf: USB - add "Cmedia Audio" to USB-Audio.pcm.iec958_device
tested the alsa-lib in focal-proposed, this issue was fixed. change verification tag to done. -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to alsa-lib in Ubuntu. https://bugs.launchpad.net/bugs/1921452 Title: [SRU] alsa-lib: conf: USB - add "Cmedia Audio" to USB- Audio.pcm.iec958_device Status in OEM Priority Project: Fix Released Status in alsa-lib package in Ubuntu: Fix Released Status in alsa-lib source package in Focal: Fix Committed Status in alsa-lib source package in Groovy: Fix Committed Status in alsa-lib source package in Hirsute: Fix Released Bug description: [Impact] On Cmedia Audio, unusable SPDIF can be selected as output from PulseAudio. [Fix] Disable IEC958 (SPDIF) through ALSA UCM. [Test] With the UCM applied, `pactl` and audio panel in gnome-control-center no longer have SPDIF option. [Where problems will occur] "Cmedia Audio" is the sound card name of this usb audio dongle, and this string is got from usb string descriptor, that is to say the "Cmedia Audio" is hard-coded in the firmware of that usb dongle. Not all Cmedia usb audio dongle use "Cmedia Audio", most of the dongles don't set string descriptor, then the audio driver sets a generic name "USB Audio Device" for them, if a dongle has string descriptor, it may have different string like "C-Media USB Headphone Set", and all dongles I met before don't have SPDIF interface. So If this SRU could introduce regression, it will happen on a Cmedia usb audio dongle which also hard-codes the "Cmedia Audio" in the string descriptor and it has SPDIF interface on it, after this SRU, users couldn't find the SPDIF playback device from the gnome-sound-setting. But this regression chance is very low since it is very rare a cmedia usb audio dongle uses "Cmedia Audio" in the string descriptor and it is very rare a usb audio dongle has SPDIF interface. So far we haven't met such a cmedia usb audio dongle. To manage notifications about this bug go to: https://bugs.launchpad.net/oem-priority/+bug/1921452/+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
[Kernel-packages] [Bug 1921452] Re: [SRU] alsa-lib: conf: USB - add "Cmedia Audio" to USB-Audio.pcm.iec958_device
tested the alsa-lib in groovy-proposed, this issue was fixed. change verification tag to done. ** Tags removed: verification-needed verification-needed-focal verification-needed-groovy ** Tags added: verification-done verification-done-focal verification-done-groovy ** Changed in: oem-priority Status: In Progress => Fix Released -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to alsa-lib in Ubuntu. https://bugs.launchpad.net/bugs/1921452 Title: [SRU] alsa-lib: conf: USB - add "Cmedia Audio" to USB- Audio.pcm.iec958_device Status in OEM Priority Project: Fix Released Status in alsa-lib package in Ubuntu: Fix Released Status in alsa-lib source package in Focal: Fix Committed Status in alsa-lib source package in Groovy: Fix Committed Status in alsa-lib source package in Hirsute: Fix Released Bug description: [Impact] On Cmedia Audio, unusable SPDIF can be selected as output from PulseAudio. [Fix] Disable IEC958 (SPDIF) through ALSA UCM. [Test] With the UCM applied, `pactl` and audio panel in gnome-control-center no longer have SPDIF option. [Where problems will occur] "Cmedia Audio" is the sound card name of this usb audio dongle, and this string is got from usb string descriptor, that is to say the "Cmedia Audio" is hard-coded in the firmware of that usb dongle. Not all Cmedia usb audio dongle use "Cmedia Audio", most of the dongles don't set string descriptor, then the audio driver sets a generic name "USB Audio Device" for them, if a dongle has string descriptor, it may have different string like "C-Media USB Headphone Set", and all dongles I met before don't have SPDIF interface. So If this SRU could introduce regression, it will happen on a Cmedia usb audio dongle which also hard-codes the "Cmedia Audio" in the string descriptor and it has SPDIF interface on it, after this SRU, users couldn't find the SPDIF playback device from the gnome-sound-setting. But this regression chance is very low since it is very rare a cmedia usb audio dongle uses "Cmedia Audio" in the string descriptor and it is very rare a usb audio dongle has SPDIF interface. So far we haven't met such a cmedia usb audio dongle. To manage notifications about this bug go to: https://bugs.launchpad.net/oem-priority/+bug/1921452/+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
[Kernel-packages] [Bug 1925750] Re: Ubuntu 21.04 not loading correctly intel graphics driver
Used to be Intel by default (not nvidia by default) until Ubuntu 21.04. This time it changed and I did not know how to revert to intel drivers. I uninstalled nvidia drivers, after restart it switched to nouveau (still nvidia) and then I blacklisted the nouveau driver in the grub. Probably there was some way to blacklist proprietary nvidia drivers, too, but I got to that solution later :D Proprietary nvidia drivers have this thing called Optimus where, if the management app is installed, you can switch between nvidia and intel graphics (unfortunately one has also to log out-log in, in Windows it works without that), I did select Intel graphics but it does not use the open source drivers from the kernel (or at least they work differently, because I got the graphical glitches for Gnome Extensions window). Intel open source drivers don't do that. -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1925750 Title: Ubuntu 21.04 not loading correctly intel graphics driver Status in gdm3 package in Ubuntu: New Status in linux package in Ubuntu: Confirmed Bug description: I just installed Ubuntu 21.04 and have a problem: I cannot boot into Wayland to test it (should be default in 21.04) because, for some reason, my system does not correctly work with the graphics drivers. I have nvidia+intel graphics on the laptop, but in the Additional Drivers tab, I only have the Nvidia one showing. I installed mate- optimus to have access to the nvidia settings and be able to change graphics from there, that one seems to be working, but Wayland still does not show up in the log in screen, maybe because it detected the kind of driver and sees it is the nvidia one? See the screenshot. I have run some terminal commands, but I don't really understand them, maybe the outputs helps you (from nvidia drivers the Intel graphics is selected): sudo lshw -c video [sudo] password for florin: *-display UNCLAIMED description: 3D controller product: GM107M [GeForce GTX 950M] vendor: NVIDIA Corporation physical id: 0 bus info: pci@:01:00.0 version: a2 width: 64 bits clock: 33MHz capabilities: pm msi pciexpress cap_list configuration: latency=0 resources: memory:9500-95ff memory:8000-8fff memory:9000-91ff ioport:5000(size=128) *-display description: VGA compatible controller product: HD Graphics 530 vendor: Intel Corporation physical id: 2 bus info: pci@:00:02.0 version: 06 width: 64 bits clock: 33MHz capabilities: pciexpress msi pm vga_controller bus_master cap_list rom configuration: driver=i915 latency=0 resources: irq:132 memory:9300-93ff memory:a000-afff ioport:6000(size=64) memory:c-d glxinfo -B name of display: :1 display: :1 screen: 0 direct rendering: Yes Extended renderer info (GLX_MESA_query_renderer): Vendor: Intel (0x8086) Device: Mesa Intel(R) HD Graphics 530 (SKL GT2) (0x191b) Version: 21.0.1 Accelerated: yes Video memory: 3072MB Unified memory: yes Preferred profile: core (0x1) Max core profile version: 4.6 Max compat profile version: 4.6 Max GLES1 profile version: 1.1 Max GLES[23] profile version: 3.2 OpenGL vendor string: Intel OpenGL renderer string: Mesa Intel(R) HD Graphics 530 (SKL GT2) OpenGL core profile version string: 4.6 (Core Profile) Mesa 21.0.1 OpenGL core profile shading language version string: 4.60 OpenGL core profile context flags: (none) OpenGL core profile profile mask: core profile OpenGL version string: 4.6 (Compatibility Profile) Mesa 21.0.1 OpenGL shading language version string: 4.60 OpenGL context flags: (none) OpenGL profile mask: compatibility profile OpenGL ES profile version string: OpenGL ES 3.2 Mesa 21.0.1 OpenGL ES profile shading language version string: OpenGL ES GLSL ES 3.20 ProblemType: Bug DistroRelease: Ubuntu 21.04 Package: linux-image-5.11.0-16-generic 5.11.0-16.17 ProcVersionSignature: Ubuntu 5.11.0-16.17-generic 5.11.12 Uname: Linux 5.11.0-16-generic x86_64 ApportVersion: 2.20.11-0ubuntu65 Architecture: amd64 AudioDevicesInUse: USERPID ACCESS COMMAND /dev/snd/controlC0: florin15003 F pulseaudio CasperMD5CheckResult: pass CurrentDesktop: ubuntu:GNOME Date: Fri Apr 23 09:20:09 2021 InstallationDate: Installed on 2021-04-22 (0 days ago) InstallationMedia: Ubuntu 21.04 "Hirsute Hippo" - Release amd64 (20210420) Lsusb: Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub Bus 001 Device 002: ID 13d3:5652 IMC Networks TOSHIBA Web Camera - HD Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Lsusb
[Kernel-packages] [Bug 1926257] Status changed to Confirmed
This change was made by a bot. ** Changed in: linux (Ubuntu) Status: New => Confirmed -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1926257 Title: Keys not working on laptop Status in linux package in Ubuntu: Confirmed Bug description: Some keys are not working in this version ProblemType: Bug DistroRelease: Ubuntu 20.10 Package: linux-image-5.8.0-50-generic 5.8.0-50.56 ProcVersionSignature: Ubuntu 5.8.0-50.56-generic 5.8.18 Uname: Linux 5.8.0-50-generic x86_64 ApportVersion: 2.20.11-0ubuntu50.5 Architecture: amd64 AudioDevicesInUse: USERPID ACCESS COMMAND /dev/snd/controlC0: shivanshu 1994 F pulseaudio /dev/snd/pcmC0D0c: shivanshu 1994 F...m pulseaudio /dev/snd/pcmC0D0p: shivanshu 1994 F...m pulseaudio /dev/snd/controlC1: shivanshu 1994 F pulseaudio CasperMD5CheckResult: skip CurrentDesktop: ubuntu:GNOME Date: Tue Apr 27 12:26:35 2021 InstallationDate: Installed on 2020-06-10 (320 days ago) InstallationMedia: Ubuntu 20.04 LTS "Focal Fossa" - Release amd64 (20200423) Lsusb: Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub Bus 001 Device 004: ID 04f2:b61e Chicony Electronics Co., Ltd Integrated Camera Bus 001 Device 003: ID 0bda:b023 Realtek Semiconductor Corp. RTL8822BE Bluetooth 4.2 Adapter Bus 001 Device 002: ID 046d:c52b Logitech, Inc. Unifying Receiver Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub MachineType: LENOVO 81EU ProcFB: 0 i915drmfb ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-5.8.0-50-generic root=UUID=86104863-1f3c-40e9-9432-c6edade6d000 ro quiet splash RelatedPackageVersions: linux-restricted-modules-5.8.0-50-generic N/A linux-backports-modules-5.8.0-50-generic N/A linux-firmware1.190.4 SourcePackage: linux UpgradeStatus: Upgraded to groovy on 2020-10-27 (181 days ago) dmi.bios.date: 11/26/2020 dmi.bios.release: 1.46 dmi.bios.vendor: LENOVO dmi.bios.version: 7PCN46WW dmi.board.asset.tag: NO Asset Tag dmi.board.name: LNVNB161216 dmi.board.vendor: LENOVO dmi.board.version: SDK0Q55722 WIN dmi.chassis.asset.tag: NO Asset Tag dmi.chassis.type: 10 dmi.chassis.vendor: LENOVO dmi.chassis.version: Lenovo ideapad 530S-14IKB dmi.ec.firmware.release: 1.46 dmi.modalias: dmi:bvnLENOVO:bvr7PCN46WW:bd11/26/2020:br1.46:efr1.46:svnLENOVO:pn81EU:pvrLenovoideapad530S-14IKB:rvnLENOVO:rnLNVNB161216:rvrSDK0Q55722WIN:cvnLENOVO:ct10:cvrLenovoideapad530S-14IKB: dmi.product.family: ideapad 530S-14IKB dmi.product.name: 81EU dmi.product.sku: LENOVO_MT_81EU_BU_idea_FM_ideapad 530S-14IKB dmi.product.version: Lenovo ideapad 530S-14IKB dmi.sys.vendor: LENOVO To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1926257/+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
[Kernel-packages] [Bug 1925452] Re: [Ubuntu 21.04] net/mlx5: Fix HW spec violation configuring uplink
** Changed in: linux (Ubuntu Groovy) Status: New => In Progress ** Changed in: linux (Ubuntu Focal) Status: New => In Progress ** Changed in: ubuntu-z-systems Status: Triaged => In Progress -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1925452 Title: [Ubuntu 21.04] net/mlx5: Fix HW spec violation configuring uplink Status in Ubuntu on IBM z Systems: In Progress Status in linux package in Ubuntu: In Progress Status in linux source package in Focal: In Progress Status in linux source package in Groovy: In Progress Status in linux source package in Hirsute: In Progress Bug description: SRU Justification: == [Impact] * In addition to 9c9be85f6b59 "net/mlx5e: Add missing capability check for uplink follow" (handled in LP#1921104) another fix 1a73704c82ed "Fix HW spec violation configuring uplink" (handled in this bug, LP#1925452) is needed to fix issues that were introduced with commit 7d0314b11cdd "net/mlx5e: Modify uplink state on interface up/down". * Commit 1a73704c82ed "Fix HW spec violation configuring uplink" fixes a regression for mlx5 adapters required to operate in switchdev mode. * This fix makes sure that the uplink port is modified to follow only if the uplink_follow capability if it's set as required by the hw specification. * Failure cause traffic to the uplink representer net device to cease after switching to switchdev mode. [Fix] * upstream fix (upstream with v5.12-rc7) 1a73704c82ed4ee95532ac04645d02075bd1ce3d 1a73704c82ed "Fix HW spec violation configuring uplink" * can be cleanly cherry picked from hirsute master-next. * a backport for groovy: https://launchpadlibrarian.net/534888680/groovy-0001-net-mlx5-Fix-HW-spec-violation-configuring-uplink.patch * a backport for focal: https://launchpadlibrarian.net/534847308/focal-0001-net-mlx5-Fix-HW-spec-violation-configuring-uplink.patch [Test Case] * Two servers, installed with Ubuntu Server 20.04 or 20.10 are needed. * Each server needs to have a Mellanox ConnectX4/5 adapter, attached to the same switch * Adapters must be running adapter firmware level 16.29.1006 or earlier. * enable SRIOV and switchdev mode on one adapter: echo 0 > /sys/bus/pci/devices/0100\:00\:00.0/sriov_drivers_autoprobe echo 0 > /sys/bus/pci/devices/0100\:00\:00.1/sriov_drivers_autoprobe echo 64 > /sys/bus/pci/devices/0100\:00\:00.0/sriov_numvfs echo 64 > /sys/bus/pci/devices/0100\:00\:00.1/sriov_numvfs devlink dev eswitch set pci/0100:00:00.0 mode switchdev devlink dev eswitch set pci/0100:00:00.1 mode switchdev * Assign an IP address to the physical function device of the adapters on both systems * IP communication will fail * With the fix, IP communication can be established. [Regression Potential] * There is always at least some potential for regression. In this case the new code can go wrong (or might become worse than before) in case the new if statement is wrong. * It checks for the condition of "MLX5_CAP_GEN(mdev, uplink_follow)" and in case MLX5_CAP_GEN is calculated erroneous or mdev is other than expected, the mlx5_modify_vport_admin_state call might go wrong, too. * But since only the If clause was added, the changes are pretty minimal and therefore well traceable. [Other] * Since the patch/commit is upstream with 5.12-rc7, it will be in Impish. __ With the 5.4.0-48 update for Ubuntu 20.04, the commit "net/mlx5e: Modify uplink state on interface up/down" was integrated which contains a regression for mlx5 adapters with older adapter firmware. This is the second bugfix to repair the regression, required to operate the adapter in switchdev mode. The first part was integrated via Bug 192185 - LP1921104. This is the upstream fix required to be backported to Ubuntu 20.04: https://github.com/torvalds/linux/commit/1a73704c82ed4ee95532ac04645d02075bd1ce3d ---Additional Hardware Info--- Mellanox ConnectX network adapter ---uname output--- 5.4.0-73-generic ---Steps to Reproduce--- enable switchdev mode try to ping external host Backports need to be provide for 21.04, 20.10 and 20.04 (if not cleanly applyable)! To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/1925452/+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
[Kernel-packages] [Bug 1923515] Re: [Dell XPS 15 9500] New touchpad detected as "PS/2 Logitech Wheel Mouse"
@edholden I'm glad you pinned down the problem! I think you might want to post this on the askubuntu thread as an answer, and to the kernel bugzilla as well, and perhaps close the reports on both bugtrackers. -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1923515 Title: [Dell XPS 15 9500] New touchpad detected as "PS/2 Logitech Wheel Mouse" Status in linux package in Ubuntu: Incomplete Bug description: I've been using Ubuntu 20.04 on a Dell XPS 15 9550. The laptop's touchpad had a hardware defect common to the model (nicknamed "wobble") so Dell sent a tech to replace it. The new touchpad looks identical to the original but the kernel doesn't correctly detect it. The device does work, but appears to the kernel as a "PS/2 Logitech Wheel Mouse," which prevents the use of features like two-finger scrolling, disabling tap to click, and palm detection. A good summary of my troubleshooting steps are here: https://askubuntu.com/questions/1330555/touchpad-detected-as-ps-2-logitech-wheel-mouse-dell-xps-15-ubuntu-20-04 Importantly, I've tried a mainline kernel downloaded from Ubuntu (5.11.12 and a 5.12.0 release candidate, whereas the current version is a 5.8.0). I've also tried two bootable USB drives containing Ubuntu 20.04 and 21.04 (release candidate). Nothing has changed the device detection or behavior. The issue is identical in the default Ubuntu desktop and in Plasma. There are no touchpad settings in the UEFI BIOS. Per the touchpad detection instructions, I've attached the output of /proc/bus/input/devices, Xorg.0.log, and the `xinput --list` command. My suspicion is that Dell has ordered a brand new touchpad model for which there is no kernel driver; looking at the logs, the previous model was an elantech, but I'm not sure if the new one is as well. --- ProblemType: Bug ApportVersion: 2.20.11-0ubuntu27.16 Architecture: amd64 AudioDevicesInUse: USERPID ACCESS COMMAND /dev/snd/controlC0: edholden 1571 F pulseaudio CasperMD5CheckResult: skip CurrentDesktop: KDE DistroRelease: Ubuntu 20.04 InstallationDate: Installed on 2020-10-11 (183 days ago) InstallationMedia: Ubuntu 20.04.1 LTS "Focal Fossa" - Release amd64 (20200731) MachineType: Dell Inc. XPS 15 9500 NonfreeKernelModules: nvidia_modeset nvidia Package: linux (not installed) ProcFB: 0 i915drmfb ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-5.8.0-48-generic root=UUID=a8be5c03-8499-4474-932d-725877e9cc6c ro quiet splash vt.handoff=7 ProcVersionSignature: Ubuntu 5.8.0-48.54~20.04.1-generic 5.8.18 RelatedPackageVersions: linux-restricted-modules-5.8.0-48-generic N/A linux-backports-modules-5.8.0-48-generic N/A linux-firmware1.187.10 Tags: focal Uname: Linux 5.8.0-48-generic x86_64 UpgradeStatus: No upgrade log present (probably fresh install) UserGroups: adm cdrom dip lpadmin lxd plugdev sambashare sudo _MarkForUpload: True dmi.bios.date: 12/24/2020 dmi.bios.release: 1.6 dmi.bios.vendor: Dell Inc. dmi.bios.version: 1.6.1 dmi.board.name: 0RDX6T dmi.board.vendor: Dell Inc. dmi.board.version: A00 dmi.chassis.type: 10 dmi.chassis.vendor: Dell Inc. dmi.modalias: dmi:bvnDellInc.:bvr1.6.1:bd12/24/2020:br1.6:svnDellInc.:pnXPS159500:pvr:rvnDellInc.:rn0RDX6T:rvrA00:cvnDellInc.:ct10:cvr: dmi.product.family: XPS dmi.product.name: XPS 15 9500 dmi.product.sku: 097D dmi.sys.vendor: Dell Inc. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1923515/+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
[Kernel-packages] [Bug 1925452] Re: [Ubuntu 21.04] net/mlx5: Fix HW spec violation configuring uplink
Kernel SRU request submitted for hirsute, groovy and focal: https://lists.ubuntu.com/archives/kernel-team/2021-April/thread.html#119562 changing status to 'In Progress'. -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1925452 Title: [Ubuntu 21.04] net/mlx5: Fix HW spec violation configuring uplink Status in Ubuntu on IBM z Systems: Triaged Status in linux package in Ubuntu: In Progress Status in linux source package in Focal: New Status in linux source package in Groovy: New Status in linux source package in Hirsute: In Progress Bug description: SRU Justification: == [Impact] * In addition to 9c9be85f6b59 "net/mlx5e: Add missing capability check for uplink follow" (handled in LP#1921104) another fix 1a73704c82ed "Fix HW spec violation configuring uplink" (handled in this bug, LP#1925452) is needed to fix issues that were introduced with commit 7d0314b11cdd "net/mlx5e: Modify uplink state on interface up/down". * Commit 1a73704c82ed "Fix HW spec violation configuring uplink" fixes a regression for mlx5 adapters required to operate in switchdev mode. * This fix makes sure that the uplink port is modified to follow only if the uplink_follow capability if it's set as required by the hw specification. * Failure cause traffic to the uplink representer net device to cease after switching to switchdev mode. [Fix] * upstream fix (upstream with v5.12-rc7) 1a73704c82ed4ee95532ac04645d02075bd1ce3d 1a73704c82ed "Fix HW spec violation configuring uplink" * can be cleanly cherry picked from hirsute master-next. * a backport for groovy: https://launchpadlibrarian.net/534888680/groovy-0001-net-mlx5-Fix-HW-spec-violation-configuring-uplink.patch * a backport for focal: https://launchpadlibrarian.net/534847308/focal-0001-net-mlx5-Fix-HW-spec-violation-configuring-uplink.patch [Test Case] * Two servers, installed with Ubuntu Server 20.04 or 20.10 are needed. * Each server needs to have a Mellanox ConnectX4/5 adapter, attached to the same switch * Adapters must be running adapter firmware level 16.29.1006 or earlier. * enable SRIOV and switchdev mode on one adapter: echo 0 > /sys/bus/pci/devices/0100\:00\:00.0/sriov_drivers_autoprobe echo 0 > /sys/bus/pci/devices/0100\:00\:00.1/sriov_drivers_autoprobe echo 64 > /sys/bus/pci/devices/0100\:00\:00.0/sriov_numvfs echo 64 > /sys/bus/pci/devices/0100\:00\:00.1/sriov_numvfs devlink dev eswitch set pci/0100:00:00.0 mode switchdev devlink dev eswitch set pci/0100:00:00.1 mode switchdev * Assign an IP address to the physical function device of the adapters on both systems * IP communication will fail * With the fix, IP communication can be established. [Regression Potential] * There is always at least some potential for regression. In this case the new code can go wrong (or might become worse than before) in case the new if statement is wrong. * It checks for the condition of "MLX5_CAP_GEN(mdev, uplink_follow)" and in case MLX5_CAP_GEN is calculated erroneous or mdev is other than expected, the mlx5_modify_vport_admin_state call might go wrong, too. * But since only the If clause was added, the changes are pretty minimal and therefore well traceable. [Other] * Since the patch/commit is upstream with 5.12-rc7, it will be in Impish. __ With the 5.4.0-48 update for Ubuntu 20.04, the commit "net/mlx5e: Modify uplink state on interface up/down" was integrated which contains a regression for mlx5 adapters with older adapter firmware. This is the second bugfix to repair the regression, required to operate the adapter in switchdev mode. The first part was integrated via Bug 192185 - LP1921104. This is the upstream fix required to be backported to Ubuntu 20.04: https://github.com/torvalds/linux/commit/1a73704c82ed4ee95532ac04645d02075bd1ce3d ---Additional Hardware Info--- Mellanox ConnectX network adapter ---uname output--- 5.4.0-73-generic ---Steps to Reproduce--- enable switchdev mode try to ping external host Backports need to be provide for 21.04, 20.10 and 20.04 (if not cleanly applyable)! To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/1925452/+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
[Kernel-packages] [Bug 1926257] [NEW] Keys not working on laptop
Public bug reported: Some keys are not working in this version ProblemType: Bug DistroRelease: Ubuntu 20.10 Package: linux-image-5.8.0-50-generic 5.8.0-50.56 ProcVersionSignature: Ubuntu 5.8.0-50.56-generic 5.8.18 Uname: Linux 5.8.0-50-generic x86_64 ApportVersion: 2.20.11-0ubuntu50.5 Architecture: amd64 AudioDevicesInUse: USERPID ACCESS COMMAND /dev/snd/controlC0: shivanshu 1994 F pulseaudio /dev/snd/pcmC0D0c: shivanshu 1994 F...m pulseaudio /dev/snd/pcmC0D0p: shivanshu 1994 F...m pulseaudio /dev/snd/controlC1: shivanshu 1994 F pulseaudio CasperMD5CheckResult: skip CurrentDesktop: ubuntu:GNOME Date: Tue Apr 27 12:26:35 2021 InstallationDate: Installed on 2020-06-10 (320 days ago) InstallationMedia: Ubuntu 20.04 LTS "Focal Fossa" - Release amd64 (20200423) Lsusb: Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub Bus 001 Device 004: ID 04f2:b61e Chicony Electronics Co., Ltd Integrated Camera Bus 001 Device 003: ID 0bda:b023 Realtek Semiconductor Corp. RTL8822BE Bluetooth 4.2 Adapter Bus 001 Device 002: ID 046d:c52b Logitech, Inc. Unifying Receiver Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub MachineType: LENOVO 81EU ProcFB: 0 i915drmfb ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-5.8.0-50-generic root=UUID=86104863-1f3c-40e9-9432-c6edade6d000 ro quiet splash RelatedPackageVersions: linux-restricted-modules-5.8.0-50-generic N/A linux-backports-modules-5.8.0-50-generic N/A linux-firmware1.190.4 SourcePackage: linux UpgradeStatus: Upgraded to groovy on 2020-10-27 (181 days ago) dmi.bios.date: 11/26/2020 dmi.bios.release: 1.46 dmi.bios.vendor: LENOVO dmi.bios.version: 7PCN46WW dmi.board.asset.tag: NO Asset Tag dmi.board.name: LNVNB161216 dmi.board.vendor: LENOVO dmi.board.version: SDK0Q55722 WIN dmi.chassis.asset.tag: NO Asset Tag dmi.chassis.type: 10 dmi.chassis.vendor: LENOVO dmi.chassis.version: Lenovo ideapad 530S-14IKB dmi.ec.firmware.release: 1.46 dmi.modalias: dmi:bvnLENOVO:bvr7PCN46WW:bd11/26/2020:br1.46:efr1.46:svnLENOVO:pn81EU:pvrLenovoideapad530S-14IKB:rvnLENOVO:rnLNVNB161216:rvrSDK0Q55722WIN:cvnLENOVO:ct10:cvrLenovoideapad530S-14IKB: dmi.product.family: ideapad 530S-14IKB dmi.product.name: 81EU dmi.product.sku: LENOVO_MT_81EU_BU_idea_FM_ideapad 530S-14IKB dmi.product.version: Lenovo ideapad 530S-14IKB dmi.sys.vendor: LENOVO ** Affects: linux (Ubuntu) Importance: Undecided Status: New ** Tags: amd64 apport-bug groovy -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1926257 Title: Keys not working on laptop Status in linux package in Ubuntu: New Bug description: Some keys are not working in this version ProblemType: Bug DistroRelease: Ubuntu 20.10 Package: linux-image-5.8.0-50-generic 5.8.0-50.56 ProcVersionSignature: Ubuntu 5.8.0-50.56-generic 5.8.18 Uname: Linux 5.8.0-50-generic x86_64 ApportVersion: 2.20.11-0ubuntu50.5 Architecture: amd64 AudioDevicesInUse: USERPID ACCESS COMMAND /dev/snd/controlC0: shivanshu 1994 F pulseaudio /dev/snd/pcmC0D0c: shivanshu 1994 F...m pulseaudio /dev/snd/pcmC0D0p: shivanshu 1994 F...m pulseaudio /dev/snd/controlC1: shivanshu 1994 F pulseaudio CasperMD5CheckResult: skip CurrentDesktop: ubuntu:GNOME Date: Tue Apr 27 12:26:35 2021 InstallationDate: Installed on 2020-06-10 (320 days ago) InstallationMedia: Ubuntu 20.04 LTS "Focal Fossa" - Release amd64 (20200423) Lsusb: Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub Bus 001 Device 004: ID 04f2:b61e Chicony Electronics Co., Ltd Integrated Camera Bus 001 Device 003: ID 0bda:b023 Realtek Semiconductor Corp. RTL8822BE Bluetooth 4.2 Adapter Bus 001 Device 002: ID 046d:c52b Logitech, Inc. Unifying Receiver Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub MachineType: LENOVO 81EU ProcFB: 0 i915drmfb ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-5.8.0-50-generic root=UUID=86104863-1f3c-40e9-9432-c6edade6d000 ro quiet splash RelatedPackageVersions: linux-restricted-modules-5.8.0-50-generic N/A linux-backports-modules-5.8.0-50-generic N/A linux-firmware1.190.4 SourcePackage: linux UpgradeStatus: Upgraded to groovy on 2020-10-27 (181 days ago) dmi.bios.date: 11/26/2020 dmi.bios.release: 1.46 dmi.bios.vendor: LENOVO dmi.bios.version: 7PCN46WW dmi.board.asset.tag: NO Asset Tag dmi.board.name: LNVNB161216 dmi.board.vendor: LENOVO dmi.board.version: SDK0Q55722 WIN dmi.chassis.asset.tag: NO Asset Tag dmi.chassis.type: 10 dmi.chassis.vendor: LENOVO dmi.chassis.version: Lenovo ideapad 530S-14IKB dmi.ec.firmware.release: 1.46 dmi.modalias: dmi:bvnLENOVO:bvr7PCN46WW:bd11/26/2020:br1.46:efr1.46:svnLENOVO:pn81EU:pvrLenovoideapad530S-14IKB:rvnLENOVO:rnLNVNB161216:rvrSDK0Q55722WIN:cvnLENOVO:ct10:cvrLenovoideapad5
[Kernel-packages] [Bug 1923670] Re: CIFS DFS entries not accessible with 5.4.0-71.74-generic
Will this be fixed for non-OEM kernels in focal? It's listed as Fix Released, but I don't see a fixed version. -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1923670 Title: CIFS DFS entries not accessible with 5.4.0-71.74-generic Status in linux package in Ubuntu: Confirmed Status in linux-oem-5.10 package in Ubuntu: Confirmed Status in linux source package in Bionic: New Status in linux source package in Focal: Fix Released Status in linux-oem-5.10 source package in Focal: Fix Released Bug description: When booting 5.4.0-71-generic I can not access DFS entries anymore, with 5.4.0-70-generic this still works. Some details: fstab entry: //example.com/public /home/user/remotecifs noauto,vers=default,noserverino,users,_netdev,user=remote_user,domain=example.com 00 shell session ~$ mount /home/user/remote Password for remote_user@//example.com/public: ~$ ls /home/user/remote/dfs-folder dfs-subfolder dfs-entry ~$ ls /home/user/remote/dfs-folder/dfs-entry ls: cannot access '/home/user/remote/dfs-folder/dfs-entry': No such file or directory dmesg excerpt [ 1219.568778] CIFS: Attempting to mount //DC01.example.com/Public/dfs-folder/dfs-entry [ 1219.584975] FS-Cache: Duplicate cookie detected [ 1219.584986] FS-Cache: O-cookie c=6e995395 [p=f4725c61 fl=222 nc=0 na=1] [ 1219.584990] FS-Cache: O-cookie d=a11c1428 n=71ab21ba [ 1219.584993] FS-Cache: O-key=[6] '5075626c6963' [ 1219.585001] FS-Cache: N-cookie c=a0608786 [p=f4725c61 fl=2 nc=0 na=1] [ 1219.585004] FS-Cache: N-cookie d=a11c1428 n=901f6a53 [ 1219.585007] FS-Cache: N-key=[6] '5075626c6963' [ 1219.725834] FS-Cache: Duplicate cookie detected [ 1219.725847] FS-Cache: O-cookie c=6e995395 [p=f4725c61 fl=222 nc=0 na=1] [ 1219.725851] FS-Cache: O-cookie d=a11c1428 n=71ab21ba [ 1219.725854] FS-Cache: O-key=[6] '5075626c6963' [ 1219.725864] FS-Cache: N-cookie c=0509709f [p=f4725c61 fl=2 nc=0 na=1] [ 1219.725868] FS-Cache: N-cookie d=a11c1428 n=556f158b [ 1219.725870] FS-Cache: N-key=[6] '5075626c6963' [ 1220.216524] CIFS VFS: cifs_read_super: get root inode failed The dmesg from 5.4.0-70-generic does not have the line CIFS VFS: cifs_read_super: get root inode failed ~$ lsb_release -rd Description:KDE neon User Edition 5.21 Release: ~$ lsb_release -rd Description:KDE neon User Edition 5.21 Release:20.04 20.04 ~$ apt-cache policy linux-image-generic linux-image-generic: Installed: 5.4.0.71.74 Candidate: 5.4.0.71.74 Version table: *** 5.4.0.71.74 500 500 http://de.archive.ubuntu.com/ubuntu focal-updates/main amd64 Packages 500 http://security.ubuntu.com/ubuntu focal-security/main amd64 Packages 100 /var/lib/dpkg/status 5.4.0.26.32 500 500 http://de.archive.ubuntu.com/ubuntu focal/main amd64 Packages --- ProblemType: Bug ApportVersion: 2.20.11-0ubuntu27.16 Architecture: amd64 AudioDevicesInUse: USERPID ACCESS COMMAND /dev/snd/controlC2: dirk 2946 F pulseaudio /dev/snd/controlC1: dirk 2946 F pulseaudio /dev/snd/controlC0: dirk 2946 F pulseaudio CasperMD5CheckResult: skip CurrentDesktop: KDE DistroRelease: KDE neon 20.04 InstallationDate: Installed on 2017-07-27 (1356 days ago) InstallationMedia: neon userlts "Xenial" - Build amd64 LIVE Binary 20170614-00:52 MachineType: LENOVO 20HMS00T00 Package: linux (not installed) ProcFB: 0 i915drmfb ProcKernelCmdLine: BOOT_IMAGE=/vmlinuz-5.4.0-71-generic root=/dev/mapper/vg00-lv_root ro intel_iommu=off ProcVersionSignature: Ubuntu 5.4.0-71.79-generic 5.4.101 RelatedPackageVersions: linux-restricted-modules-5.4.0-71-generic N/A linux-backports-modules-5.4.0-71-generic N/A linux-firmware1.187.10 Tags: focal Uname: Linux 5.4.0-71-generic x86_64 UnreportableReason: In diesem Bericht geht es um ein Paket, welches nicht installiert ist. UpgradeStatus: Upgraded to focal on 2020-11-22 (142 days ago) UserGroups: adm cdrom davfs2 dialout dip kvm libvirt lpadmin plugdev roccat sambashare scanner sudo vboxusers _MarkForUpload: False dmi.bios.date: 04/20/2020 dmi.bios.vendor: LENOVO dmi.bios.version: R0IET61W (1.39 ) dmi.board.asset.tag: Not Available dmi.board.name: 20HMS00T00 dmi.board.vendor: LENOVO dmi.board.version: Not Defined dmi.chassis.asset.tag: No Asset Information dmi.chassis.type: 10 dmi.chassis.vendor: LENOVO dmi.chassis.version: None dmi.modalias: dmi:bvnLENOVO:bvrR0IET61W(1.39):bd04/20/2020:svnLENOVO:pn20HMS00T00:pvrThinkPadX270:rvnLENOVO:rn20HMS00T00:rvrNotDefined:cvnLENOVO:ct10:cvrNone: dmi.product.family: ThinkPad X270 dmi.pro
